Ihr Browser nicht. Ihr Browser verwendet die Standard-Systemaufrufe zum Auflösen von Hostnamen (normalerweise, glaube ich, getaddrinfo() ), und diese wiederum untersuchen in der Regel den Inhalt von /etc/resolv.conf um die konfigurierten auflösenden Nameserver zu finden und abzufragen. Sie werden wiederum entweder die Abfrage des Betriebssystems Ihres Desktops an Upstream-Server weiterleiten (und jede Antwort zwischenspeichern) oder selbst eine rekursive Auflösung durchführen. Beachten Sie, dass die meisten Schritte in der obigen Kette konfigurierbar sind, sodass das, was Ihr Browser tatsächlich tut, lokal bestimmt wird; aber das obige Szenario ist typisch.
Es sind die rekursiv auflösenden Nameserver in dieser Kette (sei es Ihre lokal konfigurierten autoritativen Nameserver oder die Server einiger ISPs auf der ganzen Linie), die wissen müssen, wie sie die Root-Server finden, und sie tun dies über eine vorkonfigurierte Zonendatei für . (der normalerweise regelmäßig aktualisiert wird, indem ein verfügbarer Root-Nameserver abgefragt wird).
Bearbeiten :Das tut es nicht. Es wird von der Implementierung abhängig sein, aber in meinem Fall (BIND) wird es einfach ausgewählt und abgefragt. Solange es rechtzeitig eine Antwort erhält, kehrt es von dort nach unten zurück. Was lässt Sie glauben, dass irgendeine Art von Ranging-Operation vor sich geht?
Wie bestimmen Browser bei der DNS-Namensauflösung den nächsten verfügbaren DNS-Server unter vielen DNS-Servern?
Wie die anderen Antworten zeigen, führt Ihr Browser oder ein anderes Client-Programm diese Auswahl nicht durch. Ein Client-Programm fordert die Namensdienstauflösung an, indem es Aufrufe an eine Bibliothek namens Resolver sendet.
Der Resolver bestimmt, welche Server er kontaktieren soll, um eine Abfrage zu stellen. Es hängt von der Resolver-Implementierung ab, aber normalerweise es konsultiert der Reihe nach eine Liste rekursiver Resolver, mit denen es konfiguriert wurde (entweder durch statische Konfiguration oder indem es sie über einen Mechanismus wie DHCP erhält).
Zusammenfassend also:Ihr Programm (auf Benutzerebene) fragt den Resolver nach der Namensauflösung und der Resolver fragt die Nameserver, die ihm über einen Konfigurationsmechanismus bereitgestellt wurden.
Mir ist bekannt, dass es 13 Root-Server gibt, aber woher weiß der DNS-Server meines ISP, 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 Chancen stehen gut, dass Ihr ISP ihn verwendet, und
- Selbst wenn Ihr ISP BIND nicht verwendet, verwenden einige Alternativen einen ähnlichen Mechanismus für die Nameserver-Auswahl aus einem NS-Ressourcendatensatz.
Lassen Sie uns zunächst darüber sprechen, wie ein rekursiver Nameserver überhaupt weiß, welche Nameserver er auswählen muss, um mit einer bestimmten Domain zu kommunizieren. Für jede Domäne, die von der Root-Ebene (".") des Nameservers aus erreichbar ist, veröffentlichen die Administratoren, die diese Domäne verwalten, in der übergeordneten Domäne, in der sie enthalten sind, einen Ressourcendatensatz des Datensatztyps NS (d. h. Nameserver), der öffentlich an die Nameserver delegiert wird die im Ressourceneintrag benannt sind, legen die Verantwortung für die Lösung von Anfragen fest, die mit dieser Domäne zu tun haben.
Eine der Schönheiten dieses Systems ist, dass es eine verteilte hierarchische Delegierung für das Domänennamensystem und die einzige Domäne ermöglicht, für die ein rekursiver Server a priori benötigt Wissen ist die Root-Ebene, für die der Server so konfiguriert ist, dass er davon Kenntnis hat. Früher war es am gebräuchlichsten, das NS-RRset für den Root durch 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. [Exkurs:Sie können die eingebauten Funktionen immer noch überschreiben, indem Sie eine Root-Hinweiszone angeben, und tatsächlich hat sich die Adresse von d.root-servers.net kürzlich geändert und der neue Speicherort wird erst in der eingebauten Liste widergespiegelt, wenn sie neu ist Es werden Versionen von BIND erstellt und verteilt, die die neuen Informationen enthalten. Derzeit befinden sich Versionen, die die neue IP-Adresse der D-Root-Server enthalten, in der Beta-Phase.]
Wie auch immer, der Schlüssel zum Mitnehmen hier ist, dass jeder Domain ein NS-Eintrag RRset zugeordnet ist, der die öffentlich bekannt gegebenen Nameserver für diese Domain enthält. Sie sollten versuchen, sich selbst ein paar anzusehen. Schauen wir uns die Wurzel an:
$ dig . ns +edns=0 @f.root-servers.net.
Ich werde einfach den Antwortabschnitt ausschneiden, der das NS RRset enthält, das in keiner vorhersehbaren Reihenfolge zurückgegeben wird (ich beschönige hier ein wenig – die Reihenfolge wird im Allgemeinen durch die Konfiguration des Nameservers bestimmt, mit dem ich spreche . Unterschiedliche Wurzeln könnten mit unterschiedlichen Reihenfolgen antworten, aber die bestellten Artikel sollten die gleichen 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.
Das sind alle Nameserver für die Root-Domain (".") und wir können jedem von ihnen Fragen zur Root-Domain stellen. Wenn wir ihnen eine Frage zu etwas stellen, das sich nicht in der Root-Domain befindet, erhalten wir entweder einen Fehler oder, was wahrscheinlicher ist, einen Verweis auf eine andere Gruppe von Nameservern (z. B. „example.com? Ich beantworte keine Fragen zu example.com. . Versuchen Sie, die .com-Domain-Nameserver zu fragen – sie sind da drüben..")
Woher weiß BIND dann, welcher Nameserver aus dem NS-RRset ihm die schnellste Antwort geben wird?
Die Antwort ist:zunächst nicht. Aber unter seinem Standardverhalten lernt es mit der Zeit und gibt sich auf normalerweise fest den Server mit der kürzesten Roundtrip-Zeit fragen.
Round-Trip-Zeiten und die Auswahl von Kandidaten-Nameservern BIND verlässt sich auf Round Trip Times (RTTs) zu den Nameservern in einem RRset, um auszuwählen, welcher Nameserver seine Anfragen 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 kleine zufällige Umlaufzeit in der Größenordnung von einigen Millisekunden zugewiesen. Nach dieser anfänglichen Vorbereitung, wenn eine Abfrage erforderlich ist an die für eine bestimmte Domain delegierten Nameserver geleitet werden, überprüft BIND seinen Cache und findet (hoffentlich) das RRset. Er wählt den Server mit der niedrigsten RTT-Zeit aus der Menge 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 Roundtrip-Zeit gesetzt.
- Alle anderen Server im RRset haben ihre RTTs um einen kleinen Bruchteil reduziert (~3-4%, glaube ich...)
Sehen wir uns an, wie das funktioniert, indem wir ein Beispiel durchgehen. Wenn mein rekursiver Resolver zum ersten Mal auf die Domain example.com trifft, lädt er das NS RRset for 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 wie folgt 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 auch an, dass Ihr Resolver die folgende Zeit benötigt, um eine Antwort von jedem der Server in diesem Satz zu erhalten:
servera -- 30 ms
serverb -- 45 ms
serverc -- 50 ms
Wenn jetzt das example.com NS RRset zum ersten Mal geladen wird, werden die RTT-Gewichte mit kleinen zufälligen Werten gefüllt. Bevor wir also jemals einen Nameserver von example.com 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, also aktualisieren wir nach Abschluss unserer Abfrage unsere RTT-Tabelle, sodass sie jetzt 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 natürlich Servera auswählen, da es jetzt die niedrigste Rundreisezeit hat. Nach nur wenigen Anfragen an die example.com-Domain sollten wir eine ziemlich gute Vorstellung davon haben, welcher Nameserver uns die schnellste Antwort gibt, und wir werden diesen Server danach am meisten bevorzugen der Zeit.
Warum die meisten der Zeit und nicht alle der ganzen Zeit? Und was hat es mit dem Teil auf sich, den ich zuvor erwähnt habe, nämlich „Alle anderen Server im RRset haben ihre RTTs um einen kleinen Bruchteil reduziert“? Nun, es stellt sich heraus, dass wir es bevorzugen möchten den schnellsten Server, wir wollen 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 Versuch, ihn abzufragen, abgelaufen ist), aber wir möchten ihn erneut fragen, nachdem er wieder in Betrieb ist. Indem Sie die anderen Serverwerte jedes Mal nach unten anpassen, werden sie früher oder später unter die durchschnittliche RTT des von uns bevorzugten Servers kriechen. Wenn das passiert, werden wir eine Abfrage in ihre Richtung werfen und wenn die Zeit besser ist, dann großartig. Andernfalls setzen wir seine RTT zurück und es geht zurück an das Ende unserer Prioritätenliste, bis es wieder nach vorne kriecht. Die große Mehrheit unserer Abfragen geht an den oder die schnellsten Server in der Gruppe, 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.
Die 13 Root-Nameserver sind eigentlich keine 13 Server. Jeder einzelne ist ein verteilter Cluster von Servern an verschiedenen Standorten auf der ganzen Welt, und der Zugriff erfolgt wie auf jeden anderen Server über Standard-IP-Routing.
Apropos welche root nameserver Der DNS-Server des ISP, den er kontaktiert, hängt wahrscheinlich von den Details seines DNS-Resolvers ab. Vielleicht ist es völlig zufällig, vielleicht ist es gewichtet, aber ich kann es dir nicht sagen.
Edit:wenn du meinst, wie findet der ISP find Jeder der 13 Nameserver, es gibt eine öffentliche Liste von ihnen und ihren entsprechenden IP-Adressen, die im Grunde jeder Computer hat. Von dort aus müssen Sie nur noch einen auswählen und die Router des Internets den Rest erledigen lassen.