NXDOMAIN přes VPN neznamená výpadek tunelu

Je lákavé číst jeden neúspěšný dotaz jako důkaz, že se tunel zhroutil, zvlášť když jméno před deseti minutami fungovalo. Odpověď říká něco jiného. NXDOMAIN je dokončená DNS transakce, v níž překladač uvedl, že dotazované jméno neexistuje; rozbitý tunel obvykle produkuje ticho, vypršení časového limitu nebo pokus o překlad proti špatnému serveru. Verze argumentu bez wiresharku je jeden dotaz, jeden odpovídající a jeden kód odpovědi, a tato trojice stojí za zaznamenání před jakýmikoli změnami konfigurace.

Co odpověď vlastně dokazuje

DNS odděluje výsledky, které klienti často slijí do jednoho selhání. Neexistující jméno vytváří negativní odpověď s kódem NXDOMAIN, zatímco jméno, které existuje, ale nemá záznam požadovaného typu, vytváří úspěšnou odpověď s prázdnou sekcí odpovědí. Obojí vypadá pro aplikaci jako nic užitečného a jen jedno z toho znamená, že jméno je špatné.

Tento rozdíl rozhoduje, kam oprava patří. Chybějící záznam AAAA na hostiteli, který má záznam A, není chybějící hostitel, a opětovné vydání certifikátu nebo přestavba tunelu kvůli tomu plýtvá jediným dostupným vodítkem. Rozdíl také určuje podobu pokračování: problém pojmenování se opravuje v zóně a problém typu se opravuje dotazem na správný záznam nebo přijetím toho, že rodina adres prostě chybí.

Mýtus: chybějící soukromé jméno znamená, že tunel selhal

Mýtus přežívá, protože tyto dvě události tak často přicházejí společně. Klient se připojí k VPN, operační systém si ponechá překladač, kterému už věřil, a interní jméno, které nyní potřebuje, se ptá serveru, který o soukromé zóně nikdy neslyšel. Ten server odpovídá poctivě a negativně. Tunel nese paket; odpověď se prostě týká jmenného prostoru, který odpovídající neobsluhuje.

Uspořádání split-horizon to dělá rutinou: stejné jméno zóny existuje veřejně i interně s různým obsahem a soukromé záznamy zná jen interní překladač. Získání negativní odpovědi, která vypadá autoritativně, je proto důkaz o tom, který překladač odpověděl, a ne o stavu rozhraní.

Výsledek rozhodují dva detaily konfigurace. Tunel musí protlačit nebo vybrat interní překladač a klient musí toto vybrání použít na dotazované jméno. Pravidlo pro jednotlivou doménu, které pojmenuje suffix mírně odlišný od záznamu, který jste napsali, pošle dotaz veřejnou cestou a odpověď bude správná a nepoužitelná.

Ptejte se správného překladače se správným jménem

Zaznamenejte odpovídajícího, než zaznamenáte verdikt. Dotaz, který neukazuje, který server odpověděl, nemůže rozlišit problém politiky od problému jmenného prostoru, a oba mají nesouvisející opravy.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

První dva řádky ukazují, co místní překladač rozhodl a koho by se ptal. Dotaz +search reprodukuje to, co aplikace dělá, když přidá vyhledávací suffix, což je často skutečný dotaz, a ne ten napsaný do diagnostického nástroje. Poslední řádek se ptá interního serveru přímo, s obejitím klientské politiky; pokud to uspěje, zatímco prostý dotaz selhává, zóna je v pořádku a směrování dotazů ne.

Negativní kešování vysvětluje zpoždění po opravě

Negativní odpovědi se záměrně kešují a RFC 2308 popisuje, jak se životnost negativní keše odvozuje od záznamu autority zóny. Oprava záznamu nebo pravidla překladače proto nezaručuje okamžitou změnu na klientovi a opakování dotazu, který stále vrací kešovanou odpověď, neprokazuje nic nového. Jen jiný odpovídající, jiné jméno nebo vyčištěná keš dává čerstvé důkazy.

Vyčistěte místní keš a poté zopakujte stejný dotaz proti stejnému odpovídajícímu. Na systémech s místní službou překladače je to jeden příkaz; na jiných je to restart služby nebo platformový nástroj a konkrétní nástroj je méně důležitý než následné zopakování identického testu.

Oddělte jméno od cesty

Jakmile se jméno přeloží na očekávanou soukromou adresu, DNS je jako téma u konce a další otázkou se stává cesta aplikace. Hostitel, který odpovídá na dotazy, ale odmítá spojení, má jiný problém, a pokračování v ladění překladačů po správné odpovědi je způsob, jak incident získá tři nesouvisející změny. Porovnejte přeloženou adresu s tou, na které služba skutečně naslouchá, než předpokládáte, že se obě shodují.

Uchovejte záznam: dotaz, odpovídajícího, kód a přeloženou adresu. Tento záznam také činí pozdější zprávu ověřitelnou a je rozdílem mezi diagnózou a příběhem o tunelu, který se zdál pomalý.