10 votes

La recherche DNS échoue mais nslookup fonctionne

J'ai des problèmes de recherche DNS sur mon réseau interne. J'utilise un serveur DNS interne avec l'IP 192.168.1.254.

Si j'utilise nslookup, tout fonctionne comme il se doit :

> hawk:~ utilisateur$ nslookup publicwebserver.domain.local
> Serveur :       192.168.1.254
>
> Adresse :   192.168.1.254#53
>
> Nom :  publicwebserver.domain.local
>
> Adresse : 192.168.1.21

Mon problème est que aucun autre programme ne semble être capable de résoudre le nom DNS :

hawk:~ utilisateur$ ping publicwebserver.domain.local

ping: impossible de résoudre publicwebserver.domain.local : Hôte inconnu

C'est pareil pour tous les programmes en ligne de commande et par exemple Firefox. Si j'ouvre Utilitaire Réseau, j'ai le même problème dans l'onglet Recherche (probablement parce qu'il utilise nslookup ou host en arrière-plan).

Avez-vous déjà rencontré ce problème auparavant ?

6voto

jodyfanning Points 153

En fait, cela est probablement dû à l'utilisation d'un domaine .local. Cela entre en conflit avec la résolution mDNS (réseau de configuration zéro) qui utilise par défaut .local.

Certaines versions d'OS X peuvent prendre en charge les deux méthodes de résolution des noms, mDNS et DNS normal, mais au moins Yosemite ne semble plus le supporter.

Ce document d'assistance d'Apple un peu plus ancien explique le contexte. Pour Yosemite, ce qui fonctionne toujours est d'ajouter "domain.local" à la liste de recherche DNS dans les paramètres réseau.

La véritable solution est de ne pas utiliser le domaine .local pour les hôtes résolus par DNS.

1 votes

Cela a résolu le problème pour moi (en n'utilisant pas .local dans mes paramètres de zone dns). J'utilise OSX Yosemite.

0 votes

Oui, cela a également fonctionné pour moi. J'ai basculé de .local à .vpn et voilà, cela fonctionne ! Je dois également mentionner que nslookup fonctionnait avant le basculement de .local (et fonctionne toujours !), seule la commande ping ne fonctionnait pas (maintenant si).

0 votes

Le lien de support Apple est désormais mort. Y a-t-il de nouveaux liens sur la façon de faire ce changement?

6voto

jonhobbs Points 2702

Pour certains, vérifiez le répertoire /etc/resolver/ et supprimez tout fichier présent.

0 votes

J'avais une installation de dnsmasq restante (pour résoudre *.localhost en 127.0.0.1) que j'ai enlevée en faveur de la configurer au niveau de mon routeur (en utilisant dd-wrt, via les options dnsmasq sous Services). La seule chose que je n'avais pas enlevée était le /etc/resolver/ dossier que j'avais créé lors de l'installation locale de dnsmasq. Ainsi, cette solution a fonctionné pour moi.

0 votes

Omg MERCI. Un installateur indépendant a pris sur lui de résoudre les domaines .dev vers localhost.

3voto

Kevin Cho Points 57

Il semble que cela soit dû au fait que je pointe à la fois vers des serveurs DNS internes et externes sur mon client, comme mentionné ici. Après avoir supprimé tous les serveurs DNS externes de ma liste de serveurs, tout fonctionne comme il se doit.

0 votes

Est-ce un lien vers un forum Windows Vista ???

3voto

Flavio Lacerda Points 11

Parfois, mDNSResolver s'arrête lors de la connexion avec VPN.

Il suffit de redémarrer mDNSResolver:

sudo killall -HUP mDNSResponder

0 votes

Cela a fonctionné pour moi après avoir changé mon serveur DNS sur mon réseau local.

0 votes

En utilisant un MacBook, cela a également fonctionné pour moi. Après avoir modifié quelques entrées sur le DNS, ssh ne les résolvait pas. Cette astuce rafraîchit un peu le cache !

1voto

Dan Points 498

J'ai le même problème sur OS X Yosemite beta, et passer à 8.8.8.8 de Google a résolu le problème pour moi.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X