NXDOMAIN via en VPN betyder ikke tunneludfald

Det er fristende at læse et mislykket opslag som bevis på, at tunnelen er faldet sammen, især når navnet virkede ti minutter tidligere. Svaret siger noget andet. NXDOMAIN er en afsluttet DNS-transaktion, hvor en resolver har erklæret, at det forespurgte navn ikke findes; en brudt tunnel giver normalt tavshed, en timeout eller et opløsningsforsøg mod den forkerte server. Versionen af argumentet uden wireshark er én forespørgsel, én svarer og én svarkode, og den trio er værd at registrere, før du ændrer konfigurationen.

Hvad svaret faktisk viser

DNS adskiller resultater, som klienter ofte smelter sammen til én fejl. Et navn, der ikke findes, giver et negativt svar med koden NXDOMAIN, mens et navn, der findes, men ikke har en post af den ønskede type, giver et vellykket svar med en tom svarsektion. Begge ser ud som ingenting brugbart for en applikation, og kun det ene betyder, at navnet er forkert.

Forskellen afgør, hvor reparationen hører til. En manglende AAAA-post på en vært med en A-post er ikke en manglende vært, og at genudstede et certifikat eller genopbygge en tunnel for at jagte det spilder det eneste spor, der var tilgængeligt. Forskellen bestemmer også formen på opfølgningen: et navngivningsproblem rettes i zonen, og et typeproblem rettes ved at spørge efter den rigtige post eller ved at acceptere, at adressefamilien simpelthen mangler.

Myten: et manglende privat navn betyder, at tunnelen fejlede

Myten overlever, fordi de to begivenheder så ofte kommer sammen. En klient forbinder til VPN, operativsystemet beholder en resolver, det allerede stolede på, og det interne navn, det nu har brug for, spørges hos en server, der aldrig har hørt om den private zone. Den server svarer ærligt og negativt. Tunnelen bærer pakken; svaret handler blot om et navnerum, som svareren ikke betjener.

Split-horizon-opsætninger gør dette rutinemæssigt: det samme zonenavn findes offentligt og internt med forskelligt indhold, og kun den interne resolver kender de private poster. At få et negativt svar, der ser autoritativt ud, er derfor bevis for, hvilken resolver der svarede, ikke bevis for grænsefladens tilstand.

To konfigurationsdetaljer afgør udfaldet. Tunnelen skal skubbe eller vælge den interne resolver, og klienten skal anvende det valg på det navn, der slås op. En regel for hvert domæne, der navngiver et suffiks, som afviger lidt fra den post, du skrev, sender forespørgslen ad den offentlige vej, og svaret bliver korrekt og ubrugeligt.

Spørg den rigtige resolver med det rigtige navn

Registrér svareren, før du registrerer dommen. Et opslag, der ikke viser, hvilken server der svarede, kan ikke skelne et politikproblem fra et navnerumsproblem, og de to har uafhængige 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 linjer viser, hvad den lokale resolver besluttede, og hvem den ville spørge. +search-opslaget gengiver, hvad en applikation gør, når den tilføjer et søgesuffiks, hvilket ofte er den egentlige forespørgsel frem for den, der blev skrevet i et diagnostisk værktøj. Den sidste linje spørger den interne server direkte og omgår klientpolitikken; hvis det lykkes, mens det almindelige opslag fejler, er zonen i orden, og det er rutingen af forespørgsler ikke.

Negativ caching forklarer forsinkelsen efter en rettelse

Negative svar cachelagres efter design, og RFC 2308 beskriver, hvordan levetiden for den negative cache udledes af zonens autoritetspost. At rette en post eller en resolverregel garanterer derfor ikke en øjeblikkelig ændring på klienten, og at gentage et opslag, der bliver ved med at returnere det cachelagrede svar, beviser intet nyt. Kun en anden svarer, et andet navn eller en tømt cache giver friske beviser.

Tøm den lokale cache, og gentag derefter den samme forespørgsel mod den samme svarer. På systemer, der bruger den lokale resolvertjeneste, er det én kommando; på andre er det en genstart af tjenesten eller et platformsværktøj, og det konkrete værktøj betyder mindre end at gentage en identisk test bagefter.

Adskil navnet fra vejen

Når navnet er opløst til den forventede private adresse, er DNS færdigt som emne, og applikationsvejen bliver det næste spørgsmål. En vært, der svarer på opslag, men afviser en forbindelse, har et andet problem, og at fortsætte med at justere resolvere efter et korrekt svar er, hvordan en hændelse får tre uafhængige ændringer. Sammenlign den opløste adresse med den, tjenesten faktisk lytter på, før du antager, at de to er enige.

Gem optegnelsen: forespørgslen, svareren, koden og den opløste adresse. Den registrering er også det, der gør en senere rapport efterprøvbar, og det er forskellen mellem en diagnose og en historie om en tunnel, der virkede langsom.