NXDOMAIN via een VPN betekent geen tunnelstoring

Het is verleidelijk één mislukte opzoeking te lezen als bewijs dat de tunnel is ingestort, vooral wanneer de naam tien minuten eerder nog werkte. Het antwoord zegt iets anders. NXDOMAIN is een voltooide DNS-transactie waarin een resolver heeft verklaard dat de opgevraagde naam niet bestaat; een kapotte tunnel levert meestal stilte, een time-out of een resolutiepoging tegen de verkeerde server op. De versie van het argument zonder wireshark is één query, één antwoorder en één antwoordcode, en dat drietal is het waard om vast te leggen voordat u de configuratie wijzigt.

Wat het antwoord werkelijk vaststelt

DNS scheidt uitkomsten die clients vaak tot één fout samenvatten. Een naam die niet bestaat levert een negatief antwoord met de code NXDOMAIN, terwijl een naam die bestaat maar geen record van het gevraagde type heeft een geslaagd antwoord met een lege antwoordsectie oplevert. Beide lijken voor een applicatie niets bruikbaars, en slechts één ervan betekent dat de naam onjuist is.

Dat verschil bepaalt waar de reparatie thuishoort. Een ontbrekend AAAA-record op een host met een A-record is geen ontbrekende host, en een certificaat opnieuw uitgeven of een tunnel herbouwen om dat na te jagen verspilt de enige aanwijzing die beschikbaar was. Het onderscheid bepaalt ook de vorm van de vervolgstap: een naamprobleem wordt in de zone opgelost, en een typeprobleem wordt opgelost door naar het juiste record te vragen of door te aanvaarden dat de adresfamilie eenvoudigweg ontbreekt.

De mythe: een ontbrekende privénaam betekent dat de tunnel faalde

De mythe overleeft omdat de twee gebeurtenissen zo vaak samenkomen. Een client verbindt met de VPN, het besturingssysteem houdt een resolver die het al vertrouwde, en de interne naam die het nu nodig heeft wordt gevraagd aan een server die nog nooit van de privézone heeft gehoord. Die server antwoordt eerlijk en negatief. De tunnel draagt het pakket; het antwoord gaat alleen over een naamruimte die de antwoorder niet bedient.

Split-horizon-opstellingen maken dit routineus: dezelfde zonenaam bestaat openbaar en intern met verschillende inhoud, en alleen de interne resolver kent de privérecords. Een negatief antwoord krijgen dat gezaghebbend lijkt is daarom bewijs over welke resolver antwoordde, niet bewijs over de toestand van de interface.

Twee configuratiedetails bepalen de uitkomst. De tunnel moet de interne resolver pushen of selecteren, en de client moet die keuze toepassen op de naam die wordt opgezocht. Een regel per domein die een achtervoegsel noemt dat iets afwijkt van het record dat u typte, stuurt de query over het openbare pad, en het antwoord zal correct en nutteloos zijn.

Vraag de juiste resolver met de juiste naam

Leg de antwoorder vast voordat u het oordeel vastlegt. Een opzoeking die niet laat zien welke server antwoordde, kan een beleidsprobleem niet van een naamruimteprobleem onderscheiden, en de twee hebben onverwante reparaties.

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 eerste twee regels laten zien wat de lokale resolver besloot en wie hij zou vragen. De +search-opzoeking reproduceert wat een applicatie doet wanneer zij een zoekachtervoegsel toevoegt, wat vaak de echte query is en niet degene die in een diagnostisch hulpmiddel is getypt. De laatste regel vraagt de interne server rechtstreeks, met omzeiling van het clientbeleid; als dat slaagt terwijl de gewone opzoeking faalt, is de zone in orde en de routering van queries niet.

Negatief cachen verklaart de vertraging na een correctie

Negatieve antwoorden worden ontworpen gecachet, en RFC 2308 beschrijft hoe de levensduur van de negatieve cache wordt afgeleid van het autoriteitsrecord van de zone. Het corrigeren van een record of een resolverregel garandeert daarom geen onmiddellijke wijziging op de client, en een opzoeking herhalen die het gecachte antwoord blijft teruggeven bewijst niets nieuws. Alleen een andere antwoorder, een andere naam of een geleegde cache levert verse bewijzen.

Leeg de lokale cache en herhaal daarna dezelfde query tegen dezelfde antwoorder. Op systemen die de lokale resolverdienst gebruiken is dat één opdracht; op andere is het een herstart van de dienst of een platformhulpmiddel, en het concrete hulpmiddel is minder belangrijk dan daarna een identieke test te herhalen.

Scheid de naam van het pad

Zodra de naam naar het verwachte privéadres resolvet, is DNS als onderwerp klaar en wordt het applicatiepad de volgende vraag. Een host die opzoekingen beantwoordt maar een verbinding weigert, heeft een ander probleem, en doorgaan met het bijstellen van resolvers na een correct antwoord is hoe een incident drie onverwante wijzigingen krijgt. Vergelijk het geresolveerde adres met het adres waarop de dienst werkelijk luistert voordat u aanneemt dat de twee overeenkomen.

Bewaar het transcript: de query, de antwoorder, de code en het geresolveerde adres. Dat verslag is ook wat een later rapport verifieerbaar maakt, en het is het verschil tussen een diagnose en een verhaal over een tunnel die traag leek.