Como é determinada a ordem de pesquisa de DNS?

Por exemplo: registramos o nome de domínio domain.com e adicionamos registros do servidor de nomes no servidor de registradores:
ns1.domain.com.
ns2.domínio.com.
ns3.domínio.com.

Do que procuramos em domain.com . Recebemos todos os três endereços do servidor de nomes.
1. Qual desses servidores será solicitado mais adiante e por quê?
2. A ordem dos registros NS no arquivo de zona é importante?
3. É determinado em qualquer RFC ?

Infelizmente, a resposta aqui é "depende". Os fatores de que depende variam com o domínio e com a configuração dos servidores proprietários e com a configuração do DNS local.

Primeiro, por exemplo, em relação aos registros NS retornados: é perfeitamente permitido aleatoriamente a ordem em que esses registros são retornados, portanto, a ordem pode diferir cada vez que você solicita. Por outro lado, isso não é feito em todas as implementações de DNS, portanto é possível obter uma lista ordenada estaticamente. O ponto é que você não pode ter certeza.

Em seguida, algumas implementações de DNS consultarão cada NS em paralelo e usarão o que responder primeiro. Outros irão acertar cada um, determinar o mais rápido em alguns pedidos e usar esse. Ou poderia apenas rodopiar.

Existem várias RFCs para DNS, duas das mais úteis que encontrei são:

http://www.faqs.org/rfcs/rfc1912.html

http://www.faqs.org/rfcs/rfc1033.html

Sei que isso não é uma resposta, sem nada definitivo para você tirar, mas, considerando o exposto acima, a única maneira verdadeira de determinar o comportamento de um determinado domínio é testar.

A implementação mais comum que eu já vi no nível do cliente, como os ISPs em todo o mundo, é a seguinte:

1. Alguém (como um assinante de banda larga) pede aos servidores DNS do ISP para resolver o registro A de foo.example.com.
2. O ISP verifica seu próprio cache e, se esse registro é armazenado em cache e ainda é considerado "novo", é imediatamente retornado pelo cache. ( É assim que todos os caches DNS funcionam, para que eles não sobrecarreguem desnecessariamente os servidores DNS do site em questão. )
3. Se eles não tiverem esse registro em cache ou se o cache for considerado "obsoleto / desatualizado", o ISP saberá que precisa resolver o registro mais recente novamente.
4. Agora, o ISP precisa saber quais servidores de nomes devem ser consultados sobre o registro mais recente.
5. O ISP começa verificando sua lista em cache dos servidores de nomes autoritativos para o domínio (esses são ns1.example.com, ns2.example.com e assim por diante, juntamente com seus IPs). Se esses registros ainda forem considerados atualizados, eles passarão para a etapa 8.
6. Se os registros do servidor de nomes em cache foram considerados expirados ou se não havia registros em cache para esse domínio, o ISP consultará os servidores de nomes raiz do TLD (como o registro .com, se for um domínio .com) para obter o pares de nomes / IP mais atualizados do servidor de nomes, por exemplo.com. ( Você pode tentar isso pessoalmente em "dig @ b.gtld-servers.net example.com" para ver o que os servidores de nomes raiz do seu TLD sabem sobre o seu domínio - se o seu domínio pertencer aos TLDs com / net / etc habituais. Os TLDs precisariam consultar seus respectivos servidores raiz. )
7. Os servidores de nomes raiz do TLD sempre retornam os servidores de nomes na ordem exata em que foram especificados por você; nenhuma randomização continua. Eles também retornam os IPs para cada servidor de nomes; isso é conhecido como "GLUE" e é o que permite à Internet resolver o problema "de galinha e ovo" de como resolver um nome de host de servidor de nomes para um IP antes de saber algo sobre um domínio. Além disso, a maioria deles (como os registros com / net / etc, que são os maiores) usam um tempo de cache de 2 dias para que não sejam constantemente pressionados com "qual é a lista de servidores de nomes para o domínio X?" solicitações de. Essa é a fonte do conhecimento comum de que você DEVE esperar 2 dias até poder dizer com segurança que seus novos servidores de nomes são conhecidos em todo o mundo depois de você '
8. Quando o ISP conhece os servidores de nomes da example.com e seus IPs, como ns1.example.com, ns2.example.com, ns3.example.com, o ISP agora escolhe um servidor aleatório dessa lista e envia a consulta. ( Isso é legal da parte deles, eles não martelam desnecessariamente todos os servidores DNS do site em questão e ajudam ainda mais no balanceamento de carga, nem sempre consultando o primeiro servidor de nomes listado. )
9. Se o ISP não obtiver uma resposta desse servidor de nomes dentro de um período de tempo limite especificado, ele consultará outro na lista.
10. Quando tem uma resposta, o ISP agora o armazena em seu próprio cache local. Quanto tempo ele permanecerá em cache; cada registro retornado por qualquer servidor DNS também possui um tempo de "validade expirada" (em segundos) associado, ou seja, quanto tempo o cliente que está consultando (como o servidor DNS do ISP) pode armazenar em cache esse registro antes de ser considerado " ainda utilizável, mas possivelmente desatualizada, uma nova consulta agora deve ocorrer SE POSSÍVEL, apenas para garantir que ela não tenha sido alterada. " Também há um tempo de "validade expirada" especificado no registro "SOA" (Início da autoridade) de cada servidor de nomes individual (você pode ver o seu em "dig @ ns1.example.com example.com -t soa"), que especifica um "limite rígido" global para todos os registros retornados por esse servidor, após o qual qualquer cache DELETE seu registro em cache, mesmo que os servidores de nomes estejam inoperantes e seja impossível procurar os registros novamente. Geralmente, a expiração branda varia de 30 minutos a 5 horas e a expiração dura geralmente entre 1-3 semanas.
11. Após esse trabalho exaustivo, o ISP finalmente possui o registro DNS mais recente e pode devolvê-lo ao assinante de banda larga consultante, que não é nem um pouco mais sábio do que um grande trabalho ocorreu nos bastidores!

Esse processo é repetido para TODAS as consultas de registro. No entanto, apenas a primeira consulta faz todo o trabalho; os IPs do servidor de nomes serão armazenados em cache depois disso e as consultas subsequentes ao servidor DNS de cache do ISP poderão rapidamente saltar para a etapa 8.

Agora, quanto à randomização da etapa 8, ela funciona em nível de registro. Digamos que o assinante de banda larga desse ISP tenha perguntado sobre os seguintes registros:

• Um exemplo de foo.example.com
• A example.com
• A www.example.com
• MX example.com (um cliente ISP não deve estar solicitando esse registro, mas é apenas um exemplo)

Cada registro será tratado como sua própria "entidade" separada, armazenada em cache e pesquisada independentemente. Então, digamos que o assinante e o ISP nunca tenham encontrado o domínio antes e ambos tenham zero registros em cache completamente. As pesquisas podem ser as seguintes:

• Um foo.example.com via ns1.example.com, em seguida, armazenado no cache do ISP
• Um exemplo.com via ns3.example.com, depois armazenado no cache do ISP
• Um www.example.com via ns2.example.com e armazenado no cache do ISP
• MX example.com via ns3.example.com, em seguida, armazenado no cache do ISP

Sempre que os registros em cache expiram com facilidade, o processo é repetido, para que você nem saiba que solicitações subsequentes para esse registro usarão o mesmo servidor novamente.

Portanto, é seu maior objetivo absoluto garantir que todos os seus servidores DNS estejam completamente sincronizados, espelhando perfeitamente todos os registros DNS em todos os servidores. Você nunca sabe em qual servidor um cliente DNS estará acessando e não poderá confiar em nenhum pedido. Não existe tal coisa.

Além disso, como mencionado por Adam C, os próprios servidores DNS no nível do servidor (exemplo.com) podem retornar registros NS e aleatoriamente a ordem deles. É muito comum que servidores DNS regulares randomizem seus registros NS com a pequena chance de uma implementação DNS ruim sempre escolher o primeiro servidor de nomes retornado. No entanto, os servidores de nomes ROOT TLD (mencionados anteriormente) nunca randomizarão a lista, e a lista deles é o que realmente importa quando se trata de resolver o domínio. É por isso que a maioria das implementações seleciona um servidor aleatório nas listas de servidores de nomes, para evitar sempre atingir o mesmo servidor e sobrecarregá-lo.

Tudo bem, essa é a sua cartilha sobre como o DNS funciona e o que você deve se lembrar.

• Resumindo: trate todos os seus servidores DNS como se fossem apenas um servidor, tornando-o seu maior objetivo na vida para garantir que todos sejam igualmente capazes de responder a qualquer consulta que possa ser lançada sobre eles.

Isenção de responsabilidade: objetivos mais altos na vida do que gerenciar o DNS podem estar disponíveis, mas são vendidos separadamente, use sua imaginação. ;-)