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

No momento, estou fazendo um curso on-line para sysadmin do Linux e me fizeram uma pergunta que geralmente não entendo. Eu sei como procurar um servidor de nomes, se estiver correto, pelo menos, ele está usando o comando dig para encontrar os endereços no comando de seção adicional, mas fiquei um pouco perdido ao fazer a seguinte pergunta.

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

Não quero a resposta, gostaria apenas de saber exatamente o que me pedem.

Supondo que o servidor de nomes configurado não tenha nenhum resultado em cache à sua disposição, quantos servidores de nomes o servidor de nomes deve consultar para resolver maps.google.com? Quais comandos 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 escolher este aqui.

"Supondo que o servidor de nomes configurado não tenha resultados em cache à sua disposição" - primeiro, se não houver dados em cache, não poderá resolver nada. Para preparar o cache do resolvedor, você precisa ter os registros NS e endereço (A, AAAA) para a zona .(raiz do AKA). Esses são os servidores de nomes raiz, encontrados na root-servers.net.zona. Não há nada mágico nessa zona ou nos servidores DNS. No entanto, esses dados geralmente são fornecidos "fora da banda" para o resolvedor DNS, precisamente para preparar o cache do resolvedor. Servidores de nomes com autoridade apenas não precisam desses dados, mas a resolução de servidores de nomes exige.

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

Se pudermos supor que sabemos como encontrar os servidores de nomes raiz, mas nada mais, e que por "resolver" queremos obter o conteúdo de qualquer IN ARR associado ao nome, fica muito mais prático.

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

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

Comece descobrindo onde pedir o conteúdo de .. Isso é fácil; já temos essa informação: os nomes dos servidores raiz e os 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 ações realizadas pelo resolvedor provavelmente será usar os dados do servidor raiz fornecidos para solicitar a um dos servidores da zona raiz uma lista precisa dos servidores de nomes da zona raiz, garantindo, assim, se algum os nomes e endereços IP forem válidos e alcançáveis, eles terão um conjunto completo e completo de dados para a zona raiz quando a resolução começar.

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

Repita o processo, fazendo a mesma pergunta a um dos com.servidores de nome. Eles também não sabem, mas encaminhá-lo-ão aos servidores de nomes oficiais do Google. Nesse ponto, no caso geral, será uma falha ou não se os dados da cola são fornecidos ou não; não há nada que impeça que um comdomínio tenha servidores de nomes apenas nl, por exemplo, caso em que é improvável que os dados de colagem estejam disponíveis nos servidores de gTLDs. Os dados de cola fornecidos também podem estar incompletos ou, se você tiver realmente azar, pode até estar incorreto! Você sempre deve estar preparado para gerar a resolução de nome separada que mencionei acima.

Basicamente, você continua até obter uma resposta com o aasinalizador (resposta autorizada) definido. Essa resposta informará o que você está solicitando ou que o RR solicitado não existe ( NXDOMAINou NOERRORcom registros de dados de resposta zero). Continue procurando respostas como SERVFAIL(e volte um passo e tente outro servidor, se você o tiver; se todos os servidores nomeados retornarem SERVFAIL, falhem no processo de resolução de nomes e retornem SERVFAILpara o cliente).

A alternativa para pedir a RRname completo de cada servidor (que pode ser considerado uma má prática) é usar a lista de cisão de etiquetas que determinado anteriormente, perguntar aos servidores de nomes fornecidos pelo servidor ainda mais em direção à raiz para IN NSe IN A/ IN AAAARRS para esse rótulo e use-os para promover o processo de resolução de nomes. Isso é apenas marginalmente 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 faz parte do BIND ou set debugno nslookup.

Também vale lembrar que alguns RRtypes (notavelmente NS, MXe alguns outros; também A6foram razoavelmente bem utilizados por um tempo, mas foram obsoletos) podem e fazem referência a outros RRs. Nesse caso, talvez seja necessário iniciar outro processo de resolução de nomes para dar uma resposta completa e útil ao seu cliente.

Existe um dnstracercomando (você pode precisar instalá-lo, pelo menos no Debian, que 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 o dnstracer. -s .significa começar com a raiz; -4significa usar IPv4 (a v6 está quebrada aqui ...); -osignifica realmente mostrar os endereços IP resolvidos no final (eu omiti essa parte da saída, existem muitos).

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, pois o dnstracer rastreia todos os caminhos (para que você possa ver se, por exemplo, alguns servidores de nomes têm uma zona desatualizada).

Assim, você pode ver que são necessárias uma consulta ao servidor de nomes raiz, depois uma para os servidores gtld (o servidor da zona .com) e, finalmente, uma para o servidor de nomes do Google.

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

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
⋮

digAlém disso, mostra que ele fez uma consulta para obter a lista atual de servidores de nomes raiz. Isso é algo que um servidor DNS normalmente faz com pouca frequência. Portanto, não tenho certeza se você conta no seu caso de cache frio.

Obviamente, você também pode assistir às consultas reais na conexão com, por exemplo wireshark,.