Na resolução de nomes DNS, como os navegadores determinam os servidores DNS mais próximos disponíveis entre muitos servidores DNS?
Estou ciente de que existem 13 servidores raiz, mas como o servidor DNS do meu ISP sabe qual servidor DNS raiz contatar?
Responder1
Seu navegador não. Seu navegador usará as chamadas de sistema padrão para resolver nomes de host (geralmente, acredito, getaddrinfo()), e estas, por sua vez, geralmente examinarão o conteúdo de /etc/resolv.confpara encontrar os servidores de nomes de resolução configurados e consultá-los. Eles, por sua vez, encaminharão a consulta do sistema operacional do seu desktop para servidores upstream (armazenando em cache qualquer resposta) ou executarão eles próprios a resolução recursiva. Observe que a maioria das etapas da cadeia acima são configuráveis, portanto, o que seu navegador faz de fato será determinado localmente; mas o cenário acima é típico.
São os servidores de nomes de resolução recursiva nessa cadeia (sejam os servidores de nomes autorizados configurados localmente ou alguns servidores do ISP no futuro) que precisam saber como encontrar os servidores raiz, e fazem isso por meio de um arquivo de zona pré-configurado for .(que geralmente é atualizado periodicamente consultando um servidor de nomes raiz disponível).
Editar: Isso não acontece. Dependerá da implementação, mas no meu caso (BIND), basta escolher um e consultá-lo. Contanto que obtenha uma resposta a tempo, ele retornará a partir daí. O que faz você pensar que algum tipo de operação de alcance está acontecendo?
Responder2
Na resolução de nomes DNS, como os navegadores determinam os servidores DNS mais próximos disponíveis entre muitos servidores DNS?
Como as outras respostas indicam, seu navegador ou outro programa cliente não faz essa seleção. Um programa cliente solicita resolução de serviço de nomes fazendo chamadas para uma biblioteca chamada resolvedor.
O resolvedor determina quais servidores ele deve contatar para fazer uma consulta. Depende da implementação do resolvedor, masgeralmenteele consulta, em ordem, uma lista de resolvedores recursivos com os quais foi configurado (seja por configuração estática ou recebendo-os por meio de um mecanismo como o DHCP).
Em resumo, então: seu programa (nível de usuário) solicita ao resolvedor a resolução de nomes e o resolvedor solicita aos servidores de nomes que foram fornecidos a ele por meio de algum mecanismo de configuração.
Estou ciente de que existem 13 servidores raiz, mas como o servidor DNS do meu ISP sabe qual servidor DNS raiz contatar?
Isso também depende da implementação. Vou descrever como funciona com o BIND, já que
- BIND é um servidor de nomes muito popular e há boas chances de que seu ISP o esteja usando, e
- Mesmo que seu ISP não esteja usando BIND, algumas alternativas usam um mecanismo semelhante para seleção de servidores de nomes a partir de um conjunto de registros de recursos NS.
Para começar, vamos falar primeiro sobre como um servidor de nomes recorrente sabe quais servidores de nomes escolher para se comunicar com um domínio específico. Para cada domínio acessível a partir do nível raiz (".") do servidor de nomes, os administradores que gerenciam esse domínio publicam, no domínio pai que o contém, um conjunto de registros de recursos do tipo de registro NS (ou seja, servidor de nomes) para delegar publicamente aos servidores de nomes. nomeado no registro do recurso define a responsabilidade pela resolução de consultas relacionadas a esse domínio.
Uma das belezas deste sistema é que ele permite a delegação hierárquica distribuída para o sistema de nomes de domínio e o único domínio para o qual um servidor recursivo requera prioriconhecimento é o nível raiz, que o servidor está configurado para conhecer. Costumava ser mais comum especificar o NS RRset para a raiz através de um arquivo de "dicas" que o BIND carregava quando era iniciado, mas há algum tempo os endereços IP usados pelos servidores raiz foram pré-definidos no BIND. [Digressão: você ainda pode substituir os internos especificando uma zona de dica de raiz e, de fato, o endereço d.root-servers.net mudou recentemente e o novo local não será refletido na lista interna até novo versões do BIND são construídas e distribuídas que incluem as novas informações. No momento, as versões que contêm o novo endereço IP dos servidores raiz D estão em beta.]
De qualquer forma, a principal conclusão aqui é que cada domínio tem associado a ele um registro NS RRset contendo os servidores de nomes anunciados publicamente para esse domínio. Você deveria tentar ver alguns você mesmo. Vejamos a raiz:
$ dig . ns +edns=0 @f.root-servers.net.
Vou apenas cortar a seção de respostas, que conterá o NS RRset retornado em uma ordem não previsível (estou encobrindo um pouco aqui - a ordem é determinada geralmente pela configuração do servidor de nomes com o qual estou falando . Raízes diferentes podem responder com ordenações diferentes, mas os itens ordenados devem ser os mesmos.)
;; 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.
Esses são todos os servidores de nomes do domínio raiz (".") e podemos fazer perguntas a qualquer um deles sobre o domínio raiz. Se fizermos uma pergunta sobre algo que não está no domínio raiz, receberemos um erro ou, mais provavelmente, uma referência a outro conjunto de servidores de nomes (por exemplo, "exemplo.com? Não respondo perguntas sobre exemplo.com. . Tente perguntar aos servidores de nomes de domínio .com - eles estão lá..")
Como, então, o BIND sabe qual servidor de nomes do NS RRset lhe dará a resposta mais rápida?
A resposta é: inicialmente não. Mas sob seu comportamento padrão, ele aprende com o tempo e se estabelecegeralmenteperguntando ao servidor com o menor tempo de ida e volta.
Tempos de ida e volta e seleção de servidores de nomes candidatos O BIND depende de Round Trip Times (RTTs) para os servidores de nomes em um RRset para escolher qual servidor de nomes deve receber suas consultas. Na primeira vez que um NS RRset para um domínio é adicionado ao cache, todos os registros do conjunto recebem um pequeno tempo de ida e volta aleatório, da ordem de alguns milissegundos. Após essa preparação inicial, quando uma consulta precisa ser direcionada aos servidores de nomes delegados para um determinado domínio, o BIND verifica seu cache e (esperançosamente) encontra o RRset. Ele escolhe o servidor com menor tempo RTT do conjunto e faz sua consulta. E quando a consulta é concluída, o BIND atualiza os RTTs para o NS RRset da seguinte forma:
- o RTT do servidor que acabou de ser consultado é definido para o tempo real de ida e volta.
- Todos os outros servidores no RRset têm seus RTTs reduzidos em uma pequena fração (~3-4%, eu acho...)
Vamos ver como isso funciona examinando um exemplo. Na primeira vez que meu resolvedor recursivo encontra o domínio example.com, ele carrega o NS RRset de example.com em seu cache. Digamos que os administradores de example.com anunciaram três servidores de nomes para example.com, então o NS RRset se parece com:
example.com NS servera.example.com
example.com NS serverb.example.com
example.com NS serverc.example.com
Vamos supor também, para fins deste exemplo, que seu resolvedor leva os seguintes períodos de tempo para receber uma resposta de cada um dos servidores neste conjunto:
servera -- 30 ms
serverb -- 45 ms
serverc -- 50 ms
Agora, na primeira vez que o NS RRset de example.com é carregado, os pesos RTT são preparados com pequenos valores aleatórios. Portanto, antes de perguntarmos qualquer coisa a um servidor de nomes example.com, a tabela RTT pode ser semelhante a esta:
servera -- 8 ms
serverb -- 9 ms
serverc -- 7 ms
Na primeira vez que consultarmos example.com, iremos ao serverc e faremos nossa pergunta. O Serverc leva 50 ms para responder, então, após a conclusão da nossa consulta, atualizamos nossa tabela RTT para que ela leia agora:
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.
Na próxima vez, obviamente escolheremos servera, pois agora ele tem o menor tempo de ida e volta. Depois de apenas algumas consultas ao domínio example.com, devemos ter uma ideia bastante decente de qual servidor de nomes nos dá a resposta mais rápida e, a partir de então, preferiremos esse servidormaioriado tempo.
Por quemaioriada época e nãotodosdo tempo? E o que aconteceu com o que mencionei anteriormente sobre "Todos os outros servidores no RRset têm seus RTTs reduzidos em uma pequena fração"? Bem, acontece que embora queiramosprefiroo servidor mais rápido, não queremos anular permanentemente os outros servidores. Talvez o servidor c seja o servidor mais rápido quase o tempo todo, mas no momento em que definimos seu RTT pela primeira vez, ele estava anormalmente ocupado. Talvez um servidor tenha estado temporariamente fora de serviço, resultando em um RTT incrivelmente alto (depois que nossa tentativa de consulta expirar), mas queremos começar a perguntar novamente depois que ele voltar a funcionar. Ao ajustar os outros valores do servidor para baixo a cada vez, mais cedo ou mais tarde eles irão ficar abaixo do RTT médio do servidor que preferimos. Quando isso acontecer, lançaremos uma consulta na direção deles e se o momento for melhor, ótimo. Caso contrário, redefinimos seu RTT e ele volta para o final da nossa lista de prioridades até voltar para a frente novamente. A grande maioria de nossas consultas irá para o servidor ou servidores mais rápidos do conjunto, mas os valores discrepantes são testados periodicamente para garantir que, se as condições mudarem, a tabela será atualizada para refletir isso e o melhor servidor ainda estará sendo selecionado, em média.
Responder3
Os 13 servidores de nomes raiz não são na verdade 13 servidores. Cada um deles é um cluster distribuído de servidores em vários locais ao redor do mundo e são acessados por meio de roteamento IP padrão, como qualquer outro servidor.
Quanto aqualservidor de nomes raiz que o servidor DNS do ISP escolhe contatar, isso provavelmente depende dos detalhes de seu resolvedor DNS. Talvez seja completamente aleatório, talvez tenha peso, mas não sei dizer.
Editar: se você quis dizer, como funciona o ISPencontrarqualquer um dos 13 servidores de nomes, há uma lista pública deles e seus endereços IP correspondentes que basicamente todo computador possui. A partir daí, é só escolher um e deixar que os roteadores da internet façam o resto.