[ DNS & domæner ]

DNS A- og AAAA-poster i mail-tjenestekonfiguration

Tjek IPv4 og IPv6 -mail-endepunkter separat, og forstå, hvornår adresseregistreringer påvirker routing eller SPF .

Af EmailAuth -forskningsteamet

[Nøglepunkter]

  • Adresseudgivelse beviser ikke et fungerende SMTP slutpunkt.
  • Test alle annoncerede adressefamilier og faktiske eksterne kilder.
  • Adresseredigeringer kan påvirke eksplicitte SPF a- eller mx-afhængigheder.
På denne side

A- og AAAA-poster knytter et værtsnavn til IPv4 og IPv6 -adresser. De er afhængigheder af en posttjeneste, ikke erklæringer om, at tjenesten er klar eller autoriseret til at sende. Offentliggørelse af en adresse kan afsløre en rute, som klienter faktisk prøver, så bekræft hver annonceret familie og slutpunkt.

Følg det navn, der bruges af protokollen

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

For indgående SMTP skal du løse de udvekslingsværtsnavne, der returneres af MX . Modtagerdomænets webstedsadresse er ikke en erstatning, når eksplicitte udvekslinger er ubrugelige. Hvis der ikke findes nogen MX , kan SMTP 's implicit-MX-regel gøre modtagerdomænets egne A- eller AAAA-poster relevante i stedet.

Til udgående SPF, undersøge den faktiske politik og vurderet identitet. An a mekanisme kan godkende adresser, der returneres for dets specificerede navn; en slette En rekord autoriserer ikke noget i sig selv. Tilsvarende ændring af et værtsnavn, der bruges af en SPF mx mekanisme kan ændre de adresser, der vurderes som godkendte. Registrer disse referencer, før du behandler en DNS adresseredigering som en ændring, der kun gælder for webstedet.

Behandl dobbelt stak som to driftsveje

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

Et værtsnavn kan have flere A-poster og flere AAAA-poster. Deres tilstedeværelse garanterer ikke tilgængelighed, SMTP service, det korrekte certifikat eller tilsvarende politik. Et sundt IPv4 endepunkt fastslår ikke, at IPv6 virker. Omvendt beviser fejl på én klientsti ikke, at hver afsender bruger denne sti.

Indfang destinationsadressen, der faktisk er forsøgt, adressefamilie, forbindelsesresultat og SMTP svar. Hvis du undersøger udgående trafik, skal du fange den eksternt observerede kildeadresse i stedet for at antage, at den matcher den adresse, der bruges i applikationen. NAT- og udbyderudgangspuljer kan gøre disse værdier anderledes.

Genskab en adressefamiliefejl

Syntetisk armatur: example.com. MX 10 mx.example.com.; mx.example.com. A 192.0.2.10; mx.example.com . AAAA 2001:db8::10. I laboratoriet skal du konfigurere IPv4 endepunktet til at acceptere TCP-forbindelser på port 25 og lade IPv6 endepunktet være utilgængeligt. Forventede DNS tjek lykkes for begge posttyper, mens en familiespecifik forbindelsestest kun lykkes for IPv4 .

Forespørgsel dig @AUTH mx.example.com . En +norecurse og så den samme kommando med AAAA. Udskift AUTH med den isolerede myndighed. Optag begge svar. Brug din godkendte laboratorie SMTP klient til at fastgøre hver destination uafhængigt, registrere forbindelse og protokolresultater. Armaturet illustrerer, hvorfor DNS succes ikke er servicesucces; det gør ingen påstande om en bestemt afsenderes fallback timing.

Et andet armatur ændrer kun A-adressen fra 192.0.2.10 til 192.0.2.20 mens SPF -politikken er v=spf1 a:mx.example.com -all. For en IPv4 SPF -evaluering med ellers vellykkede opslag er adressen, der er kvalificeret til at matche a mekanisme ændringer. En eksplicit ip4:192.0.2.10 mekanismen ville i stedet forblive bundet til det bogstavelige netværk, indtil selve politikken blev ændret.

Gør adresseændringer reversible

Referencer: RFC 8767 §4.

Inventar alle forbrugere af værtsnavnet, inklusive mail-routing, SPF referencer, overvågning og certifikatforventninger. Forbered slutpunktet, før du annoncerer det. Behold den gamle tjeneste, mens passende caches stadig kan dirigere trafik dertil, baseret på den faktiske migrationsplan snarere end en universel venteperiode.

Efter ændringen skal du sammenligne autoritative svar med rekursive observationer og beviser på budskabsniveau. Et mislykket IPv6 slutpunkt skal repareres eller fjernes gennem en godkendt ændring, ikke skjult af svækkende ikke-relaterede godkendelsespolitikker. Luk kun arbejdet, når de påtænkte adresser og driftsveje stemmer overens med det dokumenterede servicedesign.

Hold bevisets omfang eksplicit

For tofamiliescenariet skal du beholde den forventede IPv4 succes og IPv6 fejl som foreslåede laboratorieobservationer, indtil de testes. SPF -adresseændringseksemplet forudsætter vellykkede opslag og den angivne politik; den etablerer ikke aktuel autorisation for nogen reel afsender.

[ Takeaway ]

Adresseudgivelse beviser ikke et fungerende SMTP slutpunkt. Test alle annoncerede adressefamilier og faktiske eksterne kilder. Adresseredigeringer kan påvirke eksplicitte SPF a- eller mx-afhængigheder.

[Efter rolle]

Hvad betyder det for dig

Vælg din rolle for praktiske næste trin.

IT / Mail Admin

Test hver annoncerede adresse

Vellykket DNS opløsning og et operationelt SMTP slutpunkt er forskellige observationer.

Næste trin

  1. Forespørgsel A og AAAA uafhængigt.
  2. Test hvert annonceret SMTP slutpunkt.
  3. Beholdnings- SPF afhængigheder før adresseredigeringer.

CISO / SecOps

Gennemgå indirekte adressetilladelser

En ændring af et delt værtsnavn kan ændre SPF adfærd, når politikken refererer til dette navn.

Næste trin

  1. Gennemgå utestet IPv6 eksponering.
  2. Bekræft eksternt observerede udgående identiteter.
  3. Hold transport- og autentificeringsfund adskilt.

Grundlægger / Ikke-teknisk

Ejer begge netværksfamilier

Annoncering IPv6 skaber en driftsafhængighed sammen med den velkendte IPv4 tjeneste.

Næste trin

  1. Finansier begge annoncerede netværksstier.
  2. Tildel ejerskab til delte værtsnavne.
  3. Kræv bevis for migrationsaccept.

[ Ofte stillede spørgsmål ]

Ofte stillede spørgsmål

Hvad handler A?

En IPv4 adresse.

RFC 1035 §3.4.1

Hvad gemmer AAAA?

En IPv6 adresse.

RFC 3596 §2.1

Beviser AAAA, at IPv6 SMTP virker?

Nej. Test tilgængelighed og SMTP adfærd uafhængigt.

Kan flere adresser returneres?

Ja. Tjek hver annoncerede adresse i stedet for kun den første.

RFC 3596 §2.3

Ændrer en A-edit SPF ?

Det kan det, når den evaluerede SPF politik refererer til det navn gennem en adresseafhængig mekanisme.

RFC 7208 §5.3 RFC 7208 §5.4

Skal jeg inspicere apex A for indgående post?

Start med MX målene, når der findes eksplicit MX ; spidsen kan have betydning under implicit-MX fallback.

RFC 5321 §5.1

Er den private server IP den afsendende IP?

Ikke nødvendigvis. Registrer den offentlige kildeadresse, der er observeret på den faktiske udgående sti.

Beviser en forbindelse levering af indbakke?

Nej. Tilslutning, SMTP accept og endelig postkasseplacering er separate observationer.

RFC 5321 §4.2.5

[ Kilder ]

Kilder

  1. RFC 7208

    Afsnit §5.3 · §5.4

  2. RFC 1035

    Afsnit §3.4.1

  3. RFC 5321

    Afsnit §4.2.5 · §5.1

  4. RFC 8767

    Afsnit §4

  5. RFC 3596

    Afsnit §2.1 · §2.3

  6. ISC BIND grave reference

    Afsnit Syntaks, -x omvendt opslag, norecurse-forespørgselsindstilling

[ Ordliste ]

Ordliste

AAAA rekord
En DNS record med én IPv6 adresse.

RFC 3596 §2.1

Adresseafhængig SPF
SPF mekanismer såsom a og mx bruger DNS adressedata under evaluering i stedet for en fast, bogstavelig IP-politik alene.

RFC 7208 §5.3 RFC 7208 §5.4

Virksomhedens herkomst

Hvorfor top finansielle institutioner og regeringer pensionerede deres e-mailsikkerhedsdashboards.

Traditionelle e-mail-godkendelsesplatforme sælger dig et dashboard og beder dine ingeniører om at gøre arbejdet. I miljøer med høj indsats betyder manuel overvågning forsinket håndhævelse, konfigurationsdrift og uovervågede skyggedomæner.

EmailAuth er den agentiske e-mail-herkomstplatform. Vores agenter håndhæver p=reject, hold tredjepartsafsendere på linje og flyt dine domæner til fuld RFC 9989 compliance, den nye DMARC standard, med menneskelig auditabilitet.

regeringer Store virksomheder Tier-1 finansielle institutioner

SaaS · Dedikeret lejemål · Air-gapped on-prem · BYOK-kryptering

Vidensbase