Atraso associado ao pedido AAAA

Question

Eu tenho uma rede isolada e autônoma executando sistemas Windows e Linux mistos, com um servidor Windows 2008 R2 executando tarefas do AD e DNS.

Estou vendo atrasos de 5 segundos com o uso de getaddrinfo no Linux sistemas.

No Wireshark, vejo (C- > S significa cliente para o servidor DNS):

t=0.000   C->S Query A     foo.example.com    ID=0x1111
t=0.000   C->S Query AAAA  foo.example.com    ID=0x2222
t=0.004   S->C Response to 0x2222, No error
          (Query is echoed)
          Authoritative nameservers:
             example.com: type SOA, class IN, mname svr01.example.com
               Name: example.com
               Type: SOA
               Class: IN
               TTL: 1 hour
               Primary name server: svr01.example.com
               Refresh interval: 15 minutes
               Retry interval: 10 minutes
               Expiration limit: 1 day
               Minimum TTL: 1 hour

[5 second delay]

t=5.004   C->S Query A     foo.example.com    ID=0x1111
t=5.005   S->C Query response A  192.168.1.17'

Se eu fizer a mesma solicitação novamente, logo em seguida, não verei atrasos, como esperado:

t=0.000   C->S Query A     foo.example.com    ID=0x3333
t=0.000   C->S Query AAAA  foo.example.com    ID=0x4444
t=0.001   S->C Query response A  192.168.1.17'

Eu posso continuar recebendo respostas imediatas por algum período de tempo. Depois de um tempo (ainda experimentando), o atraso retornará.

O que está acontecendo aqui? Se eu usar gethostbyname() (que só faz IPv4) ou nslookup foo.example.com , não há atraso.

Informação adicional:

• O IPv6 está desativado nas NICs do servidor

Atualização:

Esta resposta no Ask Ubuntu sugeriu adicionar

options single-request

para /etc/resolv.conf . Isto pareceu corrigir o problema para mim.

No entanto, ainda estou curioso:

• O que o registro SOA, na verdade, significa
• Por que o servidor não responde pela primeira vez à consulta A

Answer 1

Seu servidor DNS parece estar com bugs. Duas solicitações são enviadas para o servidor DNS, mas envia apenas uma única resposta. O cliente faz o que os clientes devem fazer nesse caso, aguarda um pouco e retransmite a solicitação.

Um atraso inicial de 5 segundos pode ser razoável para uso não interativo. Mas, para uso interativo, eu consideraria isso muito alto.

A correção adequada seria atualizar o servidor DNS para uma versão sem o bug ou entrar em contato com o fornecedor se nenhuma correção tiver sido liberada ainda. Tudo o resto é uma solução alternativa.

Usar man resolv.conf em um sistema Ubuntu explicará o que as opções single-request e single-request-reopen fazem. Essas são duas variações diferentes de uma solução alternativa para um bug conhecido em determinados servidores DNS. A desvantagem dessas opções é que ela diminui a resolução de nomes em aproximadamente um fator de dois. No entanto, dado que o bug parece retardar a resolução de nomes por um fator de cerca de 1000, talvez seja melhor usar a solução alternativa.

Ao solicitar um registro inexistente, você poderá receber uma resposta com um registro SOA. A razão para enviar não apenas um código de erro, mas também um registro SOA é que o registro SOA contém informações que permitirão que o resultado negativo seja armazenado em cache.

    

Answer 2

A maneira correta de interpretar sua captura de pacotes é que você está vendo pacotes de resposta ignorados para ambos as respostas dos registros A e AAAA .

O registro SOA parece confundir você e vale a pena elaborar:

• O registro SOA está, na verdade, na seção de autoridade, não na seção de resposta.
• NXDOMAIN significa "não há registros que possuam esse nome". Se houver outros registros com o mesmo nome, mas com tipos diferentes, a resposta que você verá será NOERROR com zero registros na seção de respostas.
• O que você está vendo é uma NOERROR de resposta com zero respostas e uma seção de autoridade informando de qual zona essa resposta veio. Você pode ignorar o componente SOA inteiramente. Esta resposta informa que não há registro AAAA .

Agora que estabelecemos que a resposta AAAA é um pacote formatado corretamente e o que você deve estar vendo neste cenário, ele muda o contexto do que você está procurando em inteiramente. Você está vendo casos em que A de respostas de registro estão sendo perdidas, além de AAAA de respostas sendo perdidas. Sua pesquisa sugere que AAAA respostas estão sendo perdidas com mais frequência, mas não exclusivamente.

Com base nas informações fornecidas, não poderemos explicar o que está acontecendo aqui. Você precisa configurar as capturas de pacotes nos próprios servidores DNS e identificar os seguintes fatores:

1. As consultas associadas às respostas ausentes chegam realmente ao servidor DNS?
2. Se as consultas chegarem ao servidor DNS, as respostas serão realmente enviadas?
3. Se o servidor não estiver enviando respostas, o seu servidor DNS precisará obter essas informações de um servidor DNS diferente que demore a responder? (expira na tentativa inicial, mas a consulta está em cache para a segunda tentativa) Você está vendo carga de consulta suficiente para estourar seu soquete fila ?
4. Se o servidor estiver enviando as respostas, quais dispositivos entre o servidor e o cliente podem estar perdendo os pacotes? Um dos seus servidores DNS tem um problema de roteamento em comparação com os outros? Parece que os pacotes estão sendo perdidos de todos os servidores DNS, sugerindo um problema de rede em algum lugar entre o cliente e o servidor?

Como você pode ver, há muitas coisas que poderiam estar acontecendo aqui. Você precisará se aprofundar no problema para descartar as possibilidades. Peço desculpas por esta resposta não ser conclusiva, mas isso foi muito mais do que poderia ser coberto dentro de alguns comentários. Sinta-se à vontade para atualizar sua pergunta.