Estoy ejecutando DNSMasq como un servidor DNS local, por lo que puedo resolver *.local.pcfdev.io
(como se explica aquí Uso de PCF Dev sin conexión con Mac OS X ). Todo funcionó cuando configuré las cosas por primera vez.
Un par de días más tarde, después de algunos reinicios de mi MacBook, mientras estoy desconectado ya no puedo resolver cosas como api.local.pcfdev.io
usar curl
o ping
. Sin embargo, dig
hace lo correcto.
$ 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
Intenté agregar -AlwaysAppendSearchDomains
como argumento /usr/sbin/mDNSResponder
y /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
reinicié mDNSResponder con launchctl
, pero fue en vano.
ACTUALIZAR 1
Definitivamente hay algo escuchando en la IP local correcta:
$ 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.
ACTUALIZAR 2
Después de probar la sugerencia a continuación de eliminar todos los servidores DNS de las Preferencias de red excepto 127.0.0.1
, no puedo resolver nada. Me las arreglé para obtener algo de depuración al cerrar sesión 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)
También observé que, como se explica en la respuesta propuesta, nslookup
y dig
no causa que nada sea registrado por mDNSResponder
, pero otras herramientas ( ping
, curl
) sí lo hacen.
Entonces parece que, por alguna razón, dnsmasq
no funciona (puedo establecer una conexión TCP con 127.0.0.1:53
) o mDNSResponder
no lo está usando.
ACTUALIZAR 3
etc/resolve.conf
deja de existir cuando mi adaptador wifi está activo, pero no estoy conectado a una red. ¿Podría ser por eso que las herramientas CLI no usan el dnsmasq
servidor local?
Tenía este mismo problema. Creo que el caché de DNS local tenía datos incorrectos de mis pruebas anteriores. Se solucionó rápidamente por:
sudo killall -HUP mDNSResponder
ping
y, dig
a veces, devuelve diferentes direcciones IP (generalmente con DNS de horizonte dividido) y este comando lo soluciona. Desafortunadamente, no estoy seguro de cuál es la causa raíz.dig por un lado y curl/ping por el otro están recuperando datos de diferentes hosts:
dig consulta un servidor DNS, en su caso, su servidor local (127.0.0.1), para obtener una entrada de la base de datos: la dirección IP relacionada con el FQDN api.local.pcfdev.io. El host en sí no tiene que ejecutarse ni existir en absoluto.
curl/ping intente resolver una dirección IP con mDNSResponder o por otros medios y finalmente opere o interactúe con el host remoto. Si el host 192.168.11.11 no se ejecuta o no existe, ambos fallarán.
Ahora bien, la entrada de DNS es incorrecta (api.local.pcfdev.io tiene una IP diferente a 192.168.11.11) o la entrada de DNS es correcta pero el host 192.168.11.11 no se está ejecutando.
No se recomienda agregar -AlwaysAppendSearchDomains como argumento a /usr/sbin/mDNSResponder en /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist . En su lugar, debe agregarlo a /Library/Preferences/com.apple.mDNSResponder.plist (fuente:) man mDNSResponder
:
Para hacer que mDNSResponder se ejecute con estos argumentos opcionales cuando se inicia en OS X 10.11 (El Capitan) y versiones posteriores, establezca las claves booleanas AlwaysAppendSearchDomains o NoMulticastAdvertisements en verdadero en /Library/Preferences/com.apple.mDNSResponder.plist y reinicie.
En su caso, no es necesario en absoluto configurar esta clave, ya que no es la causa de su problema.
Después de profundizar en VirtualBox, PCF Dev (fallando repetidamente con algunas "credenciales incorrectas" al intentar iniciar sesión en la máquina virtual) y dnsmasq, recomiendo transferir las consultas de DNS solo a dnsmasq:
agregue un archivo /usr/local/etc/resolv.dnsmasq.conf con el contenido
#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
resolv-file=/usr/local/etc/resolv.dnsmasq.conf
en la línea ~46 de /usr/local/etc/dnsmasq.confaddress=/.local.pcfdev.io/192.168.11.11
en/a la línea ~80 de /usr/local/etc/dnsmasq.confreiniciar dnsmasq con:
sudo launchctl stop homebrew.mxcl.dnsmasq
sudo launchctl start homebrew.mxcl.dnsmasq
192.168.11.11
; la entrada DNS pública real para *.local.pcfdev.io
siempre apunta a la misma IP local, por lo que tan pronto como me conecte a inforwebs curl
, debe obtener una respuesta de ese servidor DNS y poder averiguar qué dirección IP usar.curl
, ping
y los otros binarios a los que quiero llegar están usando un medio para buscar entradas de DNS (que no usan el dnsmasq
servidor en localhost), nslookup
y dig
están usando otro medio. ¡Supongo que necesito aprender más sobre mDNSResponder!Me tomó mucho más tiempo resolver esto de lo que debería. Después de reiniciar mDNSResolver docenas de veces como se recomienda en otros hilos:
sudo killall -HUP mDNSResponder
Finalmente probé algo más. Desactivé Wi-Fi y eliminé todas mis redes preferidas. Luego restablecí la conexión Wi-Fi y todo funcionó bien:
YMMV, pero esto es lo que finalmente funcionó para mí. Probablemente debería haber sido lo primero que probé.
mango
IngenieroMejor_DJ
mango
jamshid
bmike
curl
owget
los obtendría en instrumentos/perfilador/depurador y vería qué está sucediendo realmente para causar el error de no poder resolver.