Feil VPN-DNS? En autoritativ server kan være utdatert

Koble til VPN og ett vertsnavn slås opp til gårsdagens adresse, eller til ingenting. Koble fra og det virker igjen. Refleksen er å skylde på resolvern tunnelen pushet, men den vanligere årsaken er en publisert navneserver som sluttet å motta soneoppdateringer. Den nye veien nådde ganske enkelt en annen autoritet enn den svaret i hurtigbufferen kom fra.

Symptomet endrer seg med resolvern

En rekursiv resolver returnerer det en autoritet fortalte den, og beholder deretter svaret i TTL-en. Hvis tunnelen pusher en annen resolver, eller endrer veien slik at den gamle ikke lenger er tilgjengelig, spør klienten en annen autoritet og får et annet svar. Domenet endret seg ikke i det øyeblikket; ditt syn på det gjorde det.

Derfor kan samme navn virke på ett kontor og feile fra et hotell, og derfor hjelper det bare noen ganger å tømme en lokal hurtigbuffer. Tømming av bufferen sender spørsmålet til den samme autoriteten igjen.

Den avgjørende testen er et direkte spørsmål til hver publisert server.

Spør hver autoritet direkte

Begynn med delegasjonen, ikke med en liste du husker. Spør forelderen om NS-settet, og spør deretter hvert navn i settet om posten du trenger. To spørringer mot samme navn hos ulike autoriteter forteller deg umiddelbart om sonen er konsistent.

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

Gjør det samme for NS-postene ved sonens topp, fordi forelderdelegasjonen og sonens eget NS-sett kan være uenige etter en migrering. Serienumre på SOA er det neste som skal sammenlignes, og en sekundær som ligger langt bak er et overføringsproblem, ikke et svarsproblem.

Kjør disse spørringene fra nettverket som feiler, ikke bare fra skrivebordet ditt.

Skill tiltenkte visninger fra ødelagte

Noen domener svarer bevisst ulikt etter region eller resolvern-gruppe, og split-horizon-oppsett er normale i bedriftsnettverk.

Spørsmålet er om forskjellen er dokumentert og stabil. En utilsiktet visning ser annerledes ut: én autoritet har en post som de andre aldri fikk, eller mangler en som alle deler. RFC 2182 veiledning for valg og utrulling behandler autoritativ tilgjengelighet som et felles ansvar, og det er den riktige rammen her. Redundans finnes bare hvis hver publisert server kan svare med de tiltenkte dataene, ikke bare godta en tilkobling på port 53.

En server som svarer SERVFAIL, er lettere å diagnostisere enn en som svarer selvsikkert og feil.

En migrering avdekker hva en hurtigbuffer skjulte

Under et leverandørbytte endres to autoritative steder: forelderdelegasjonen og sonens egne NS-poster. Begge må oppdateres, og begge hurtigbufres for sine TTL-er. Hvis en gammel server blir stående og fortsetter å betjene den forrige sonen, vil klienter hvis resolvere spør den, fortsatt få det gamle svaret lenge etter at overgangen så ut til å være ferdig.

Det er nøyaktig tilstanden en langvarig hurtigbuffer skjuler. Arbeidsstasjonen som virket hele uken, snakket med en resolver som holdt et ferskt svar fra den nye autoriteten, mens den gamle fortsatte å dele ut utdaterte data til alle andre.

Å bytte resolver på en bærbar PC fikser den bærbare og ingenting annet.

Fiks sonen, ikke resolvern

Finn ut hvilke servere som skal være autoritative for sonen, rett opp den administrerte sonen eller delegasjonen slik at hver av dem leverer de tiltenkte dataene, og behold redundansen du planla. Å slette en navneserver fordi én VPN-utgang fikk et merkelig svar, reduserer tilgjengeligheten og lar inkonsistensen bli stående.

Kjør deretter de direkte spørringene på nytt fra begge nettverk og vent til TTL-en for posten du endret, løper ut.

Bekreft at svaret er stabilt fra hver autoritet, og skriv den tiltenkte visningen i sonedokumentasjonen slik at den neste forskjellen er lett å klassifisere.