En nyttig DNS historie forklarer både hensigt og observation. Skiftbilletten siger, hvad en operatør har tænkt sig at offentliggøre. Et autoritativt svar viser, hvad en forespurgt server returnerede på et bestemt tidspunkt. Et rekursivt svar viser, hvad den resolver returnerede, muligvis fra cache. Behold alle tre, når du rekonstruerer en autentificeringshændelse; ingen alene fortæller hele historien.
Optag det nøjagtige objekt og kilde
For hver observation behold UTC-tid, forespurgt ejernavn, type, serveradresse, transport, svarkode, relevante flag, TTL og fuldt svar. Bevar rå output eller ledningsdata samt en normaliseret visning. Registrer, om observationen kom fra en autoritativ server, en rekursiv resolver eller en kontrolpaneleksport. RFC 1034 forklarer autoritet og caching sondring.
For en politikændring skal du beholde de tidligere og tilsigtede værdier, godkender, forretningsgrund, berørte afsendere og tilbagerulningsbetingelser. Et senere skærmbillede kan ikke bevise den tidligere DNS tilstand. Hvis historien ikke blev fanget, så sig det. Passive observationer eller rapportmetadata kan give spor, men bør ikke præsenteres som en komplet autoritativ ændringslog.
Bevar semantikken, når du sammenligner poster
Normaliser omhyggeligt. DNS navne skelner mellem store og små bogstaver, men en vilkårlig transformation af alt TXT indhold kan skade beviser. TXT RDATA kan indeholde flere tegnstrenge; præsentationscitat er ikke det samme som flere uafhængige ressourceposter. Bevar den oprindelige struktur og sammenlign den applikationsbetydende værdi separat. For SPF, er flere politikregistreringer et semantisk problem, ikke harmløs formatering.
Adskil en politikværdiændring fra en TTL-ændring, en delegationsændring og en resolver-cache-overgang. Negative svar kan fortsætte i henhold til negative caching-regler i RFC 2308. En ny autoritativ værdi fastslår ikke, at enhver modtager straks brugte den. Undgå at udlede en universel udbredelsestid fra et vellykket opslag.
Læs to observationer uden at opfinde et redigeringstidspunkt
Antag, at en autoriseret autoritativ forespørgsel kl. 10:00 viser en gammel politik. 10:05 returnerer den samme myndighed den nye politik, mens en rekursiv resolver stadig returnerer den gamle værdi med en resterende cachelevetid. Begge observationer kan være nøjagtige for deres respektive kilder. Ingen af dem fastslår, at alle andre servere eller modtagere har den nye værdi.
Dette er en hypotetisk tidslinje, ikke bevarede pakker eller et udført DNS laboratorium. Hvis udbyderens revisionshændelse ikke er tilgængelig, er det nøjagtige mutationsøjeblikk ukendt. Under den erklærede antagelse om en enkelt overgang hos den adspurgte myndighed, var observationerne bundet, når denne myndigheds synlige svar ændrede sig; de beviser ikke den præcise udgivelsestid eller global konvergens. Optag den manglende revisionsbegivenhed i stedet for at udfylde den med et gættet tidsstempel.
Forbind historik til meddelelsesbevis
Når du gennemgår en fejl, skal du justere meddelelsestidsstempler, DNS observationer, signeringsvælgere, køforsinkelser og rapportere observationsintervaller. RFC 9990 giver samlet rapporteringskontekst, men en rapport er ikke en transaktionslog for DNS redigeringer. Et godkendelsesresultat beskriver en evaluering; det afslører muligvis ikke det nøjagtige indhold i resolver-cache, der forårsagede det.
Opbevar beviserne under en godkendt adgangs- og opbevaringspolitik. Hashes hjælper med at opdage ændrede bytes, men et usigneret lokalt manifest er ikke manipulationssikker herkomst. Hold kilde- og samlingskontekst med fordøjelsen. Gør mellemrum eksplicit, herunder manglende udsigtspunkter eller uregistrerede perioder. Målet er en forsvarlig rekonstruktion og en sikrere næste ændring, ikke falsk sikkerhed om enhver modtagers synspunkt.