Resolución DNS falla para ping y curl, pero no para excavar

8

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 después, después de algunos reinicios de mi MacBook, mientras estoy fuera de línea, ya no puedo resolver cosas como api.local.pcfdev.io usando 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

He intentado agregar -AlwaysAppendSearchDomains como un argumento a /usr/sbin/mDNSResponder en /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist y reinicié el mDNSResponder con launchctl , pero fue en vano.

ACTUALIZACIÓN 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.

ACTUALIZACIÓN 2

Después de intentar 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 un poco de cierre de depuración 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)

También observé que, como se explica en la respuesta propuesta, nslookup y dig no hacen que se registre nada con mDNSResponder , pero sí lo hacen otras herramientas ( ping , curl ).

Parece que, por cualquier motivo, dnsmasq no funciona (puedo establecer una conexión TCP con 127.0.0.1:53 ) o mDNSResponder no lo está utilizando.

ACTUALIZACIÓN 3

etc/resolve.conf deja de existir cuando mi adaptador wifi está activo, pero no estoy conectado a una red. ¿Podría ser esta la razón por la que las herramientas CLI no usan el servidor local dnsmasq ?

    
pregunta EngineerBetter_DJ 06.09.2016 - 11:21

2 respuestas

4

dig por un lado y curl / ping por otro lado están recuperando datos de diferentes hosts:

dig consulta un servidor DNS, en su caso, su localhost (127.0.0.1), para una entrada de base de datos: la dirección IP relacionada con el api.local.pcfdev.io del FQDN. El host en sí no tiene que ejecutarse o incluso no existe en absoluto.

curl / ping intente resolver una dirección IP con mDNSResponder o por otros medios y finalmente opere / interactúe con el host remoto. Si el host 192.168.11.11 no se ejecuta o no existe en absoluto, ambos fallarán.

Ahora, la entrada de DNS es incorrecta (api.local.pcfdev.io tiene otra IP que 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 un 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 inicie en OS X 10.11 (El Capitan) y versiones posteriores, configure las claves booleanas AlwaysAppendSearchDomains o NoMulticastAdvertisements en true en /Library/Preferences/com.apple.mDNSResponder.plist and reinboot .

En su caso, no es necesario establecer esta clave, porque no es la causa de su problema.

Después de profundizar en VirtualBox, PCF Dev (fallando repetidamente con algunas "credenciales incorrectas" que intentan iniciar sesión en la VM) y dnsmasq, recomiendo devolver las consultas de DNS a dnsmasq solamente:

  • En Preferencias del sistema > Red > Interfaz > El servidor DNS elimina todos los servidores DNS excepto 127.0.0.1 y aplica los cambios. También puede configurar una segunda Ubicación con una configuración 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.conf en la línea ~ 46 de /usr/local/etc/dnsmasq.conf
  • agregar o mover address=/.local.pcfdev.io/192.168.11.11 en / a la línea ~ 80 de /usr/local/etc/dnsmasq.conf
  • reinicia dnsmasq con:

    sudo launchctl stop homebrew.mxcl.dnsmasq
    sudo launchctl start homebrew.mxcl.dnsmasq
    
respondido por el klanomath 06.09.2016 - 12:47
2

Tenía este mismo problema. Creo que la memoria caché de DNS local tenía datos erróneos de mis pruebas anteriores. Fue arreglado rápidamente por:

sudo killall -HUP mDNSResponder
    
respondido por el cmcginty 21.10.2018 - 04:54

Lea otras preguntas en las etiquetas