Zuständige Nameserver und TTL eines DNS-Eintrages abfragen

[Jörg Reinholz]

Moin!

es ging in diesem Thread um eine Second-Level-Domain und es ist genau der Fall eingetreten, dass im whois, wo misterunknown nachgeschlagen hat, falsche Informationen standen (falsch in dem Sinne, dass sie nicht den Stand im DNS abgebildet haben);

Woraus entnimmst Du das? Ich glaube nicht, dass es hier eine Diskrepanz zwischen den authorisierten Nameservern gab oder das misterunknown eine solche je fest gestellt hat:

ich bei meinem Provider die Domain dejungs.de auf meine Nameserver umgestellt, kann aber den Namen nicht mehr auflösen; in der Antwort steht immer nur "SERVFAIL". Hat jemand eine Idee, wo der Fehler liegen könnte? Der Eintrag bei der Denic scheint korrekt zu sein.

dejungs.de ist, wie Du schon schreibst, eine Second-Level-Domain. Also erscheinen die korrekten DNS-Server für diese Domain im whois.

hätte er wie ich direkt im DNS nachgesehen, hätte er sofort gesehen, warum seine Namensauflösung noch nicht so funktioniert, wie er sich das vorstellte.

Äh. Nein. Dazu hätte er von den cachenden DNS bei Providern, Firme, selbst in DSL-Routern wissen müssen.

Im übrigen hast Du auf

~> nslookup -type=soa www.example.org
~> dig www.example.org +trace

nicht hingewiesen, auch nicht auf die Idee, einen der root-server zu befragen, sondern lediglich dig und nslookup erwähnt, was im Hinblick darauf, dass ohne diese "längst nicht jedem bekannten" Optionen der "authorative" Nameserver regelmäßig nicht benannt wird, deutlich weniger zielführend ist als das von mir genannte whois.

Exkurs: DNS-Abfrage zu Fuß über die root-server

Die gegenwärtig 13 root-server sind

• a.root-servers.net
• b.root-servers.net
• …
• m.root-servers.net

Die kann befragen,

~> dig example.org @l.root-servers.net
…
;; AUTHORITY SECTION:
org.                    172800  IN      NS      a0.org.afilias-nst.info.
org.                    172800  IN      NS      a2.org.afilias-nst.info.
org.                    172800  IN      NS      b0.org.afilias-nst.org.
org.                    172800  IN      NS      b2.org.afilias-nst.org.
org.                    172800  IN      NS      c0.org.afilias-nst.info.
org.                    172800  IN      NS      d0.org.afilias-nst.org.
…

was zwar nicht zur IP-Adresse aber immerhin unter "AUTHORITY SECTION" zur Liste der für die Top-Level-Domain zuständigen Nameserver führt, die (einen von denen) man sodann auch gleich fragt:

~> dig example.org @a0.org.afilias-nst.info
…
;; AUTHORITY SECTION:
example.org.            86400   IN      NS      a.iana-servers.net.
example.org.            86400   IN      NS      b.iana-servers.net.
…

um wiederum unter "AUTHORITY SECTION" die Liste der tatsächlich für die Second-Level-Domain zuständigen Nameserver zu erhalten. Geht es jetzt um eine Third-Level-Domain muss man den Vorgang halt wiederholen.

/Exkurs

Aber auch das muss man erst mal wissen und ein dünner Hinweis auf dig oder nslookup ist da nicht wirklich zielführend.

... lohnt es sich nicht hierfür im Whois nachzuschlagen.

Nun. Ja. Wenn man die oben genannten Optionen bzw. Optionsparameter nicht kennt oder die Mühe scheut, hat man mit whois die einzige mir bekannte Chance um festzustellen, dass es der neue Nameserver auch hinterlegt wurde. Aber irgendwie kommen wir hier in den Bereich der Meinung und darüber hinaus in einen, wo man Umstände berücksichtigen muss welche nicht bekannt sind. Und das beginnt hier beim Wissen des Fragestellers.

Fakt ist, man mit whois ganz einfach mal den authorisierten Nameservers sehen (und weiß dann ob der Dienstleister die Umstellung schon veranlasst hat oder nicht.) Danach kann man die Kette der Caches testen - was natürlich nur geht, soweit man vom Caching weiß und diese Caches überhaupt kennt (nicht jedes DSL-Modem gibt den verwendeten DNS preis) oder Zugriff hat (DNS in fremden Netzwerken).

Und das Problem war ja die Kette der Caches, bzw. deren bloße Existenz.

Noch ein Exkurs

Die TTL ist nur auf den zuständigen Nameservern, also an der Quelle des DNS-Eintrages konstant. Die Caches ziehen von der erhaltenen TTL immer das Alter der gecachten Information ab, so dass sich die effektive TTL nicht erhöht, wenn mehrere Caches beteiligt sind. Wenn man jetzt über das Cachen spricht, dann sollte aber auch gleich erwähnen, wo man die die TTL sieht:

a) dig

;; ANSWER SECTION:
example.org.            5       IN      A       93.184.216.34

  ^                     ^                       ^
hostname                TTL                     IP(v4)- Adresse

mit nslookup weiß ich nur diesen Weg um an die TTL zu kommen (Ich hab ja unter den von mir betreuten Linuxen regelmäßig dig zur Verfügung):

~$ nslookup

> set debug
> dejungs.de

    QUESTIONS:
        dejungs.de, type = A, class = IN
    ANSWERS:
    ->  dejungs.de
        internet address = 46.4.101.180
        ttl = 80851  # Da steht die des befragten Servers/Caches den man auch wechseln kann.

Jörg Reinholz