En DNS monitor som kun sjekker om domenet løser seg, kan gå glipp av en slettet DKIM velger eller en ødelagt SPF avhengighet. Start fra postene som ekte poststier bruker. Tilgjengelighetsovervåking bør rapportere hva som ble spurt om, hvorfra og hvilken forventet eiendom som sviktet, ikke bare at DNS er usunn.
Bygg en eksplisitt målbeholdning
Referanser: RFC 6376 §3.1, RFC 7208 §4.4.
List opp forfatterdomener, konvoluttdomener, aktive velgere og policynavn som brukes av hver sendetjeneste. Inkluder avhengigheter nådd gjennom aliaser og SPF mekanismer. Legg til transportpolicynavn når du overvåker mottakssikkerhet. Vanlige DNS spørringer kan ikke oppdage hver velger, så hent det aktive settet fra tjenestekonfigurasjon og representativ signerte meldinger.
For hvert mål, posteier, type, forventet form eller godkjent verdi, ansvarlig eier og endringsvindu. Unngå å anta at hver verdi må forbli byte-identisk for alltid: en planlagt nøkkelrotasjon endrer data legitimt. Versjon forventede verdier og skille en ikke-godkjent endring fra en godkjent overgang.
Undersøke autoritet og rekursjon hver for seg
Referanser: RFC 1035 §4.1.1, RFC 2308 §2.2, RFC 4035 §5.5.
Et direkte autoritativt søk hjelper til med å fastslå hva sonen tjener. En rekursiv spørring representerer én løsers effektive visning, inkludert cacher og valideringsatferd. Behold spørretid, serveradresse, svarkode, flagg, svarposter og TTL-kontekst for begge. Bruk flere relevante utsiktspunkter der tjenesten krever dem, uten å hevde at noen få sonder dekker hver mottaker.
Skill NXDOMAIN , et eksisterende navn uten forespurt type, SERVFAIL , timeout og et vellykket, men feil svar. EN DNSSEC problem kan gi feil ved en validerende løser selv når en autoritativ server returnerer posten. Et autoritativt svarflagg er ikke bevis på at svaret ble kryptografisk validert.
Varsle om avgjørelsen som følger
En manglende aktiv velger trenger en annen respons enn et kort tidsavbrudd på én skjerm. Grupperelaterte avhengighetsfeil slik at én utilgjengelig autoritet ikke oppretter hundrevis av urelaterte billetter. Bruk fortløpende observasjoner og uavhengige stier for å redusere støy, samtidig som du bevarer tiden for første feil og rå resultater. Terskler er lokale driftsvalg, ikke universelle DNS protokollkrav.
Ikke skift ut poster automatisk eller deaktiver håndheving bare fordi en sonde mislykkes. Finn først ut om monitoren spurte om riktig navn og gjeldende autoritet. Send funnet til journaleieren med den berørte tjenesten, siste god observasjon og bevis på nøyaktig endring eller responstilstand.
Gjengi tre distinkte observasjoner
Den lokale armaturen klassifiserer en forventet velgermarkør returnert med NOERROR som tilstede, et NXDOMAIN svar som navn mangler, og et SERVFAIL svar som oppløsningsfeil. Det viser da at NOERROR med en annen markør er et innholdsmisforhold i stedet for et avbrudd. Markørene er syntetiske og er det ikke DKIM nøkler.
Kjør det inkluderte skriptet for å reprodusere klassifiseringen. Den bruker armaturobjekter i stedet for å sende pakker. For å validere en utplassert monitor, forespør en isolert autorisert sone med de samme tilfellene og behold faktiske ledningssvar, tidsavbruddsmålinger og varslingsleveringsbevis. Disse live-testene ble ikke utført her.
Lukk overvåkingssløyfen
Referanser: RFC 2308 §5, RFC 6376 §6.
Etter reparasjon, sammenligne alle testede autoritative endepunkter, og observer deretter rekursiv gjenoppretting og en representativ melding når autorisert. Negative svar kan forbli bufret etter at posten kommer tilbake. Ikke slett hendelsen bare fordi et senere oppslag lykkes.
Gjennomgå beholdningen etter avsender onboarding, velgerrotasjon, domenemigrering og pensjonering. DNS observasjoner etablerer en forutsetning for tilgjengelighet på et tidspunkt. De kan ikke alene demonstrere en gyldig DKIM signatur, DMARC justering, postboksaksept eller innboksplassering.
Beholdt historisk trådbevis
Følgende beskriver den beholdte 7. november 2026 loopback-fangsten, inspisert, men ikke kjørt på nytt som et nettverkseksperiment for denne gjennomgangen. Kontroller av nye offline-modeller registreres separat.
Den beholdte trådfangsten registrerer faktiske UDP-spørsmål til en minimal tilbakekoblingsmyndighet. Den beholder eier, type, endepunkt, UTC-observasjonstid, spørrings- og svarbytes, flagg, TTL- og SOA-kontekst. De resulterende grenene er: NOERROR med forventede TXT midler tilstede; NOERROR uten AAAA på den eksisterende apex betyr ingen forespurte data; NXDOMAIN for absent.example .test betyr at navn mangler; SERVFAIL betyr løsningsfeil; et tilsiktet ubesvart spørsmål gir en tidsavbrudd for klienten. Serveren skripter disse svarene, men pakkene og tidsavbruddet blir faktisk observert. Dette tester beslutningstreet, ikke kommersiell monitoratferd eller varslingslevering.