Compreendendo o mecanismo de pesquisa de domínio DNS

Question

A consulta específica que me levou a tentar desfazer esse processo foi:

Uma pesquisa de DNS para um subdomínio, como assets.example.com , será mais rápida se o domínio pai, example.com , já tiver sido resolvido?

Por meu entendimento (ingênuo), o processo básico para traduzir um nome de domínio em um endereço IP é bastante simples. Os endereços dos treze servidores-raiz, que sabem como resolver domínios de nível superior, como com e net , são efetivamente codificados em hardware de rede. No caso de uma pesquisa por example.com , nosso servidor DNS local, provavelmente nosso roteador, consultará um desses servidores raiz para o domínio em questão e será encaminhado ao servidor de nome de nível superior para com . Em seguida, ele pergunta a este servidor de nomes se ele sabe como resolver example . Se isso acontecer, terminamos, se não, nos referimos a outro servidor. Alguns dos servidores neste processo podem estar em cache, de modo que por um tempo nosso roteador local saberá agora onde procurar com e example .

Ainda assim, eu realmente não entendi.

• Eu sei que existem outros servidores DNS intermediários, como os fornecidos pelos ISPs. Em que ponto eles são questionados?
• Se o servidor de nomes com TLD a que nos referimos não souber como resolver example , será correto dizer que esse é o fim da linha: example.com não pode ser resolvido?
• Quando eu registro um domínio e configuro servidores de nomes, estou, na verdade, editando um grupo de registros do NS para meu subdomínio no banco de dados usado pelos servidores de nomes para esse TLD? O próprio registrador mantém servidores de nomes "proxy"?

A Wikipédia explica que alguns servidores DNS combinam o armazenamento em cache com uma implementação de consulta recursiva que permite que eles atendam a ocorrências de cache e resolvam erros de cache de maneira confiável. Eu não entendo como esses servidores são consultados, ou como (mesmo amplamente) o algoritmo de resolução funciona. Todos os servidores de nomes com autoridade com , por exemplo, espelhos exatos, ou um resolvedor teria que testar cada um deles por sua vez?

Olhando para a minha pergunta inicial, eu poderia fazer uma tentativa muito especulativa de "não", assumindo que os registros A estão no mesmo servidor de nomes. Eu ficaria muito grato a qualquer um que pudesse reduzir minha ignorância!

    

Answer 1

Will a DNS lookup for a subdomain, such as assets.example.com, be faster if the parent domain, example.com, has already been resolved?

Supondo que haja um servidor de cache na cena, sim. Isso ocorre porque, para encontrar um registro A para qualquer coisa em example.com., Os servidores de nomes para example.com. deve ser conhecido. Quando a solicitação de assets.example.com. é feito o nameservers por example.com. já deve estar em cache e, portanto, a única consulta é para assets.example.com. em si.

I know there are other intermediate DNS servers, such as those provided by ISPs. At what point are they queried?

Estes são, normalmente, servidores de nomes em cache ou recursivos. Eles fazem o trabalho pesado em seu nome (as várias solicitações para percorrer a árvore) e, em seguida, armazenam em cache o resultado para acelerar as consultas posteriores para o mesmo nome.

Are all authoritative com nameservers, for example, exact mirrors, or would a resolver have to try each in turn?

Sim, eles contêm as mesmas informações. O resolvedor só precisa encontrar um que esteja realmente funcionando.

If the com TLD nameserver we're referred to does not know how to resolve example, is it right to say that's the end of the line: example.com cannot be resolved?

Se o .com. nameserver responde e diz example.com. não existe, então o resultado é que o nome não existe. Se o .com. O servidor de nomes não responde à consulta. O resolvedor deve tentar um .com diferente. servidor de nomes.

When I register a domain and configure nameservers, am I in effect editing a group of NS records for my subdomain in the database used by the nameservers for that TLD? Does the registrar itself maintain "proxy" nameservers?

Correto. Quando você registra o domínio, você fornece registros NS (e alguns registros A, se precisar de cola) para serem inseridos no domínio pai. O registrador não necessariamente executa esses servidores de nomes, mas tem um mecanismo para modificar o banco de dados desses servidores de nomes.

    

Answer 2

Provavelmente, o seu computador está configurado para usar um servidor DNS no seu ISP. Este é provavelmente um servidor de nomes em cache. O que isso significa é que ele armazenará em cache ocorrências (e, em alguns casos, perdas) por algum período de tempo (geralmente o TTL). Se você consultar este servidor de nomes para algo em seu cache, está feito. Ele vai te dizer o IP.

Se for um erro, ele consultará o servidor de nomes de nível superior (com, net, org, etc ...) para o domínio. Neste exemplo, ele perguntará COM onde encontrar EXAMPLE.COM e COM responderá com o endereço do servidor de nomes autoritativo (ip) para o domínio EXAMPLE.COM. Em seguida, ele solicitará ao servidor de nomes o IP de EXAMPLE.COM e informará ao servidor de nomes de armazenamento em cache que informará (esse é um registro A). Além disso, ele será armazenado em cache caso outra pessoa pergunte depois.

Se você estiver procurando por ASSETS.EXAMPLE.COM, a mesma coisa acontece, mas quando você encontrar o servidor de nomes autoritativo para EXAMPLE.COM, poderá solicitá-lo diretamente para ASSETS.EXAMPLE.COM e ele responderá com um registro A ( ip), CNAME, ou registro NS (existem outros tipos também como AAAA para ipv6, MX para mail ... mas isso será suficiente para este exemplo). Se der um registro A, você está pronto. Você tem um IP. Se isso der a você um NS, significa que esse outro servidor é autoritativo para ASSETS.EXAMPLE.COM e você deve perguntar àquele cara qual é o IP.

CNAME é outro tipo que inicia todo esse processo e não está disponível nos registros apex (como example.com) de qualquer maneira.