Eigentlich ist es komplizierter - anstatt einer "zentralen Registrierung (die eine Tabelle enthält, die Domänen (www.mysite.com) DNS-Servern zuordnet", gibt es mehrere Hierarchieebenen
Es gibt eine zentrale Registrierungsstelle (den Root - Server) , die nur einen kleinen Satz von Einträgen enthalten: die NS (Name - Server) Aufzeichnungen für all Top-Level - Domains - .com, .net, .org, .uk, .us, .au, und so weiter.
Diese Server enthalten nur NS-Einträge für die nächsthöhere Ebene. Um ein Beispiel zu wählen, der Nameserver für die .ukDomain hat nur Einträge für .co.uk, .ac.ukund die anderen Second-Level - Zonen im Einsatz in Großbritannien.
Diese Server enthalten nur NS-Einträge für die nächstniedrigere Ebene. Um das Beispiel fortzusetzen, erfahren Sie, wo sich die NS-Einträge befinden google.co.uk. Auf diesen Servern finden Sie schließlich eine Zuordnung zwischen einem Hostnamen wie www.google.co.ukund einer IP-Adresse.
Als zusätzliche Falte wird jede Schicht auch "Klebe" -Aufzeichnungen dienen. Jeder NS-Eintrag ordnet eine Domäne einem Hostnamen zu. Beispielsweise werden die NS-Einträge für die .ukListe nsa.nic.ukals einer der Server aufgeführt. Um auf die nächste Ebene zu gelangen, müssen wir die NS-Datensätze für nic.ukare herausfinden , und es stellt sich heraus, dass sie nsa.nic.ukauch enthalten sind. Nun müssen wir die IP von kennen nsa.nic.uk, aber um das herauszufinden, müssen wir eine Anfrage an stellen nsa.nic.uk, aber wir können diese Anfrage nicht stellen, bis wir die IP für nsa.nic.uk... kennen.
Um dieses Problem zu beheben, fügen die Server für .ukden Eintrag A nsa.nic.ukin ADDITIONAL SECTIONdie Antwort ein (die Antwort unten wurde der Kürze halber gekürzt ):
jamezpolley@li101-70:~$dig nic.uk ns
; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;nic.uk. IN NS
;; ANSWER SECTION:
nic.uk. 172800 IN NS nsb.nic.uk.
nic.uk. 172800 IN NS nsa.nic.uk.
;; ADDITIONAL SECTION:
nsa.nic.uk. 172800 IN A 156.154.100.3
nsb.nic.uk. 172800 IN A 156.154.101.3
Ohne diese zusätzlichen Leimdatensätze könnten wir niemals die Nameserver finden nic.uk.und daher niemals Domains nachschlagen, die dort gehostet werden.
Um auf Ihre Fragen zurückzukommen ...
a) Was ist der Vorteil? Warum nicht direkt einer IP-Adresse zuordnen?
Zum einen können Bearbeitungen auf jede einzelne Zone verteilt werden. Wenn Sie den Eintrag für aktualisieren möchten www.mydomain.co.uk, müssen Sie nur die Informationen auf Ihrem mydomain.co.ukNameserver bearbeiten . Es ist nicht erforderlich, die zentralen .co.ukServer, die .ukServer oder die Root-Nameserver zu benachrichtigen . Wenn es nur eine einzige zentrale Registrierung gäbe, die alle Ebenen in der gesamten Hierarchie abbildet, die über jede einzelne Änderung eines DNS-Eintrags in der gesamten Kette benachrichtigt werden müsste, würde dies den Datenverkehr überfluten.
Vor 1982 war dies tatsächlich der Fall, als die Namensauflösung erfolgte. Eine zentrale Registrierungsstelle wurde über alle Aktualisierungen benachrichtigt, und sie verteilten eine so genannte Datei, hosts.txtdie den Hostnamen und die IP-Adresse jedes Computers im Internet enthielt. Alle paar Wochen wurde eine neue Version dieser Datei veröffentlicht, und jede Maschine im Internet musste eine neue Kopie herunterladen. Lange vor 1982 begann dies problematisch zu werden, und so wurde DNS erfunden, um ein verteilteres System bereitzustellen.
Zum anderen wäre dies ein Single Point of Failure - wenn die zentrale Registrierung ausfällt, ist das gesamte Internet offline. Ein verteiltes System bedeutet, dass Ausfälle nur kleine Teile des Internets betreffen, nicht das Ganze.
(Um zusätzliche Redundanz bereitzustellen, gibt es tatsächlich 13 separate Cluster von Servern, die die Stammzone bedienen. Änderungen an den Top-Level-Domain-Einträgen müssen an alle 13 übertragen werden. Stellen Sie sich vor, Sie müssen die Aktualisierung aller 13 für jede einzelne Änderung koordinieren zu jedem Hostnamen irgendwo auf der Welt ...)
b) Wenn sich der einzige Datensatz, der geändert werden muss, wenn ich einen DNS-Server so konfiguriere, dass er auf eine andere IP-Adresse verweist, auf dem DNS-Server befindet, warum erfolgt der Vorgang nicht sofort?
Da DNS viel Caching verwendet, um die NSes zu beschleunigen und zu entlasten. Ohne Caching, besuchten Sie jedes Mal google.co.ukIhren Computer mit dem Netzwerk gehen müssen , um die Server suchen würde .uk, dann .co.uk, dann .google.co.uk, dann www.google.co.uk. Diese Antworten ändern sich nicht wesentlich, sodass es Zeit- und Netzwerkverschwendung ist, sie jedes Mal aufzusuchen. Wenn der NS stattdessen Datensätze an Ihren Computer zurückgibt, enthält er einen TTL-Wert, der Ihren Computer anweist, die Ergebnisse für einige Sekunden im Cache zu speichern.
Beispielsweise haben die NS-Datensätze für .ukeine TTL von 172800 Sekunden - 2 Tage. Google ist noch konservativer - die NS-Aufzeichnungen google.co.ukhaben eine TTL von 4 Tagen. Dienste, die auf eine schnelle Aktualisierung angewiesen sind, können eine viel niedrigere TTL wählen - beispielsweise telegraph.co.ukhaben sie eine TTL von nur 600 Sekunden in ihren NS-Einträgen.
Wenn Sie möchten, dass Aktualisierungen Ihrer Zone so schnell wie möglich durchgeführt werden, können Sie die TTL so weit senken, wie Sie möchten. Je niedriger der Wert, desto mehr Verkehr sehen Ihre Server, wenn Clients ihre Datensätze häufiger aktualisieren. Jedes Mal, wenn ein Client Kontakt zu Ihren Servern aufnimmt, um eine Abfrage durchzuführen, führt dies zu Verzögerungen, da die Antwort langsamer als im lokalen Cache nachgeschlagen wird. Daher sollten Sie auch den Kompromiss zwischen schnellen Aktualisierungen und einem schnellen Service in Betracht ziehen.
c) Wenn der einzige Grund für die Verzögerung DNS-Caches sind, ist es möglich, diese zu umgehen, damit ich in Echtzeit sehen kann, was passiert?
Ja, dies ist einfach, wenn Sie manuell mit digoder ähnlichen Tools testen. Geben Sie einfach an, an welchen Server Sie sich wenden sollen.
Hier ist ein Beispiel für eine zwischengespeicherte Antwort:
jamezpolley@host:~$dig telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 319 IN NS ns1-63.akam.net.
telegraph.co.uk. 319 IN NS eur3.akam.net.
telegraph.co.uk. 319 IN NS use2.akam.net.
telegraph.co.uk. 319 IN NS usw2.akam.net.
telegraph.co.uk. 319 IN NS use4.akam.net.
telegraph.co.uk. 319 IN NS use1.akam.net.
telegraph.co.uk. 319 IN NS usc4.akam.net.
telegraph.co.uk. 319 IN NS ns1-224.akam.net.
;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb 2 05:46:02 2012
;; MSG SIZE rcvd: 198
Der Abschnitt flags enthält hier kein aaFlag, daher können wir sehen, dass dieses Ergebnis aus einem Cache stammt und nicht direkt aus einer autorisierenden Quelle. Tatsächlich können wir sehen, dass es von 97.107.133.4einem der lokalen DNS-Resolver von Linode stammt. Die Tatsache, dass die Antwort aus einem Cache in meiner Nähe zugestellt wurde, bedeutet, dass ich 0 ms brauchte, um eine Antwort zu erhalten. Aber wie wir gleich sehen werden, ist der Preis, den ich für diese Geschwindigkeit zahle, dass die Antwort fast 5 Minuten veraltet ist.
Um Linodes Resolver zu umgehen und direkt zur Quelle zu gelangen, wählen Sie einfach einen dieser NSes aus und teilen Sie dig mit, sich direkt mit ihm in Verbindung zu setzen:
jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 600 IN NS use2.akam.net.
telegraph.co.uk. 600 IN NS eur3.akam.net.
telegraph.co.uk. 600 IN NS use1.akam.net.
telegraph.co.uk. 600 IN NS ns1-63.akam.net.
telegraph.co.uk. 600 IN NS usc4.akam.net.
telegraph.co.uk. 600 IN NS ns1-224.akam.net.
telegraph.co.uk. 600 IN NS usw2.akam.net.
telegraph.co.uk. 600 IN NS use4.akam.net.
;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb 2 05:48:47 2012
;; MSG SIZE rcvd: 198
Sie können sehen, dass die Ergebnisse dieses Mal direkt von der Quelle geliefert wurden. Beachten Sie das aaKennzeichen, das angibt, dass die Ergebnisse von einer maßgeblichen Quelle stammen. In meinem vorherigen Beispiel stammten die Ergebnisse aus meinem lokalen Cache, sodass ihnen das aaFlag fehlt . Ich kann sehen, dass die maßgebliche Quelle für diese Domain eine TTL von 600 Sekunden festlegt. Die Ergebnisse, die ich zuvor von einem lokalen Cache erhalten habe, hatten eine TTL von nur 319 Sekunden, was mir sagt, dass sie für (600-319) Sekunden - fast 5 Minuten - im Cache gesessen haben, bevor ich sie gesehen habe.
Obwohl die TTL hier nur 600 Sekunden beträgt, werden einige ISPs versuchen, ihren Datenverkehr noch weiter zu reduzieren, indem sie ihre DNS-Resolver zwingen, die Ergebnisse länger zwischenzuspeichern - in einigen Fällen 24 Stunden oder länger. Es ist üblich (in einer Art und Weise, in der wir nicht wissen, ob dies wirklich notwendig ist, aber wir sollten auf Nummer sicher gehen), anzunehmen, dass DNS-Änderungen, die Sie vornehmen, nicht überall auf der Website sichtbar sind Internet für 24-48 Stunden.