NXDOMAIN a través d’una VPN no significa una caiguda del túnel

És temptador llegir una consulta fallida com a prova que el túnel ha col·lapsat, sobretot quan el nom funcionava deu minuts abans. La resposta diu una altra cosa. NXDOMAIN és una transacció DNS completada en què un resolutor ha declarat que el nom consultat no existeix; un túnel trencat normalment produeix silenci, un temps d’espera esgotat o un intent de resolució contra el servidor equivocat. La versió de l’argument sense wireshark és una consulta, un responedor i un codi de resposta, i aquesta tripleta val la pena enregistrar-la abans de qualsevol canvi de configuració.

Què estableix realment la resposta

El DNS separa resultats que els clients sovint ajunten en un sol fracàs. Un nom que no existeix produeix una resposta negativa amb el codi NXDOMAIN, mentre que un nom que existeix però no té cap registre del tipus sol·licitat produeix una resposta correcta amb una secció de respostes buida. Tots dos semblen res d’útil per a una aplicació, i només un d’ells vol dir que el nom és erroni.

Aquesta diferència decideix on pertoca la reparació. Un registre AAAA absent en un amfitrió que té un registre A no és un amfitrió absent, i reemetre un certificat o reconstruir un túnel per perseguir-ho malbarata l’únic indici disponible. La distinció també fixa la forma del seguiment: un problema de nomenclatura es corregeix a la zona, i un problema de tipus es corregeix demanant el registre correcte o acceptant que la família d’adreces simplement no hi és.

El mite: un nom privat absent vol dir que el túnel ha fallat

El mite sobreviu perquè els dos esdeveniments arriben tan sovint junts. Un client es connecta a la VPN, el sistema operatiu conserva un resolutor en què ja confiava, i el nom intern que ara necessita es demana a un servidor que mai no ha sentit a parlar de la zona privada. Aquest servidor respon honestament i negativament. El túnel porta el paquet; la resposta només tracta d’un espai de noms que el responedor no serveix.

Les disposicions d’horitzó dividit fan que això sigui rutinari: el mateix nom de zona existeix públicament i internament amb continguts diferents, i només el resolutor intern coneix els registres privats. Per tant, obtenir una resposta negativa que sembla autoritzada és una prova de quin resolutor ha respost, no una prova de l’estat de la interfície.

Dos detalls de configuració decideixen el resultat. El túnel ha d’empènyer o seleccionar el resolutor intern, i el client ha d’aplicar aquesta selecció al nom que es consulta. Una regla per domini que anomeni un sufix lleugerament diferent del registre que ha escrit enviarà la consulta pel camí públic, i la resposta serà correcta i inútil.

Pregunti al resolutor correcte amb el nom correcte

Enregistri el responedor abans d’enregistrar el veredicte. Una consulta que no mostra quin servidor ha respost no pot distingir un problema de política d’un problema d’espai de noms, i els dos tenen reparacions no relacionades.

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

Les dues primeres línies mostren què ha decidit el resolutor local i a qui preguntaria. La consulta +search reprodueix què fa una aplicació quan afegeix un sufix de cerca, que sovint és la consulta real i no la que s’ha escrit en una eina de diagnòstic. L’última línia pregunta directament al servidor intern, saltant-se la política del client; si això té èxit mentre la consulta simple falla, la zona és correcta i l’encaminament de les consultes no.

La memòria cau negativa explica el retard després d’una correcció

Les respostes negatives es guarden a la memòria cau per disseny, i RFC 2308 descriu com la durada de la memòria cau negativa es deriva del registre d’autoritat de la zona. Per tant, corregir un registre o una regla de resolutor no garanteix un canvi immediat al client, i reintentar una consulta que continua retornant la resposta en memòria cau no demostra res de nou. Només un responedor diferent, un nom diferent o una memòria cau esborrada produeixen proves noves.

Esborri la memòria cau local i després repeteixi la mateixa consulta contra el mateix responedor. En sistemes que utilitzen el servei de resolutor local això és una ordre; en altres és un reinici del servei o una utilitat de la plataforma, i l’eina concreta importa menys que repetir després una prova idèntica.

Separi el nom del camí

Un cop el nom es resol a l’adreça privada esperada, el DNS queda acabat com a tema i el camí de l’aplicació passa a ser la pregunta següent. Un amfitrió que respon les consultes però refusa una connexió té un problema diferent, i continuar ajustant resolutors després d’una resposta correcta és com un incident adquireix tres canvis no relacionats. Comparï l’adreça resolta amb la que el servei realment escolta abans de suposar que les dues coincideixen.

Conservi la transcripció: la consulta, el responedor, el codi i l’adreça resolta. Aquest registre també és el que fa verificable un informe posterior, i és la diferència entre un diagnòstic i una història sobre un túnel que semblava lent.