Jeder DNS-Server, der mit dem Internet verbunden ist, verfügt wahrscheinlich über eine Kopie der named.root Datei von InterNIC, die die named.root für das gesamte Internet auflistet. Diese Datei lässt sich sehr einfach mit dem Build-it-yourself-Modus mit dig holen.
dig +nocmd . NS +noall +answer +additional
Verglichen mit der Ausgabe auf ftp://ftp.internic.net/domain/named.root werden die TTL-Werte etwas kürzer sein, aber ansonsten ist die Ausgabe genauso aktuell.
Wem traceroute bekannt ist und der Weg, den die Pakete von Punkt A nach Punkt B nehmen, wird diese Möglichkeit auch bei dig zu schätzen wissen. Ähnliche Möglichkeiten bietet die +trace Option.
dig linuxmaker.de +trace
Deutlich sichtbar ist der Weg zu den Root-Nameservern, über die Server, die für alle *.de-Domains zuständig sind, und schließlich zu den Nameservern, die für linuxmaker.de verantwortlich sind.
Macht der DNS-Administrator Änderungen an den DNS-Dateien und will wissen, ob die Nameserver nach wie vor die alten Daten pusht, dann ist die Option +nssearch hilfreich.
dig linuxmaker.com +nssearch
Hier werden alle SOA-Einträge geliefert. Während dagegen das Resultat dieses Befehls ausschließlich die Serial Number und die IP-Adresse des jeweilgen Hosts liefert.
dig linuxmaker.com +nssearch | cut -d' ' -f4,11
Die Time to live (TTL) ist die Gültigkeitsdauer, die Daten in Rechnernetzen mitgegeben wird. Wenn der lokale DNS-Server nach einer Internetadresse gefragt, ermittelt der Server, wo er eine autoritative Antwort finden kann und fragt danach. Sobald der Server eine Antwort erhält, behält er die Antwort in einem lokalen Cache, sodass sie, wenn die gleiche IP-Adresse kurze Zeit später erneut angefordert wird, die Antwort schnell liefern kann, ohne das Internet erneut zu durchsuchen zu müssen.
Wenn Domänenadministratoren ihre DNS-Einträge konfigurieren, entscheiden sie, wie lange die Datensätze in Remotecaches verbleiben sollen. Dies ist die TTL-Nummer, die generell in Sekunden angegeben wird.
In der Regel speichert ein Remote-Server diese Datensätze nur für die von der TTL angegebene Zeitspanne in seinem Cache zwischen. Danach löscht der Remote-Server seinen lokalen Cache wieder und fragt erneut nach einer autoritativen Antwort.
Wenn dig verwendet wird, um einen DNS-Server bezüglich eines bestimmten Datensatzes abzufragen, teilt der Server dig die Zeit in Sekunden mit, die der Datensatz im Cache verbleiben wird.
Dieses Verhalten lässt sich beobachten:
dig +nocmd google.com MX +noall +answer
google.com. 68 IN MX 40 alt3.aspmx.l.google.com.
google.com. 68 IN MX 30 alt2.aspmx.l.google.com.
google.com. 68 IN MX 10 aspmx.l.google.com.
google.com. 68 IN MX 20 alt1.aspmx.l.google.com.
google.com. 68 IN MX 50 alt4.aspmx.l.google.com.
Sekunden später, wenn der Befehl erneut abgesetzt wird, wird sich die TTL bereits verringert haben.
dig +nocmd google.com MX +noall +answer
google.com. 56 IN MX 30 alt2.aspmx.l.google.com.
google.com. 56 IN MX 40 alt3.aspmx.l.google.com.
google.com. 56 IN MX 10 aspmx.l.google.com.
google.com. 56 IN MX 20 alt1.aspmx.l.google.com.
google.com. 56 IN MX 50 alt4.aspmx.l.google.com.
Danach wird der DNS-Server die Anfrage vergessen und aus seinem Cache löschen, so dass der ganze Zyklus bei einer erneuten Anfrage von Vorne beginnt. Normalerweise beträgt die TTL 300 Sekunden.
Ein fehlerhaft konfiguriertes DNS-System kann Zeit und Nerven kosten. Offen gesagt reicht ein falsches Zeichen oder ein fehlender Punkt in den Zonendateien bereits aus, die gesamte DNS-Konfiguration über den Haufen zu werfen. Nichts wird mehr wie gefordert funktionieren. Und die Fehlersuche ist nervenaufraubend. Grundsätzlichen sollte sichergestellt sein, dass die DNS-Zuordnungen in beide Richtungen funktionieren.
Selbstverständlich gibt es Ausnahmen von diesen beiden Regeln. So wird ein CNAME zuerst zu einem anderen Hostnamen aufgelöst und erst dann zu einer IP-Adresse aufgelöst. Oder manchmal verweisen auch mehrere Hostnamen auf dieselbe Adresse, aber diese IP-Adresse hat naturgemäß nur einen Reverse Pointer.