Wenn (und warum) nslookup unerwartete Ergebnisse zeigt

Ein Kunde kam neulich mit einem speziellen Problem auf mich zu. Die DNS-Namensauflösung in seinem Netzwerk erzeugte Resultate, mit denen er nicht gerechnet hatte. Wie viele Administratoren nutzte er nslookup, um bei möglichen Netzwerkproblemen an Clients und Servern die Konnektivität und die Namensauflösung zu prüfen. Dabei stellte er fest, dass damit ausschließlich Fehler gemeldet wurden. Das Seltsame daran: nslookup beantwortete niemals seine Anforderung, etwa www.heise.de aufzulösen (was bei deutschen Admins wohl der beliebteste DNS-Test ist), sondern hängte immer den Namen seiner internen AD-Domäne an und gab dabei stets dieselbe IP-Adresse zurück – die mit seinem LAN aber überhaupt nichts zu tun hatte. Versuchte er dann, heise.de im Browser zu öffnen, ging das problemlos.

Was war hier los? Hatte nslookup einen Fehler, wie er vermutete?

Nein. Das Hilfsprogramm nslookup arbeitete genau so, wie es das immer tut – und wie es das auch tun muss. Das Problem lag tatsächlich an einer ungünstigen Konfiguration seiner AD-Domäne. Ein näherer Blick auf die Hintergründe deckte dies auf.

Beim Einrichten des Active Directory vor vielen Jahren hatte der ausführende Administrator nicht den DNS-Namen des Unternehmens verwendet, sondern einen generischen Begriff – sagen wir der Anonymität halber: firma.de. Später hatte man dann festgestellt, dass diese Idee nicht besonders gut war, denn auf diese Weise konnte man aus dem LAN die Webadresse www.firma.de nicht erreichen: Der AD-integrierte DNS-Server war ja der Meinung, diesen Namen selbst zu verwalten, und verwies daher nicht auf den externen Webserver. Das war bekannt und nachvollziehbar, damit konnte man leben. Aber wie hängt das mit dem nslookup-Problem zusammen, das der Kunde hatte?

Anders als viele Administratoren vermuten, ist nslookup kein Profi-Tool, um die Namensauflösung eines Computers zu überprüfen. Tatsächlich dient das Werkzeug dazu, die Daten eines konkreten DNS-Servers abzufragen. Standardmäßig handelt es sich dabei um den DNS-Server, der in der IP-Konfiguration des Rechners eingetragen ist. Dabei arbeitet nslookup grundsätzlich anders als der „normale“ Client-Resolver, der innerhalb des Betriebssystems die Namensauflösung erledigt.

Dieser Resolver nämlich nimmt den Namen entgegen, den der Anwender bzw. die jeweilige Applikation angibt, und versucht diesen in eine IP-Adresse aufzulösen. Sollte es sich um einen Kurznamen handeln, also nicht den FQDN, dann wird der Resolver nach einem erfolglosen Versuch die DNS-Suffixe anhängen, die für den Rechner konfiguriert sind, und zwar versuchsweise einen nach dem anderen. Sollte dies auch nicht zum Erfolg führen, dann gibt es eine Fehlermeldung an die Applikation. Man kann dies mit einem simplen „ping“ gut nchvollziehen: pingt man einen internen Rechner mit seinem Kurznamen an, so gibt ping in der Regel den FQDN und die zugehörige IP-Adresse zurück. Ist dies erfolglos, so kann man selbst statt des Kurznamens den FQDN angeben, was dann meist gelingt.

nslookup hingegen arbeitet genau andersherum: Es wird immer an den angegebenen Namen das vollständige DNS-Suffix des lokalen Rechners anhängen, auch wenn es sich bei der Angabe schon um den vollständigen FQDN gehandelt hat. Führt dies nicht zum Erfolg, so probiert nslookup die Anfrage an den DNS-Server erneut, lässt diesmal aber das Suffix weg. Falls dies irgendwann zu einem korrekten Namen führt, den der DNS-Server auflösen kann, so gibt nslookup die Antwort des Servers aus. Von diesem Vorgang sieht man normalerweise nichts, weil nslookup diese Zwischenschritte verbirgt und nur die Antwort ausgibt, die am Ende des Vorgangs steht.

Siehe dazu:

[NSLookup]
http://technet.microsoft.com/de-de/library/cc725991(v=WS.10).aspx

[Der Befehl nslookup]
http://www.datahelpsolution.de/prog/allg/nslookup-befehl.htm

[nslookup – Linux Manpage]
http://linux.die.net/man/1/nslookup

Merke: nslookup ist kein Tool, um die eigentliche DNS-Namensauflösung zu prüfen. Hierfür benötigt man in der Regel den Client-Resolver, den man am einfachsten über einen Webbrowser oder mit ping anspricht.

Mit dem Schalter d2 (erweiterte Debug-Informationen) kann man nslookup anweisen, alle Schritte zu dokumentieren. Das folgende Beispiel belegt dies: Auf einem Rechner, der in der internen Domäne faq-o-matic.net Mitglied ist, wird nslookup nach der Adresse des Hosts www.heise.de gefragt. Zunächst hängt das Tool also „faq-o-matic.net“ als Suffix an, was die Angabe „www.heise.de.faq-o-matic.net“ ergibt. Diese Frage gibt es an den Standard-DNS-Server weiter, welcher hier (wie in den meisten Windows-Netzen) ein Domänencontroller ist (im Beispiel heißt er „DC01“). Einen solchen Hostnamen kennt der DNS-Server für faq-o-matic.net nicht, daher fragt nslookup noch einmal ohne das Suffix, also nur nach „www.heise.de“. Dies führt zum Erfolg, weil der DNS-Server sich nun nicht selbst zuständig für den Domänennamen sieht und daher per DNS-Forwarding einen anderen DNS-Server fragt. Dieser kennt den Eintrag, welchen der interne DNS-Server dann als „nicht autorisierende Antwort“ zurückgibt.

Microsoft Windows [Version 6.2.9200]
(c) 2012 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\ICH>nslookup
Standardserver:  dc01.faq-o-matic.net
Address:  192.168.8.100

> set d2
> www.heise.de
Server:  dc01.faq-o-matic.net
Address:  192.168.8.100

------------
SendRequest(), len 42
    HEADER:
        opcode = QUERY, id = 2, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        www.heise.de.faq-o-matic.net, type = A, class = IN

------------
------------
Got answer (105 bytes):
    HEADER:
        opcode = QUERY, id = 2, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        www.heise.de.faq-o-matic.net, type = A, class = IN
    AUTHORITY RECORDS:
    ->  faq-o-matic.net
        type = SOA, class = IN, dlen = 40
        ttl = 3600 (1 hour)
        primary name server = dc01.faq-o-matic.net
        responsible mail addr = hostmaster.faq-o-matic.net
        serial  = 21307
        refresh = 900 (15 mins)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 3600 (1 hour)

------------
------------
SendRequest(), len 42
    HEADER:
        opcode = QUERY, id = 3, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        www.heise.de.faq-o-matic.net, type = AAAA, class = IN

------------
------------
Got answer (105 bytes):
    HEADER:
        opcode = QUERY, id = 3, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        www.heise.de.faq-o-matic.net, type = AAAA, class = IN
    AUTHORITY RECORDS:
    ->  faq-o-matic.net
        type = SOA, class = IN, dlen = 40
        ttl = 3600 (1 hour)
        primary name server = dc01.faq-o-matic.net
        responsible mail addr = hostmaster.faq-o-matic.net
        serial  = 21307
        refresh = 900 (15 mins)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 3600 (1 hour)

------------
------------
SendRequest(), len 30
    HEADER:
        opcode = QUERY, id = 4, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        www.heise.de, type = A, class = IN

------------
------------
Got answer (46 bytes):
    HEADER:
        opcode = QUERY, id = 4, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        www.heise.de, type = A, class = IN
    ANSWERS:
    ->  www.heise.de
        type = A, class = IN, dlen = 4
        internet address = 193.99.144.85
        ttl = 3339 (55 mins 39 secs)

------------
Nicht autorisierende Antwort:
------------
SendRequest(), len 30
    HEADER:
        opcode = QUERY, id = 5, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        www.heise.de, type = AAAA, class = IN

------------
------------
Got answer (58 bytes):
    HEADER:
        opcode = QUERY, id = 5, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        www.heise.de, type = AAAA, class = IN
    ANSWERS:
    ->  www.heise.de
        type = AAAA, class = IN, dlen = 16
        AAAA IPv6 address = 2a02:2e0:3fe:100::7
        ttl = 3600 (1 hour)

------------
Name:    www.heise.de
Addresses:  2a02:2e0:3fe:100::7
          193.99.144.85

>

Man kann nslookup auch mitteilen, dass es das DNS-Suffix nicht anhängen soll. Dazu hängt man an den FQDN hinten noch einen Punkt an (im Beispiel wäre das also: „www.heise.de.“), was nach der DNS-Logik bedeutet, dass „de“ schon die First Level Domain ist, an die nichts mehr anzuhängen ist. Dadurch erfolgt die Namensauflösung gleich gegen den zuständigen (externen) DNS-Server.

Das erklärt das Problem des eingangs erwähnten Kunden aber noch nicht vollständig. Nachdem nun aber nachgewiesen war, dass nslookup nicht fehlerhaft, sondern korrekt arbeitet, lag der Schluss nahe, dass der Fehler außerhalb des LANs entstand. Etwas Recherche ergab, dass nslookup immer dieselbe (falsche) IP-Adresse zurückgab, egal, welchen externen Hostnamen man nachfragte. Diese Adresse gehörte dem Webserver der Internet-Webdomain firma.de. Ein solches Verhalten ist nach den DNS-Regularien nicht korrekt. Tatsächlich trifft man es aber immer mal wieder an.

Wie sich herausstellte, war der DNS-Server des „rechtmäßigen“ Besitzers der Domain firma.de so konfiguriert, dass er bei unbekannten Hostnamen immer die IP-Adresse des eigenen Webservers zurückgab. Bequem für den Betreiber, weil so auch Besucher, die sich bei dem Hostnamen vertippen, immer auf den Webserver kommen. Aus naheliegenden Gründen ist so eine Konfiguration aber nicht gut, weil sie zu unerwarteten Ergebnissen führt.

Eine einfache Lösung gab es für den Kunden nicht. Zu den Auswirkungen des Problems hatte er selbst beigetragen, als er seiner AD-Domäne einen DNS-Namen gegeben hatte, der nicht nur im Internet verwendet wird, sondern über den er auch selbst keine Hoheit hat. Dies zu ändern, hätte ein Umbenennen der AD-Domäne erfordert – realistisch also einen kompletten Neuaufbau mit vollständiger Migration aller Ressourcen. Als Workaround bleibt nur, die Arbeitsweise beim Troubleshooting umzustellen: Prüfen der Namensauflösung immer über den Client-Resolver, also mit dem Browser oder über ping. Prüfen der DNS-Daten mit nslookup, aber dann mit einem „Root-Punkt“ am Ende des FQDN.