La resolución de DNS falla para hacer ping y curl, pero no para excavar

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.iousar curlo ping. Sin embargo, dighace 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 -AlwaysAppendSearchDomainscomo argumento /usr/sbin/mDNSRespondery /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistreinicié 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, nslookupy digno causa que nada sea registrado por mDNSResponder, pero otras herramientas ( ping, curl) sí lo hacen.

Entonces parece que, por alguna razón, dnsmasqno funciona (puedo establecer una conexión TCP con 127.0.0.1:53) o mDNSResponderno lo está usando.


ACTUALIZAR 3

etc/resolve.confdeja 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 dnsmasqservidor local?

¿Tu adaptador de red se ha caído por casualidad? Si va a 'Red' en Preferencias del sistema, ¿hay un punto verde al lado del adaptador en el que está configurado dnsmasq?
Bueno, estoy en un tren sin wi-fi, presumiblemente.
Específicamente, ¿está apagado el adaptador wifi? Si es así, intente nuevamente con el adaptador wifi encendido (aunque es posible que no esté conectado a Internet). Para que la configuración funcione, dnsmasq debe ser un servidor DNS en la interfaz de red en uso .
Gracias por tratar de rastrear esto. También estoy luchando con esto, no entiendo por qué "curl foo: 8989" no puede encontrar el host pero "dig foo" sí. Sí, "curl 172.20.0.17:8989" funciona bien. Al igual que usted, tengo el DNS de la red Wi-Fi configurado en 127.0.0.1 (un dnsmasq que se ejecuta en un contenedor acoplable). FWIW en mi situación actual, el problema es específico de la red wifi a la que me conecto: funciona bien en mi punto de acceso personal, el problema está en el wifi de una cafetería.
No he aplicado ingeniería inversa a los programas en cuestión, pero mi expectativa es que estén llamando a bases de código de resolución de DNS completamente diferentes y es por eso que está viendo fallas: algunos apuntan localmente, otros no. Probablemente buscaría en curlo wgetlos obtendría en instrumentos/perfilador/depurador y vería qué está sucediendo realmente para causar el error de no poder resolver.

Respuestas (3)

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
He notado eso pingy, diga 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:

  • En Preferencias del sistema > Red > Interfaz > Servidor DNS, elimine todos los servidores DNS excepto 127.0.0.1 y aplique los cambios. También puede configurar una segunda ubicación con una configuración de solo 127.0.0.1 y mantener su servidor DNS actual en la otra configuración.
  • 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
    
  • agregue resolv-file=/usr/local/etc/resolv.dnsmasq.confen la línea ~46 de /usr/local/etc/dnsmasq.conf
  • agregar o mover address=/.local.pcfdev.io/192.168.11.11en/a la línea ~80 de /usr/local/etc/dnsmasq.conf
  • reiniciar dnsmasq con:

    sudo launchctl stop homebrew.mxcl.dnsmasq
    sudo launchctl start homebrew.mxcl.dnsmasq
    
Gracias por tomarse el tiempo para responder. Definitivamente hay algo escuchando 192.168.11.11; la entrada DNS pública real para *.local.pcfdev.iosiempre 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.
Parece que curl, pingy los otros binarios a los que quiero llegar están usando un medio para buscar entradas de DNS (que no usan el dnsmasqservidor en localhost), nslookupy digestán usando otro medio. ¡Supongo que necesito aprender más sobre mDNSResponder!
@EngineerBetter ¿Tiene otras entradas en Preferencias del sistema> Red> Interfaz> DNS que 127.0.0.1? - Voy a instalar toda la suite (VBox, PCF Dev, etc.) y verifico esto... ¿Alguna configuración especial?
Gracias de nuevo por tomarse el tiempo para ayudarme con esto. La pregunta ha sido actualizada, aún no ha tenido suerte.

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:

  1. Menú Apple -> Preferencias del sistema -> Wi-Fi (a la izquierda)
  2. 'Desactivar Wi-Fi' y luego seleccionar 'Avanzado'
  3. Elimine la conexión Wi-Fi con la que tiene problemas (o todas si lo desea). Haga esto seleccionando la red Wi-Fi que desea eliminar y presionando "-"
  4. Haga clic en 'Aplicar' y 'Aceptar'
  5. Vuelva a encender el Wi-Fi.
  6. Seleccione su red Wi-Fi e inicie sesión nuevamente.

YMMV, pero esto es lo que finalmente funcionó para mí. Probablemente debería haber sido lo primero que probé.