Ein neuer A Record und nslookup dreht durch

Für eine neue Seite wurde eine temporäre Subdomain benötigt. Da wir einen Hidden Primary DNS betreiben, war das Anlegen des A Records nur ein formaler Akt. Viel interessanter war der Effekt, der sich daraus ergab:
Änderungen sprechen sich im DNS nur langsam rum, das dürfte allgemein bekannt sein.

Um zu testen ob der DNS Server des eigenen Providers bereits die aktuellen Änderungen kennt, gibt es ebenfalls mehrere Methoden. Eine simple und schnelle ist es, die neu angelegte Domain im Browser zu öffnen und zu schauen, ob das Ergebnis den Erwartungen entspricht.

Da dieser Test versagte löste ich den Namen mit nslookup auf – und hier kam die Überraschung: nslookup zeigte mir die richtige IP Adresse. Also warum versagte der Browsertest?

Aus purer Verzweiflung startete ich nslookup erneut und hier ergab sich die zweite Überraschung: Dieses Mal zeigte mir nslookup eine IP Adresse, welche aus einem Wildcard-Eintrag im DNS stammte.

Dieses Wechselspiel ließ sich beliebig reproduzieren. Immer war die Antwort abwechselnd “richtige IP” und dann wieder “falsche IP”.

So etwas hatte ich bislang noch nie gesehen. War es ein Bug im nslookup den bislang noch niemand gefunden hatte? War es irgendein Cache auf meinem Computer oder im DSL Router? Um auf ganz Sicher zu gehen leerte ich den DNS Auflösungscache auf dem Computer (ipconfig /flushdns) und startete den DSL Router durch.
Selbes Ergebnis. Ich stieg tiefer ein und öffnete mir eine eigene nslookup Session. Wie es der Zufall wollte, bekam ich nun nur die richtige IP angezeigt, egal wie oft ich fragte.

Was war denn das für ein Verhalten? Wenn ich mit nslookup (domainname) eine Anfrage an den DNS stellte wechselte die IP von Falsch <-> Richtig und wenn ich nslookup startete und nach (domainname) fragte, blieb die Adresse gleich? WTF?

Die Lösung dieses Phänomens brachte ein Blick in die DSL Router Konfiguration. Für die externe Netzwerkkarte war ein primärer und ein sekundärer DNS Server eingetragen.

Über nslookup fragte ich zuerst den einen und anschlißend den sekundären ab. Das Ergebnis: Einer kannte die richtige IP, der andere nicht.

Der DSL Router hat also – wahrscheinlich um den Traffic nicht auf einen DNS Server zu konzentrieren – abwechselnd den primären und den sekundären DNS Server befragt. Da nur einer von beiden die aktuelle IP der Subdomain kannte, brachte der andere das falsche Ergebnis – und der Browsertest scheiterte (am timing )