Warum funktioniert DNS so?

Dies ist eine kanonische Frage zu DNS (Domain Name Service).

Wenn ich das DNS-System richtig verstehe, enthält die .com-Registrierung eine Tabelle, in der Domänen (www.example.com) DNS-Servern zugeordnet sind.

1. Was ist der vorteil Warum nicht direkt einer IP-Adresse zuordnen?

2. 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?

3. Wenn der einzige Grund für die Verzögerung DNS-Caches sind, ist es möglich, sie zu umgehen, damit ich in Echtzeit sehen kann, was passiert?

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.

a) Die Anzahl der IP -> Host-Namenszuordnungen in der Welt ist WIRKLICH groß. Dieses System verteilt die Verantwortung für das Hosten aller Subdomain- und MX-Einträge sowie aller anderen DNS-Einträge an den Eigentümer des Domainnamens. Dies war so ziemlich der Punkt des Domainnamens. .comwird von einem Register gehalten, wo .ukvon einem anderen gehalten werden kann. Ebenso example.comund otherexample.comkann separat gehostet werden, damit die Ressourcen verteilt werden können.

b) Es wird zwischengespeichert, wodurch die Anzahl der Zugriffe auf Ihren DNS-Host auf einen kleinen Bruchteil dessen reduziert wird, was sonst der Fall wäre. Standardmäßig werden Datensätze 2 Tage im Cache gespeichert, bevor sie gelöscht werden. Dies kann durch Ändern der TTL (Time to Live) der Aufzeichnung geändert werden.

c) Sie können das Zwischenspeichern von Datensätzen effektiv stoppen, indem Sie eine wirklich kurze TTL festlegen. Dies wird NICHT empfohlen, es sei denn, Sie verwenden es für dynamisches DNS. Durch das Zwischenspeichern werden die Zugriffe auf den DNS-Server erheblich verringert. Um eine erratene Zahl aus der Luft herauszusuchen, wollen wir 95% der Anfragen abschaffen.

Wenn Sie auf einem * nix-System arbeiten, laden Sie eine Kopie von Dan Bernsteins djbdns von http://cr.yp.to/djbdns.html herunter und führen Sie sein Programm dnstrace aus, um zu sehen, wie das rekursive Abfragesystem funktioniert. Es ist sehr informativ.

a) Die Anzahl der möglichen Domainnamen ist viel zu groß, um von einem Server verarbeitet zu werden. Und es gibt nicht nur .com; Es gibt .net, .org, .se, .info und eine beliebige Anzahl anderer. Darüber hinaus können Sie die Verantwortung für eine Unterdomäne delegieren (und genau das ist es, was dies combewirkt). Weniger zentrales DNS erleichtert die Verwaltung.

b) Computer auf dem Weg vom Benutzer zu Ihnen haben DNS-Caches, um die Anzahl der erforderlichen Anforderungen zu minimieren. Es verhindert beispielsweise, dass das Netzwerk jedes Mal, wenn Sie eine Seite von SF erhalten, mit Anfragen nach der Adresse "serverfault.com" überflutet wird. Diese Server können sogar die Ergebnisse "Domain existiert nicht" zwischenspeichern, weshalb es eine Weile dauern kann, bis auch eine brandneue Domain angezeigt wird.

c) Obwohl Sie Ihren Cache deaktivieren können, befinden sich häufig andere DNS-Server zwischen Ihrem Computer und dem DNS-Server von yourdomain.com. Der DNS-Server Ihres Internetdienstanbieters versucht beispielsweise, so viel wie möglich zwischenzuspeichern. Die einzigen Datensätze, die relativ schnell im Internet aktualisiert werden, sind Datensätze mit einer kurzen TTL (die im Grunde "Ich bin nur für ein paar Sekunden gültig; danach frag mich noch einmal nach den aktuellen Informationen"). Die TTLs sind jedoch so hoch, dass der für die Domäne verantwortliche Server einen Teil der Arbeit auf andere Server verlagern kann. Wenn das gesamte Netz Ihre ein oder zwei Rinky-Dink-DNS-Server für jeden Treffer auf Ihrer Website kontaktiert hätte, wären sie so gut wie unbrauchbar, wenn jemand Ihre Website auf /., Digg usw. gesehen hätte.