DNS-ul VPN greșit? Un server autoritativ poate fi învechit
Conectați VPN-ul și un nume se rezolvă la adresa de ieri. Tunelul nu a stricat DNS-ul; un server autoritativ publicat servea date de zonă învechite tot timpul.
Conectați VPN-ul și un nume de gazdă se rezolvă la adresa de ieri, sau la nimic. Deconectați și funcționează din nou. Reflexul este să dăm vina pe resolverul pe care tunelul l-a impus, dar cauza mai frecventă este un server de nume publicat care a încetat să primească actualizări ale zonei. Noua cale a ajuns pur și simplu la o altă autoritate decât cea de la care a venit răspunsul din cache.
Simptomul se schimbă cu resolverul
Un resolver recursiv returnează ce i-a spus o autoritate, apoi păstrează acel răspuns pentru TTL. Dacă tunelul impune alt resolver, sau schimbă calea astfel încât cel vechi să nu mai fie accesibil, clientul întreabă altă autoritate și primește alt răspuns. Domeniul nu s-a schimbat în acel moment; viziunea dumneavoastră asupra lui s-a schimbat.
De aceea același nume poate funcționa într-un birou și poate eșua dintr-un hotel, și de aceea golirea unui cache local ajută doar uneori. Golirea cache-ului trimite întrebarea din nou la aceeași autoritate.
Testul care le distinge este o interogare directă la fiecare server publicat.
Întrebați fiecare autoritate direct
Începeți de la delegare, nu de la o listă pe care o țineți minte. Întrebați părintele despre setul NS, apoi interogați fiecare nume din acel set pentru înregistrarea care vă interesează. Două interogări pentru același nume la autorități diferite vă spun imediat dacă zona este coerentă.
dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A
Faceți același lucru pentru înregistrările NS din vârful zonei, pentru că delegarea părintelui și setul NS propriu al zonei pot diferi după o migrare. Numerele de serie din SOA sunt următorul lucru de comparat, iar un secundar rămas mult în urmă este o problemă de transfer, nu de răspuns.
Rulați acele interogări din rețeaua care eșuează, nu doar de la biroul dumneavoastră.
Separați viziunile intenționate de cele stricate
Unele domenii răspund intenționat diferit în funcție de regiune sau de grupul de resolvere, iar configurațiile cu orizont divizat sunt normale în rețelele de întreprindere.
Întrebarea este dacă diferența este documentată și stabilă. O viziune neintenționată arată altfel: o autoritate are o înregistrare pe care celelalte nu au primit-o niciodată, sau îi lipsește una pe care toate o împărtășesc. Ghidul RFC 2182 pentru selecție și implementare tratează disponibilitatea autoritativă ca responsabilitate comună, și acesta este cadrul corect aici. Redundanța există doar dacă fiecare server publicat poate răspunde cu datele intenționate, nu doar dacă acceptă o conexiune pe portul 53.
Un server care răspunde SERVFAIL este mai ușor de diagnosticat decât unul care răspunde cu încredere și greșit.
O migrare dezvăluie ce ascundea un cache
În timpul unei schimbări de furnizor, două locații autoritative se schimbă: delegarea părintelui și înregistrările NS proprii ale zonei. Ambele trebuie actualizate, și ambele sunt păstrate în cache pentru TTL-urile lor. Dacă un server vechi rămâne pornit și continuă să servească zona anterioară, clienții ale căror resolvere îl întreabă vor continua să primească răspunsul vechi mult după ce trecerea a părut completă.
Exact aceasta este starea pe care un cache de lungă durată o ascunde. Stația de lucru care a funcționat toată săptămâna vorbea cu un resolver care avea un răspuns proaspăt de la noua autoritate, în timp ce cel vechi continua să distribuie date învechite tuturor celorlalți.
Schimbarea resolverului pe un laptop repară acel laptop și nimic altceva.
Reparați zona, nu resolverul
Identificați ce servere ar trebui să fie autoritative pentru zonă, corectați zona gestionată sau delegarea astfel încât fiecare dintre ele să servească datele intenționate, și păstrați redundanța pe care ați planificat-o. Ștergerea unui server de nume pentru că o ieșire VPN a primit un răspuns ciudat reduce disponibilitatea și lasă inconsistența pe loc.
Apoi rulați din nou interogările directe din ambele rețele și așteptați să expire TTL-ul înregistrării pe care ați modificat-o.
Confirmați că răspunsul este stabil de la fiecare autoritate, și scrieți viziunea intenționată în documentația zonei pentru ca următoarea diferență să fie ușor de clasificat.