Špatné DNS přes VPN? Jeden autoritativní server může být zastaralý

Připojte VPN a jedno jméno hostitele se přeloží na včerejší adresu, nebo vůbec na nic. Odpojte a zase to funguje. Reflexem je vinit překladač, který tunel vnutil, ale častější příčinou je publikovaný jmenný server, který přestal dostávat aktualizace zóny. Nová cesta prostě dosáhla jiného autoritativního serveru než toho, odkud přišla vaše odpověď z mezipaměti.

Příznak se mění podle překladače

Rekurzivní překladač vrací to, co mu autoritativní server řekl, a pak tuto odpověď drží po dobu TTL. Pokud tunel vnutí jiný překladač nebo změní cestu tak, že starý už není dostupný, klient se ptá jiného autoritativního serveru a dostane jinou odpověď. Doména se v tu chvíli nezměnila; změnil se váš pohled na ni.

Proto stejné jméno může v jedné kanceláři fungovat a z hotelu selhat a proto vymazání místní mezipaměti pomůže jen někdy. Vymazání mezipaměti pošle dotaz znovu stejnému autoritativnímu serveru.

Rozlišovacím testem je přímý dotaz na každý publikovaný server.

Ptejte se každého autoritativního serveru přímo

Začněte delegací, ne seznamem, který si pamatujete. Zeptejte se nadřazeného serveru na sadu NS a potom se dotažte každého jména z této sady na záznam, který potřebujete. Dva dotazy na stejné jméno u různých autoritativních serverů okamžitě ukážou, zda 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

Totéž udělejte pro záznamy NS v apexu zóny, protože delegace nadřazeného serveru a vlastní sada NS zóny se po migraci mohou rozejít. Sériová čísla v SOA jsou další věc k porovnání a sekundární server, který je daleko pozadu, je problém přenosu, nikoli odpovědi.

Spouštějte tyto dotazy ze sítě, která selhává, ne jen ze svého stolu.

Oddělte zamýšlené pohledy od rozbitých

Některé domény záměrně odpovídají jinak podle regionu nebo skupiny překladačů a nastavení split-horizon jsou v podnikových sítích běžná.

Otázkou je, zda je rozdíl zdokumentovaný a stabilní. Nezamýšlený pohled vypadá jinak: jeden autoritativní server má záznam, který ostatní nikdy nedostali, nebo mu chybí ten, který všichni sdílejí. Pokyny RFC 2182 pro výběr a nasazení považují autoritativní dostupnost za sdílenou odpovědnost a to je zde správný rámec. Redundance existuje jen tehdy, když každý publikovaný server dokáže odpovědět zamýšlenými daty, ne jen přijmout spojení na portu 53.

Server, který odpoví SERVFAIL, se diagnostikuje snadněji než ten, který odpoví sebevědomě a špatně.

Migrace odhalí, co mezipaměť skrývala

Během přesunu poskytovatele se mění dvě autoritativní místa: delegace nadřazeného serveru a vlastní záznamy NS zóny. Obě je třeba aktualizovat a obě se ukládají do mezipaměti na dobu svých TTL. Pokud starý server zůstane běžet a dál obsluhuje předchozí zónu, klienti, jejichž překladače se ho ptají, budou dostávat starou odpověď dlouho poté, co přechod vypadal dokončeně.

To je přesně stav, který dlouhodobá mezipaměť skrývá. Pracovní stanice, která celý týden fungovala, mluvila s překladačem, který držel čerstvou odpověď od nového autoritativního serveru, zatímco starý dál rozdával zastaralá data všem ostatním.

Změna překladače na notebooku opraví ten notebook a nic jiného.

Opravte zónu, ne překladač

Určete, které servery mají být pro zónu autoritativní, opravte spravovanou zónu nebo delegaci tak, aby každý z nich obsluhoval zamýšlená data, a zachovejte redundanci, kterou jste naplánovali. Smazání jmenného serveru proto, že jeden výstup VPN dostal podivnou odpověď, snižuje dostupnost a nechává nekonzistenci na místě.

Potom znovu spusťte přímé dotazy z obou sítí a počkejte, až vyprší TTL záznamu, který jste změnili.

Ověřte, že odpověď je z každého autoritativního serveru stabilní, a zapište zamýšlený pohled do dokumentace zóny, aby se příští rozdíl dal snadno klasifikovat.