Por que essa pesquisa de DNS falha para mim, mas funciona para outras pessoas?

Question

Dia Um

Eu tenho que esconder os nomes dos hosts, então estou esperando ainda existir informação suficiente para responder a esta questão ...

Estou tentando resolver um determinado nome de host (vamos fingir que é www.example.com , mas isso é não o nome do host real). Uma simples solicitação de dig funciona, mas quando tento fazer uma série de dig a partir de um servidor de nomes raiz, chego a um beco sem saída. Aqui está um exemplo:

# Starting with arbitrarily-chosen root nameserver
$ dig @198.41.0.4 www.example.com
(returns the usual list of TLD .com nameservers)

# Using a.gtld-servers.net
$ dig @192.5.6.30 www.example.com
(returns a list of 5 example.com authorities)

Neste ponto, tentei cada uma das autoridades de 5 example.com . Três deles falham com status SERVFAIL , e os dois restantes esgotam o tempo limite. Aqui está um exemplo de SERVFAIL :

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33577
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.example.com.       IN  A

;; Query time: 74 msec
;; SERVER: <intentionally removed>
;; WHEN: Tue Mar  8 10:10:33 2011
;; MSG SIZE  rcvd: 37

Eu tentei isso várias vezes, a partir de minha própria máquina em casa e de uma máquina remota em nosso co-lo, e ambas as máquinas obtêm consistentemente os mesmos resultados.

No entanto,

• Como mencionei acima, dig www.example.com (sem especificar um @server ) funciona bem.
• Este utilitário de rastreamento DNS é capaz de resolver o nome do host e mostra claramente que está usando um dos os servidores de nome que expiram para mim!

Alguém pode me ajudar a descobrir o que está acontecendo?

EDIT 1: Caso isso ajude, o que deve acontecer é que esse nome de host seja resolvido para um registro CNAME apontando para www.example.com.edgesuite.net , que por sua vez deve resolva para outro registro CNAME apontando para um servidor de borda Akamai.

EDIT 2: Por recomendação de Joris, eu corri dig +trace www.example.com , e na verdade não consegui encontrar um resultado. Ele chega à mesma lista de example.com autoridades que encontrei antes e para lá.

O cache parece ser um provável culpado (e eu pensei nisso antes), mas a parte estranha é que o nome do host atual não é tão popular. Ele seria armazenado em cache em dois servidores de nomes locais do ISP diferentes se eu fosse a primeira pessoa a solicitá-lo? : -)

Dia Dois

OK, descobri algumas coisas:

1. As duas example.com autoridades que eu pensei estavam expirando (ao contrário das outras três, que estavam retornando SERVFAIL ) não estão realmente atingindo o tempo limite. Eles exigem apenas um tempo limite maior . Se eu usar dig +time=10 , por exemplo, eu eventualmente recupero um resultado.
2. Eu tentei isso de vários servidores nos EUA e a história é a mesma - usar dig www.example.com retorna um resultado muito rapidamente, mas dig @ns1.example.com (ou @ns2.example.com ) exige o uso de um grande parâmetro de tempo limite.

Então, minhas novas perguntas são:

1. O resultado pode realmente ser armazenado em cache em vários servidores DNS de proxy, mesmo que não seja um nome de host comumente usado? O TTL é 54.000 (ou 15 horas, se eu entendi corretamente).
2. Se não, então é possível que ns1.example.com seja de alguma forma configurado para retornar um resultado mais rapidamente para servidores DNS de proxy do que para minhas próprias dig consultas (algum tipo de lista branca)? Ou isso é apenas uma conversa maluca?

Answer 1

Não obscureça seus dados de DNS ao solicitar ajuda com Problemas de DNS . É inútil e bobo, e este é um exemplo clássico de como isso serviu para obscurecer o problema real que você tem.

Existem duas grandes possibilidades aqui:

• Você tem conectividade intermitente com os servidores DNS de conteúdo. Uma causa comum de tais problemas é um problema de roteamento de tráfego IP ou um simples caso de haver muitos saltos entre você e eles. Descubra os endereços IP dos 5 servidores DNS de conteúdo em questão e use traceroute ou algo assim para determinar se você realmente tem conectividade IP com todos eles. Teste a conectividade UDP / IP com a porta 53, especificamente, se a sua ferramenta for capaz disso.
• A resposta foi fornecida em um dos caminhos que você não realizou ao fazer as coisas manualmente e que o servidor DNS de proxy resolvido às vezes só demora. A infeliz verdade sobre a resolução da consulta DNS é que há uma muito mais caminhos que podem derrubar a árvore do namespace DNS do que se poderia pensar das explicações superficiais do processo que existe. É possível, por exemplo, que o primeiro conjunto de registros de recursos CNAME (que você não pode obter) tenha sido servido e armazenado em cache pelo seu resolvendo o servidor DNS proxy , ao mapear os nomes de alguns dos servidores DNS de conteúdo de nível superior para os endereços. Dado que seu servidor DNS proxy de resolução às vezes funciona, você pode descobrir como ele descobriu a resposta observando seus logs de consulta / resposta. (Alguns softwares de servidor DNS precisam ter esse registro explicitamente ativado. Alguns têm por padrão. Como fazer isso para o seu software em particular, o que você não afirmou, é o domínio de uma questão separada.)

Observe que o único cache que ocorre aqui é local, no seu servidor DNS de proxy de resolução. Os servidores DNS de conteúdo que você está consultando não armazenam em cache. (Ou, mais estritamente falando, se eles armazenam em cache, armazenam em cache os bancos de dados back-end dos quais estão trabalhando, de maneiras que têm pouco ou nada a ver com TTLs de registro de recursos e que não são visíveis publicamente através do protocolo DNS. )

Há também algumas possibilidades menores e bastante improváveis, incluindo firewalls tênues em seu site, reescrevendo o tráfego de DNS na hora em que ele passa por eles. Mas como você não forneceu os dados corretos, há pouco mais para restringir e descartar as possibilidades que você pode obter de transeuntes aleatórios na Internet.

    

Answer 2

Para eliminar qualquer chance de consultas incorretas, você poderia tentar o dig + trace example.com? Ele seguirá a corrente para você. Se isso for bem-sucedido (ele tentará apenas uma das autoridades em cada nível), você terá pelo menos uma trilha de trabalho.

Se várias tentativas falharem, há algo quebrado. É provável que você esteja vendo respostas em cache com a solicitação "normal". espere que a quebra apareça assim que o TTL expirar.

    

Answer 3

At this point, I tried each of the 5 foo.com authorities.

Eu recebo duas autoridades:

;; AUTHORITY SECTION:
foo.com.        172800  IN  NS  ns.okdirect.com.
foo.com.        172800  IN  NS  ns2.okdirect.com.

Ambos resolvem www.foo.com corretamente.

    

Answer 4

Você alterou o número de servidores de nome autorizados para seu domínio? No nível que você está consultando, elas são tratadas no nível de registrador. Se você viu 5 antes e agora você vê 2, eu teria que adivinhar que você fez uma alteração em suas entradas de servidor de nomes autorizados?

Da próxima vez, tente um telnet simples para a porta 53 dos servidores de nomes autorizados

    

Answer 5

Isso soa como um problema da ACL nos servidores de nomes. A prática recomendada é separar resolvedores e servidores autoritativos. O domínio parece ter 2x servidores autoritativos e três resolvedores de armazenamento em cache que possuem restrições restritivas que impedem a consulta do domínio. Seu caso "no entanto" funciona devido à solicitação ser uma consulta e não solicitar recursão.

No bind você deve ter as seguintes três opções especificadas ou o padrão será aplicado, o que mudou com as versões de bind.

allow-recursion {nenhum; }; allow-query {any; }; allow-query-cache {ournets; };

    

Answer 6

Acabei de encontrar uma solução para um problema semelhante:

O servidor Debian registrado no Windows Server 2003 não foi resolvido corretamente. às vezes eu era capaz de alcançar o servidor através do seu nome de host, às vezes não.

o problema era um endereço ipv6 da máquina Linux. desativar o ipv6 resolveu o problema.

    

Answer 7

O problema é que você não está usando as consultas certas. Você precisa perguntar aos servidores-raiz pelo NS do TLD (por exemplo, dig @ROOT-NS com. ), depois pergunte ao TLD sobre seu domínio (por exemplo, dig @TLD-NS example.com ) e depois pergunte ao NS por exemplo.com sobre www.example.com (por exemplo, dig @eaxmple.com-NS-IP www.example.com )

Editar: Aqui está um exemplo completo:

dig -t NS .                         # Find the root NS using local resolver
dig -t NS @f.root-servers.net com. 
dig -t NS @a.gtld-servers.net example.com
dig -t A @ns.example.com www.example.com