[ DNS og domener ]

DNS A- og AAAA-poster i e-posttjenestekonfigurasjon

Sjekk IPv4 og IPv6 postendepunkter separat og forstå når adresseposter påvirker ruting eller SPF .

Av EmailAuth -forskningsteamet

[Nøkkelpunkter]

  • Adressepublisering beviser ikke et fungerende SMTP endepunkt.
  • Test hver annonserte adressefamilie og faktiske eksterne kilder.
  • Adresseredigeringer kan påvirke eksplisitte SPF a- eller mx-avhengigheter.
På denne siden

A- og AAAA-poster tilordner et vertsnavn til IPv4 og IPv6 -adresser. De er avhengigheter av en posttjeneste, ikke erklæringer om at tjenesten er klar eller autorisert til å sende. Å publisere en adresse kan avsløre en rute som klienter faktisk prøver, så kontroller hver annonserte familie og endepunkt.

Følg navnet som brukes av protokollen

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

For innkommende SMTP må du løse utvekslingsvertsnavnene som returneres av MX . Mottakerdomenets nettstedsadresse er ikke en erstatning når eksplisitte utvekslinger er ubrukelige. Hvis ingen MX eksisterer, kan SMTP implisitt-MX-regel gjøre mottakerdomenets egne A- eller AAAA-poster relevante i stedet.

For utgående SPF, undersøke den faktiske politikken og evaluert identitet. An a mekanismen kan autorisere adresser returnert for det angitte navnet; en slette En rekord godkjenner ikke noe i seg selv. På samme måte endrer du et vertsnavn som brukes av en SPF mx mekanismen kan endre adressene som er evaluert som autorisert. Registrer disse referansene før du behandler en DNS adresseredigering som en endring som kun gjelder for nettstedet.

Behandle dobbel stabel som to operasjonsbaner

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

Et vertsnavn kan ha flere A-poster og flere AAAA-poster. Deres tilstedeværelse garanterer ikke tilgjengelighet, SMTP tjeneste, riktig sertifikat eller tilsvarende policy. Et sunt IPv4 endepunkt fastslår ikke at IPv6 fungerer. Omvendt beviser ikke feil på én klientbane at hver avsender bruker denne banen.

Registrer destinasjonsadressen som faktisk ble forsøkt, adressefamilie, tilkoblingsutfall og SMTP svar. Hvis du undersøker utgående trafikk, fange opp den eksternt observerte kildeadressen i stedet for å anta at den samsvarer med adressen som brukes i applikasjonen. NAT og leverandørutgangspuljer kan gjøre disse verdiene forskjellige.

Gjengi en adressefamiliefeil

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, konfigurer IPv4 endepunktet til å akseptere TCP-tilkoblinger på port 25 og la IPv6 endepunktet være utilgjengelig. Forventede DNS kontroller lykkes for begge posttyper, mens en familiespesifikk tilkoblingstest bare lykkes for IPv4 .

Spørsmål dig @AUTH mx.example.com . En +norecurse og deretter samme kommando med AAAA. Erstatt AUTH med den isolerte autoriteten. Noter begge svarene. Bruk din godkjente laboratorie SMTP klient til å feste hver destinasjon uavhengig, registrere tilkoblings- og protokollutfall. Armaturet illustrerer hvorfor DNS suksess ikke er tjenestesuksess; den gjør ingen påstander om en bestemt avsenderes fallback-timing.

En annen armatur endrer bare 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 oppslag, er adressen kvalifisert til å matche a mekanismeendringer. En eksplisitt ip4:192.0.2.10 mekanismen ville i stedet forbli knyttet til det bokstavelige nettverket inntil selve policyen ble endret.

Gjør adresseendringer reversible

Referanser: RFC 8767 §4.

Inventar alle forbrukere av vertsnavnet, inkludert e-postruting, SPF referanser, overvåking og sertifikatforventninger. Forbered endepunktet før du annonserer det. Behold den gamle tjenesten mens passende cacher fortsatt kan lede trafikk dit, basert på den faktiske migrasjonsplanen i stedet for en universell venteperiode.

Etter endringen, sammenligne autoritative svar med rekursive observasjoner og bevis på meldingsnivå. Et mislykket IPv6 endepunkt bør repareres eller fjernes gjennom en godkjent endring, ikke skjult av svekke urelaterte autentiseringspolicyer. Lukk kun arbeidet når de tiltenkte adressene og driftsveiene samsvarer med det dokumenterte servicedesignet.

Hold bevisomfanget eksplisitt

For to-familiescenarioet, behold forventet IPv4 suksess og IPv6 feil som foreslåtte laboratorieobservasjoner inntil testet. Eksempelet på SPF -adresseendring forutsetter vellykkede oppslag og den angitte policyen; den etablerer ikke gjeldende autorisasjon for noen reell avsender.

[ Takeaway ]

Adressepublisering beviser ikke et fungerende SMTP endepunkt. Test hver annonserte adressefamilie og faktiske eksterne kilder. Adresseredigeringer kan påvirke eksplisitte SPF a- eller mx-avhengigheter.

[Etter rolle]

Hva dette betyr for deg

Velg din rolle for praktiske neste trinn.

IT / Mail Admin

Test hver annonserte adresse

Vellykket DNS oppløsning og et operativt SMTP endepunkt er forskjellige observasjoner.

Neste trinn

  1. Spørr A og AAAA uavhengig.
  2. Test hvert annonserte SMTP endepunkt.
  3. Inventar SPF avhengigheter før adresseredigeringer.

CISO / SecOps

Gjennomgå indirekte adressetillatelser

En endring av et delt vertsnavn kan endre SPF atferd når policyen refererer til det navnet.

Neste trinn

  1. Gjennomgå ikke-testet IPv6 eksponering.
  2. Bekreft eksternt observerte utgående identiteter.
  3. Hold transport- og autentiseringsfunn atskilt.

Grunnlegger / Ikke-teknisk

Eier begge nettverksfamiliene

Annonsering av IPv6 skaper en driftsavhengighet ved siden av den kjente IPv4 -tjenesten.

Neste trinn

  1. Finansiere begge annonserte nettverksbanene.
  2. Tildel eierskap for delte vertsnavn.
  3. Krev bevis for migrasjonsaksept.

[ Vanlige spørsmål ]

Ofte stilte spørsmål

Hva lager A?

En IPv4 adresse.

RFC 1035 §3.4.1

Hva lagrer AAAA?

En IPv6 adresse.

RFC 3596 §2.1

Beviser AAAA at IPv6 SMTP fungerer?

Nei. Test tilgjengelighet og SMTP atferd uavhengig.

Kan flere adresser returneres?

Ja. Sjekk hver annonserte adresse i stedet for bare den første.

RFC 3596 §2.3

Endrer en A-redigering SPF ?

Det kan når den evaluerte SPF policyen refererer til det navnet gjennom en adresseavhengig mekanisme.

RFC 7208 §5.3 RFC 7208 §5.4

Bør jeg inspisere apex A for innkommende post?

Start med MX målene når eksplisitt MX eksisterer; apex kan ha betydning under implisitt-MX fallback.

RFC 5321 §5.1

Er den private server-IP-en avsender-IP-en?

Ikke nødvendigvis. Registrer den offentlige kildeadressen som er observert på den faktiske utgående banen.

Beviser en tilkobling innbokslevering?

Nei. Tilkobling, SMTP aksept og endelig postboksplassering er egne observasjoner.

RFC 5321 §4.2.5

[ Kilder ]

Kilder

  1. RFC 7208

    Seksjoner §5.3 · §5.4

  2. RFC 1035

    Seksjoner §3.4.1

  3. RFC 5321

    Seksjoner §4.2.5 · §5.1

  4. RFC 8767

    Seksjoner §4

  5. RFC 3596

    Seksjoner §2.1 · §2.3

  6. ISC BIND gravereferanse

    Seksjoner Syntaks, -x omvendt oppslag, norecurse spørringsalternativ

[ Ordliste ]

Ordliste

AAAA rekord
En DNS post som inneholder én IPv6 adresse.

RFC 3596 §2.1

Adresseavhengig SPF
SPF mekanismer som a og mx bruker DNS adressedata under evaluering i stedet for en fast bokstavelig IP-policy alene.

RFC 7208 §5.3 RFC 7208 §5.4

Enterprise herkomst

Hvorfor topp finansinstitusjoner og regjeringer pensjonert e-postsikkerhetsdashboardene deres.

Tradisjonelle e-postautentiseringsplattformer selger deg et dashbord og ber ingeniørene dine gjøre jobben. I miljøer med høy innsats betyr manuell overvåking forsinket håndheving, konfigurasjonsdrift og uovervåkede skyggedomener.

EmailAuth er den agentiske e-postopprinnelsesplattformen. Våre agenter håndhever p=reject, hold tredjepartssendere på linje og flytt domenene dine til fulle RFC 9989 compliance, den nye DMARC standarden, med menneskelig-in-the-loop reviderbarhet.

Regjeringer Store bedrifter Tier-1 finansinstitusjoner

SaaS · Dedikert leieforhold · Air-gaped on-prem · BYOK-kryptering

Kunnskapsbase