Minha pesquisa preliminar indica que a resposta é sim. Usando dig <domain> +trace Tenho observado o tempo que o servidor de nomes de nível superior relevante leva para retornar os servidores de nomes da próxima etapa (na maioria dos casos, a etapa que retorna ns1.someisp.com e ns2.someisp.com). / p>
Embora um número surpreendente de consultas ambas para domínios .au e domínios .com provenham de servidores de nomes que parecem envolver uma viagem de ida e volta aos EUA, isso estava ocorrendo mais para domínios .com. domínios au.
...
Ok, eu fiz mais pesquisas e pensei em relatar os resultados.
-
Todas as consultas DNS começam com a zona raiz, embora seja muito improvável que uma consulta na zona raiz precise consultar um servidor da zona raiz, pois quase sempre será armazenada em cache (essa é uma zona pequena, que apenas resolve os nomes "com", "org", "au", etc. Os servidores de nomes da zona raiz têm uma boa presença na Austrália (acho que 4 de 13 têm um nó na Austrália). precisa se preocupar com isso.
-
Em seguida, uma consulta DNS consultará os servidores de domínio de nível superior. Para um nome de domínio desconhecido, isso não será armazenado em cache, portanto, essa etapa é importante na rapidez com que algo é resolvido.
Dos 13 servidores de TLD para os domínios .com e .net , 1 deles responderão da Austrália (provavelmente porque usa o endereçamento anycast e tem um nó australiano). Ao tentar um servidor de nomes aleatório para um domínio .com desconhecido, há uma chance de 1/13 de retornar rapidamente (pelo que quero dizer < 25ms para os australianos, em oposição a 190-280ms, o que é típico para uma viagem de ida e volta aos EUA) .
Dos 12 servidores TLD para o domínio .au , 4 deles responderão da Austrália. Ao tentar um servidor de nomes aleatório para um domínio desconhecido. *. Au existe uma chance de 4/12 (ou 1/3) de que ele retornará rapidamente. FYI, dois destes resposta em menos de 5ms da localização com sede em Sydney eu testei.
Dos 6 servidores TLD para o domínio .org , 1 deles responderão da costa leste da Austrália e outro 1 responderá de um local próximo a ~ 55ms de distância (o que poderia significar, por exemplo, Cingapura), então daremos um meio ponto. Ao tentar um servidor de nomes aleatório para um domínio .org desconhecido, há uma chance de 1,5 / 6 (ou 1/4) de retornar rapidamente.
Testes que eu fiz de tempo para resolver .au vs .org respaldaram isso: os tempos de retorno para domínios não armazenados em cache variaram porque o servidor DNS testou a escolha de servidores de nomes aleatoriamente. No entanto, pesquisas para domínios .au tiveram uma média de 203 ms (12 tentativas) e para domínios .com em média 278ms (12 tentativas ). Conforme discutido abaixo, isso pode se tornar muito mais rápido ao usar um servidor DNS ocupado (um com um cache bem preparado).
-
Um servidor DNS recursivo ocupado executando algo como uma cópia recente do BIND armazenará em cache o RTT (tempo de viagem de retorno) para vários servidores de nomes e favorecerá os que já retornaram mais rapidamente. Esta é uma boa notícia, mas para que isso funcione bem, tem que ser um servidor DNS de tráfego razoavelmente grande. As informações de RTT para um servidor são decaídas com o tempo e descartadas quando são 30 minutos ou quando um determinado número de consultas aos servidores mais rápidos é concluído. Para "preparar" esse cache RTT, é necessário dúzias, ou centenas, de consultas para diferentes domínios (para que você atinja todos os servidores de nomes? .Gtld-servers.net, todos os servidores de nomes .au, etc., pelo menos uma vez). Para mantê-lo preparado exigiria, portanto, dezenas ou centenas de consultas por meia hora.
Um par típico de servidores DNS recursivos para um grande ISP deve se sair muito bem nisso.
-
Não é apenas o suficiente para obter o resultado do servidor TLD - isso apenas faz referência aos próprios servidores de nomes do domínio. Então você tem que consultá-los também. E se não houver registros de cola nos servidores TLD (o que não acontecerá se, por exemplo, seu domínio for exemplo. com e seus servidores de nomes forem ns ?. exemplo. org ), isso requer uma nova pesquisa de DNS para o endereço do servidor de nomes.
Quando eu fiz inicialmente este teste, fiquei surpreso com quantos dos servidores de nomes .au responderam em > 190ms (indicando que eles estavam quase certamente nos EUA).