Respostas do servidor DNS e tempos limite

Estamos enfrentando um problema frustrante em nossa LAN. Periodicamente, as consultas DNS aos nossos servidores de nomes ISP atingem o tempo limite, forçando um atraso de 5 segundos. Mesmo se eu ignorar /etc/resolv.confusando uma escavação direta em um de nossos servidores DNS, ainda encontro o problema. Aqui está um exemplo:

mv-m-dmouratis:~ dmourati$ time dig www.google.com @209.81.9.1 

; <<>> DiG 9.8.3-P1 <<>> www.google.com @209.81.9.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14473
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 4, ADDITIONAL: 4

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

;; ANSWER SECTION:
www.google.com.     174 IN  A   74.125.239.148
www.google.com.     174 IN  A   74.125.239.147
www.google.com.     174 IN  A   74.125.239.146
www.google.com.     174 IN  A   74.125.239.144
www.google.com.     174 IN  A   74.125.239.145

;; AUTHORITY SECTION:
google.com.     34512   IN  NS  ns2.google.com.
google.com.     34512   IN  NS  ns1.google.com.
google.com.     34512   IN  NS  ns3.google.com.
google.com.     34512   IN  NS  ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     212097  IN  A   216.239.34.10
ns3.google.com.     207312  IN  A   216.239.36.10
ns4.google.com.     212097  IN  A   216.239.38.10
ns1.google.com.     212096  IN  A   216.239.32.10

;; Query time: 8 msec
;; SERVER: 209.81.9.1#53(209.81.9.1)
;; WHEN: Fri Jul 26 14:44:25 2013
;; MSG SIZE  rcvd: 248


real    0m5.015s
user    0m0.004s
sys 0m0.002s

Outras vezes, as consultas respondem instantaneamente, como em menos de 20 ms. Fiz um rastreamento de pacotes e descobri algo interessante. O servidor DNS está respondendo, mas o cliente ignora a resposta inicial e envia uma segunda consulta idêntica à qual é respondida imediatamente.

Veja rastreamento de pacotes . Observe as portas de origem idênticas às consultas (62076).

Pergunta: o que está causando a falha da primeira consulta DNS?

ATUALIZAR

Recursos:

Rastreamento de pacote:

http://www.cloudshark.org/captures/8b1c32d9d015

Dtruss (strace para mac):

https://gist.github.com/dmourati/6115180

O firewall do Mountain Lion está atrasando aleatoriamente as solicitações de DNS do apple.stackexchange.com:

/apple/80678/mountain-lion-firewall-is-randomly-delaying-dns-requests

ATUALIZAÇÃO 2

System Software Overview:

  System Version:   OS X 10.8.4 (12E55)
  Kernel Version:   Darwin 12.4.0
  Boot Volume:  Macintosh HD
  Boot Mode:    Normal
  Computer Name:    mv-m-dmouratis
  User Name:    Demetri Mouratis (dmourati)
  Secure Virtual Memory:    Enabled
  Time since boot:  43 minutes

Hardware Overview:

  Model Name:   MacBook Pro
  Model Identifier: MacBookPro10,1
  Processor Name:   Intel Core i7
  Processor Speed:  2.7 GHz
  Number of Processors: 1
  Total Number of Cores:    4
  L2 Cache (per Core):  256 KB
  L3 Cache: 6 MB
  Memory:   16 GB

Firewall Settings:

  Mode: Limit incoming connections to specific services and applications
  Services:
  Apple Remote Desktop: Allow all connections
  Screen Sharing:   Allow all connections
  Applications:
  com.apple.java.VisualVM.launcher: Block all connections
  com.getdropbox.dropbox:   Allow all connections
  com.jetbrains.intellij.ce:    Allow all connections
  com.skype.skype:  Allow all connections
  com.yourcompany.Bitcoin-Qt:   Allow all connections
  org.m0k.transmission: Allow all connections
  org.python.python:    Allow all connections
  Firewall Logging: Yes
  Stealth Mode: No

— dmourati
fonte

dtrussa saída parece truncada. Nunca vemos as chamadas do sistema que gravam a saída do programa em STDOUT.

— Andrew B

Você já tentou outro servidor de nome público, por exemplo, DNS do Google.

— vasco.debian

@ vasco.debian sim, mesmo comportamento.

— dmourati 31/07/2013

A única diferença que vejo entre esses dois pares de solicitação-resposta é o atraso entre solicitação e resposta. Também não vejo problemas na rede. Experimente e verifique se o atraso é importante - o SO pode soltar alguns pacotes udp no aplicativo por algum motivo, apesar de ser mostrado no analisador. Definitivamente, não é um problema com a rede ou a configuração geral, "dig" deve funcionar. Talvez algo esteja errado com o ajuste da pilha de rede. Verifique as configurações sysctl da rede. Como este rolande.wordpress.com/2010/12/30/…

— GioMac 1/13

Você não diz se você tem um firewall rodando no mac?

— JustinP

Parece ser um bug no firewall do Lion. Está ativado no seu sistema?

Neste segmento MacRumors ( problemas de DNS após a atualização para o Mountain Lion (10.8) ), uma possível solução alternativa é discutida:

Tente reduzir o tamanho da MTU.

Preferências do sistema> Rede> WiFi> Avançado> Hardware> Manualmente> MTU: Custom> 1300

Trabalhou para mim.

Você poderia verificar se a redução do tamanho da MTU atenua seu problema?

— Mels
fonte

Alterar as configurações do firewall fez com que o problema desaparecesse. O MTU não teve efeito. O firewall precisa estar desativado ou "Bloquear todas as conexões de entrada".

— Dmourati 1/08/13

Alterar o firewall para uma das configurações diminuiu a frequência do problema, mas não o eliminou completamente. Capaz de reproduzir 1/200 vezes mais ou menos.

— Dmourati

Eu consideraria uma perda de pacotes dessa magnitude bastante razoável ao atravessar a Internet, especialmente se houver saltos congestionados na rota. Lembre-se, o DNS usa UDP, o que não garante a entrega de datagramas. Que é exatamente por isso que o próprio protocolo DNS tem novas tentativas e um mecanismo de tempo limite embutido.

— Mels

By the way, eu sei que não é suposto post "obrigado" comentários aqui, mas você só aumentou a minha reputação seis vezes :)

— Mels

Recentemente, tive um problema semelhante e descobri que o firewall do Cisco ASA não estava configurado para oferecer suporte ao EDNS0, a especificação que permite pacotes UDP DNS maiores que 512 bytes. Depois que meu administrador do fw permitiu até 4096 bytes, o problema foi resolvido. Ótimas informações aqui:

http://www.petenetlive.com/KB/Article/0000312.htm

— Roubar
fonte

Eu não acho que isso se aplica aqui. A resposta está bem abaixo de 512 bytes para essa consulta DNS específica, mesmo com a autoridade e seções adicionais.

— Andrew B