NXDOMAIN over ein VPN tyder ikkje at tunnelen er nede

Det er freistande å lese eitt mislukka oppslag som prov på at tunnelen kollapsa, særleg når namnet verka ti minutt tidlegare. Svaret seier noko anna. NXDOMAIN er ein fullført DNS-transaksjon der ein løysar erklærte at namnet som vart spurt om ikkje finst; ein broten tunnel gir vanlegvis stille, eit tidsavbrot eller eit oppløysingsforsøk mot feil tenar. Versjonen av argumentet utan wireshark er éi spørjing, éin svarar og éin svarkode, og denne trioen er verdt å registrere før noka konfigurasjonsendring.

Kva svaret faktisk provar

DNS skil utfall som klientar ofte slår saman til éin feil. Eit namn som ikkje finst gir eit negativt svar med koden NXDOMAIN, medan eit namn som finst men ikkje har nokon post av den etterspurde typen gir eit vellukka svar med ein tom svardel. Begge ser ut som ingenting nyttig for ein applikasjon, og berre éin av dei tyder at namnet er feil.

Den skilnaden avgjer kvar reparasjonen høyrer heime. Ein manglande AAAA-post på ein vert som har ein A-post er ikkje ein manglande vert, og å gje ut eit sertifikat på nytt eller byggje tunnelen på nytt for å jage det sløser med det einaste sporet som var tilgjengeleg. Skilnaden avgjer òg forma på oppfølginga: eit namneblem vert retta i sona, og eit typeproblem vert retta ved å spørje etter rett post eller ved å godta at adressefamilien rett og slett manglar.

Myten: eit manglande privatnamn tyder at tunnelen feila

Myten overlever fordi dei to hendingane så ofte kjem saman. Ein klient koplar til VPN, operativsystemet held på ein løysar det alt stolte på, og det interne namnet det no treng, vert spurt hjå ein tenar som aldri har høyrt om den private sona. Den tenaren svarar ærleg og negativt. Tunnelen ber pakken; svaret handlar rett og slett om eit namnerom som svararen ikkje tenar.

Split-horizon-oppsett gjer dette rutinemessig: det same sonenamnet finst offentleg og internt med ulikt innhald, og berre den interne løysaren kjenner dei private postane. Å få eit negativt svar som ser autoritativt ut er derfor prov for kva løysar som svara, ikkje prov for tilstanden til grensesnittet.

To konfigurasjonsdetaljar avgjer utfallet. Tunnelen må skyve eller velje den interne løysaren, og klienten må bruke det valet på namnet som vert slått opp. Ein regel per domene som namngir eit suffiks som avvik litt frå posten du skreiv, sender spørjinga via den offentlege vegen, og svaret vert korrekt og ubrukeleg.

Spør den rette løysaren med det rette namnet

Registrer svararen før du registrerer dommen. Eit oppslag som ikkje viser kva tenar som svara, kan ikkje skilje eit policyproblem frå eit namneromsproblem, og dei to har urelaterte rettingar.

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

Dei to første linjene viser kva den lokale løysaren bestemte og kven han ville spørje. Oppslaget +search gjev att kva ein applikasjon gjer når han legg til eit søkjesuffiks, som ofte er den eigentlege spørjinga og ikkje den som vart skriven inn i eit diagnostisk verktøy. Den siste linja spør den interne tenaren direkte, og omgår klientpolicyen; om det lukkast medan det vanlege oppslaget feilar, er sona i orden og ruttinga av spørjingar ikkje.

Negativ hurtiglagring forklarar forseinkinga etter ei retting

Negative svar vert hurtiglagra etter design, og RFC 2308 skildrar korleis levetida for den negative hurtiglagringa vert utleidd frå autoritetsposten til sona. Å rette ein post eller ein løysarregel garanterer derfor ikkje ei umiddelbar endring på klienten, og å gjenta eit oppslag som framleis returnerer det hurtiglagra svaret provar ingenting nytt. Berre ein annan svarar, eit anna namn eller ei tømd hurtiglagring gir friske prov.

Tøm den lokale hurtiglagringa, og gjenta deretter den same spørjinga mot den same svararen. På system som brukar den lokale løysartenesta er det éin kommando; på andre er det ein tenestestart eller eit plattformverkty, og det konkrete verktyet er mindre viktig enn å gjenta ein identisk test etterpå.

Skil namnet frå vegen

Når namnet er løyst til den forventa private adressa, er DNS ferdig som tema, og applikasjonsvegen vert det neste spørsmålet. Ein vert som svarar på oppslag men avviser ei tilkopling, har eit anna problem, og å halde fram med å justere løysarar etter eit korrekt svar er måten ei hending får tre urelaterte endringar. Samanlikn den løyste adressa med den tenesta faktisk lyttar på før du går ut frå at dei to stemmer.

Ta vare på utskrifta: spørjinga, svararen, koden og den løyste adressa. Den registreringa er òg det som gjer ein seinare rapport etterprøvbar, og det er skilnaden mellom ein diagnose og ei historie om ein tunnel som verka treg.