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.
dig +trace, mas não sei ao certo o que significa níveis. Isso pode ser uma pergunta para a falha do servidor.