Klassificera DNS resultatet innan du ändrar autentisering
“DKIM rekord saknas” kan beskriva flera olika situationer: den väljare namnet finns inte, namnet har ingen användbar TXT post, ett aliasmål saknas eller så kunde upplösaren inte få något svar. De förhållandena kräver olika utredningar. Att behandla varje misslyckad sökning som frånvaro kan skicka ärendet till fel operatör och uppmuntra onödigt SPF eller DMARC förändringar.
Börja med att den exakta identiteten kontrolleras. För en DKIM signatur, konstruera frågan från dess faktiska väljare och signeringsdomän. En sökning efter förra månadens väljare säger lite om ett meddelande som signerats med månadens väljare. Spara hela svaret, inte bara en tom utmatningslåda. RFC 6376 , avsnitt 3.6.2 och 6.1.2.
Följande beslutssekvens är en föreslagen diagnostisk metod. Dess exempel använder fiktiva namn och resultat; det är inte backat upp av original levande frågeutskrifter ännu.
Gren ett: kom ett användbart DNS -svar?
En timeout innebär att klienten inte fick något svar inom sin vänteperiod. Det är inte en DNS svarskod och bevisar inte NXDOMAIN . Registrera destinationsadress, transport, timing och om andra godkända slutpunkter svarar. Ett avslag skiljer sig också från frånvaro: REFUSED säger att servern avböjde operationen. RFC 1035 , avsnitt 4.1.1.
Kontrollera trunkering och transport där bevisen pekar dit. Ett UDP-svar med TC-flaggan kan kräva ett TCP-försök, och DNS implementationer måste stödja TCP. En publicerad nyckel kan förbli otillgänglig genom en väg som bryter det utbytet. Använd en föreslagen jämförelse som t.ex dig @SERVER_IP amber._domainkey.example.com . TXT +tcp, med samma ägare och slutpunkt som den tidigare frågan. Inget kommando i den här artikeln har körts. RFC 7766 , avsnitt 5–6.
Eskalera ett transportproblem med det fångade beviset till nätverket eller DNS operatören. Att ändra postinnehåll kommer inte att reparera en oåtkomlig tjänst. Inaktivera inte säkerhetskontroller som en oförklarlig felsökningsgenväg.
Gren två: identifierar NXDOMAIN det förväntade namnet?
NXDOMAIN är namnfelssvaret. Utan något alias inblandat gäller det det efterfrågade namnet. När en CNAME är närvarande kan felet gälla det slutliga målet snarare än den ursprungliga ägaren. Läs kedjan innan du tillkännager att kundens väljare aldrig publicerades. RFC 2308 , avsnitt 2.1.
I ett fiktivt fall, amber._domainkey.example.com finns som en CNAME till amber.keys.example.net, men målet är obefintligt. Publikationen på kundsidan och målet på leverantörssidan har olika ansvar. Den föreslagna nästa åtgärden är att bekräfta det utfärdade målet med sin operatör och fråga lämpliga myndigheter. Att ta bort kundaliaset enbart för att det rekursiva svaret säger att NXDOMAIN skulle förkasta användbar konfiguration utan att lösa det faktiska saknade namnet.
Jämför även cachetillstånd. Ett auktoritativt positivt svar tillsammans med en äldre rekursiv NXDOMAIN kan indikera cachad frånvaro. Bevara det negativa svarets SOA-kontext och tidsstämpel, och undersök oenighet mellan myndigheter innan du tillskriver allt till cachning.
Gren tre: betyder NOERROR verkligen NODATA ?
NOERROR rapporterar inget DNS fel, men det garanterar inte att den begärda TXT datan finns. NODATA bestäms utifrån svarets innehåll: inget relevant svar, med myndighetskontext som skiljer det från en remiss. En SOA i myndighetssektionen eller frånvaron av hänvisnings-NS-poster hjälper till att göra den skillnaden; alias kan kräva ytterligare frågor. RFC 2308 , avsnitt 2.2.
En fiktiv amber._domainkey.example.com kan ha en Ett rekord men ingen TXT nyckel. Det är en annan reparation än ett helt frånvarande namn. Ett annat svar kan innehålla NS-poster som hänvisar klienten till en delegerad barnzon; Att stanna vid den remissen skulle felmärka en ofullständig sökning som saknad data. Håll den exakta efterfrågade typen synlig under hela beslutet.
När relevant TXT data finns, undersök dess protokollsyntax och postgränser separat. En DNS framgång garanterar inte en giltig DKIM nyckel eller SPF policy. Vid SPF -postsökningssteget skiljer RFC 7208 ingen matchande policy från DNS fel som timeout eller serverfel. Platta inte ut dessa resultat till en enda etikett för autentiseringsfel. RFC 7208 , avsnitt 4.4–4.5.
Gren fyra: undersök SERVFAIL utan att anta frånvaro
SERVFAIL indikerar att servern inte kunde bearbeta frågan framgångsrikt. Möjliga orsaker inkluderar otillgängliga auktoriteter, delegerings- eller aliasslingor och DNSSEC valideringsfel. Dess betydelse är inte "publicera en ny TXT post." Bevara all utökad felinformation, men dra inte slutledning av en unik orsak från enbart SERVFAIL . RFC 9520 , avsnitt 2.
Jämför relevanta auktoritativa servrar och den berörda rekursiva resolvern. Ett positivt direkt svar från myndigheten kan minska problemet samtidigt som skillnaderna i validering och nåbarhet lämnas olösta. RFC 9520 kräver också felcache, så ett omedelbart upprepat fel behöver inte betyda att resolvern upprepade varje uppströmsfråga. RFC 9520 , avsnitt 3.2.
Stäng grenen med bevis
Incidentposten ska identifiera meddelandeväljaren eller annan protokollidentitet, frågeägare/typ/klass, UTC-tid, serverslutpunkt, flaggor, svarskod, fullständiga sektioner och transport. Bifoga originalresultatet till det föreslagna grenbeslutet. Ange nästa ansvarig operatör och den observation som skulle motbevisa den aktuella förklaringen.
Efter korrigering upprepar du den relevanta DNS jämförelsen och testar ett kontrollerat meddelande genom den berörda vägen. Rapportera DNS tillgänglighet, autentiseringsverifiering och leverans som separata observationer. Ursprungliga frågeutskrifter, oberoende teknisk granskning och utgivningsgodkännande förblir öppna för denna dokumentärkandidat; de fiktiva beslutsexemplen kan inte ersätta dem.