Váš prohlížeč ne. Váš prohlížeč bude používat standardní systémová volání pro rozlišení názvů hostitelů (obvykle se domnívám, že getaddrinfo() ), a ty zase obvykle prozkoumají obsah /etc/resolv.conf najít nakonfigurované rozlišující jmenné servery a dotazovat se na ně. Budou na oplátku buď přeposílat dotaz OS vašeho počítače na upstream servery (ukládat do mezipaměti jakoukoli odpověď), nebo sami provádějí rekurzivní rozlišení. Všimněte si, že většina kroků ve výše uvedeném řetězci je konfigurovatelná, takže to, co váš prohlížeč ve skutečnosti dělá, bude určeno místně; ale výše uvedený scénář je typický.
Jsou to jmenné servery s rekurzivním rozlišením v tomto řetězci (ať už to jsou vaše lokálně konfigurované autoritativní jmenné servery nebo servery některých ISP), které potřebují vědět, jak najít kořenové servery, a dělají to prostřednictvím předem nakonfigurovaného souboru zóny. pro . (který je obvykle pravidelně aktualizován dotazem na dostupný kořenový jmenný server).
Upravit :Není. Bude to záviset na implementaci, ale v mém případě (BIND) to prostě vybere jeden a zeptá se ho. Dokud dostane odpověď včas, vrací se odtamtud dolů. Proč si myslíte, že probíhá jakákoliv operace měření vzdálenosti?
Jak při překladu názvů DNS prohlížeče určí nejbližší dostupné servery DNS mezi mnoha servery DNS?
Jak naznačují ostatní odpovědi, váš prohlížeč nebo jiný klientský program tento výběr neprovádí. Klientský program požádá o rozlišení služby názvů voláním knihovny zvané resolver.
Překladač určuje, které servery by měl kontaktovat s dotazem. Záleží na implementaci resolveru, ale obvykle konzultuje v daném pořadí seznam rekurzivních překladačů, se kterými byl nakonfigurován (buď statickou konfigurací nebo jejich přijetím prostřednictvím mechanismu, jako je DHCP.)
Souhrnně tedy:váš program (na uživatelské úrovni) požádá resolver o překlad názvů a ten se zeptá jmenných serverů, které mu byly poskytnuty prostřednictvím nějakého konfiguračního mechanismu.
Jsem si vědom toho, že existuje 13 kořenových serverů, ale jak server DNS mého ISP ví, který kořenový server DNS má kontaktovat?
To také závisí na implementaci. Popíšu, jak to funguje s BIND, od
- BIND je velmi populární jmenný server a je docela pravděpodobné, že jej váš ISP používá, a
- I když váš ISP nepoužívá BIND, některé alternativy používají podobný mechanismus pro výběr jmenného serveru ze sady záznamů prostředků NS.
Nejprve si promluvme o tom, jak rekurzující jmenný server vůbec ví, ze kterých jmenných serverů si vybrat, aby mohl mluvit s konkrétní doménou. Pro každou doménu, která je dosažitelná z kořenové (."") úrovně jmenného serveru, publikují administrátoři spravující tuto doménu v obsahující nadřazené doméně sadu záznamů prostředků typu záznamů NS (tj. jmenný server), aby je mohli veřejně delegovat na jmenné servery. pojmenovaná v záznamu prostředku nastavuje odpovědnost za řešení dotazů souvisejících s danou doménou.
Jednou z výhod tohoto systému je, že umožňuje distribuované hierarchické delegování pro systém doménových jmen a jedinou doménu, pro kterou rekurzivní server vyžaduje a priori znalost je kořenová úroveň, o které je server nakonfigurován tak, aby o ní věděl. Dříve bylo nejběžnější specifikovat NS RRset pro kořenový adresář prostřednictvím souboru „hints“, který BIND načetl při spuštění, ale nyní jsou IP adresy používané kořenovými servery předdefinovány v BIND. [Odbočka:Stále můžete přepsat vestavěné funkce zadáním kořenové nápovědní zóny a ve skutečnosti se adresa d.root-servers.net nedávno změnila a nové umístění se v vestavěném seznamu neprojeví, dokud nebude nové jsou sestavovány a distribuovány verze BIND, které obsahují nové informace. V současné době jsou verze, které obsahují novou IP adresu kořenových serverů D, v beta verzi.]
Klíčovým přínosem zde každopádně je, že každá doména s ní má spojenou sadu RR záznamů NS obsahující veřejně oznámené jmenné servery pro danou doménu. Měli byste se sami na pár podívat. Podívejme se na kořen:
$ dig . ns +edns=0 @f.root-servers.net.
Jen vystřihnu sekci odpovědí, která bude obsahovat NS RRset vrácený v nepředvídatelném pořadí (trochu se zde vyhýbám -- pořadí je obecně určeno konfigurací jmenného serveru, se kterým mluvím Různé kořeny mohou odpovídat různým řazením, ale objednávané položky by měly být stejné.)
;; 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.
To jsou všechny jmenné servery pro kořenovou (."") doménu a kterémukoli z nich můžeme položit otázky týkající se kořenové domény. Pokud se jich zeptáme na něco, co není v kořenové doméně, obdržíme buď chybu, nebo pravděpodobněji odkaz na jinou sadu jmenných serverů (např. „example.com? Na otázky o example.com neodpovídám. Zkuste se zeptat na jmenné servery domény .com – jsou tam..")
Jak tedy BIND ví, který jmenný server ze sady NS RRset mu poskytne nejrychlejší odezvu?
Odpověď zní:zpočátku ne. Při výchozím chování se však postupem času učí a obvykle se ustálí dotazem serveru na nejkratší zpáteční čas.
Doby zpáteční cesty a výběr kandidátských jmenných serverů BIND se při výběru, který jmenný server má přijímat dotazy, spoléhá na časy Round Trip Times (RTT) k jmenným serverům v sadě RR. Při prvním přidání sady RR NS pro doménu do mezipaměti se všem záznamům v sadě přiřadí malá náhodná doba oběhu v řádu několika milisekund. být nasměrován na jmenné servery delegované pro danou doménu, BIND zkontroluje svou mezipaměť a (doufejme) najde sadu RR. Vybere server s nejnižší dobou RTT ze sady a provede dotaz. A když je dotaz hotový, BIND aktualizuje RTT pro NS RRset následovně:
- RTT serveru, který byl právě dotázán, je nastaven na skutečný čas zpáteční cesty.
- Všem ostatním serverům v sadě RRset je RTT snížena o malý zlomek (asi 3-4 %, myslím...)
Podívejme se, jak to funguje, na příkladu. Když můj rekurzivní resolver poprvé narazí na doménu example.com, načte do své mezipaměti sadu RRset NS for example.com. Řekněme, že administrátoři example.com oznámili tři jmenné servery pro example.com, takže NS RRset vypadá takto:
example.com NS servera.example.com
example.com NS serverb.example.com
example.com NS serverc.example.com
Pro účely tohoto příkladu také předpokládejme, že vašemu resolveru trvá přijetí odpovědi od každého ze serverů v této sadě následující množství času:
servera -- 30 ms
serverb -- 45 ms
serverc -- 50 ms
Nyní, když se poprvé načte sada RRset NS example.com, jsou váhy RTT doplněny malými náhodnými hodnotami. Než jsme se tedy jmenného serveru example.com na něco zeptali, mohla by tabulka RTT vypadat takto:
servera -- 8 ms
serverb -- 9 ms
serverc -- 7 ms
Při prvním dotazu na example.com pak přejdeme na serverc a položíme naši otázku. Serverc potřebuje odpověď 50 ms, takže po dokončení našeho dotazu aktualizujeme naši tabulku RTT tak, aby nyní zní:
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.
Příště budeme samozřejmě vybírat servera, protože má nyní nejnižší dobu zpáteční cesty. Již po několika dotazech na doménu example.com bychom měli mít docela slušnou představu, který jmenný server nám poskytuje nejrychlejší odezvu, a poté budeme tento server nejvíce preferovat času.
Proč nejvíce času a ne všech času? A co se děje s tím, o čem jsem se již zmínil dříve, že „všem ostatním serverům v sadě RRset jsou RTT sníženy o malý zlomek“? No, ukázalo se, že zatímco my chceme preferovat nejrychlejší server, nechceme ostatní servery trvale odepisovat. Možná je server c nejrychlejším serverem téměř po celou dobu, ale v době, kdy jsme poprvé nastavili jeho RTT, byl anomálně zaneprázdněn. Možná byl server dočasně mimo provoz, což vedlo k neuvěřitelně vysokému RTT (poté, co vypršel časový limit našeho pokusu o dotazování), ale chceme se ho začít ptát znovu, až bude opět v provozu. Tím, že pokaždé upravíte hodnoty ostatních serverů směrem dolů, dříve nebo později klesnou pod průměrnou RTT serveru, který preferujeme. Když se to stane, hodíme dotaz jejich směrem, a pokud je čas lepší, pak skvělé. V opačném případě resetujeme jeho RTT a vrátí se na konec našeho seznamu priorit, dokud se znovu nevplíží zpět do popředí. Velká většina našich dotazů bude směřovat na nejrychlejší server nebo servery v sadě, ale odlehlé hodnoty jsou pravidelně zkoušeny, abychom se ujistili, že pokud se podmínky změní, bude tabulka aktualizována tak, aby to odrážela, a stále je v průměru vybrán nejlepší server.
Těch 13 kořenových jmenných serverů není ve skutečnosti 13 serverů. Každý z nich je distribuovaný shluk serverů na různých místech po celém světě a je k nim přistupováno prostřednictvím standardního směrování IP, stejně jako ke každému jinému serveru.
Pokud jde o které kořenový jmenný server, který se server DNS ISP rozhodne kontaktovat, což pravděpodobně závisí na podrobnostech jejich DNS resolveru. Možná je to úplně náhodné, možná je to vážené, ale to vám nemůžu říct.
Edit:pokud jste mysleli, jak ISP najde kterýkoli ze 13 jmenných serverů, existuje jejich veřejný seznam a jejich odpovídající IP adresy, které má v podstatě každý počítač. Odtud už jde jen o to vybrat si jeden a nechat routery internetu udělat zbytek.