A pesquisa de DNS do Mac OS X parece estar desarrumada - mas apenas no trabalho

Question

As pesquisas de DNS do Mac OS X levam uma eternidade do Safari e de outros aplicativos que usam o mDNSResponder. As mesmas pesquisas funcionam bem se eu usar o nslookup a partir da linha de comando, e elas também funcionam bem no meu iPhone e iPad na mesma rede sem fio.

E isso é apenas na rede no trabalho; quando estou em casa ou ligado ao meu iPhone, todas as pesquisas de DNS funcionam bem. Quando estou na rede no trabalho, seja via Wi-Fi ou Ethernet, tenho esses problemas. Eu tentei usar os seguintes comandos:

launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
launchctl load /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Isso costumava fornecer algum alívio temporário (minutos) sob o Snow Leopard, mas agora, sob o Lion, geralmente não fornece nada.

Nem minhas configurações de Ethernet nem de Wi-Fi especificam servidores DNS; eles são preenchidos automaticamente pelo roteador. Mas eu tentei especificar o meu próprio, como o DNS do Google ou o OpenDNS, e isso não resolve o problema.

A configuração da rede é um roteador conectado ao modem a cabo, com todas as portas Ethernet do escritório saindo dele. Um roteador wifi Airport Extreme também está conectado ao roteador principal (no modo bridge) e os clientes WiFi se conectam a ele.

Eu pesquisei tudo e encontrei outras coisas que parecem aplicáveis no início (por exemplo, A pesquisa de DNS falha mas o nslookup funciona , fazendo-me pensar que esses problemas mDNSResponder não são muito incomuns, mas nenhum deles combina exatamente e suas soluções ainda não funcionaram para mim.

Além disso, não é toda a pesquisa de DNS, apenas a maioria. As pesquisas do Google surgem instantaneamente, mas o Google Maps leva uma eternidade para carregar (quando olho para a janela de atividades, geralmente são scripts e outros que vêm de algum servidor do Google CDN). Mesmo os sites que usamos todos os dias, e você acha que seriam armazenados em cache em algum lugar (como php.net) levam uma eternidade para carregar, ou o tempo limite.

Além disso: tudo funciona bem em um navegador dentro de uma máquina virtual Windows XP, o que para mim aponta ainda mais acusador para mDNSResponder como o culpado - mas tudo funciona bem quando eu sou qualquer outra rede.

    

Answer 1

A razão para o DNS ser lento no escritório, mas não em casa, pode ser que o roteador do escritório use IPv6, mas o roteador doméstico usa IPv4 e que o Lion é melhor usando o IPv6 do que o Snow Leopard. Os sites que não são afetados por essa desaceleração provavelmente são os que têm melhor suporte para o IPv6.

Veja este artigo para medidas que mostram que o IPv6 é 2 a 3 vezes mais lento que o IPv4 no DNS: O IPv6 irá atrasá-lo (DNS)

Se for esse o caso, desabilitar o IPv6 no roteador do escritório (e assim em toda a rede do escritório) pode resolver o problema.

Este artigo também pode ser útil: Como desabilitar o IPv6 no Mac OS X 10.7 Lion .

    

Answer 2

Eu costumava ter o mesmo problema com o meu MacBook Pro executando 10.6. Eu raramente desligo a minha máquina. Basicamente em casa eu apenas fecho a tampa e coloco na minha bolsa e levo para o trabalho. No trabalho eu abro a tampa e vou embora. O que eu notei é que o OS X não parece fazer essa transição tão perfeitamente quanto eu gostaria. Eu obteria DNS lento, grandes quantidades de recursos de rede em espera, etc. O que me corrige é desconectar manualmente de cada rede antes de fechar a máquina (ou seja, desligar o aeroporto antes de fechar a tampa). Se eu não fizer isso, meu modo de espera é:

dscacheutil -flushcache

De qualquer maneira, funciona muito bem para mim. Em uma ocasião rara, eu reinicio a máquina.

    

Answer 3

Os outros Macs funcionam corretamente na rede do escritório?

Certifique-se de que as configurações de rede que estão sendo atribuídas sejam autoconsistentes. Eu vi a situação em que um servidor DHCP estava atribuindo um gateway padrão que não estava na sub-rede do cliente. O Windows foi em frente e usou isso, e funcionou bem, mas o MacOS (corretamente!) Se recusou a enviar para um endereço IP que não estava na sub-rede.

Quando a máscara de sub-rede é aplicada ao endereço IP do cliente e ao gateway padrão, os resultados devem ser iguais. Caso contrário, é uma configuração ruim do servidor DHCP.

Isso não parece exatamente a mesma situação. O seu Mac está configurado para usar tanto o WiFi quanto a Ethernet no trabalho? Se assim for, tente desligar um de cada vez.