La résolution DNS échoue pour le ping et le curl, mais pas pour creuser

J'exécute DNSMasq en tant que serveur DNS local, donc je peux résoudre *.local.pcfdev.io(comme indiqué ici Utilisation de PCF Dev hors ligne avec Mac OS X ). Tout a fonctionné quand j'ai mis les choses en place.

Quelques jours plus tard, après quelques redémarrages de mon MacBook, hors ligne, je ne peux plus résoudre des problèmes comme l' api.local.pcfdev.ioutilisation de curlou ping. Cependant, digfait la bonne chose.

$ 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 -AlwaysAppendSearchDomainscomme argument à /usr/sbin/mDNSResponderin /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistet redémarré le mDNSResponder avec launchctl, mais en vain.

MISE À JOUR 1

Il y a certainement quelque chose à écouter 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 des préférences réseau sauf 127.0.0.1, je ne peux rien résoudre. J'ai réussi à me déconnecter du débogage 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, nslookupet digne cause rien à enregistrer mDNSResponder, mais d'autres outils ( ping, curl) le font.

Il semble donc que pour une raison quelconque, cela dnsmasqne fonctionne pas (je peux établir une connexion TCP 127.0.0.1:53) ou mDNSResponderne l'utilise pas.

MISE À JOUR 3

etc/resolve.confcesse d'exister lorsque mon adaptateur wifi est actif, mais je ne suis pas connecté à un réseau. Serait-ce la raison pour laquelle les outils CLI n'utilisent pas le dnsmasqserveur local ?

macos yosemite dns

— EngineerBetter_DJ
source

Votre adaptateur réseau est-il tombé par hasard? Si vous allez dans «Réseau» dans les Préférences Système, y a-t-il un point vert à côté de l'adaptateur dans lequel dnsmasq est configuré pour être utilisé?

— mangue

Eh bien, je suis dans un train sans Wi-Fi, donc sans doute.

— EngineerBetter_DJ

Plus précisément, l'adaptateur wifi est-il désactivé? Si c'est le cas, veuillez réessayer avec l'adaptateur wifi allumé (même s'il n'est peut-être pas réellement connecté à Internet). Pour que la configuration fonctionne, dnsmasq doit être un serveur DNS sur l'interface réseau utilisée .

— mangue

Merci d'avoir essayé de retrouver cela. Je suis également aux prises avec cela, je ne comprends pas pourquoi "curl foo: 8989" ne peut pas trouver d'hôte mais "dig foo" le peut. Oui, "curl 172.20.0.17:8989" fonctionne très bien. Comme vous, le DNS du réseau Wi-Fi est défini sur 127.0.0.1 (un dnsmasq exécuté dans un conteneur Docker). FWIW dans ma situation actuelle, le problème est spécifique au réseau wifi auquel je me connecte - fonctionne très bien sur mon hotspot personnel, le problème est sur un wifi de coffeeshop.

— jamshid

Je n'ai pas procédé à une ingénierie inverse des programmes en question, mais je m'attends à ce qu'ils appellent des bases de code de résolution DNS entièrement différentes et c'est pourquoi vous voyez des bris - certains pointent localement, d'autres non. Je creuserais probablement dans curlou wgetou les obtiendrais dans des instruments / profileur / débogueur et verrais ce qui se produit réellement pour causer l'erreur ne pourrait pas résoudre.

— bmike

Réponses:

Eu ce même problème. Je pense que le cache DNS local contenait de mauvaises données de mes tests précédents. Il a été rapidement corrigé par:

sudo killall -HUP mDNSResponder

— cmcginty
source

J'ai remarqué cela pinget digparfois renvoyer des adresses IP différentes (généralement avec un DNS à horizon divisé) et cette commande le corrige. Quelle est la cause profonde, je ne suis pas sûr, malheureusement.

— James

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

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

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

Maintenant, soit l'entrée DNS est incorrecte (api.local.pcfdev.io a une autre IP que 192.168.11.11) ou l'entrée DNS est correcte mais l'hôte 192.168.11.11 n'est pas en cours d'exécution.

Il n'est pas recommandé d' ajouter -AlwaysAppendSearchDomains comme argument à / usr / sbin / mDNSResponder dans /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist . Au lieu de cela, vous devez 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 sur 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 nécessaire de définir cette clé, car ce n'est pas la cause de votre problème.

Après avoir creusé dans VirtualBox, PCF Dev (échec répété avec des "informations d'identification erronées" essayant de se connecter à la machine virtuelle) et dnsmasq, je recommande de déléguer 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 emplacement avec une configuration 127.0.0.1 uniquement et conserver votre serveur DNS actuel dans l'autre configuration.

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

#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à / vers la ligne ~ 80 de /usr/local/etc/dnsmasq.conf

redémarrez dnsmasq avec:

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

— klanomath
source

Merci d'avoir pris le temps de répondre. Il y a certainement quelque chose à écouter 192.168.11.11; l'entrée DNS publique réelle pour *.local.pcfdev.iotoujours pointe vers la même adresse IP locale, donc dès que je me connecte à l'inforwebs curldoit recevoir une réponse de ce serveur DNS et est en mesure de déterminer quelle adresse IP utiliser.

— EngineerBetter_DJ

Il semble que curl, pinget les autres fichiers binaires que je veux utiliser, utilisent un moyen de rechercher les entrées DNS (qui n'utilise pas le dnsmasqserveur sur localhost) nslookupet digutilisent un autre moyen. Je suppose que je dois en savoir plus sur mDNSResponder!

— EngineerBetter_DJ

@EngineerBetter Avez-vous d'autres entrées dans Préférences Système> Réseau> Interface> DNS que 127.0.0.1? - Je vais installer toute la suite (VBox, PCF Dev etc.) et vérifier ça ... Une config spéciale?

— klanomath

Merci encore d'avoir pris le temps de m'aider. La question a été mise à jour, sans succès.

— EngineerBetter_DJ

Il m'a fallu beaucoup plus de temps pour résoudre ce problème qu'il n'aurait dû. Après avoir redémarré mDNSResolver des dizaines de fois comme recommandé sur d'autres threads:

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. Ensuite, j'ai rétabli la connexion Wi-Fi et tout a bien fonctionné:

Menu Apple -> Préférences Système -> Wi-Fi (à gauche)
'Désactiver le Wi-Fi' puis sélectionnez 'Avancé'
Supprimez la connexion Wi-Fi avec laquelle vous rencontrez des problèmes (ou toutes si vous le souhaitez). Pour ce faire, sélectionnez le réseau Wi-Fi que vous souhaitez supprimer et appuyez sur "-"
Cliquez sur «Appliquer» et «OK»
Rétablissez le Wi-Fi.
Sélectionnez votre réseau Wi-Fi et reconnectez-vous.

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

— Joel Griffiths
source