nslookup säger att servern är okänd: det är bara en etikett

Anslut VPN, kör nslookup, och rubriken visar resolverns adress med namnfältet ifyllt som Unknown. Det ordet står ovanför svaret, och de flesta slutar läsa före den del som spelar roll. Etiketten beskriver om resolvern har ett eget omvänt namn; den säger ännu inget om huruvida värdnamnet du frågade om löstes upp. Att stänga det fönstret tidigt är hela konsten här.

Två olika frågor kan ge den visningen, och bara en av dem handlar om ditt problem. Att skilja dem åt kostar ett extra kommando och sparar en eftermiddag med att redigera DNS-inställningar som aldrig var fel.

Vad verktyget gör innan det svarar dig

nslookup kan försöka hitta ett namn för serveradressen den ska använda, vilket är en omvänd sökning i domänen in-addr.arpa eller ip6.arpa. Om den PTR-posten saknas, filtreras av policy eller helt enkelt inte publiceras, skriver verktyget Unknown och går vidare. Framåtuppslagningen påverkas inte av det felet, eftersom det är en annan fråga som skickas till samma server.

Därför kan en privat resolver svara korrekt på varje företagsnamn och ändå verka anonym i verktygets rubrik. Adressen är känd; namnet bakom den är det inte, och verktyget är ärligt om det medan det förblir en aning teatraliskt kring ordet det väljer.

Kör de två frågorna med avsikt

Fråga om en värd du bryr dig om, och fråga sedan om resolverns egen adress. Den första förfrågan bär namnet du behöver; den andra frågar servern om den kan namnge sig själv. Utskrivna ser de ut så här: nslookup app.corp.example 10.77.0.53 för värden och nslookup 10.77.0.53 10.77.0.53 för resolverns omvända namn.

Båda exemplen är illustrativa, så byt ut dem mot dina egna namn och adresser. Poängen är inte den exakta syntaxen utan uppdelningen: de två kommandona ställer olika frågor och får ge olika resultat utan att något av dem är ett fel.

Tre resultat som ser likadana ut och inte är det

En tidsgräns innebär att inget svar kom alls, vilket pekar på nåbarhet, filtrering eller fel serveradress. Ett negativt svar innebär att servern svarade och sa att namnet inte finns, vilket pekar på zonen eller suffixet. Ett saknat omvänt namn innebär att servern svarade på den andra frågan utan något användbart, och framåtssvaret kan fortfarande ha varit perfekt. Tre resultat, tre ägare, och bara ett av dem handlar om värdnamnet du behövde.

Bara de två första beskriver en DNS-väg som misslyckas för din applikation. Den tredje beskriver en post som aldrig publicerades, och att behandla den som ett fel leder till ändringar som inte kan åtgärda den, som att skriva om söksuffixet tills rubriken ser vänligare ut.

Läs avsnitten, inte rubriken

Under rubriken skriver verktyget ut svaret, auktoriteten och eventuella ytterligare poster. En korrekt adress i svarsavsnittet är resultatet du ville ha, även när namnet i rubriken är Unknown. Ett tomt svar med en auktoritativ avvisning är ett annat utfall och förtjänar sin egen undersökning.

Håll båda objekten uttryckliga i allt du skickar till supporten: vilket namn som efterfrågades och vilken server som tillfrågades. Rapporter som bara nämner att DNS är trasigt över VPN tvingar nästa person att återskapa ett test du redan har gjort.

När ett omvänt namn verkligen spelar roll

Vissa tjänster bryr sig verkligen om PTR-poster: loggning som löser klientadresser, kontroller av e-postrykte eller administrativa verktyg som visar namn. Om någon av dem misslyckas, publicera posten eller reparera zonen som borde hålla den. Det arbetet är legitimt och skilt från frågan om VPN vidarebefordrar frågor korrekt.

Den smala poängen står kvar: en saknad resolveretikett bevisar inte att framåtuppslagningen genom tunneln är trasig, och en fungerande framåtsökning bevisar inte att varje namn i zonen löses upp. Testa namnet du faktiskt behöver och avgör sedan vad ordet i rubriken är värt.