NXDOMAIN printr-un VPN nu înseamnă o cădere a tunelului

Este tentant să citești o singură căutare eșuată ca dovadă că tunelul s-a prăbușit, mai ales când numele funcționa acum zece minute. Răspunsul spune altceva. NXDOMAIN este o tranzacție DNS finalizată în care un resolver a declarat că numele interogat nu există; un tunel defect produce de obicei tăcere, un timeout sau o încercare de rezolvare către serverul greșit. Versiunea argumentului fără wireshark este o interogare, un respondent și un cod de răspuns, iar acest triou merită consemnat înainte de orice modificare de configurare.

Ce stabilește de fapt răspunsul

DNS separă rezultate pe care clienții le fuzionează adesea într-un singur eșec. Un nume care nu există produce un răspuns negativ cu codul NXDOMAIN, în timp ce un nume care există dar nu are nicio înregistrare de tipul cerut produce un răspuns de succes cu o secțiune de răspunsuri goală. Ambele par lipsite de utilitate pentru o aplicație, și doar unul dintre ele înseamnă că numele este greșit.

Această diferență decide unde îi revine reparația. O înregistrare AAAA lipsă pe un host care are o înregistrare A nu este un host lipsă, iar reemiterea unui certificat sau reconstruirea unui tunel pentru a o urmări irosește singurul indiciu disponibil. Distincția stabilește și forma continuării: o problemă de denumire se corectează în zonă, iar o problemă de tip se corectează cerând înregistrarea corectă sau acceptând că familia de adrese pur și simplu lipsește.

Mitul: un nume privat lipsă înseamnă că tunelul a eșuat

Mitul supraviețuiește pentru că cele două evenimente vin atât de des împreună. Un client se conectează la VPN, sistemul de operare păstrează un resolver în care avea deja încredere, iar numele intern de care are acum nevoie este întrebat la un server care nu a auzit niciodată de zona privată. Acel server răspunde sincer și negativ. Tunelul transportă pachetul; răspunsul se referă doar la un spațiu de nume pe care respondentul nu îl deservește.

Aranjamentele split-horizon fac acest lucru rutină: același nume de zonă există public și intern cu conținut diferit, și doar resolverul intern cunoaște înregistrările private. Obținerea unui răspuns negativ care pare autoritar este, așadar, dovada despre care resolver a răspuns, nu o dovadă despre starea interfeței.

Două detalii de configurare decid rezultatul. Tunelul trebuie să împingă sau să selecteze resolverul intern, iar clientul trebuie să aplice acea selecție numelui căutat. O regulă pe domeniu care numește un sufix ușor diferit de înregistrarea tastată va trimite interogarea pe calea publică, iar răspunsul va fi corect și inutil.

Întrebați resolverul corect cu numele corect

Consemnați respondentul înainte de a consemna verdictul. O căutare care nu arată care server a răspuns nu poate distinge o problemă de politică de o problemă de spațiu de nume, iar cele două au remedieri nelegate.

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

Primele două linii arată ce a decis resolverul local și pe cine ar întreba. Căutarea +search reproduce ce face o aplicație când adaugă un sufix de căutare, care este adesea interogarea reală și nu cea tastată într-un instrument de diagnostic. Ultima linie întreabă direct serverul intern, ocolind politica clientului; dacă aceasta reușește în timp ce căutarea simplă eșuează, zona este în regulă, iar rutarea interogărilor nu.

Cache-ul negativ explică întârzierea după o corecție

Răspunsurile negative sunt puse în cache prin proiectare, iar RFC 2308 descrie cum durata de viață a cache-ului negativ este derivată din înregistrarea de autoritate a zonei. Corectarea unei înregistrări sau a unei reguli de resolver nu garantează, prin urmare, o schimbare imediată la client, iar repetarea unei căutări care continuă să returneze răspunsul din cache nu dovedește nimic nou. Doar un alt respondent, un alt nume sau un cache golit produc dovezi proaspete.

Goliți cache-ul local, apoi repetați aceeași interogare către același respondent. Pe sistemele care folosesc serviciul de resolver local aceasta este o singură comandă; pe altele este o repornire de serviciu sau un utilitar de platformă, iar instrumentul concret contează mai puțin decât repetarea unui test identic după aceea.

Separați numele de cale

Odată ce numele se rezolvă la adresa privată așteptată, DNS s-a încheiat ca subiect, iar calea aplicației devine următoarea întrebare. Un host care răspunde la căutări dar refuză o conexiune are altă problemă, iar continuarea ajustării resolverelor după un răspuns corect este felul în care un incident dobândește trei modificări nelegate. Comparați adresa rezolvată cu cea pe care serviciul ascultă de fapt înainte de a presupune că cele două coincid.

Păstrați transcrierea: interogarea, respondentul, codul și adresa rezolvată. Acea consemnare este și ceea ce face verificabil un raport ulterior, și este diferența dintre un diagnostic și o poveste despre un tunel care părea lent.