nslookup sier at serveren er ukjent: det er bare en etikett

Koble til VPN, kjør nslookup, og headeren viser resolverens adresse med navnefeltet fylt ut som Unknown. Det ordet står over svaret, og de fleste slutter å lese før delen som betyr noe. Etiketten beskriver om resolveren har sitt eget omvendte navn; den sier ennå ingenting om hvorvidt vertsnavnet du spurte om ble slått opp. Å lukke det vinduet tidlig er hele kunsten her.

To forskjellige spørringer kan gi den visningen, og bare én av dem handler om problemet ditt. Å skille dem koster én ekstra kommando og sparer en ettermiddag med å redigere DNS-innstillinger som aldri var feil.

Hva verktøyet gjør før det svarer deg

nslookup kan prøve å finne et navn for serveradressen den er i ferd med å bruke, som er et omvendt oppslag i domenet in-addr.arpa eller ip6.arpa. Hvis den PTR-posten mangler, er filtrert av policy eller rett og slett ikke publisert, skriver verktøyet Unknown og går videre. Videresøket påvirkes ikke av den feilen, fordi det er et annet spørsmål sendt til samme server.

Derfor kan en privat resolver svare riktig på hvert bedriftsnavn og likevel virke anonym i verktøyets header. Adressen er kjent; navnet bak den er ikke, og verktøyet er ærlig om det mens det forblir litt teatralsk om ordet det velger.

Kjør de to spørringene med vilje

Spør om en vert du bryr deg om, og spør deretter om resolverens egen adresse. Den første forespørselen bærer navnet du trenger; den andre spør serveren om den kan navngi seg selv. Skrevet ut ser de slik ut: nslookup app.corp.example 10.77.0.53 for verten og nslookup 10.77.0.53 10.77.0.53 for resolverens omvendte navn.

Begge eksemplene er illustrative, så bytt dem ut med dine egne navn og adresser. Poenget er ikke den nøyaktige syntaksen, men skillet: de to kommandoene stiller forskjellige spørsmål og kan gi forskjellige resultater uten at noen av dem er en feil.

Tre resultater som ser like ut og ikke er det

En tidsavbrudd betyr at det ikke kom noe svar i det hele tatt, noe som peker på tilgjengelighet, filtrering eller feil serveradresse. Et negativt svar betyr at serveren svarte og sa at navnet ikke finnes, noe som peker på sonen eller suffikset. Et manglende omvendt navn betyr at serveren svarte på det andre spørsmålet uten noe nyttig, og videresvaret kan fortsatt ha vært perfekt. Tre resultater, tre eiere, og bare ett av dem handler om vertsnavnet du trengte.

Bare de to første beskriver en DNS-vei som feiler for applikasjonen din. Den tredje beskriver en post som aldri ble publisert, og å behandle den som en feil fører til endringer som ikke kan rette den, som å skrive om søkesuffikset til headeren ser vennligere ut.

Les seksjonene, ikke headeren

Under headeren skriver verktøyet ut svaret, autoriteten og eventuelle tilleggsposter. En korrekt adresse i svarseksjonen er resultatet du ønsket, selv når navnet i headeren er Unknown. Et tomt svar med en autoritativ avvisning er et annet utfall og fortjener sin egen undersøkelse.

Hold begge objektene eksplisitte i alt du sender til support: hvilket navn som ble spurt om, og hvilken server som ble spurt. Rapporter som bare nevner at DNS er ødelagt over VPN, tvinger neste person til å gjenoppbygge en test du allerede har kjørt.

Når et omvendt navn virkelig betyr noe

Noen tjenester bryr seg virkelig om PTR-poster: logging som slår opp klientadresser, kontroller av e-postomdømme eller administrative verktøy som viser navn. Hvis en av dem feiler, publiser posten eller reparer sonen som skal holde den. Det arbeidet er legitimt og adskilt fra spørsmålet om VPN videresender spørringer riktig.

Det smale poenget står: én manglende resolveretikett beviser ikke at videresøket gjennom tunnelen er ødelagt, og ett fungerende videresøk beviser ikke at hvert navn i sonen slås opp. Test navnet du faktisk trenger, og avgjør deretter hva ordet i headeren er verdt.