NXDOMAIN över en VPN betyder inte att tunneln är nere

Det är frestande att läsa en misslyckad uppslagning som bevis för att tunneln kollapsade, särskilt när namnet fungerade tio minuter tidigare. Svaret säger något annat. NXDOMAIN är en avslutad DNS-transaktion där en resolver förklarade att namnet som frågades efter inte finns; en trasig tunnel ger vanligtvis tystnad, en timeout eller ett upplösningsförsök mot fel server. Versionen av argumentet utan wireshark är en fråga, en svarare och en svarskod, och den trion är värd att registrera före någon konfigurationsändring.

Vad svaret faktiskt bevisar

DNS skiljer utfall som klienter ofta slår ihop till ett enda fel. Ett namn som inte finns ger ett negativt svar med koden NXDOMAIN, medan ett namn som finns men inte har någon post av den efterfrågade typen ger ett lyckat svar med en tom svarsdel. Båda ser ut som ingenting användbart för en applikation, och bara en av dem betyder att namnet är fel.

Den skillnaden avgör var reparationen hör hemma. En saknad AAAA-post på en värd som har en A-post är inte en saknad värd, och att utfärda ett certifikat på nytt eller bygga om tunneln för att jaga det slösar bort den enda ledtråd som fanns. Skillnaden bestämmer också formen på uppföljningen: ett namproblem åtgärdas i zonen, och ett typproblem åtgärdas genom att fråga efter rätt post eller genom att acceptera att adressfamiljen helt enkelt saknas.

Myten: ett saknat privat namn betyder att tunneln misslyckades

Myten överlever eftersom de två händelserna så ofta kommer tillsammans. En klient ansluter till VPN, operativsystemet behåller en resolver som det redan litade på, och det interna namn det nu behöver frågas hos en server som aldrig har hört talas om den privata zonen. Den servern svarar ärligt och negativt. Tunneln bär paketet; svaret handlar helt enkelt om ett namnutrymme som svararen inte betjänar.

Split-horizon-uppsättningar gör detta rutinmässigt: samma zonnamn finns offentligt och internt med olika innehåll, och bara den interna resolvern känner till de privata posterna. Att få ett negativt svar som ser auktoritativt ut är därför bevis för vilken resolver som svarade, inte bevis för gränssnittets tillstånd.

Två konfigurationsdetaljer avgör utfallet. Tunneln måste trycka ut eller välja den interna resolvern, och klienten måste tillämpa det valet på namnet som slås upp. En regel per domän som namnger ett suffix som avviker lite från posten du skrev skickar frågan via den offentliga vägen, och svaret blir korrekt och oanvändbart.

Fråga rätt resolver med rätt namn

Registrera svararen innan du registrerar domen. En uppslagning som inte visar vilken server som svarade kan inte skilja ett policyproblem från ett namnutrymmesproblem, och de två har orelaterade åtgärder.

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

De två första raderna visar vad den lokala resolvern beslutade och vem den skulle fråga. Uppslagningen +search återger vad en applikation gör när den lägger till ett söksuffix, vilket ofta är den egentliga frågan och inte den som skrevs in i ett diagnostikverktyg. Den sista raden frågar den interna servern direkt och kringgår klientpolicyn; om det lyckas medan den vanliga uppslagningen misslyckas är zonen i ordning och routningen av frågor inte.

Negativ cachning förklarar fördröjningen efter en rättelse

Negativa svar cachas enligt design, och RFC 2308 beskriver hur livstiden för den negativa cachen härleds från zonens auktoritetspost. Att rätta en post eller en resolverregel garanterar därför inte en omedelbar ändring på klienten, och att upprepa en uppslagning som fortsätter att returnera det cachade svaret bevisar ingenting nytt. Bara en annan svarare, ett annat namn eller en tömd cache ger färska bevis.

Töm den lokala cachen och upprepa sedan samma fråga mot samma svarare. På system som använder den lokala resolvertjänsten är det ett enda kommando; på andra är det en omstart av tjänsten eller ett plattformsverktyg, och det konkreta verktyget är mindre viktigt än att upprepa ett identiskt test efteråt.

Skilj namnet från vägen

När namnet har lösts upp till den förväntade privata adressen är DNS färdigt som ämne, och applikationsvägen blir nästa fråga. En värd som svarar på uppslagningar men nekar en anslutning har ett annat problem, och att fortsätta justera resolvrar efter ett korrekt svar är sättet en incident får tre orelaterade ändringar. Jämför den upplösta adressen med den som tjänsten faktiskt lyssnar på innan du antar att de två stämmer.

Spara utskriften: frågan, svararen, koden och den upplösta adressen. Den registreringen är också det som gör en senare rapport verifierbar, och det är skillnaden mellan en diagnos och en historia om en tunnel som verkade långsam.