Como funciona a resolução de nomes DNS, em princípio?

Question 1

Supondo que seu servidor de nomes configurado não tenha nenhum resultado em cache à sua disposição, quantos servidores de nomes seu servidor de nomes deve consultar para resolver o maps.google.com? Que comando(s) você usaria para encontrar todos esses servidores de nomes? Liste um de cada nível e explique por que esse nível é necessário.

Bem, vamos separar este.

"Supondo que seu servidor de nomes configurado não tenha nenhum resultado em cache à sua disposição"- primeiro, se tivernãodados armazenados em cache, então ele não poderá resolver nada. Para preparar o cache do resolvedor, você precisa ter os registros NS e de endereço (A, AAAA) para a .zona (AKA root). Esses são os servidores de nomes raiz, encontrados na root-servers.net.zona. Não há nada de mágico nessa zona ou nesses servidores DNS. No entanto, esses dados são frequentemente fornecidos “fora de banda” ao resolvedor DNS, precisamente para preparar o cache do resolvedor. Os servidores de nomes somente autoritativos não precisam desses dados, mas os servidores de nomes de resolução precisam.

Além disso, "resolver" o quê? Algum tipo de RR com esse nome? Um ARR? Ou alguma outra coisa? Qual classe ( CH/Chaosnet, IN/Internet, ...)? O processo exato será diferente, mas a ideia geral permanece a mesma.

Se pudermos assumir que sabemos como encontrar os servidores de nomes raiz, mas nada mais, e que por "resolver" queremos dizer obter o conteúdo de quaisquer IN ARRs associados ao nome, fica muito mais prático.

Para resolver um nome DNS, você basicamente divide o nome em rótulos e depois trabalha da direita para a esquerda. Não se esqueça do .final; você realmente estaria resolvendo maps.google.com.em vez de maps.google.com. Isso nos deixa com a necessidade de resolver (sabemos disso, mas uma implementação de resolvedor de DNS provavelmente não):

.
com.
google.com.
maps.google.com.

Comece descobrindo onde solicitar o conteúdo de .. Isso é fácil; já temos essa informação: o servidor de nomes raiznomes e endereços IP. Portanto, temos um servidor de nomes raiz. Digamos que decidimos usar 198.41.0.4 ( a.root-servers.net, também 2001:503:ba3e::2:30) para continuar a resolução de nomes. Na prática, uma das primeiras coisas feitas pelo resolvedor provavelmente será usar os dados fornecidos pelo servidor raiz para solicitar a um dos servidores da zona raiz uma lista precisa dos servidores de nomes da zona raiz, garantindo assim que se qualquer um dos os nomes e endereços IP são válidos e acessíveis, ele terá um conjunto completo de dados para a zona raiz quando a resolução começar.

Faça uma consulta DNS para maps.google.com. IN A198.41.0.4. A resposta será "não, não vou fazer isso, mas aqui está alguém que pode saber"; isso é uma referência. Ele contém NSregistros da zona mais próxima que o servidor em questão conhece, junto com quaisquer registros de cola que o servidor tenha disponível. Se nenhum dado de colagem estiver disponível, primeiro você terá que resolver o host nomeado no registro NS escolhido, então crie uma resolução de nome separada para obter o endereço IP; se os dados cola estiverem disponíveis, você terá o endereço IP de um servidor de nomes que está pelo menos "mais próximo" da resposta. Nesse caso, esse será o conjunto de servidores da com.zona, e os dados cola também serão fornecidos.

com.Repita o processo, fazendo a mesma pergunta a um dos servidores de nomes. Eles também não sabem, mas irão encaminhá-lo para os servidores de nomes oficiais do Google. Neste ponto, no caso geral, será um sucesso ou um fracasso se os dados da cola forem fornecidos ou não; não há nada que impeça um comdomínio de ter servidores de nomes apenas em nl, por exemplo, caso em que é improvável que os dados cola estejam disponíveis nos servidores gTLD. Os dados da cola fornecidos também podem estar incompletos ou, se você tiver muito azar, podem até estar incorretos! Você tem quesempreesteja preparado para gerar aquela resolução de nomes separada que mencionei acima.

Basicamente, você continua até obter uma resposta com o aasinalizador (resposta oficial) definido. Essa resposta lhe dirá o que você está pedindo ou que o RR solicitado não existe ( NXDOMAINou NOERRORcom zero registros de dados de resposta). Continue procurando respostas como SERVFAIL(e recue uma etapa e tente outro servidor, se conseguir um; se todos os servidores nomeados retornarem SERVFAIL, falhe no processo de resolução de nomes e retorne SERVFAILao cliente).

A alternativa para solicitar o RRname completo de cada servidor (o que pode ser considerado uma má prática) é usar a lista dividida de rótulos que determinamos anteriormente, perguntar aos servidores de nomes fornecidos pelo servidor mais em direção à raiz para IN NSe IN A/ IN AAAARRs para esse rótulo e usá-los para promover o processo de resolução de nomes. Isso é apenas ligeiramente diferente na prática, e o mesmo processo ainda se aplica.

Você pode simular todo esse processo usando a +traceopção do digutilitário, que vem como parte do BIND, ou set debugem formato nslookup.

Também vale a pena lembrar que alguns RRtypes (notavelmente NS, MXe alguns outros; também A6foram razoavelmente bem usados por um tempo, mas foram obsoletos) podem e fazem referência a outros RRs. Nesse caso, você pode precisar desovarAinda outraprocesso de resolução de nomes para dar uma resposta completa e útil ao seu cliente.

Answer

Supondo que seu servidor de nomes configurado não tenha nenhum resultado em cache à sua disposição, quantos servidores de nomes seu servidor de nomes deve consultar para resolver o maps.google.com? Que comando(s) você usaria para encontrar todos esses servidores de nomes? Liste um de cada nível e explique por que esse nível é necessário.

Bem, vamos separar este.

"Supondo que seu servidor de nomes configurado não tenha nenhum resultado em cache à sua disposição"- primeiro, se tivernãodados armazenados em cache, então ele não poderá resolver nada. Para preparar o cache do resolvedor, você precisa ter os registros NS e de endereço (A, AAAA) para a .zona (AKA root). Esses são os servidores de nomes raiz, encontrados na root-servers.net.zona. Não há nada de mágico nessa zona ou nesses servidores DNS. No entanto, esses dados são frequentemente fornecidos “fora de banda” ao resolvedor DNS, precisamente para preparar o cache do resolvedor. Os servidores de nomes somente autoritativos não precisam desses dados, mas os servidores de nomes de resolução precisam.

Além disso, "resolver" o quê? Algum tipo de RR com esse nome? Um ARR? Ou alguma outra coisa? Qual classe ( CH/Chaosnet, IN/Internet, ...)? O processo exato será diferente, mas a ideia geral permanece a mesma.

Se pudermos assumir que sabemos como encontrar os servidores de nomes raiz, mas nada mais, e que por "resolver" queremos dizer obter o conteúdo de quaisquer IN ARRs associados ao nome, fica muito mais prático.

Para resolver um nome DNS, você basicamente divide o nome em rótulos e depois trabalha da direita para a esquerda. Não se esqueça do .final; você realmente estaria resolvendo maps.google.com.em vez de maps.google.com. Isso nos deixa com a necessidade de resolver (sabemos disso, mas uma implementação de resolvedor de DNS provavelmente não):

.
com.
google.com.
maps.google.com.

Comece descobrindo onde solicitar o conteúdo de .. Isso é fácil; já temos essa informação: o servidor de nomes raiznomes e endereços IP. Portanto, temos um servidor de nomes raiz. Digamos que decidimos usar 198.41.0.4 ( a.root-servers.net, também 2001:503:ba3e::2:30) para continuar a resolução de nomes. Na prática, uma das primeiras coisas feitas pelo resolvedor provavelmente será usar os dados fornecidos pelo servidor raiz para solicitar a um dos servidores da zona raiz uma lista precisa dos servidores de nomes da zona raiz, garantindo assim que se qualquer um dos os nomes e endereços IP são válidos e acessíveis, ele terá um conjunto completo de dados para a zona raiz quando a resolução começar.

Faça uma consulta DNS para maps.google.com. IN A198.41.0.4. A resposta será "não, não vou fazer isso, mas aqui está alguém que pode saber"; isso é uma referência. Ele contém NSregistros da zona mais próxima que o servidor em questão conhece, junto com quaisquer registros de cola que o servidor tenha disponível. Se nenhum dado de colagem estiver disponível, primeiro você terá que resolver o host nomeado no registro NS escolhido, então crie uma resolução de nome separada para obter o endereço IP; se os dados cola estiverem disponíveis, você terá o endereço IP de um servidor de nomes que está pelo menos "mais próximo" da resposta. Nesse caso, esse será o conjunto de servidores da com.zona, e os dados cola também serão fornecidos.

com.Repita o processo, fazendo a mesma pergunta a um dos servidores de nomes. Eles também não sabem, mas irão encaminhá-lo para os servidores de nomes oficiais do Google. Neste ponto, no caso geral, será um sucesso ou um fracasso se os dados da cola forem fornecidos ou não; não há nada que impeça um comdomínio de ter servidores de nomes apenas em nl, por exemplo, caso em que é improvável que os dados cola estejam disponíveis nos servidores gTLD. Os dados da cola fornecidos também podem estar incompletos ou, se você tiver muito azar, podem até estar incorretos! Você tem quesempreesteja preparado para gerar aquela resolução de nomes separada que mencionei acima.

Basicamente, você continua até obter uma resposta com o aasinalizador (resposta oficial) definido. Essa resposta lhe dirá o que você está pedindo ou que o RR solicitado não existe ( NXDOMAINou NOERRORcom zero registros de dados de resposta). Continue procurando respostas como SERVFAIL(e recue uma etapa e tente outro servidor, se conseguir um; se todos os servidores nomeados retornarem SERVFAIL, falhe no processo de resolução de nomes e retorne SERVFAILao cliente).

A alternativa para solicitar o RRname completo de cada servidor (o que pode ser considerado uma má prática) é usar a lista dividida de rótulos que determinamos anteriormente, perguntar aos servidores de nomes fornecidos pelo servidor mais em direção à raiz para IN NSe IN A/ IN AAAARRs para esse rótulo e usá-los para promover o processo de resolução de nomes. Isso é apenas ligeiramente diferente na prática, e o mesmo processo ainda se aplica.

Você pode simular todo esse processo usando a +traceopção do digutilitário, que vem como parte do BIND, ou set debugem formato nslookup.

Também vale a pena lembrar que alguns RRtypes (notavelmente NS, MXe alguns outros; também A6foram razoavelmente bem usados por um tempo, mas foram obsoletos) podem e fazem referência a outros RRs. Nesse caso, você pode precisar desovarAinda outraprocesso de resolução de nomes para dar uma resposta completa e útil ao seu cliente.

Question 2

Existe um dnstracercomando (talvez seja necessário instalá-lo, pelo menos no Debian, esse também é o nome do pacote) que rastreará a resolução de nomes. Você também pode (como Koveras aponta em um comentário) usar dig.

Aqui está com dnstracer. -s .significa começar pela raiz; -4significa usar IPv4 (v6 está quebrado aqui...); -osignifica realmente mostrar os endereços IP resolvidos no final (omiti essa parte da saída, há muitos deles).

anthony@Zia:~$ dnstracer -s . -4 -o maps.google.com
Tracing to maps.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4) 
 |\___ m.gtld-servers.net [com] (192.55.83.30) 
 |     |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer 
 |     |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer 
 |     |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer 
 |      \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer 
⋮

Essa saída continua, enquanto o dnstracer rastreia todos os caminhos (para que você possa ver se, por exemplo, alguns dos servidores de nomes têm uma zona desatualizada).

Portanto, você pode ver que é necessária uma consulta ao servidor de nomes raiz, depois uma aos servidores gtld (o servidor da zona .com) e, finalmente, uma a um servidor de nomes do Google.

Com dig, a saída é muito mais detalhada (então farei muitos cortes):

dig -4 maps.google.com. +norecurse +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> maps.google.com. +norecurse +trace
;; global options: +cmd
.                       425379  IN      NS      b.root-servers.net.
⋮
com.                    172800  IN      NS      f.gtld-servers.net.
⋮
google.com.             172800  IN      NS      ns2.google.com.
⋮
maps.google.com.        300     IN      A       74.125.228.70
⋮

digmostra adicionalmente que fez uma consulta para obter a lista atual de servidores de nomes raiz. Isso é algo que um servidor DNS normalmente fará com pouca frequência. Portanto, não tenho certeza se você conta isso em seu caso de cache frio.

É claro que você também pode assistir às consultas reais na transmissão com, por exemplo, wireshark.

Answer