A razão pela qual isso não importaria é que ninguém nunca pediria ao seu servidor de DNS pessoal para resolver o google.com.
Digamos que eu pergunte ao meu navegador por google.com. Aqui estão os passos que o servidor de nomes recursivo do meu provedor passa, supondo que o registro A do Google não esteja armazenado em cache localmente:
- Solicito o DNS Um registro para google.com do servidor de nomes do meu provedor (e não está no meu cache DNS pessoal).
- Se não estiver armazenado em cache recentemente, o servidor de nomes saberá que ele não é autoritativo para a zona google.com, por isso não é possível procurar no banco de dados da zona local. Assim, ele solicita um dos 13 servidores de nomes raiz aleatórios sobre o google.com.
- O servidor raiz envia o servidor de nomes do ISP para o servidor de domínio de nível superior global para o TLD .COM, usando seus registros NS.
- O servidor de nomes do GTLD também não sabe onde google.com está, mas envia ao servidor de nomes os registros dos servidores de nomes que são autoritativos para a zona do google.com.
- Agora, nosso servidor de nomes pergunta ao servidor autoritativo e ele retorna o registro A para google.com, que é retornado para nós (e armazenado em cache no servidor de nomes do ISP para evitar ter que passar por tudo isso novamente).
Como você pode ver, em nenhum ponto desse processo eu ou meu servidor de nomes perguntamos ao seu servidor DNS onde google.com está.
Agora, existem vulnerabilidades potenciais, por envenenamento de cache e outros ataques semelhantes. Uma das mais famosas é a vulnerabilidade de Kaminsky.
Para obter um guia passo-a-passo sobre a resolução de DNS, além de descrições dos problemas e vulnerabilidades mais graves, confira este guia ilustrado .