nslookup seier at tenaren er ukjend: det er berre ei etikett
Resolveren sitt eige omvende namn og eit mislukka videresøk er ulike resultat. Les svarseksjonen før du endrar noka VPN-DNS-innstilling.
Kopla til VPN, køyr nslookup, og hovudet viser adressa til resolveren med namnefeltet fylt ut som Unknown. Det ordet står over svaret, og dei fleste sluttar å lese før delen som betyr noko. Etiketten skildrar om resolveren har eit eige omvende namn; han seier enno ingenting om vertsnamnet du spurde om vart slått opp. Å lukke det vindauget tidleg er heile kunsten her.
To ulike spørjingar kan gje den visinga, og berre éi av dei handlar om problemet ditt. Å skilje dei kostar éin ekstra kommando og sparer ein ettermiddag med å redigere DNS-innstillingar som aldri var feil.
Kva verktøyet gjer før det svarar deg
nslookup kan prøve å finne eit namn for tenaradressa det er i ferd med å bruke, som er eit omvendt oppslag i domenet in-addr.arpa eller ip6.arpa. Viss den PTR-posten manglar, er filtrert av policy eller rett og slett ikkje publisert, skriv verktøyet Unknown og går vidare. Videresøket blir ikkje påverka av den feilen, fordi det er eit anna spørsmål sendt til same tenar.
Difor kan ein privat resolver svare rett på kvart firmanamn og likevel verke anonym i hovudet til verktøyet. Adressa er kjend; namnet bak henne er det ikkje, og verktøyet er ærleg om det medan det held fram med å vere litt teatralsk om ordet det vel.
Køyr dei to spørjingane med vilje
Spør om ein vert du bryr deg om, og spør deretter om adressa til resolveren sjølv. Den første førespurnaden ber namnet du treng; den andre spør tenaren om han kan namngje seg sjølv. Skrivne ut ser dei slik ut: nslookup app.corp.example 10.77.0.53 for verten og nslookup 10.77.0.53 10.77.0.53 for det omvende namnet til resolveren.
Båe døma er illustrerande, så byt dei ut med dine eigne namn og adresser. Poenget er ikkje den nøyaktige syntaksen, men skillet: dei to kommandokøyr er ulike, og dei kan gje ulike resultat utan at nokon av dei er ein feil.
Tre resultat som ser like ut og ikkje er det
Eit tidsavbrot betyr at det ikkje kom noko svar i det heile, noko som peikar på tilgjenge, filtrering eller feil tenaradresse. Eit negativt svar betyr at tenaren svara og sa at namnet ikkje finst, noko som peikar på sona eller suffikset. Eit manglande omvendt namn betyr at tenaren svara på det andre spørsmålet utan noko nyttig, og videresvaret kan framleis ha vore perfekt. Tre resultat, tre eigarar, og berre eitt av dei handlar om vertsnamnet du trong.
Berre dei to første skildrar ein DNS-veg som feilar for applikasjonen din. Den tredje skildrar ein post som aldri vart publisert, og å handsame han som ein feil fører til endringar som ikkje kan rette han, som å skrive om søkjesuffikset til hovudet ser venlegare ut.
Les seksjonane, ikkje hovudet
Under hovudet skriv verktøyet ut svaret, autoriteten og eventuelle tilleggspostar. Ei rett adresse i svarseksjonen er resultatet du ønskte, sjølv når namnet i hovudet er Unknown. Eit tomt svar med ei autoritativ avvising er eit anna utfall og fortener si eiga gransking.
Hald båe objekta eksplisitte i alt du sender til støtte: kva namn som vart spurt om, og kva tenar som vart spurt. Rapportar som berre nemner at DNS er øydelagt over VPN, tvingar neste person til å byggje opp att ein test du alt har køyrt.
Når eit omvende namn verkeleg betyr noko
Nokre tenester bryr seg verkeleg om PTR-postar: logging som slår opp klientadresser, kontrollar av e-postomdøme eller administrative verktøy som viser namn. Viss ein av dei feilar, publiser posten eller reparer sona som skal halde han. Det arbeidet er legitimt og skilt frå spørsmålet om VPN videresender spørjingar rett.
Det smale poenget står: éi manglande resolveretikett beviser ikkje at videresøket gjennom tunnelen er øydelagt, og eitt fungerande videresøk beviser ikkje at kvart namn i sona blir slått opp. Test namnet du faktisk treng, og avgjer deretter kva ordet i hovudet er verdt.