Wie ermitteln Browser bei der DNS-Namensauflösung unter den zahlreichen DNS-Servern den nächstgelegenen verfügbaren DNS-Server?
Mir ist bewusst, dass es 13 Root-Server gibt, aber woher weiß der DNS-Server meines Internetdienstanbieters, welcher Root-DNS-Server kontaktiert werden soll?
Antwort1
Ihr Browser tut dies nicht. Ihr Browser verwendet die Standardsystemaufrufe zum Auflösen von Hostnamen (normalerweise, glaube ich, getaddrinfo()), und diese untersuchen wiederum normalerweise den Inhalt von , /etc/resolv.confum die konfigurierten auflösenden Nameserver zu finden und diese abzufragen. Sie leiten wiederum entweder die Abfrage des Betriebssystems Ihres Desktops an Upstream-Server weiter (und speichern alle Antworten zwischen) oder führen selbst eine rekursive Auflösung durch. Beachten Sie, dass die meisten Schritte in der obigen Kette konfigurierbar sind, sodass das, was Ihr Browser tatsächlich tut, lokal bestimmt wird; das obige Szenario ist jedoch typisch.
Es sind die rekursiv auflösenden Nameserver in dieser Kette (seien es Ihre lokal konfigurierten autoritativen Nameserver oder die Server eines weiter unten stehenden ISPs), die wissen müssen, wie die Stammserver zu finden sind, und sie tun dies über eine vorkonfigurierte Zonendatei .(die normalerweise regelmäßig durch Abfragen eines verfügbaren Stamm-Nameservers aktualisiert wird).
Bearbeiten: Das tut es nicht. Es hängt von der Implementierung ab, aber soweit ich weiß (BIND), wählt es einfach eines aus und fragt es ab. Solange es rechtzeitig eine Antwort erhält, rekursiert es von dort aus nach unten. Was lässt Sie glauben, dass irgendeine Art von Entfernungsoperation stattfindet?
Antwort2
Wie ermitteln Browser bei der DNS-Namensauflösung unter den zahlreichen DNS-Servern den nächstgelegenen verfügbaren DNS-Server?
Wie aus den anderen Antworten hervorgeht, führt Ihr Browser oder ein anderes Client-Programm diese Auswahl nicht durch. Ein Client-Programm fordert die Namensdienstauflösung an, indem es eine Bibliothek namens Resolver aufruft.
Der Resolver bestimmt, welche Server er kontaktieren soll, um eine Abfrage zu stellen. Dies hängt von der Resolver-Implementierung ab, abernormalerweiseEs konsultiert der Reihe nach eine Liste rekursiver Resolver, mit denen es konfiguriert wurde (entweder durch statische Konfiguration oder durch Empfang über einen Mechanismus wie DHCP).
Zusammengefasst also: Ihr (Benutzerebenen-)Programm fordert den Resolver zur Namensauflösung an und der Resolver fragt die Nameserver ab, die ihm über einen Konfigurationsmechanismus bereitgestellt wurden.
Mir ist bewusst, dass es 13 Root-Server gibt, aber woher weiß der DNS-Server meines Internetdienstanbieters, welcher Root-DNS-Server kontaktiert werden soll?
Dies ist auch implementierungsabhängig. Ich werde beschreiben, wie es mit BIND funktioniert, da
- BIND ist ein sehr beliebter Nameserver und die Wahrscheinlichkeit ist groß, dass Ihr ISP ihn verwendet.
- Auch wenn Ihr ISP BIND nicht verwendet, nutzen einige Alternativen einen ähnlichen Mechanismus zur Nameserver-Auswahl aus einem NS-Ressourcendatensatzsatz.
Lassen Sie uns zunächst darüber sprechen, wie ein rekursiver Nameserver überhaupt weiß, welche Nameserver er auswählen muss, um mit einer bestimmten Domäne zu kommunizieren. Für jede Domäne, die von der Stammebene (".") des Nameservers aus erreichbar ist, veröffentlichen die Administratoren, die diese Domäne verwalten, in der übergeordneten Domäne einen Ressourcendatensatz des Datensatztyps NS (d. h. Nameserver), um die Verantwortung für die Lösung von Abfragen, die mit dieser Domäne zu tun haben, öffentlich an die im Ressourcendatensatz genannten Nameserver zu delegieren.
Einer der Vorteile dieses Systems ist, dass es eine verteilte hierarchische Delegation für das Domain Name System ermöglicht und die einzige Domain ist, für die ein rekursiver Server erforderlich ist.a prioriWissen ist die Root-Ebene, die der Server laut Konfiguration kennen soll. Früher war es üblich, das NS RRset für die Root über eine „Hints“-Datei anzugeben, die BIND beim Start geladen hat, aber seit einiger Zeit sind die von den Root-Servern verwendeten IP-Adressen in BIND vordefiniert. [Abschweifung: Sie können die integrierten Funktionen immer noch überschreiben, indem Sie eine Root-Hint-Zone angeben. Tatsächlich hat sich die Adresse von d.root-servers.net kürzlich geändert und der neue Standort wird nicht in der integrierten Liste angezeigt, bis neue Versionen von BIND erstellt und verteilt werden, die die neuen Informationen enthalten. Derzeit befinden sich Versionen, die die neue IP-Adresse der D-Root-Server enthalten, in der Betaphase.]
Wie dem auch sei, die wichtigste Erkenntnis hier ist, dass jeder Domain ein NS-Record-RRset zugeordnet ist, das die öffentlich bekannt gegebenen Nameserver für diese Domain enthält. Sie sollten sich selbst ein paar davon ansehen. Sehen wir uns die Wurzel an:
$ dig . ns +edns=0 @f.root-servers.net.
Ich werde einfach den Antwortabschnitt herausschneiden, der das in keiner vorhersehbaren Reihenfolge zurückgegebene NS RRset enthält (ich gehe hier ein wenig darüber hinweg – die Reihenfolge wird im Allgemeinen durch die Konfiguration des Nameservers bestimmt, mit dem ich spreche. Unterschiedliche Roots antworten möglicherweise in unterschiedlicher Reihenfolge, aber die sortierten Elemente sollten dieselben sein.)
;; ANSWER SECTION:
. 518400 IN NS h.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS g.root-servers.net.
Dies sind alle Nameserver für die Stammdomäne (".") und wir können jedem von ihnen Fragen zur Stammdomäne stellen. Wenn wir ihnen eine Frage zu etwas stellen, das sich nicht in der Stammdomäne befindet, erhalten wir entweder eine Fehlermeldung oder, was wahrscheinlicher ist, eine Weiterleitung zu einem anderen Satz von Nameservern (z. B. "example.com? Ich beantworte keine Fragen zu example.com. Versuchen Sie es mit den Nameservern der .com-Domäne – sie sind dort drüben.")
Woher weiß BIND dann, welcher Nameserver aus dem NS-RRset die schnellste Antwort liefert?
Die Antwort lautet: zunächst nicht. Aber im Standardverhalten lernt es mit der Zeit dazu und entscheidet sich fürnormalerweiseFragen Sie den Server mit der kürzesten Roundtrip-Zeit an.
Round Trip Times und Auswahl der Nameserver-Kandidaten BIND verlässt sich auf Round Trip Times (RTTs) zu den Nameservern in einem RRset, um zu entscheiden, welcher Nameserver seine Abfragen erhalten soll. Wenn zum ersten Mal ein NS RRset für eine Domäne zum Cache hinzugefügt wird, wird allen Datensätzen im Set eine kurze zufällige Round-Trip-Zeit im Bereich von einigen Millisekunden zugewiesen. Nach dieser anfänglichen Vorbereitung prüft BIND seinen Cache und findet (hoffentlich) das RRset, wenn eine Abfrage an die für eine bestimmte Domäne delegierten Nameserver gerichtet werden muss. Es wählt den Server mit der kürzesten RTT-Zeit aus dem Set aus und stellt seine Abfrage. Und wenn die Abfrage abgeschlossen ist, aktualisiert BIND die RTTs für das NS RRset wie folgt:
- die RTT des gerade abgefragten Servers wird auf seine tatsächliche Round Trip Time gesetzt.
- Bei allen anderen Servern im RRset sind die RTTs um einen kleinen Bruchteil reduziert (~3–4 %, glaube ich …)
Sehen wir uns anhand eines Beispiels an, wie das funktioniert. Wenn mein rekursiver Resolver zum ersten Mal auf die Domäne example.com trifft, lädt er das NS RRset für example.com in seinen Cache. Nehmen wir an, die Administratoren von example.com haben drei Nameserver für example.com angekündigt, sodass das NS RRset folgendermaßen aussieht:
example.com NS servera.example.com
example.com NS serverb.example.com
example.com NS serverc.example.com
Nehmen wir für dieses Beispiel außerdem an, dass Ihr Resolver die folgende Zeitspanne benötigt, um von jedem der Server in diesem Set eine Antwort zu erhalten:
servera -- 30 ms
serverb -- 45 ms
serverc -- 50 ms
Wenn nun das example.com NS RRset zum ersten Mal geladen wird, werden die RTT-Gewichte mit kleinen Zufallswerten gefüllt. Bevor wir also jemals einen example.com-Nameserver etwas gefragt haben, könnte die RTT-Tabelle so aussehen:
servera -- 8 ms
serverb -- 9 ms
serverc -- 7 ms
Wenn wir example.com zum ersten Mal abfragen, gehen wir zu serverc und stellen unsere Frage. Serverc braucht 50 ms, um zu antworten. Nachdem unsere Abfrage abgeschlossen ist, aktualisieren wir unsere RTT-Tabelle, sodass sie nun lautet:
servera -- 7 ms // reduced by a small fraction
serverb -- 8 ms // reduced by a small fraction
serverc -- 50 ms // updated to reflect the actual round trip time.
Beim nächsten Mal werden wir uns natürlich für Servera entscheiden, da dieser jetzt die kürzeste Roundtrip-Zeit hat. Nach nur wenigen Anfragen an die Domäne example.com sollten wir eine ziemlich gute Vorstellung davon haben, welcher Nameserver uns die schnellste Antwort liefert, und wir werden diesen Server danach bevorzugen.am meistender ganzen Zeit.
Warumam meistender Zeit und nichtalleder Zeit? Und was ist mit dem Teil, den ich zuvor erwähnt habe, über "Alle anderen Server im RRset haben ihre RTTs um einen kleinen Bruchteil reduziert"? Nun, es stellt sich heraus, dass wir zwarbevorzugender schnellste Server, wir möchten die anderen Server nicht dauerhaft abschreiben. Vielleicht ist Server C fast immer der schnellste Server, aber als wir seine RTT zum ersten Mal eingestellt haben, war er ungewöhnlich ausgelastet. Vielleicht war ein Server vorübergehend außer Betrieb, was zu einer unglaublich hohen RTT führte (nachdem unser Abfrageversuch abgelaufen war), aber wir möchten ihn erneut abfragen, nachdem er wieder in Betrieb ist. Indem wir die Werte der anderen Server jedes Mal nach unten anpassen, werden sie früher oder später unter die durchschnittliche RTT des von uns bevorzugten Servers sinken. Wenn das passiert, senden wir eine Abfrage an sie, und wenn die Zeit besser ist, ist das großartig. Andernfalls setzen wir ihre RTT zurück und sie wandert zurück ans Ende unserer Prioritätenliste, bis sie wieder nach vorne kriecht. Die große Mehrheit unserer Abfragen geht an den oder die schnellsten Server im Set, aber die Ausreißer werden regelmäßig getestet, um sicherzustellen, dass die Tabelle aktualisiert wird, wenn sich die Bedingungen geändert haben, um dies widerzuspiegeln, und im Durchschnitt immer noch der beste Server ausgewählt wird.
Antwort3
Bei den 13 Root-Nameservern handelt es sich nicht wirklich um 13 Server. Jeder von ihnen ist ein verteilter Cluster von Servern an verschiedenen Standorten auf der ganzen Welt. Der Zugriff auf sie erfolgt über Standard-IP-Routing, genau wie auf jeden anderen Server.
Wie fürwelcheRoot-Nameserver, den der DNS-Server des ISPs kontaktiert, hängt wahrscheinlich von den Details seines DNS-Resolvers ab. Vielleicht ist es völlig zufällig, vielleicht ist es gewichtet, aber das kann ich Ihnen nicht sagen.
Edit: Wenn du meinst, wie funktioniert der ISPfindenFür jeden der 13 Nameserver gibt es eine öffentliche Liste mit den entsprechenden IP-Adressen, die praktisch jeder Computer hat. Von dort aus muss man nur noch einen auswählen und die Router des Internets erledigen den Rest.