Délai de 10 secondes pour le TLD .local dans Mac OS X Lion

Notre réseau d'entreprise utilise xxx.companyname.localpour tous les serveurs de notre réseau local. Chaque fois que j'accède à l'un de ces serveurs sur mon Mac, j'ai un délai de 10 secondes. J'ai découvert que ce retard est dû à des recherches DNS, car apparemment Lion résout les domaines .local dans l'ordre suivant:

vérifier l' /etc/hostsadresse IPv6
vérifier le serveur DNS pour un enregistrement AAAA (adresse IPv6)
vérifier via MDNS (Bonjour) pour un enregistrement AAAA
vérifier /etc/hostsune adresse IPv4
vérifier le serveur DNS pour un enregistrement A (adresse IPv4)
vérifier MDNS pour un enregistrement A

Maintenant, le problème est que nous n'avons pas de réseau IPv6. Tous les xxx.companyname.localserveurs de notre réseau n'ont que des adresses IPv4 et le serveur DNS n'a que des enregistrements A. Cela signifie que l'adresse est résolue à l'étape 5. Le problème avec cela est que l'étape 3 prend dix secondes avant son expiration! Chaque fois que je me connecte à notre wiki, serveur SVN, serveur Kerberos, etc., il y a un délai de 10 secondes.

J'ai réussi à tromper Lion en ajoutant des lignes comme celle-ci à /etc/hosts

::FFFF:10.99.99.99 xxx.companyname.local

Si je fais cela, Lion pense qu'il existe une adresse IPv6 pour le domaine et s'arrête après l'étape 1. Cependant, cette solution de contournement contourne totalement toutes les fonctionnalités utiles du DNS. Je ne veux pas suivre manuellement les adresses IP de dizaines de domaines internes! Je pourrais aussi bien arrêter d'utiliser des noms d'hôtes et taper simplement des adresses IP!

Donc: Quelqu'un a-t-il une idée de comment modifier cet ordre de recherche? Ou désactiver la recherche IPv6 car nous n'avons pas de réseau IPv6 de toute façon?

dns osx-lion bonjour

— Jakob Egger
source

Merci pour la question - Je l'ai mise en signet comme référence de résolution DNS Mac;)

— Alex

Vous seriez bien mieux servi d'essayer de déterminer pourquoi vos serveurs DNS prennent 10 secondes pour envoyer une réponse de jeu d'enregistrements vide pour les AAAAenregistrements lorsqu'ils (selon ce que vous dites) ne prennent pas autant de temps pour répondre aux Arequêtes pour le tout mêmes noms de domaine. Vous semblez être en territoire RFC 4074 classique, où le problème est que les serveurs sont cassés . Notez également que vous avez rencontré l'une des nombreuses raisons bien connues et longuement discutées de ne pas utiliser local.le service DNS à horizon partagé. C'est mieux de réparer aussi.

— JdeBP

Les serveurs DNS de l'étape deux renvoient instantanément un enregistrement AAAA vide. Le problème est l'étape 3 - la requête MDNS / Bonjour / Zeroconf. Lion attend 10 secondes après la diffusion avant de se terminer. Après avoir googlé un peu, je suis bien conscient que l'utilisation local.est une mauvaise idée, mais le service informatique m'a dit qu'il pensait que l'utilisation local.companyname.était parfaitement bien et que je ne pouvais vraiment rien y faire.

— Jakob Egger

Les employés de votre service informatique sont largement sous-informés. On sait que cela n'est pas «parfaitement bien» dans les cercles d'administration de réseau depuis environ une demi-décennie. Vous pourriez… encourager… les connaissances en réseautage des gens de votre service informatique à entrer dans le 21e siècle. Vous pourriez… leur rappeler… que leur travail n'est pas d'organiser des choses telles que les ordinateurs de l'entreprise ne fonctionnent pas correctement. ☺

— JdeBP

@JdeBP Et pourtant, Apple a décidé que ce serait une bonne idée de l'utiliser ... Vous remarquerez que Microsoft l'utilise également et le recommande comme meilleure pratique. Alors ... Qui a dit que non ?

— Basic

Réponses:

Empêchez votre service informatique d'abuser `local.`.

Comme nous l'avons vu, abuser d'un nom de domaine que votre entreprise ne possède pas et ne doit donc pas supposer qu'il peut créer des sous-domaines d'entreprise est incorrect et constitue la moitié du problème ici. Si les ordinateurs de l'entreprise incluent Macintoshes (ou toute autre chose qui utilise DNSSD d'ailleurs), alors ne présumez certainement pas que local.c'est à vous de jouer librement avec de cette manière.

Mettez à niveau votre Macintosh.

MacOS 10.4 traiterait en effet xxx.companyname.local.comme vous le décrivez. Mais cela a changé dans les révisions ultérieures du système d'exploitation. MacOS 10.5 ne transmet que des noms à deux étiquettes au DNS multidiffusion. Les noms à trois étiquettes tels que xxx.companyname.local.ne sont pas gérés par MDNS. MacOS 10.6 va plus loin et essaie de détecter si le serveur DNS a été mal configuré pour avoir une local. zone et agir en conséquence.

Au minimum , vous devez configurer votre Macintosh pour avoir un /etc/resolver/companyname.local fichier search_order 1dans ce que les listes de l'adresse IP actuelle (s) de votre serveur DNS proxy (s). Cela ne fonctionnera pas bien avec les adresses IP de serveurs DNS attribuées par DHCP qui changent, cependant, comme le dit Apple.

Sur la main agrippante…

… Ce sont simplement des bodges de plus en plus complexes pour s'adapter à la mauvaise tête. Pour citer Marc Krochmal d'Apple, "il y aura toujours un problème" lorsque les gens abusent local.de la manière dont votre entreprise le fait. Il est connu pour être mal dirigé depuis (une recherche rapide me dit) 2002, sinon avant. Ne le fais pas .

Lectures complémentaires

dlove (2002-12-02). Le domaine .local et les problèmes DNS . macworld.
Apple Corporation (2010). Mac OS X v10.4, 10.5, 10.6: comment rechercher des noms d'hôtes ".local" via Bonjour et DNS standard .
Stephen Hoffman (2010). Conseils DNS: mélange de DNS unicast et multicast avec .local . HoffmanLabs.
Apple Corporation (2008). Mac OS X 10.3: comment rechercher des noms d'hôtes ".local" via Bonjour et DNS standard .

— JdeBP
source

Aucune de ces informations ne résout mes problèmes de résolution DNS dans Lion (Mac OS X 10.7). En outre, /etc/resolver/companyname.localsemble être ignoré dans Lion.

— Jakob Egger

Je ne connais pas mac donc je ne peux pas vraiment aider, mais je suis venu avec une idée de contournement intelligent: si vous configurez quelque part sur Internet, "somedomain.com DNAME companyname.local"- il va attraper DNAME à l'étape 2. Maintenant, je ne sais pas ce qui va se passer Ensuite, cela retombera-t-il encore bonjour, ou puisqu'il est déjà au milieu d'un processus DNS, peut-être qu'il restera avec DNS.

— Alex
source

Je peux me porter volontaire pour créer le DNAME pour vous si vous le souhaitez :)