Le DNS ne se résout pas sur Mac OS X

En fait, je pense que vous devriez utiliser

scutil --dns

scutil -r hostname

Ces commandes utilisent le magasin dynamique de configd, par opposition aux fichiers plats de /etc, qui ne sont souvent lus qu'en mode mono-utilisateur et pour les systèmes non connectés au réseau.

man scutil   # or

scutil --help

J'ai rencontré le même problème Et bien que le redémarrage de mDNSResponder semble "fonctionner", le redémarrer plusieurs fois par heure est plutôt pénible.

Donc, pour l'instant, j'ai "résolu" le problème en exécutant dnsmasq localement. Pour ce faire :

• Construisez dnsmasq (téléchargez les fichiers tgz et make ou brew install dnsmasq )

• Mettez cela dans un dnsmasq.conf archivo:

  resolv-file=resolv.conf
  user=nobody
  group=nobody
  interface=lo0
  cache-size=1024

• Mettez ça dans un resolv.conf qui se trouve dans le même répertoire que le fichier dnsmasq.conf fichier (nb : no /etc/resolv.conf ) :

  nameserver 8.8.8.8
  nameserver 4.2.2.1
  nameserver 4.2.2.2

• Exécuter dnsmasq avec sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf . La sortie devrait ressembler à quelque chose comme :

  ...
  dnsmasq: reading resolv.conf
  dnsmasq: using nameserver 4.2.2.1#53
  dnsmasq: using nameserver 4.2.2.2#53
  dnsmasq: using nameserver 8.8.8.8#53
  dnsmasq: read /etc/hosts - 6 addresses

• Ouvrez les préférences réseau et assurez-vous que 127.0.0.1 est le seul serveur DNS (préférences réseau -> avancé -> DNS -> ajouter 127.0.0.1)

Les choses devraient recommencer à fonctionner correctement.

Une fois que les choses fonctionnent, vous pouvez lancer dnsmasq sans le --no-daemon y --log-queries afin qu'il démarre en arrière-plan et que vous n'ayez pas besoin de garder une fenêtre de terminal ouverte.

La résolution de noms sous OSX (et UNIX en général) est prise à partir des adresses IP des DNS dans le fichier situé dans /etc/resolv.conf (qu'OS X génère automatiquement pour autant que je m'en souvienne).

Puisque vous avez essayé pratiquement tout ce qui me vient à l'esprit, j'aimerais vous demander :

• Pouvez-vous faire un ping sur le DNS que vous voulez utiliser ?
• Quelle(s) est/sont l'adresse(s) IP du/des DNS que vous voulez utiliser ?
• Avez-vous essayé d'utiliser 8.8.8.8 (google) ou l'un des OpenDNS 208.67.222.222 ou 208.67.220.220 ?
• Pouvez-vous faire un ping sur ces hôtes ?

Enfin, un test généralement agréable consiste à créer un utilisateur vierge et à voir si ce nouvel utilisateur présente le même problème. Si ce n'est pas le cas, vous pouvez alors commencer à chercher ce que votre utilisateur actuel possède qui pourrait être à l'origine du problème ; si cela échoue également, vous savez alors qu'il s'agit de quelque chose de plus "système".

Jetez également un coup d'œil à la Console pour voir si vous pouvez repérer quelque chose qui pourrait être lié (et que vous aimeriez coller ici).

Enfin, votre Mac est équipé de deux commandes DNS importantes, nslookup y dig .

Donc pour résoudre www.apple.com en utilisant le serveur de google, vous devez taper :

nslookup "hôte à résoudre" "serveur DNS à utiliser". Par exemple :

$ nslookup www.apple.com 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
www.apple.com   canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net    canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net   canonical name = e3191.c.akamaiedge.net.
Name:   e3191.c.akamaiedge.net
Address: 184.24.141.15

NSLookup est une ancienne commande (qui était censée être dépréciée il y a quelques années et remplacée par DIG, mais sa syntaxe facile à utiliser était trop belle pour être supprimée, je suppose), son "remplaçant" est dig , une commande beaucoup plus puissante, dont la syntaxe est plus folle.

Pour effectuer la même requête, vous devez taper :

dig @8.8.8.8 www.apple.com

Et voici le résultat :

$ dig @8.8.8.8 www.apple.com

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17356
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

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

;; ANSWER SECTION:
www.apple.com.      1782    IN  CNAME   www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 42 IN CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 21581 IN CNAME   e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 2   IN  A   184.24.141.15

;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct  3 21:21:49 2011
;; MSG SIZE  rcvd: 158

Comme vous pouvez le constater, dig est beaucoup plus "verbeux" (ce qui est utile pour déboguer ce qui se passe). La puissance de dig vient du fait que vous pouvez spécifier le type de requête que vous voulez effectuer (entre autres choses).

Dans tous les cas, faites-nous connaître les résultats exacts de ces commandes.

J'ai eu exactement les mêmes symptômes (et j'ai passé un certain temps à résoudre le problème), mais j'ai pu le résoudre lorsque j'ai réalisé que j'avais modifié les paramètres suivants /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist et ce que j'ai fait a été en quelque sorte interprété comme étant malformé. J'ai restauré à partir d'une sauvegarde et la machine a pu à nouveau résoudre les noms d'hôtes.

Avant d'en arriver à la solution, je me suis également rendu compte que je pouvais naviguer sur Internet si j'utilisais un proxy SOCKS5 par l'intermédiaire de ssh -D et j'ai essayé les recherches de DNS à travers le tunnel.