Nesprávne DNS cez VPN? Jeden autoritatívny server môže byť zastaraný

Pripojte VPN a jedno meno hostiteľa sa preloží na včerajšiu adresu alebo vôbec na nič. Odpojte a znova to funguje. Reflexom je viniť prekladač, ktorý tunel vnútil, ale častejšou príčinou je publikovaný menný server, ktorý prestal dostávať aktualizácie zóny. Nová cesta jednoducho dosiahla iný autoritatívny zdroj ako ten, odkiaľ prišla vaša odpoveď z vyrovnávacej pamäte.

Príznak sa mení s prekladačom

Rekurzívny prekladač vráti to, čo mu autoritatívny zdroj povedal, a potom túto odpoveď drží počas TTL. Ak tunel vnúti iný prekladač alebo zmení cestu tak, že starý už nie je dostupný, klient sa pýta iného autoritatívneho zdroja a dostane inú odpoveď. Doména sa v tej chvíli nezmenila; zmenil sa váš pohľad na ňu.

Preto to isté meno môže v jednej kancelárii fungovať a z hotela zlyhať, a preto vymazanie miestnej vyrovnávacej pamäte pomôže len niekedy. Vymazanie pamäte pošle otázku znova tomu istému autoritatívnemu zdroju.

Rozlišovacím testom je priamy dotaz na každý publikovaný server.

Pýtajte sa každého autoritatívneho zdroja priamo

Začnite delegáciou, nie zoznamom, ktorý si pamätáte. Opýtajte sa nadradeného servera na množinu NS a potom sa opýtajte každého mena z tejto množiny na záznam, ktorý potrebujete. Dva dotazy na to isté meno u rôznych autoritatívnych zdrojov hneď ukážu, či je zóna konzistentná.

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

To isté urobte pre záznamy NS v vrchole zóny, pretože delegácia nadradeného servera a vlastná množina NS zóny sa po migrácii môžu rozísť. Sériové čísla v SOA sú ďalšia vec na porovnanie a sekundárny server, ktorý je ďaleko pozadu, je problém prenosu, nie odpovede.

Spúšťajte tieto dotazy zo siete, ktorá zlyháva, nie iba zo svojho stola.

Oddeľte zamýšľané pohľady od pokazených

Niektoré domény zámerne odpovedajú inak podľa regiónu alebo skupiny prekladačov a nastavenia split-horizon sú v podnikových sieťach bežné.

Otázkou je, či je rozdiel zdokumentovaný a stabilný. Nezamýšľaný pohľad vyzerá inak: jeden autoritatívny server má záznam, ktorý ostatné nikdy nedostali, alebo mu chýba ten, ktorý všetci zdieľajú. Usmernenia RFC 2182 pre výber a nasadenie považujú autoritatívnu dostupnosť za spoločnú zodpovednosť a to je tu správny rámec. Redundancia existuje len vtedy, keď každý publikovaný server dokáže odpovedať zamýšľanými údajmi, nie len prijať spojenie na porte 53.

Server, ktorý odpovie SERVFAIL, sa diagnostikuje ľahšie ako ten, ktorý odpovie sebavedomo a nesprávne.

Migrácia odhalí, čo vyrovnávacia pamäť skrývala

Pri presune poskytovateľa sa menia dve autoritatívne miesta: delegácia nadradeného servera a vlastné záznamy NS zóny. Obe treba aktualizovať a obe sa ukladajú do vyrovnávacej pamäte na svoje TTL. Ak starý server zostane bežať a ďalej obsluhuje predchádzajúcu zónu, klienti, ktorých prekladače sa ho pýtajú, budú dostávať starú odpoveď ešte dlho po tom, čo sa prechod zdal dokončený.

Presne tento stav skrýva dlhotrvajúca vyrovnávacia pamäť. Pracovná stanica, ktorá fungovala celý týždeň, hovorila s prekladačom, ktorý držal čerstvú odpoveď od nového autoritatívneho zdroja, kým starý ďalej rozdával zastarané údaje všetkým ostatným.

Zmena prekladača na notebooku opraví ten notebook a nič iné.

Opravte zónu, nie prekladač

Určite, ktoré servery majú byť pre zónu autoritatívne, opravte spravovanú zónu alebo delegáciu tak, aby každý z nich poskytoval zamýšľané údaje, a zachovajte redundanciu, ktorú ste naplánovali. Vymazanie menného servera preto, že jeden výstup VPN dostal podivnú odpoveď, znižuje dostupnosť a necháva nekonzistenciu na mieste.

Potom znova spustite priame dotazy z oboch sietí a počkajte, kým vyprší TTL záznamu, ktorý ste zmenili.

Overte, že odpoveď je z každého autoritatívneho zdroja stabilná, a zapíšte zamýšľaný pohľad do dokumentácie zóny, aby sa ďalší rozdiel dal ľahko klasifikovať.