[ Regionala krav ]

Mät DNS distribution utan att göra anspråk på att det bevisar överensstämmelse på meddelandenivå

Mät exakta DNS -distributionsegenskaper med bevarade frågebevis, utan att behandla postnärvaro som efterlevnad på meddelandenivå.

Av EmailAuth forskningsteam · 8 min läsning

[Nyckelpunkter]

  • Definiera domänenheten och den uppmätta egenskapen innan du frågar.
  • Behåll auktoritativa, rekursiva och felbevis separat.
  • Publicering fastställer inte faktisk avsändarjustering eller leverans.
På den här sidan

Definiera distribution som en observerbar DNS egenskap

En DNS distributionsstudie kan fastställa att en viss post observerades vid ett visst ägarnamn och tidpunkt. Den kan i sig inte fastställa att varje meddelande från organisationen har autentiserats, att mottagare tillämpat samma policy eller att en affärsbegäran var legitim. Studien bör definiera dess uppmätta egenskap innan data samlas in: postnärvaro, syntaktisk giltighet, tillämplig policyupptäckt och efterlevnad av operativa meddelanden är olika resultat.

RFC 1035 definierar DNS meddelande- och poststrukturer. RFC 9989 definierar DMARC upptäckt och inriktning beteende. Dessa standarder stödjer en reproducerbar mätmetod, inte ett påstående om att en skanning har utförts. Det här manuskriptet innehåller inga domänobservationer, adoptionsprocenter eller indikerade meddelanderesultat.

Välj enhet och population innan du frågar

Ange om studien räknar registrerade domäner, fullständigt kvalificerade namn, avsändande identiteter eller kundorganisationer. Dessa enheter är inte utbytbara. En organisation kan driva många domäner, medan en domän kan vara värd för flera oberoende sändningsarbetsflöden. En lista med webbplatsnamn är inte automatiskt en lista över domäner som skickar e-post. Anteckna hur urvalet valdes och vad urvalet utesluter.

Frys indatalistan med en versionsidentifierare och en bibehållen hash. Definiera hantering av dubbletter, internationaliserade namn, avslutande punkter, alias och förändringar i ägande eller status. Ta inte tyst bort svåra namn efter att ha sett deras resultat. Om populationen är ett bekvämlighetsurval, beskriv det så istället för att presentera det som representativt för alla e-postdomäner. Ingen befolkningslista skapades eller frågades efter detta utkast.

Skilj observation med exakt namn från upptäckt

En exakt TXT -sökning svarar på en snävare fråga än att fastställa en tillämplig DMARC -policy. Under RFC 9989, kan upptäcktsprocessen involvera en DNS Tree Walk. En metod som bara frågar efter ett förväntat ägarnamn bör märka dess resultat med exakt namn, inte fullständig DMARC distribution. Behåll algoritmen och standardversionen som används så att en annan analytiker kan förstå vad ett negativt resultat betyder.

SPF har sin egen identitet och postvalsregler i RFC 7208. Att leta efter en policy på en webbplatsdomän bevisar inte att det är det MAIL FRÅN identitet som används av organisationens meddelanden. En DNS-studie kan beskriva publicering vid utvalda namn, men den får inte uppfinna sändningsidentiteter eller ersätta varumärkesnamn för observerad SMTP kontext.

Behåll auktoritativa och rekursiva bevis separat

För varje auktoriserad observation, registrera exakt ägare, typ, klass, server eller resolver, tid och svarsstatus. Auktoritativa svar beskriver den tillfrågade myndighetens svar; rekursiva svar kan återspegla cachad data och resolverns egen bearbetning. Om båda är insamlade, bevara båda istället för att välja svaret som passar det förväntade resultatet. Deras oenighet kan vara analytiskt viktig.

Dokumentera hur auktoritativa servrar upptäcks och hur metoden hanterar inkonsekventa svar över dem. Registrera eventuella misslyckanden i sökvägen i stället för att märka att de saknar den slutliga policyn. En rekursiv TTL kan återspegla återstående cachelivslängd, så den bör inte rapporteras som den ursprungliga konfigurerade TTL utan bevis. Studien bör bevara råa transkriptioner tillsammans med normaliserade fält för att stödja senare granskning.

Bevara postgränser och felkategorier

TXT RDATA kan innehålla flera teckensträngar inom en post. Det skiljer sig från flera TXT resursposter hos samma ägare. En mätparser bör bevara dessa gränser innan protokollspecifikt urval tillämpas. Orelaterade TXT data kan samexistera med autentiseringsposter; det bör inte blåsa upp en policyräkning eller slås samman till ett giltigt påstående.

Distinguish name error, ett framgångsrikt svar utan begärd data, serverfel, timeout, ogiltig syntax och tvetydiga relevanta poster. Dessa kategorier bör inte alla bli saknade distributioner. Resultattabellen ska behålla det ursprungliga svaret och regeln som används för att tilldela en kategori. Om metoden försöker igen, fördefiniera försöksschemat och den slutliga klassificeringen så att tillfälliga misslyckanden inte hanteras annorlunda beroende på önskat resultat.

Håll DNSSEC bevis inom sitt eget område

RFC 4033 särskiljer säkra, osäkra, falska och obestämda valideringstillstånd. Ett rekord kan vara närvarande utan en säkert validerad kedja. Ett valideringsfel kan också hindra en resolver från att returnera användbar data. Om studien mäter DNSSECmåste den dokumentera förtroendeankare och resolverkontext snarare än att anta att någon synlig post är autentiserad.

Gör inte DNSSEC status till en dold uteslutning som ändrar urvalsnämnaren. Rapportera hur många namn som bedömdes, vilka tillstånd som observerades och vilka som inte kunde fastställas, med hjälp av faktiska bevis när de samlades in. Detta utkast innehåller inga sådana räkningar. Poängen med metoden är att bevara osäkerhet, inte att förvandla otillgänglig data till ett bekvämt distributionsresultat.

Separera publicering från efterlevnad på meddelandenivå

En publicerad SPF policy visar inte vilken IP-adress som skickade ett riktigt meddelande. A DKIM nyckel visar inte att en leverantör undertecknat ett visst meddelande eller behållit motsvarande privata nyckel på ett säkert sätt. En DMARC policy visar inte att alla legitima strömmar stämmer överens. Dessa frågor kräver operativa bevis från den faktiska rutten och en pålitlig mottagare.

RFC 8601 förklarar förtroendegränsen för Authentication-Results. Ett matchande prov av mottagna meddelanden kan stödja en observation på meddelandenivå med omfattning, men det validerar inte automatiskt varje domän eller arbetsflöde i en DNS studie. Behåll publikationsmått och meddelandemått som separata mått med sina egna populationer och begränsningar. Märk inte om en DNS antagandeprocent som överensstämmelse eller uppnått skydd.

Ett reproducerbart observationsarbetsblad

Skapa ett kalkylblad med exempelversion, domänenhet, normaliserad indata, exakt frågad ägare, posttyp, frågemetod, observationstid, auktoritativ transkription, rekursiv transkription och parserversion. Lägg till den tilldelade resultatkategorin, sökvägen för upptäckt av tillämplig policy, DNSSEC status där den bedömdes och en förklaring av fel. Behåll en länk till det råa beviset snarare än bara den slutliga klassificeringen.

Analysspecifikationen bör ange täljare och nämnare för varje måttenhet. Närvaro bland alla försök till namn, giltighet bland namn med svar och tillämplig försäkring är olika fraktioner. Om flera är användbara, rapportera dem separat. Definiera uteslutningar före analys och bevara en uteslutningslogg med skäl. Inga originalinmatningar, frågeutskrifter eller mätresultat tillhandahålls i detta manuskript.

Fiktiv diagnos: ett distributionsdiagram blir ett efterlevnadsanspråk

En fiktiv analytiker frågar efter en lista över företagswebbplatsdomäner och hittar policyutseende TXT data på några av dem. En presentation markerar resultatet av e-postautentiseringsefterlevnaden. Den föreslagna granskningen identifierar två luckor: provet fastställer inte de faktiska sändande identiteterna, och postnärvaro etablerar inte autentisering på meddelandenivå. Diagrammet bör bytas om för att beskriva den observerade DNS egenskapen och dess exempel.

En senare auktoriserad studie skulle kunna lägga till avsändarinventeringar och mottagna meddelandebevis, men det skulle behöva en ny metrisk definition snarare än att tyst uppgradera det ursprungliga påståendet. Det här exemplet innehåller inga riktiga domäner, räkningar eller skanningar. Det illustrerar ett rapporteringsfel i en hypotetisk metod, inte ett resultat om en organisation eller en genomförd implementeringsstudie.

Släpp metoden med dess bevisgränser

En användbar studieslutsats anger populationen, observationsdatum, frågealgoritm, resultatkategorier och vad bevisen inte kan fastställa. Det undviker påståenden om universellt mottagarbeteende, inkorgsleverans eller förhindrat bedrägeri. En transparent DNS -mätning förblir värdefull just för att dess omfattning är tydlig.

Katalogen kräver tidsstämplade auktoritativa och rekursiva svar med exakta ägarnamn och posttyper. Dessa originalutskrifter förblir öppna. Mänsklig specialistgranskning, källans tillämplighet, produktionsvägar, tillgänglighet och ägarefrisläppande förblir också öppna. Detta utkast är en föreslagen mätmetod, inte en utförd skanning eller ett resultat av meddelandeefterlevnad.

[ Takeaway ]

Rapportera den faktiska observerade DNS egenskapen och håll anspråk på meddelandenivå utanför dess bevisgräns.

[Efter roll]

Vad detta betyder för dig

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

Studiedesigner

Definiera provet

Webbplatsnamn och avsändande identiteter är olika populationer.

Nästa steg

  1. Frys ingångsmedlemskap.
  2. Statliga urvals- och uteslutningsgränser.

DNS analytiker

Bevara härkomsten

Enbart ett normaliserat värde kan inte förklara oenighet.

Nästa steg

  1. Behåll råa svar och tider.
  2. Håll auktoritativa och rekursiva observationer åtskilda.

Rapportgranskare

Bundet slutsatsen

Implementeringsbevis är inte universell efterlevnad.

Nästa steg

  1. Kontrollera varje nämnare.
  2. Separat meddelande- och DNS statistik.

[ Vanliga frågor ]

Vanliga frågor

Bevisar ett policydokument att varje meddelande överensstämmer?

Nej. Faktiska sändande identiteter och betrodda mottagareobservationer är separata bevis.

RFC 9989: DMARC

Är en exakt _dmarc sökning fullständig upptäckt?

Inte nödvändigtvis. RFC 9989 definierar en upptäcktsprocess inklusive DNS Tree Walk-beteende.

RFC 9989: DMARC

Kan en webbplatslista representera alla sändande domäner?

Inte av antagande. Provet och dess relation till SMTP identiteter måste dokumenteras.

RFC 7208 : Framework för avsändarpolicy

Varför behålla auktoritativa och rekursiva svar?

De kan skilja sig åt i källa, timing och cacheläge; bevara båda sammanhangen.

RFC 1035 : Implementering och specifikation av domännamn

Är alla tomma resultat frånvaro av implementering?

Nej. Namnfel, inga data, timeout och serverfel behöver separata kategorier.

RFC 1035 : Implementering och specifikation av domännamn

Bevisar synliga data DNSSEC validering?

Nej. Säkra, osäkra, falska och obestämda tillstånd kräver sin egen valideringskontext.

RFC 4033 : DNS säkerhetsintroduktion och krav

Skannades domäner?

Nej. Detta är en föreslagen metod utan ursprungliga DNS observationer.

Vilka bevis är fortfarande öppna?

Tidsstämplade auktoritativa och rekursiva svar med exakta ägare och posttyper har inte samlats in.

[ Källor ]

Källor

  1. RFC 1035 : Implementering och specifikation av domännamn

    Avsnitt §3.3.14 TXT RDATA-format · §4.1 Format · §5.1 Format

  2. RFC 9989: DMARC

    Avsnitt §4.7 DMARC -policypostformat · §4.8 Formell definition · §4.10 DNS Tree Walk · §5.3.2 Bestäm om DMARC mekanismen är tillämplig · §4.4 Identifieringsjustering förklaras · A.6 Borttagning av pct-taggen

  3. RFC 8601: Authentication-Results

    Avsnitt §1.2 Förtroendegräns · §7. Säkerhetsöverväganden

  4. RFC 7208 : Framework för avsändarpolicy

    Avsnitt §2.4 POST FRÅN Identitet · §3.2 Flera DNS poster · §4.5 Välja poster · §4.6.4 DNS sökningsgränser · §5.2 inkluderar · §6.1 omdirigering · §8 Resultathantering

  5. RFC 4033 : DNS säkerhetsintroduktion och krav

    Avsnitt §5 Omfattningen av DNSSEC Document Set och Last Hop Issues · §6 Resolver-överväganden · §7 Stub Resolver-överväganden

[ Ordlista ]

Ordlista

Implementeringsegenskap
Det explicit definierade DNS tillståndet som mäts, såsom postnärvaro eller giltig tillämplig policy.
Exempelversion
Den frusna populationen och normaliseringsreglerna för en mätkörning.
Observationsproveniens
Källan, frågekontext och tid som stöder ett DNS fynd.

RFC 1035 : Implementering och specifikation av domännamn

Gräns ​​för meddelandeefterlevnad
Gränsen som skiljer DNS -publiceringsbevis från faktiska meddelandeautentiseringsresultat.

RFC 9989: DMARC

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