En gemt DNS ændring og en fejlmeddelelse kan begge være reelle. Posten kan have nået autoritativ DNS , mens en resolver stadig har et ældre svar. Eller ændringen kan være synlig overalt, men ikke relateret til den identitet, som den afsendende applikation bruger.
Start med at identificere præcis, hvad der ændrede sig, og hvad du forventede, at ændringen ville opnå. En politikredigering, en SPF autorisation og en DKIM offentlig nøgle løse forskellige problemer. At behandle dem som udskiftelige fører til gentagne ændringer uden en årsagsforklaring.
Skriv den forventede effekt ned
Behold den tidligere værdi, den nye værdi, det nøjagtige ejernavn, posttype, tidsstempel og ansvarlig operatør. Angiv en testbar hypotese: for eksempel skal en ny DKIM nøgle lade modtageren bekræfte en signatur med et bestemt d-domæne og s vælger. Hvis tjenesten ikke signerer med disse værdier, kan DNS publiceringen ikke alene producere dette resultat.
Ændring p=reject til p=none ændrer den ønskede håndteringskontekst; det gør ikke en uafhængig identitet til en afstemt identitet. Under RFC 7208 §2.4 og RFC 7208 §4.4, udgivelse af en SPF include på example.com reparerer ikke SPF for et ikke-relateret konvolutdomæne, der bruges af leverandøren. De justering guide forklarer, hvordan man sammenligner disse identiteter.
Bestem, om den tilsigtede DNS rent faktisk tjener
Spørg de autoritative navneservere for det nøjagtige navn og type, med bevarelse af fuldstændige svar. Sammenlign den forventede rekord med alle relevante autoritative svar. Hvis den autoritative tjeneste stadig returnerer den gamle værdi, skal du undersøge editoren, zonevalg, delegering og udrulning på udbydersiden, før du venter på rekursive caches.
Når autoritative svar er enige om den nye værdi, skal du stille spørgsmål til den resolver, der bruges af dit testmiljø, og en anden relevant rekursiv resolver. Optag status og TTL samt indhold. Et cachet fravær er forskelligt fra en cachet gammel værdi: negativ caching kan bevare et tidligere NXDOMAIN eller NODATA svar i dets resterende levetid. RFC 2308 §3, RFC 2308 §4 og RFC 2308 §5.
Sænkning en rekord's TTL forkorter nu ikke retrospektivt en kopi, der allerede er cachelagret under dens tidligere levetid. Undgå et universelt løfte om, at alle DNS ændringer bliver synlige i løbet af et fast antal minutter. Kvalificerende server-forældet adfærd kan også beholde og bruge ældre data efter TTL-udløb under RFC 8767 §4. Brug observerede svar og cachebevis til at afgøre, hvornår gentestning er meningsfuld.
Test en ny besked, ikke gårsdagens header
Godkendelsesresultater registreres for en bestemt levering. En ny DNS konfiguration omskriver ikke en allerede modtaget besked. Generer en frisk kontrolleret besked gennem den berørte applikation og bevar dens tidsstempel og modtagergenererede resultater. RFC 8601 §1.2 og RFC 8601 §4.
Sammenlign det synlige Fra-domæne, SPF-evaluerede identitet og resultat og hvert relevant DKIM -signeringsdomæne, vælger og verifikationsresultat. Undersøg derefter justering under det gældende DMARC politik. Stop ikke ved et leverandørdashboard og siger, at godkendelse er aktiveret; bestemme, hvad den faktiske besked indeholder.
Hvis signeringsvælgeren adskiller sig fra den, du har offentliggjort, skal du undersøge tjenestens aktivering eller konfiguration. Hvis signaturen bekræfter for et ikke-relateret domæne, skal du undersøge dets understøttede kundetilpassede identitetsindstillinger. Hvis en signatur kun mislykkes efter en gateway, skal du sammenligne ruten før og efter denne mellemmand. Ændringer i dækket indhold kan påvirke bekræftelse under RFC 6376 §3.7, men fejl alene identificerer ikke årsagen eller beviser, hvilket hop der ændrede meddelelsen. Det er forskellige diagnoser og bør føre til forskellige ændringer.
Brug en kompakt beslutningsjournal
Dette syntetiske eksempel viser, hvorfor lagene betyder noget:
- Bemærkning: Autoritativ DKIM nøgle er ny; rekursivt opslag er gammelt; Hvad det understøtter: DNS observationer er forskellige; Næste undersøgelse: Cachelevetid og resolversti
- Observation: Begge DNS visninger er nye; besked bruger en anden vælger; Hvad det understøtter: Udgivet nøgle matcher ikke denne signatur; Næste undersøgelse: Afsenderens aktive signeringskonfiguration
- Observation: Matchende signaturpas; d domæne er ikke relateret til From; Hvad det understøtter: Signatur virker, men leverer ikke justering; Næste undersøgelse: Understøttet tilpasset afsendende identitet
- Observation: Ny direkte besked passerer; videresendt kopi mislykkes; Hvad den understøtter: Ruten påvirker overlevende godkendelse; Næste undersøgelse: Videresendelse og ændring af besked
Ingen af disse observationer alene beviser et angreb eller et afbrydelse på tværs af alle modtagere. Hold konklusionen proportional med beviserne.
Undgå at ændre politik for at skjule symptomet
Et forretningskritisk leveringsproblem kan have behov for en dokumenteret midlertidig afhjælpning. Vælg dens omfang, ejer, udløbs- og verifikationskriterier separat fra den tekniske rettelse. En politikreduktion i hele organisationen kan påvirke ikke-relateret trafik og bør ikke være refleksreaktionen på en enkelt ubekræftet applikationsfejl.
Bevar en tilbagerulningsplan for den faktiske ændring. Gendannelse af en DNS værdi kan i sig selv tage tid at blive synlig gennem caches, og gendannelse af en gammel nøgle er ikke passende, hvis denne nøgle mistænkes for kompromitteret. Identificer disse begrænsninger, før du behandler tilbagerulning som øjeblikkelig gendannelse.
Afslut med en årsagsforklaring
Registrer hvilket lag der var forkert, hvad der ændrede sig, og hvilke nye beviser bekræfter rettelsen. Hold en før-og-efter-modtaget-meddelelse-sammenligning og de relevante DNS observationer sammen. Bruge samlede rapporter at lede efter det samme mønster over efterfølgende rapporteret trafik uden at behandle dem som en realtids- eller komplet leveringslog; RFC 9990 §3.1 beskriver aggregeret rapportering.
Problemet er løst, når den tilsigtede arbejdsgang har et betroet, passerende justeret resultat, og ethvert leveringsproblem er forklaret. Indbakkeplacering forbliver en separat modtagerbeslutning. En vellykket DNS opdatering er en milepæl, ikke afslutningen på den undersøgelse.
Gør den næste beslutning eksplicit
Brug den ændrede vælgeropstilling til at beslutte, om aktiv signeringskonfiguration skal rettes i stedet for at genudgive den samme ubrugte nøgle. Inden du lukker, skal du optage en ny test gennem den berørte arbejdsgang, dens betroede modtagerresultat, nøjagtige d/s-værdier og resterende dækningsgrænser. Hvis dette bevis ikke er tilgængeligt, behold det relevante krav afventende. Ingen DNS publicering, nøgleaktivering eller leveringstest blev udført her.