[ DNS och domäner ]

DNS A- och AAAA-poster i e-posttjänstkonfiguration

Kontrollera IPv4 och IPv6 -postslutpunkter separat och förstå när adressposter påverkar routing eller SPF .

Av EmailAuth forskningsteam

[Nyckelpunkter]

  • Adresspublicering bevisar inte en fungerande SMTP slutpunkt.
  • Testa varje annonserad adressfamilj och faktisk extern källa.
  • Adressredigeringar kan påverka explicita SPF a- eller mx-beroenden.
På den här sidan

A- och AAAA-poster mappar ett värdnamn till IPv4 och IPv6 -adresser. De är beroenden av en e-posttjänst, inte deklarationer om att tjänsten är redo eller auktoriserad att skicka. Att publicera en adress kan avslöja en rutt som kunder faktiskt försöker, så verifiera varje annonserad familj och slutpunkt.

Följ namnet som används av protokollet

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

För inkommande SMTP löser du utbytesvärdnamnen som returneras av MX . Mottagardomänens webbadress är inte en ersättning när explicita utbyten är oanvändbara. Om ingen MX existerar kan SMTP :s implicita-MX-regel göra mottagardomänens egna A- eller AAAA-poster relevanta istället.

För utgående SPF, undersöka den faktiska policyn och utvärderade identiteten. En a mekanism kan auktorisera adresser som returneras för dess angivna namn; en slätt Ett rekord godkänner inte något i sig. På samma sätt, ändra ett värdnamn som används av en SPF mx mekanism kan ändra adresserna som utvärderas som auktoriserade. Spela in dessa referenser innan du behandlar en DNS adressändring som en ändring av enbart webbplats.

Behandla dubbel stack som två arbetsvägar

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

Ett värdnamn kan ha flera A-poster och flera AAAA-poster. Deras närvaro garanterar inte nåbarhet, SMTP tjänst, rätt certifikat eller motsvarande policy. En sund IPv4 ändpunkt fastställer inte att IPv6 fungerar. Omvänt bevisar inte fel på en klientsökväg att varje avsändare använder den sökvägen.

Fånga destinationsadressen som faktiskt försökte, adressfamilj, anslutningsresultat och SMTP svar. Om du undersöker utgående trafik ska du fånga den externt observerade källadressen istället för att anta att den matchar adressen som används i programmet. NAT och leverantörsutgående pooler kan göra dessa värden annorlunda.

Återskapa ett fel i adressfamiljen

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 labbet konfigurerar du IPv4 ändpunkten så att den accepterar TCP-anslutningar på port 25 och låter IPv6 ändpunkten inte nås. Förväntade DNS kontroller lyckas för båda posttyperna, medan ett familjespecifikt anslutningstest bara lyckas för IPv4 .

Fråga dig @AUTH mx.example.com . En +norecurse och sedan samma kommando med AAAA. Ersätt AUTH med den isolerade myndigheten. Spela in båda svaren. Använd din godkända labb SMTP -klient för att fästa varje destination oberoende, registrera anslutnings- och protokollresultat. Fixturen illustrerar varför DNS framgång inte är tjänstframgång; den gör inga anspråk på en viss avsändares reservtiming.

En andra fixtur ändrar endast A-adressen från 192.0.2.10 till 192.0.2.20 medan SPF -policyn är v=spf1 a:mx.example.com -all. För en IPv4 SPF utvärdering med annars framgångsrika uppslagningar, adressen som är kvalificerad att matcha a mekanismförändringar. En uttrycklig ip4:192.0.2.10 mekanismen skulle istället förbli bunden till det bokstavliga nätverket tills själva policyn ändrades.

Gör adressändringar reversibla

Referenser: RFC 8767 §4.

Inventera alla konsumenter av värdnamnet, inklusive e-postdirigering, SPF referenser, övervakning och certifikatförväntningar. Förbered slutpunkten innan du gör reklam för den. Behåll den gamla tjänsten medan lämpliga cacher fortfarande kan dirigera trafik dit, baserat på den faktiska migreringsplanen snarare än en universell väntetid.

Efter förändringen, jämför auktoritativa svar med rekursiva observationer och bevis på meddelandenivå. En misslyckad IPv6 slutpunkt bör repareras eller tas bort genom en godkänd ändring, inte döljas av försvagande orelaterade autentiseringspolicyer. Stäng endast arbetet när de avsedda adresserna och driftvägarna matchar den dokumenterade servicedesignen.

Håll bevisens omfattning tydlig

För tvåfamiljsscenariot, behåll den förväntade IPv4 framgången och IPv6 misslyckandet som föreslagna labbobservationer tills de testas. Exemplet med SPF -adressändring förutsätter framgångsrika uppslagningar och den angivna policyn; den fastställer inte aktuell auktorisation för någon verklig avsändare.

[ Takeaway ]

Adresspublicering bevisar inte en fungerande SMTP slutpunkt. Testa varje annonserad adressfamilj och faktisk extern källa. Adressredigeringar kan påverka explicita SPF a- eller mx-beroenden.

[Efter roll]

Vad detta betyder för dig

Välj din roll för praktiska nästa steg.

IT / Mail Admin

Testa alla annonserade adresser

Framgångsrik DNS upplösning och en fungerande SMTP slutpunkt är olika observationer.

Nästa steg

  1. Fråga A och AAAA oberoende.
  2. Testa varje annonserad SMTP slutpunkt.
  3. Lager SPF beroenden före adressredigeringar.

CISO / SecOps

Granska indirekta adressbehörigheter

En ändring av ett delat värdnamn kan ändra SPF beteendet när policyn refererar till det namnet.

Nästa steg

  1. Granska oprövad IPv6 exponering.
  2. Verifiera externt observerade utgående identiteter.
  3. Håll transport- och autentiseringsresultat åtskilda.

Grundare / Icke-teknisk

Äger båda nätverksfamiljerna

Att annonsera IPv6 skapar ett driftberoende vid sidan av den välbekanta IPv4 tjänsten.

Nästa steg

  1. Finansiera båda annonserade nätverksvägarna.
  2. Tilldela äganderätt för delade värdnamn.
  3. Kräv bevis för migrationsacceptans.

[ Vanliga frågor ]

Vanliga frågor

Vad lagrar A?

En IPv4 -adress.

RFC 1035 §3.4.1

Vad lagrar AAAA?

En IPv6 -adress.

RFC 3596 §2.1

Bevisar AAAA att IPv6 SMTP fungerar?

Nej. Testa nåbarhet och SMTP beteende oberoende.

Kan flera adresser returneras?

Ja. Kontrollera varje annonserad adress snarare än bara den första.

RFC 3596 §2.3

Ändrar en A-redigering SPF ?

Det kan när den utvärderade SPF policyn refererar till det namnet genom en adressberoende mekanism.

RFC 7208 §5.3 RFC 7208 §5.4

Ska jag inspektera apex A för inkommande post?

Börja med MX målen när explicit MX finns; spetsen kan ha betydelse under implicit-MX fallback.

RFC 5321 §5.1

Är den privata serverns IP den sändande IP:n?

Inte nödvändigtvis. Anteckna den offentliga källadressen som observeras på den faktiska utgående sökvägen.

Bevisar en anslutning leverans av inkorgen?

Nej. Anslutning, SMTP acceptans och slutlig postlådeplacering är separata observationer.

RFC 5321 §4.2.5

[ Källor ]

Källor

  1. RFC 7208

    Avsnitt §5.3 · §5.4

  2. RFC 1035

    Avsnitt §3.4.1

  3. RFC 5321

    Avsnitt §4.2.5 · §5.1

  4. RFC 8767

    Avsnitt §4

  5. RFC 3596

    Avsnitt §2.1 · §2.3

  6. ISC BIND grävreferens

    Avsnitt Syntax, -x omvänd lookup, norecurse-frågealternativ

[ Ordlista ]

Ordlista

AAAA rekord
En DNS post som innehåller en IPv6 -adress.

RFC 3596 §2.1

Adressberoende SPF
SPF mekanismer som a och mx använder DNS adressdata under utvärdering snarare än enbart en fast bokstavlig IP-policy.

RFC 7208 §5.3 RFC 7208 §5.4

Företagets härkomst

Varför toppfinansiella institutioner och regeringar avvecklat sina instrumentpaneler för e-postsäkerhet.

Traditionella plattformar för e-postautentisering säljer dig en instrumentpanel och ber dina ingenjörer att göra jobbet. I miljöer med hög insats innebär manuell övervakning försenad tillämpning, konfigurationsdrift och oövervakade skuggdomäner.

EmailAuth är den agentiska e-postplattformen. Våra agenter verkställer p=reject, håll avsändare från tredje part i linje och flytta dina domäner till fulla RFC 9989 överensstämmelse, den nya DMARC standarden, med auditerbarhet för människor i slingan.

regeringar Stora företag Tier-1 finansiella institutioner

SaaS · Dedikerad hyresavtal · Air-gapped on-prem · BYOK-kryptering

Kunskapsbas