NXDOMAIN preko VPN-a ne znači prekid tunela

Primamljivo je jedan neuspjeli upit pročitati kao dokaz da se tunel srušio, osobito kad je ime radilo deset minuta ranije. Odgovor govori drugačije. NXDOMAIN je dovršena DNS transakcija u kojoj je resolver naveo da traženo ime ne postoji; pokvaren tunel obično proizvodi tišinu, istek vremena ili pokušaj razrješavanja prema pogrešnom poslužitelju. Verzija argumenta bez wiresharka je jedan upit, jedan sugovornik i jedan kod odgovora, a tu trojku vrijedi zabilježiti prije ikakvih promjena konfiguracije.

Što odgovor zapravo dokazuje

DNS razdvaja ishode koje klijenti često stapaju u jedan neuspjeh. Ime koje ne postoji daje negativan odgovor s kodom NXDOMAIN, dok ime koje postoji ali nema zapis tražene vrste daje uspješan odgovor s praznim odjeljkom odgovora. Oboje aplikaciji izgleda kao ništa korisno, a samo jedno od toga znači da je ime pogrešno.

Ta razlika odlučuje gdje popravak pripada. Nedostajući zapis AAAA na hostu koji ima zapis A nije nedostajući host, a ponovno izdavanje certifikata ili ponovna izgradnja tunela da bi se to lovilo troši jedini dostupni trag. Razlika određuje i oblik nastavka: problem imenovanja popravlja se u zoni, a problem vrste popravlja se traženjem ispravnog zapisa ili prihvaćanjem da obitelj adresa jednostavno nije prisutna.

Mit: nedostajuće privatno ime znači da je tunel zakazao

Mit preživljava jer ta dva događaja tako često dolaze zajedno. Klijent se povezuje na VPN, operacijski sustav zadržava resolver kojem je već vjerovao, a interno ime koje mu sada treba pita se poslužitelja koji nikada nije čuo za privatnu zonu. Taj poslužitelj odgovara iskreno i negativno. Tunel nosi paket; odgovor je jednostavno o prostoru imena koji sugovornik ne poslužuje.

Split-horizon postavke to čine rutinskim: isto ime zone postoji javno i interno s različitim sadržajem, a privatne zapise zna samo interni resolver. Zato je dobivanje negativnog odgovora koji izgleda mjerodavno dokaz o tome koji je resolver odgovorio, a ne dokaz o stanju sučelja.

Dva detalja konfiguracije odlučuju ishod. Tunel mora progurati ili odabrati interni resolver, a klijent mora primijeniti taj odabir na ime koje se traži. Pravilo po domeni koje imenuje sufiks malo drugačiji od zapisa koji ste upisali poslat će upit javnim putem, a odgovor će biti točan i beskorisan.

Pitajte pravi resolver s pravim imenom

Zabilježite sugovornika prije nego zabilježite presudu. Upit koji ne pokazuje koji je poslužitelj odgovorio ne može razlikovati problem politike od problema prostora imena, a njihove su popravke nepovezane.

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

Prva dva retka pokazuju što je lokalni resolver odlučio i koga bi pitao. Upit +search reproducira što aplikacija radi kad doda sufiks za pretraživanje, što je često pravi upit, a ne onaj upisan u dijagnostički alat. Posljednji redak pita interni poslužitelj izravno, zaobilazeći klijentsku politiku; ako to uspije dok obični upit ne uspijeva, zona je u redu, a usmjeravanje upita nije.

Negativno keširanje objašnjava kašnjenje nakon popravka

Negativni se odgovori keširaju po dizajnu, a RFC 2308 opisuje kako se životni vijek negativnog keša izvodi iz zapisa autoriteta zone. Ispravljanje zapisa ili pravila resolvera stoga ne jamči trenutačnu promjenu na klijentu, a ponavljanje upita koji stalno vraća keširani odgovor ne dokazuje ništa novo. Samo drugi sugovornik, drugo ime ili očišćeni keš daje svježe dokaze.

Očistite lokalni keš, zatim ponovite isti upit prema istom sugovorniku. Na sustavima s lokalnom uslugom resolvera to je jedna naredba; na drugima je to ponovno pokretanje usluge ili platformski alat, a konkretan alat manje je važan od ponavljanja identičnog testa nakon toga.

Odvojite ime od puta

Kad se ime razriješi na očekivanu privatnu adresu, DNS je kao tema završen i sljedeće je pitanje put aplikacije. Host koji odgovara na upite ali odbija vezu ima drugi problem, a nastavak podešavanja resolvera nakon točnog odgovora način je na koji incident dobije tri nepovezane promjene. Usporedite razriješenu adresu s onom na kojoj usluga stvarno sluša prije nego pretpostavite da se dvije slažu.

Sačuvajte zapis: upit, sugovornik, kod i razriješena adresa. Taj zapis ujedno čini kasnije izvješće provjerljivim i razlika je između dijagnoze i priče o tunelu koji se činio sporim.