NXDOMAIN oor ’n VPN beteken nie dat die tonnel weg is nie

Dit is aanloklik om een mislukte opsoeking te lees as bewys dat die tonnel ingegee het, veral wanneer die naam tien minute vroeër gewerk het. Die antwoord sê anders. NXDOMAIN is ’n voltooide DNS-transaksie waarin ’n oplosser verklaar het dat die gevraagde naam nie bestaan nie; ’n gebreekte tonnel lewer gewoonlik stilte, ’n tydsverloop of ’n oplossingspoging teen die verkeerde bediener. Die weergawe van die argument sonder wireshark is een navraag, een antwoorder en een antwoordkode, en daardie drietal is die moeite werd om vas te lê voordat enige konfigurasie verander.

Wat die antwoord werklik vasstel

DNS skei uitkomste wat kliënte dikwels in een fout saamvat. ’n Naam wat nie bestaan nie lewer ’n negatiewe antwoord met die NXDOMAIN-kode, terwyl ’n naam wat bestaan maar geen rekord van die gevraagde tipe het nie, ’n suksesvolle antwoord met ’n leë antwoordafdeling lewer. Albei lyk vir ’n toepassing soos niks nuttigs, en net een van hulle beteken dat die naam verkeerd is.

Daardie verskil bepaal waar die herstel hoort. ’n Ontbrekende AAAA-rekord op ’n gasheer met ’n A-rekord is nie ’n ontbrekende gasheer nie, en om ’n sertifikaat te heruitreik of ’n tonnel te herbou om dit te jaag, mors die enigste leidraad wat beskikbaar was. Die onderskeid bepaal ook die vorm van die opvolging: ’n naamprobleem word in die sone reggestel, en ’n tipeprobleem word reggestel deur die regte rekord te vra of deur te aanvaar dat die adresfamilie eenvoudig afwesig is.

Die mite: ’n Ontbrekende private naam beteken die tonnel het gefaal

Die mite oorleef omdat die twee gebeure so dikwels saam kom. ’n Kliënt verbind met die VPN, die bedryfstelsel hou ’n oplosser wat hy al vertrou het, en die interne naam wat hy nou nodig het, word gevra van ’n bediener wat nog nooit van die private sone gehoor het nie. Daardie bediener antwoord eerlik en negatief. Die tonnel dra die pakkie; die antwoord gaan bloot oor ’n naamruimte wat die antwoorder nie bedien nie.

Split-horizon-reëlings maak dit roetine: dieselfde sonenaam bestaan publiek en intern met verskillende inhoud, en net die interne oplosser ken die private rekords. Om ’n gesaghebbend-voorkomende negatiewe antwoord te kry, is dus bewyse oor watter oplosser geantwoord het, nie bewyse oor die toestand van die koppelvlak nie.

Twee konfigurasiebesonderhede bepaal die uitkoms. Die tonnel moet die interne oplosser stoot of kies, en die kliënt moet daardie keuse toepas op die naam wat opgesoek word. ’n Reël per domein wat ’n agtervoegsel noem wat effens van die rekord wat jy getik het verskil, sal die navraag na die openbare pad stuur, en die antwoord sal korrek en nutteloos wees.

Vra die regte oplosser met die regte naam

Teken die antwoorder op voordat jy die uitspraak opteken. ’n Opsoeking wat nie wys watter bediener geantwoord het nie, kan nie ’n beleidsprobleem van ’n naamruimteprobleem onderskei nie, en die twee het onverwante regstellings.

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

Die eerste twee reëls wys wat die plaaslike oplosser besluit het en wie hy sou vra. Die +search-opsoeking reproduseer wat ’n toepassing doen wanneer dit ’n soek-agtervoegsel byvoeg, wat dikwels die werklike navraag is eerder as die een wat in ’n diagnostiese instrument getik is. Die laaste reël vra die interne bediener direk, en omseil die kliëntbeleid; as dit slaag terwyl die gewone opsoeking misluk, is die sone reg en die routering van navrae nie.

Negatiewe kas verduidelik die vertraging ná ’n regstelling

Negatiewe antwoorde word volgens ontwerp gekas, en RFC 2308 beskryf hoe die leeftyd van die negatiewe kas uit die sone se gesagsrekord afgelei word. Om ’n rekord of ’n oplosserreël reg te stel waarborg dus nie ’n onmiddellike verandering op die kliënt nie, en om ’n opsoeking te herhaal wat aanhou om die gekasde antwoord terug te gee, bewys niks nuuts nie. Net ’n ander antwoorder, ’n ander naam of ’n skoongemaakte kas lewer vars bewyse.

Maak die plaaslike kas skoon en herhaal dan dieselfde navraag teen dieselfde antwoorder. Op stelsels wat die plaaslike oplosserdiens gebruik, is dit een opdrag; op ander is dit ’n diensherstart of ’n platformnutsding, en die spesifieke instrument maak minder saak as om daarna ’n identiese toets te herhaal.

Skei die naam van die pad

Sodra die naam na die verwagte private adres oplos, is DNS as onderwerp afgehandel en word die toepassingspad die volgende vraag. ’n Gasheer wat opsoekings beantwoord maar ’n verbinding weier, het ’n ander probleem, en om aan te hou om oplossers by te stel ná ’n korrekte antwoord is hoe ’n voorval drie onverwante veranderinge opdoen. Vergelyk die opgeloste adres met die een waarop die diens werklik luister voordat jy aanneem die twee stem ooreen.

Hou die transkripsie: die navraag, die antwoorder, die kode en die opgeloste adres. Daardie rekord is ook wat ’n latere verslag verifieerbaar maak, en dit is die verskil tussen ’n diagnose en ’n verhaal oor ’n tonnel wat traag gelyk het.