NXDOMAIN over en VPN betyr ikke at tunnelen er nede

Det er fristende å lese ett mislykket oppslag som bevis på at tunnelen kollapset, spesielt når navnet virket ti minutter tidligere. Svaret sier noe annet. NXDOMAIN er en fullført DNS-transaksjon der en resolver erklærte at navnet som ble spurt om ikke finnes; en brutt tunnel gir vanligvis stillhet, en tidsavbrudd eller et oppløsningsforsøk mot feil server. Versjonen av argumentet uten wireshark er én spørring, én svarer og én svarkode, og denne trioen er verdt å registrere før noen konfigurasjonsendring.

Hva svaret faktisk beviser

DNS skiller utfall som klienter ofte slår sammen til én feil. Et navn som ikke finnes gir et negativt svar med koden NXDOMAIN, mens et navn som finnes men ikke har noen post av den etterspurte typen gir et vellykket svar med en tom svardel. Begge ser ut som ingenting nyttig for en applikasjon, og bare én av dem betyr at navnet er feil.

Den forskjellen avgjør hvor reparasjonen hører hjemme. En manglende AAAA-post på en vert som har en A-post er ikke en manglende vert, og å utstede et sertifikat på nytt eller bygge tunnelen på nytt for å jage det sløser med det eneste sporet som var tilgjengelig. Forskjellen bestemmer også formen på oppfølgingen: et navneproblem rettes i sonen, og et typeproblem rettes ved å spørre etter riktig post eller ved å akseptere at adressefamilien rett og slett mangler.

Myten: et manglende privat navn betyr at tunnelen feilet

Myten overlever fordi de to hendelsene så ofte kommer sammen. En klient kobler til VPN, operativsystemet beholder en resolver det allerede stolte på, og det interne navnet det nå trenger, spørres hos en server som aldri har hørt om den private sonen. Den serveren svarer ærlig og negativt. Tunnelen bærer pakken; svaret handler rett og slett om et navnerom som svareren ikke betjener.

Split-horizon-oppsett gjør dette rutinemessig: det samme sonenavnet finnes offentlig og internt med ulikt innhold, og bare den interne resolveren kjenner de private postene. Å få et negativt svar som ser autoritativt ut er derfor bevis for hvilken resolver som svarte, ikke bevis for tilstanden til grensesnittet.

To konfigurasjonsdetaljer avgjør utfallet. Tunnelen må skyve eller velge den interne resolveren, og klienten må bruke det valget på navnet som slås opp. En regel per domene som navngir et suffiks som avviker litt fra posten du skrev, sender spørringen via den offentlige veien, og svaret blir korrekt og ubrukelig.

Spør den riktige resolveren med det riktige navnet

Registrer svareren før du registrerer dommen. Et oppslag som ikke viser hvilken server som svarte, kan ikke skille et policyproblem fra et navneromsproblem, og de to har urelaterte rettelser.

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 to første linjene viser hva den lokale resolveren bestemte og hvem den ville spørre. Oppslaget +search gjengir hva en applikasjon gjør når den legger til et søkesuffiks, som ofte er den egentlige spørringen og ikke den som ble skrevet inn i et diagnostisk verktøy. Den siste linjen spør den interne serveren direkte, og omgår klientpolicyen; hvis det lykkes mens det vanlige oppslaget feiler, er sonen i orden og rutingen av spørringer ikke.

Negativ hurtiglagring forklarer forsinkelsen etter en rettelse

Negative svar hurtiglagres ved design, og RFC 2308 beskriver hvordan levetiden for den negative hurtiglagringen utledes fra sonens autoritetspost. Å rette en post eller en resolverregel garanterer derfor ikke en umiddelbar endring på klienten, og å gjenta et oppslag som fortsatt returnerer det hurtiglagrede svaret beviser ingenting nytt. Bare en annen svarer, et annet navn eller en tømt hurtiglagring gir ferske bevis.

Tøm den lokale hurtiglagringen, og gjenta deretter den samme spørringen mot den samme svareren. På systemer som bruker den lokale resolvertjenesten er det én kommando; på andre er det en tjenestegenstart eller et plattformverktøy, og det konkrete verktøyet er mindre viktig enn å gjenta en identisk test etterpå.

Skill navnet fra veien

Når navnet er løst til den forventede private adressen, er DNS ferdig som tema, og applikasjonsveien blir det neste spørsmålet. En vert som svarer på oppslag men avviser en tilkobling, har et annet problem, og å fortsette å justere resolvere etter et korrekt svar er måten en hendelse får tre urelaterte endringer. Sammenlign den løste adressen med den tjenesten faktisk lytter på før du antar at de to stemmer.

Ta vare på utskriften: spørringen, svareren, koden og den løste adressen. Den registreringen er også det som gjør en senere rapport etterprøvbar, og det er forskjellen mellom en diagnose og en historie om en tunnel som virket treg.