La recherche DNS sur Mac OS X semble être foirée - mais uniquement au travail

Les recherches DNS sur Mac OS X prennent une éternité dans Safari et dans d'autres applications qui utilisent mDNSResponder. Les mêmes recherches fonctionnent bien si j'utilise nslookup à partir de la ligne de commande, et elles fonctionnent également très bien à partir de mon iPhone et iPad sur le même réseau sans fil.

Et ce n'est que sur le réseau au travail; lorsque je suis à la maison ou connecté à mon iPhone, toutes les recherches DNS fonctionnent correctement. Lorsque je suis sur le réseau au travail, via Wi-Fi ou Ethernet, j'ai ces problèmes. J'ai essayé d'utiliser les commandes suivantes:

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

Cela fournissait un soulagement temporaire (minutes) sous Snow Leopard, mais maintenant, sous Lion, il ne fournit généralement rien du tout.

Ni mes paramètres Ethernet ni Wi-Fi ne spécifient de serveurs DNS; ils sont remplis automatiquement depuis le routeur. Mais j'ai essayé de spécifier le mien, comme Google DNS ou OpenDNS, et cela ne résout pas le problème.

La configuration du réseau est un routeur branché sur le modem câble, tous les ports Ethernet du bureau s'en détachant. Un routeur wifi Airport Extreme est également branché sur le routeur principal (en mode pont), et les clients WiFi s'y connectent.

J'ai cherché partout et j'ai trouvé d'autres choses qui semblent applicables au premier abord (par exemple, la recherche DNS échoue mais nslookup fonctionne ), ce qui me fait penser que ces problèmes de mDNSResponder ne sont pas trop rares, mais aucun d'entre eux ne correspond exactement et leurs solutions ne l'ont pas travaillé pour moi encore.

Aussi: ce n'est pas toutes les recherches DNS, juste la plupart. Les recherches Google apparaissent instantanément, mais Google Maps prend une éternité à charger (lorsque je regarde la fenêtre d'activité, il s'agit généralement de scripts et d'autres informations provenant d'un serveur Google CDN). Même les sites que nous utilisons tous les jours et dont vous pensez qu'ils seraient mis en cache quelque part (comme php.net) prennent une éternité à se charger ou à expirer.

En outre: tout se charge correctement à partir d'un navigateur dans une machine virtuelle Windows XP, ce qui me fait encore plus reprocher à mDNSResponder d'être le coupable - mais tout fonctionne bien lorsque je suis sur un autre réseau.

La raison pour laquelle le DNS est lent au bureau mais pas à la maison peut être que le routeur de bureau utilise IPv6 mais que votre routeur domestique utilise IPv4, et que Lion utilise mieux IPv6 que Snow Leopard. Les sites Web qui ne sont pas affectés par ce ralentissement sont alors probablement ceux qui prennent mieux en charge IPv6.

Consultez cet article pour les mesures qui montrent qu'IPv6 est 2 à 3 fois plus lent que IPv4 sur DNS:
IPv6 vous ralentira (DNS)

Si tel est le cas, la désactivation d'IPv6 sur le routeur de bureau (et ainsi de suite sur l'ensemble du réseau de bureau) pourrait résoudre le problème.

Cet article peut également être utile: Comment désactiver IPv6 sur Mac OS X 10.7 Lion .

J'ai eu le même problème avec mon MacBook Pro fonctionnant sous 10.6. J'arrête rarement ma machine. En gros, à la maison, je ferme le couvercle, je le mets dans mon sac et je l'emmène au travail. Au travail, j'ouvre le couvercle et je pars. Ce que j'ai remarqué, c'est que OS X ne semble pas effectuer cette transition de manière aussi transparente que je le souhaiterais. J'obtiendrais un DNS lent, de grandes quantités de ressources réseau en attente, etc. Si je ne le fais pas, mon attente est de:

dscacheutil -flushcache

Dans les deux cas, cela fonctionne assez bien pour moi. En de rares occasions, je redémarre la machine.

Les autres Mac fonctionnent-ils correctement sur le réseau du bureau?

Assurez-vous que les paramètres réseau attribués sont cohérents. J'ai vu la situation où un serveur DHCP assignait une passerelle par défaut qui n'était pas sur le sous-réseau du client. Windows est allé de l'avant et a utilisé cela, et a bien fonctionné, mais MacOS (correctement!) A refusé d'envoyer à une adresse IP qui n'était pas sur le sous-réseau.

Lorsque le masque de sous-réseau est appliqué à la fois à l'adresse IP du client et à la passerelle par défaut, les résultats doivent être égaux. Sinon, c'est une mauvaise configuration de serveur DHCP.

Cependant, cela ne ressemble pas à cette situation exacte. Votre Mac est-il configuré pour utiliser à la fois le WiFi et Ethernet au travail? Si c'est le cas, essayez de désactiver un à la fois.