dnsmasq no funciona en Mac OS Sierra

Estoy ejecutando dnsmasq en un MBP 2016 con Mac OS Sierra (10.12.1), pero no puedo hacer ping a ninguna dirección .dev a pesar de tener lo que creo que es la configuración adecuada. Ejecutar excavación devuelve una salida sana.

/usr/local/etc/dnsmasq.conf

resolv-file=/usr/local/etc/resolv-dnsmasq.conf
address=/.dev/127.0.0.1

/etc/resolver/dev

nameserver 127.0.0.1

/usr/local/etc/resolv-dnsmasq.conf

nameserver 8.8.8.8
nameserver 8.8.4.4

Mi lista de servidores DNS en Preferencias del sistema tiene solo una entrada que apunta a 127.0.0.1.

Cuando ejecuto dig en una dirección .dev, obtengo el siguiente resultado:

; <<>> DiG 9.11.0-P1 <<>> test.dev
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36126
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;test.dev.          IN  A

;; ANSWER SECTION:
test.dev.       0   IN  A   127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 19 23:13:20 PST 2016
;; MSG SIZE  rcvd: 42

Puedo cargar perfectamente sitios externos como google.com, pero si intento acceder a un servidor web local o incluso hacer ping a una dirección .dev, falla.

¡La ayuda sería apreciada!

Gracias por la sugerencia. Eliminé la línea, pero desafortunadamente todavía no funciona.
¿Qué método utiliza para asignar nombres de host? ¿El método de archivo /etc/hosts o /usr/local/etc/hosts/?
No estoy usando ninguno de esos archivos. Configuré dnsmasq de tal manera que debería enrutar todo el tráfico que coincida con el patrón .dev a localhost. Esto significa que no debería tener que ingresar manualmente todos los dominios que quiero redirigir en mi archivo de hosts.
Agregue esta parte del archivo dnsmasq.conf a su pregunta.
Esa sería la segunda línea del archivo: dirección=/.dev/127.0.0.1
Hmm no quise decir eso. Tiene que definir sus nombres de host en alguna parte (por ejemplo, test1(.dev) > 127.0.0.1, test2(.dev) > 192.168.56.1, test1.sub(.dev)>192.168.56.2, etc.).
Descubrí que tampoco funcionaba para mí, hasta que reinicié mi mac y luego comenzó a funcionar... incluso usando dscacheutilno funcionó. Parece que macOS X solo actualiza los resolutores después de un restablecimiento completo.
Tuve la misma experiencia que @ortonomy

Respuestas (2)

Su demonio dnsmasq no está configurado correctamente.

Su resolución externa está funcionando: todas las consultas a hosts/dominios que no son desarrolladores se reenvían a servidores DNS de terceros con la resolv-file=/usr/local/etc/resolv-dnsmasq.conflínea: en su caso, el archivo configurado contiene dos servidores DNS públicos de Google.

Sin embargo, su resolución interna no resuelve los nombres internos.

La línea address=/.dev/127.0.0.1o mejor address=/dev/127.0.0.1redirigirá cualquier consulta *.dev al host 127.0.0.1. Entonces no se necesita una resolución interna y el servidor de nombres interno definido en /etc/resolver/dev es inútil.

Compare esto con el ejemplo en el archivo dnsmasq.conf:

# Add domains which you want to force to an IP address here.
# The example below send any host in double-click.net to a local
# web-server.
#address=/double-click.net/127.0.0.1

Cualquier consulta de *.double-click.net se redirigirá a 127.0.0.1 y a un sitio web arbitrario servido en localhost.

Recomiendo encarecidamente definir un archivo hosts.config e ingresar/definir todos los hosts necesarios allí:

Agregue una línea addn-hosts=/usr/local/etc/hosts/hosts.confen dnsmasq.conf. Luego agregue una carpeta con sudo mkdir /usr/local/etc/hostsy cree un archivo hosts.conf

sudo nano /usr/local/etc/hosts/hosts.conf

con el siguiente contenido:

127.0.0.1   localhost
127.0.0.1   test.dev
127.0.0.1   test2.dev
...

Después de guardar el archivo, vuelva a cargar su demonio dnsmasq.

Si desea utilizar diferentes direcciones IP para sus nombres de host, por ejemplo:

127.0.0.1   localhost
127.0.0.2   test.dev
127.0.0.3   test2.dev
...

tendrías que agregar direcciones IP adicionales con:

sudo ifconfig lo0 alias 127.0.0.2 up
sudo ifconfig lo0 alias 127.0.0.3 up
...
Entiendo su punto acerca de que la resolución interna es inútil, pero no entiendo la necesidad del archivo hosts.conf. Si dnsmasq se estaba comportando correctamente, debería dirigir todas las direcciones de desarrollo a localhost. Tener que codificar todos los dominios y subdominios en un archivo host quita el beneficio de usar dnsmasq.
@Steve No conozco su configuración, pero a menudo los desarrolladores (web) usan varios nombres de host diferentes en la máquina local y/o hosts adicionales en máquinas virtuales u otras máquinas reales. Entonces necesita un servidor DNS/DHCP liviano y fácil de configurar como dnsmasq. En mi humilde opinión, el propósito de dnsmasq no es resolver nombres de host solo locales en localhost. Esto se puede hacer más fácilmente editando /etc/hosts directamente con sudo nano ...o con una GUI como Gas Mask .
El problema con el enfoque del archivo host es que falla si su aplicación web se basa en subdominios generados dinámicamente como en el que estoy trabajando. dnsmasq ha podido lograr mi objetivo de redirigir todo con "dev" en máquinas que ejecutan Linux en el pasado con la misma configuración.
@Steve 1. Se sabe que la resolución de DNS es inestable en OS X. 2. No creo que el enfoque de resolución de nombres de "agujero negro" siga un estándar RFC. 3. En mi VM de prueba, la "resolución de nombres" funcionó con su configuración para varios hosts apache virtuales (test.dev, test2.dev, etc.), pero IIRC también hizo ping. Puedo probar el ping nuevamente, volví a una instantánea de VM guardada sin dnsmasq instalado y lleva algún tiempo configurarlo nuevamente para investigar más a fondo el problema.
No estoy seguro de qué cambió, pero después de instalar una actualización de Mac OS, dnsmasq parece estar funcionando como debería.

Los desarrolladores ya no pueden usar el TLD .dev como un TLD privado. Me encontré con esto y tuve que cambiar las cosas para usar ".priv" u otra cosa en su lugar. El TLD ".dev" ya no es algo privado, ya que ahora pertenece a Google, y Chrome y otros navegadores lo tratan de manera especial.

El siguiente es un clip del siguiente artículo: https://www.tomshardware.com/news/google-enforces-https-tld-hsts,35564.html

"Google anunció que 45 de los dominios de nivel superior (TLD) que compró recientemente, incluidos .dev, .app, .eat, etc., reforzarán la seguridad HTTPS, lo que garantiza que todas las conexiones a los sitios que usan esos TLD estarán sobreencriptadas. canales".

¡este .testtld es excelente para locales y, de hecho, está diseñado exactamente para este caso!