nslookup siger, at serveren er ukendt: det er kun en etiket

Tilslut VPN, kør nslookup, og headeren viser resolverens adresse med navnefeltet udfyldt som Unknown. Det ord står over svaret, og de fleste holder op med at læse før den del, der betyder noget. Etiketten beskriver, om resolveren har sit eget omvendte navn; den siger endnu intet om, hvorvidt det værtsnavn, du spurgte om, blev opløst. At lukke det vindue tidligt er hele kunsten her.

To forskellige forespørgsler kan give den visning, og kun én af dem handler om dit problem. At skille dem ad koster én ekstra kommando og sparer en eftermiddag med at redigere DNS-indstillinger, som aldrig var forkerte.

Hvad værktøjet gør, før det svarer dig

nslookup kan forsøge at finde et navn til den serveradresse, den er ved at bruge, hvilket er en omvendt forespørgsel i domænet in-addr.arpa eller ip6.arpa. Hvis den PTR-post mangler, er filtreret af politik eller slet ikke offentliggjort, udskriver værktøjet Unknown og går videre. Videresøgningen påvirkes ikke af den fejl, fordi det er et andet spørgsmål sendt til den samme server.

Det er derfor, en privat resolver kan svare korrekt på alle virksomhedsnavne og stadig fremstå anonym i værktøjets header. Adressen er kendt; navnet bag den er ikke, og værktøjet er ærligt om det, mens det forbliver en smule teatralsk om det ord, det vælger.

Kør de to forespørgsler med vilje

Spørg til en vært, du bekymrer dig om, og spørg derefter til resolverens egen adresse. Den første anmodning bærer det navn, du har brug for; den anden spørger serveren, om den kan navngive sig selv. Skrevet ud ser de sådan ud: nslookup app.corp.example 10.77.0.53 for værten og nslookup 10.77.0.53 10.77.0.53 for resolverens omvendte navn.

Begge eksempler er illustrative, så erstat dem med dine egne navne og adresser. Pointen er ikke den præcise syntaks, men adskillelsen: de to kommandoer stiller forskellige spørgsmål og må give forskellige resultater, uden at nogen af dem er en fejl.

Tre resultater, der ligner hinanden og ikke er det

En timeout betyder, at der slet ikke kom et svar, hvilket peger på tilgængelighed, filtrering eller den forkerte serveradresse. Et negativt svar betyder, at serveren svarede og sagde, at navnet ikke findes, hvilket peger på zonen eller suffikset. Et manglende omvendt navn betyder, at serveren svarede på det andet spørgsmål uden noget nyttigt, og det videresvarede svar kan stadig have været perfekt. Tre resultater, tre ejere, og kun ét af dem handler om det værtsnavn, du havde brug for.

Kun de to første beskriver en DNS-vej, der fejler for din applikation. Det tredje beskriver en post, der aldrig blev offentliggjort, og at behandle det som en fejl fører til ændringer, der ikke kan rette det, som at omskrive søgesuffikset, indtil headeren ser venligere ud.

Læs afsnittene, ikke headeren

Under headeren udskriver værktøjet svaret, autoriteten og eventuelle yderligere poster. En korrekt adresse i svarafsnittet er det resultat, du ønskede, selv når headerens navn er Unknown. Et tomt svar med en autoritativ afvisning er et andet udfald og fortjener sin egen undersøgelse.

Hold begge objekter eksplicitte i alt, hvad du sender til support: hvilket navn der blev forespurgt, og hvilken server der blev spurgt. Rapporter, der kun nævner, at DNS er brudt over VPN, tvinger den næste person til at genskabe en test, du allerede har kørt.

Når et omvendt navn virkelig betyder noget

Nogle tjenester bekymrer sig faktisk om PTR-poster: logning, der opløser klientadresser, checks af mailomdømme eller administrative værktøjer, der viser navne. Hvis en af dem fejler, skal du offentliggøre posten eller rette den zone, der burde indeholde den. Det arbejde er legitimt og adskilt fra spørgsmålet om, hvorvidt VPN videresender forespørgsler korrekt.

Den snævre pointe står: én manglende resolveretiket beviser ikke, at videresøgning gennem tunnelen er brudt, og ét fungerende videresøg beviser ikke, at hvert navn i zonen opløses. Test det navn, du faktisk har brug for, og beslut derefter, hvad headerens ord er værd.