[ DNS e domini ]

Record DNS A e AAAA nella configurazione del servizio di posta

Controlla separatamente gli endpoint di posta IPv4 e IPv6 e scopri quando i record di indirizzi influiscono sul routing o SPF .

A cura del team di ricerca EmailAuth

[ Punti chiave ]

  • La pubblicazione dell'indirizzo non dimostra un endpoint SMTP funzionante.
  • Testa ogni famiglia di indirizzi pubblicizzata e la fonte esterna effettiva.
  • Le modifiche agli indirizzi possono influire sulle dipendenze esplicite SPF a o mx.
In questa pagina

I record A e AAAA associano un nome host agli indirizzi IPv4 e IPv6 . Sono dipendenze di un servizio di posta, non dichiarazioni che il servizio è pronto o autorizzato a inviare. La pubblicazione di un indirizzo può esporre un percorso che i client effettivamente provano, quindi verifica ogni famiglia ed endpoint pubblicizzati.

Seguire il nome utilizzato dal protocollo

Riferimenti: RFC 5321 §5.1, RFC 7208 §5.3, RFC 7208 §5.4.

Per SMTP in entrata, risolvere i nomi host di Exchange restituiti da MX . L'indirizzo del sito web del dominio destinatario non è sostitutivo quando gli scambi espliciti sono inutilizzabili. Se non esiste alcun MX , la regola MX implicita di SMTP può invece rendere rilevanti i record A o AAAA del dominio destinatario.

Per l'uscita SPF, esaminare la politica attuale e l'identità valutata. UN a il meccanismo può autorizzare gli indirizzi restituiti per il nome specificato; una pianura Un record non autorizza nulla di per sé. Allo stesso modo, la modifica di un nome host utilizzato da un SPF mx Il meccanismo può modificare gli indirizzi valutati come autorizzati. Registra questi riferimenti prima di considerare la modifica di un indirizzo DNS come una modifica riguardante solo il sito web.

Trattare il dual stack come due percorsi operativi

Riferimenti: RFC 1035 §3.4.1, RFC 3596 §2.1, RFC 3596 §2.3.

Un nome host può avere diversi record A e diversi record AAAA. La loro presenza non garantisce la raggiungibilità, il servizio SMTP , il certificato corretto o una policy equivalente. Un endpoint IPv4 integro non stabilisce che IPv6 funzioni. Al contrario, l'errore su un percorso client non dimostra che ogni mittente utilizza quel percorso.

Cattura l'indirizzo di destinazione effettivamente tentato, la famiglia di indirizzi, l'esito della connessione e la risposta SMTP . Se si analizza il traffico in uscita, acquisire l'indirizzo di origine osservato esternamente anziché presumere che corrisponda all'indirizzo utilizzato all'interno dell'applicazione. NAT e pool di uscita del provider possono rendere questi valori diversi.

Riprodurre un errore della famiglia di indirizzi

Apparecchio sintetico: example.com. MX 10 mx.example.com.; mx.example.com. A 192.0.2.10; mx.example.com . AAAA 2001:db8::10. Nel laboratorio, configura l'endpoint IPv4 per accettare connessioni TCP sulla porta 25 e lasciare l'endpoint IPv6 irraggiungibile. I controlli DNS previsti hanno esito positivo per entrambi i tipi di record, mentre un test di connessione specifico per la famiglia ha esito positivo solo per IPv4 .

Domanda dig @AUTH mx.example.com . A +noricorso e poi lo stesso comando con AAAA. Sostituisci AUTH con l'autorità isolata. Registra entrambe le risposte. Utilizza il client SMTP del tuo laboratorio approvato per fissare ciascuna destinazione in modo indipendente, registrando la connessione e i risultati del protocollo. L'evento illustra perché il successo DNS non equivale al successo del servizio; non fa alcuna pretesa sui tempi di fallback di un particolare mittente.

Un secondo apparecchio cambia solo l'indirizzo A da 192.0.2.10 A 192.0.2.20 mentre la politica SPF lo è v=spf1 a:mx.example.com -all. Per una valutazione SPF IPv4 con ricerche altrimenti riuscite, l'indirizzo idoneo a corrispondere a a cambiamenti nel meccanismo. Un esplicito ip4:192.0.2.10 Il meccanismo rimarrebbe invece legato a quella rete letterale fino a quando la politica stessa non cambierebbe.

Rendi reversibili le modifiche all'indirizzo

Riferimenti: RFC 8767 §4.

Inventaria tutti i consumatori del nome host, inclusi routing della posta, riferimenti SPF , monitoraggio e aspettative sui certificati. Preparare l'endpoint prima di pubblicizzarlo. Conserva il vecchio servizio mentre le cache appropriate possono ancora indirizzare il traffico lì, in base al piano di migrazione effettivo piuttosto che a un periodo di attesa universale.

Dopo la modifica, confronta le risposte autorevoli con osservazioni ricorsive e prove a livello di messaggio. Un endpoint IPv6 guasto dovrebbe essere riparato o rimosso tramite una modifica approvata, non nascosto indebolendo le policy di autenticazione non correlate. Chiudere il lavoro solo quando gli indirizzi e i percorsi operativi previsti corrispondono al progetto di servizio documentato.

Mantenere esplicito l'ambito delle prove

Per lo scenario bifamiliare, mantenere il successo IPv4 previsto e il fallimento IPv6 come osservazioni di laboratorio proposte fino al momento del test. L'esempio di modifica dell'indirizzo SPF presuppone ricerche riuscite e la politica dichiarata; non stabilisce l'autorizzazione corrente per alcun mittente reale.

[ Porta via ]

La pubblicazione dell'indirizzo non dimostra un endpoint SMTP funzionante. Testa ogni famiglia di indirizzi pubblicizzata e la fonte esterna effettiva. Le modifiche agli indirizzi possono influire sulle dipendenze esplicite SPF a o mx.

[Per ruolo]

Cosa significa questo per te

Scegli il tuo ruolo per i prossimi passi pratici.

Amministratore IT/Posta

Prova ogni indirizzo pubblicizzato

La corretta risoluzione DNS e un endpoint SMTP operativo sono osservazioni diverse.

Prossimi passi

  1. Interroga A e AAAA in modo indipendente.
  2. Testare ogni endpoint SMTP annunciato.
  3. Dipendenze SPF dell'inventario prima delle modifiche agli indirizzi.

CISO/SecOps

Esaminare le autorizzazioni per gli indirizzi indiretti

Una modifica a un nome host condiviso può alterare il comportamento SPF quando la policy fa riferimento a quel nome.

Prossimi passi

  1. Esaminare l'esposizione IPv6 non testata.
  2. Verificare le identità di uscita osservate esternamente.
  3. Mantenere separati i risultati del trasporto e dell'autenticazione.

Fondatore / Non tecnico

Possiedi entrambe le famiglie di rete

La pubblicità IPv6 crea una dipendenza operativa accanto al noto servizio IPv4 .

Prossimi passi

  1. Finanzia entrambi i percorsi di rete pubblicizzati.
  2. Assegna la proprietà per i nomi host condivisi.
  3. Richiedere prova di accettazione della migrazione.

[ Domande frequenti ]

Domande frequenti

Cosa memorizza A?

Un indirizzo IPv4 .

RFC 1035 §3.4.1

Cosa memorizza AAAA?

Un indirizzo IPv6 .

RFC 3596 §2.1

AAAA dimostra che SMTP IPv6 funziona?

No. Testa la raggiungibilità e il comportamento SMTP in modo indipendente.

È possibile restituire più indirizzi?

SÌ. Controlla ogni indirizzo pubblicizzato anziché solo il primo.

RFC 3596 §2.3

Una modifica A modifica SPF ?

Può farlo quando la politica SPF valutata fa riferimento a quel nome attraverso un meccanismo dipendente dall'indirizzo.

RFC 7208 §5.3 RFC 7208 §5.4

Devo controllare l'apice A per la posta in entrata?

Inizia con i target MX quando esiste MX esplicito; l'apice può avere importanza in caso di fallback implicito-MX.

RFC 5321 §5.1

L'IP del server privato è l'IP di invio?

Non necessariamente. Registra l'indirizzo di origine pubblico osservato sul percorso in uscita effettivo.

Una connessione dimostra la consegna della posta in arrivo?

No. La connessione, l'accettazione SMTP e il posizionamento finale della casella di posta sono osservazioni separate.

RFC 5321 §4.2.5

[ Fonti ]

Fonti

  1. RFC 7208

    Sezioni §5.3 · §5.4

  2. RFC 1035

    Sezioni §3.4.1

  3. RFC 5321

    Sezioni §4.2.5 · §5.1

  4. RFC 8767

    Sezioni §4

  5. RFC 3596

    Sezioni §2.1 · §2.3

  6. Riferimento di scavo ISC BIND

    Sezioni Sintassi, -x ricerca inversa, opzione di query norecurse

[ Glossario ]

Glossario

Record AAAA
Un record DNS che contiene un indirizzo IPv6 .

RFC 3596 §2.1

SPF dipendente dall'indirizzo
I meccanismi SPF come a e mx utilizzano i dati degli indirizzi DNS durante la valutazione anziché una sola politica IP letterale fissa.

RFC 7208 §5.3 RFC 7208 §5.4

Provenienza aziendale

Perché le principali istituzioni finanziarie e i governi hanno ritirato le dashboard di sicurezza della posta elettronica.

Le tradizionali piattaforme di autenticazione e-mail ti vendono una dashboard e chiedono ai tuoi ingegneri di fare il lavoro. Negli ambienti ad alto rischio, la supervisione manuale comporta un’applicazione ritardata, deviazioni della configurazione e domini ombra non monitorati.

EmailAuth è la piattaforma di provenienza della posta elettronica degli agenti. I nostri agenti applicano p=reject, mantieni allineati i mittenti di terze parti e sposta i tuoi domini al massimo RFC 9989 conformità, il nuovo standard DMARC , con verificabilità human-in-the-loop.

Governi Grandi imprese Istituti finanziari di primo livello

SaaS · Locazione dedicata · Air-gapped on-premise · Crittografia BYOK

Base di conoscenza