Forkert VPN-DNS? En autoritativ server kan være forældet

Opret VPN og ét værtsnavn opløses til gårsdagens adresse eller slet ikke. Afbryd, og det virker igen. Refleksen er at bebrejde den resolver, tunnelen har skubbet ind, men den hyppigere årsag er en offentliggjort navneserver, der holdt op med at modtage zoneopdateringer. Den nye vej nåede blot en anden autoritativ server end den, din cachelagrede svar kom fra.

Symptomet ændrer sig med resolveren

En rekursiv resolver returnerer det, en autoritativ server har fortalt den, og beholder derefter svaret i TTL-perioden. Hvis tunnelen skubber en anden resolver ind eller ændrer vejen, så den gamle ikke længere kan nås, spørger klienten en anden autoritativ server og får et andet svar. Domænet ændrede sig ikke i det øjeblik; dit billede af det gjorde.

Derfor kan samme navn virke på et kontor og fejle fra et hotel, og derfor hjælper det kun nogle gange at tømme en lokal cache. Tømning af cachen sender spørgsmålet til den samme autoritative server igen.

Den afgørende test er en direkte forespørgsel til hver offentliggjort server.

Spørg hver autoritativ server direkte

Begynd ved delegationen i stedet for ved en liste, du husker. Spørg forælderen om NS-sættet, og forespørg derefter hvert navn i sættet om den post, du har brug for. To forespørgsler på samme navn hos forskellige autoritative servere viser med det samme, om zonen er konsistent.

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

Gør det samme for NS-posterne ved zonens top, fordi forældredelegationen og zonens eget NS-sæt kan være uenige efter en migrering. Serienumre på SOA er det næste, der skal sammenlignes, og en sekundær, der er langt bagud, er et overførselsproblem snarere end et svarsproblem.

Kør disse forespørgsler fra det netværk, der fejler, ikke kun fra dit skrivebord.

Skil tilsigtede visninger fra ødelagte

Nogle domæner svarer bevidst forskelligt afhængigt af region eller resolvergruppe, og split-horizon-opsætninger er normale i virksomhedsnetværk.

Spørgsmålet er, om forskellen er dokumenteret og stabil. En utilsigtet visning ser anderledes ud: én autoritativ server har en post, som de andre aldrig modtog, eller mangler en, som de alle deler. RFC 2182’s vejledning i valg og udrulning behandler autoritativ tilgængelighed som et fælles ansvar, og det er den rigtige ramme her. Redundans findes kun, hvis hver offentliggjort server kan svare med de tilsigtede data, ikke blot acceptere en forbindelse på port 53.

En server, der svarer SERVFAIL, er lettere at diagnosticere end en, der svarer selvsikkert og forkert.

En migrering afslører, hvad en cache skjulte

Under et udbytterskifte ændres to autoritative steder: forældredelegationen og zonens egne NS-poster. Begge skal opdateres, og begge cachelagres i deres TTL-perioder. Hvis en gammel server bliver oppe og fortsætter med at betjene den forrige zone, vil klienter, hvis resolvere spørger den, fortsat få det gamle svar længe efter, at overgangen så ud til at være færdig.

Det er præcis den tilstand, en langlivet cache skjuler. Arbejdsstationen, der virkede hele ugen, talte med en resolver, der holdt et friskt svar fra den nye autoritative server, mens den gamle fortsatte med at udlevere forældede data til alle andre.

At skifte resolveren på en bærbar computer retter den bærbare og intet andet.

Ret zonen, ikke resolveren

Find ud af, hvilke servere der skal være autoritative for zonen, ret den administrerede zone eller delegationen, så hver af dem leverer de tilsigtede data, og behold den redundans, du planlagde. At slette en navneserver, fordi ét VPN-udgang fik et underligt svar, reducerer tilgængeligheden og lader uoverensstemmelsen blive.

Kør derefter de direkte forespørgsler igen fra begge netværk, og vent på, at TTL udløber for den post, du ændrede.

Bekræft, at svaret er stabilt fra hver autoritativ server, og skriv den tilsigtede visning i zonens dokumentation, så den næste forskel er let at klassificere.