25 votes

Résolution DNS Échec pour ping et curl, mais pas pour dig

J'utilise DNSMasq comme un serveur DNS local, donc je peux résoudre *.local.pcfdev.io (comme discuté ici Utilisation de PCF Dev Offline avec Mac OS X ). Tout a fonctionné lors de la première mise en place.

Quelques jours plus tard, après quelques redémarrages de mon MacBook, je ne parviens plus à résoudre les problèmes suivants, alors que je suis hors ligne api.local.pcfdev.io en utilisant curl o ping . Cependant, dig fait ce qu'il faut.

$ dig api.local.pcfdev.io

; <<>> DiG 9.8.3-P1 <<>> api.local.pcfdev.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46877
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;api.local.pcfdev.io.       IN      A

;; ANSWER SECTION:
api.local.pcfdev.io.    0       IN      A       192.168.11.11

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep  6 10:17:44 2016
;; MSG SIZE  rcvd: 53

$ curl api.local.pcfdev.io
curl: (6) Could not resolve host: api.local.pcfdev.io

J'ai essayé d'ajouter -AlwaysAppendSearchDomains en tant qu'argument pour /usr/sbin/mDNSResponder en /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist et redémarré le mDNSResponder avec launchctl mais en vain.


MISE À JOUR 1

Il y a certainement quelque chose qui écoute sur la bonne IP locale :

$ nslookup api.local.pcfdev.io
Server:     127.0.0.1
Address:        127.0.0.1#53

Name:   api.local.pcfdev.io
Address: 192.168.11.11

$ ping api.local.pcfdev.io
ping: cannot resolve api.local.pcfdev.io: Unknown host

$ telnet 192.168.11.11 80
Trying 192.168.11.11...
Connected to 192.168.11.11.
Escape character is '^]'.

HTTP/1.1 400 Bad Request

Connection closed by foreign host.

MISE À JOUR 2

Après avoir essayé la suggestion ci-dessous de supprimer tous les serveurs DNS dans les Préférences réseau, à l'exception des serveurs DNS de l'entreprise. 127.0.0.1 mais je ne peux rien résoudre. J'ai réussi à obtenir un journal de débogage à partir de mDNSResponder :

mDNSResponder[91]:  74: DNSServiceCreateConnection START PID[32612](ping)
mDNSResponder[91]:  74: Error socket 75 created 00000000 00000001
mDNSResponder[91]:  74: DNSServiceQueryRecord(15000, 0, api.local.pcfdev.io., Addr) START PID[32612]()
mDNSResponder[91]:  74: Error socket 75 closed  00000000 00000001 (0)
mDNSResponder[91]:  74: DNSServiceQueryRecord(api.local.pcfdev.io., Addr) ADD    0 api.local.pcfdev.io. Addr
mDNSResponder[91]:  74: Cancel 00000000 00000001
mDNSResponder[91]:  74: DNSServiceQueryRecord(api.local.pcfdev.io., Addr) STOP PID[32612]()
mDNSResponder[91]:  74: DNSServiceCreateConnection STOP PID[32612](ping)

J'ai également observé cela comme expliqué dans la réponse proposée, nslookup y dig ne provoquent pas d'enregistrement par mDNSResponder mais d'autres outils ( ping , curl ) font.

Il semble donc que pour une raison quelconque, soit dnsmasq ne fonctionne pas (je peux établir une connexion TCP vers 127.0.0.1:53 ) ou mDNSResponder ne l'utilise pas.


MISE À JOUR 3

etc/resolve.conf cesse d'exister lorsque mon adaptateur wifi est actif, mais que je ne suis pas connecté à un réseau. Cela pourrait-il être la raison pour laquelle les outils CLI n'utilisent pas l'adresse locale de l'utilisateur ? dnsmasq serveur ?

27voto

cmcginty Points 487

J'ai eu le même problème. Je pense que le cache DNS local avait de mauvaises données suite à mes tests précédents. Il a été rapidement corrigé par :

sudo killall -HUP mDNSResponder

8voto

klanomath Points 63400

creuser d'une part, et curl/ping d'autre part, récupèrent les données de différents hôtes :

creuser interroge un serveur DNS - dans votre cas votre localhost (127.0.0.1) - pour une entrée de base de données : l'adresse IP liée au FQDN api.local.pcfdev.io. L'hôte lui-même n'a pas besoin de fonctionner ou même d'exister.

curl/ping essayer de résoudre une adresse IP avec mDNSResponder ou par d'autres moyens et enfin opérer sur/interagir avec l'hôte distant. Si l'hôte 192.168.11.11 ne fonctionne pas ou n'existe pas du tout, les deux tentatives échoueront.

Maintenant, soit l'entrée DNS est erronée (api.local.pcfdev.io a une autre IP que 192.168.11.11), soit l'entrée DNS est correcte mais l'hôte 192.168.11.11 ne fonctionne pas.


Ajout de -AlwaysAppendSearchDomains en tant qu'argument de /usr/sbin/mDNSResponder en /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist n'est pas recommandé. Vous devriez plutôt l'ajouter à /Library/Preferences/com.apple.mDNSResponder.plist (source : man mDNSResponder ) :

Pour que mDNSResponder s'exécute avec ces arguments facultatifs lors de son lancement sous OS X 10.11 (El Capitan) et versions ultérieures, définissez les clés booléennes AlwaysAppendSearchDomains ou NoMulticastAdvertisements sur true dans /Library/Preferences/com.apple.mDNSResponder.plist et redémarrez.

Dans votre cas, il n'est pas du tout nécessaire de définir cette clé, car elle n'est pas à l'origine de votre problème.


Après avoir creusé dans VirtualBox, PCF Dev (échouant à plusieurs reprises avec des "mauvaises informations d'identification" en essayant de se connecter à la VM) et dnsmasq, je recommande de dévoluer les requêtes DNS à dnsmasq uniquement :

  • Dans Préférences système > Réseau > Interface > Serveur DNS, supprimez tous les serveurs DNS sauf 127.0.0.1 et appliquez les modifications. Vous pouvez également configurer un deuxième Localisation avec une configuration 127.0.0.1 seulement et garder votre serveur DNS actuel dans l'autre configuration.

  • ajouter un fichier /usr/local/etc/resolv.dnsmasq.conf avec le contenu suivant

    #use your preferred DNS servers here. In the example I use some Google name servers
    nameserver 8.8.8.8
    nameserver 8.8.4.4
  • ajouter resolv-file=/usr/local/etc/resolv.dnsmasq.conf à la ligne ~46 de /usr/local/etc/dnsmasq.conf

  • ajouter ou déplacer address=/.local.pcfdev.io/192.168.11.11 à la ligne ~80 de /usr/local/etc/dnsmasq.conf

  • redémarrer dnsmasq avec :

    sudo launchctl stop homebrew.mxcl.dnsmasq
    sudo launchctl start homebrew.mxcl.dnsmasq

1voto

Joel Griffiths Points 11

Il m'a fallu beaucoup plus de temps que prévu pour résoudre ce problème. Après avoir redémarré mDNSResolver des dizaines de fois comme recommandé dans d'autres fils de discussion :

sudo killall -HUP mDNSResponder

J'ai finalement essayé autre chose. J'ai désactivé le Wi-Fi et supprimé tous mes réseaux préférés. J'ai ensuite rétabli la connexion Wi-Fi et tout s'est bien passé :

  1. Menu Apple -> Préférences Système -> Wi-Fi (à gauche)
  2. Désactiver le Wi-Fi", puis sélectionnez "Avancé".
  3. Supprimez la connexion Wi-Fi qui vous pose problème (ou toutes les connexions). si vous le souhaitez). Pour ce faire, sélectionnez le réseau Wi-Fi que vous souhaitez supprimer et appuyez sur "-".
  4. Cliquez sur "Appliquer" et "OK".
  5. Réactivez le Wi-Fi.
  6. Sélectionnez votre réseau Wi-Fi et connectez-vous à nouveau.

YMMV, mais c'est ce qui a finalement fonctionné pour moi. Ça aurait probablement dû être la première chose que j'ai essayée.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X