16.10 falla al resolver DNS

Después de actualizar mi instalación 16.04 a 16.10, tengo problemas con DNS.

Primero tuve problemas un par de veces cuando estaba conectado a WiFi, mientras funcionaba en ethernet. Ahora parece funcionar también con WiFi. No estoy seguro de por qué, y si de alguna manera está relacionado con el problema que enfrento ahora:

Cuando se conecta a un host VPN con Cisco Anyconnect VPN , agrega una línea en '/etc/resolv.conf' . Entiendo que Ubuntu ahora está usando systemd-resolve , y la página del manual dice que hay tres modos diferentes para manejar /etc/resolv.conf. Mi /etc/resolv.conf no es un enlace simbólico, y no enumera 127.0.0.53 como un servidor DNS, por lo que entiendo que systemd resuelto debería "leerlo para los datos de configuración de DNS". Sin embargo, no parece importarle.

cavar

Lo extraño (para mí) es que dig host.customer.tlddevuelve una buena respuesta con una SECCIÓN DE RESPUESTA que muestra la ip del host solicitado, y se refiere al servidor dns agregado a /etc/resolv.conf por vpn client como el SERVIDOR. Cuando la conexión vpn está desactivada, no obtengo respuesta. Es decir, dig lee /etc/resolv.conf .

silbido

El navegador, por otro lado, no llega a /etc/resolv.conf y no puede resolver el nombre del host. Tampoco es ping / curl, por cierto.

nmcli

Encontré una publicación relacionada e intenté ejecutar

nmcli device show <interfacename> | grep IP4.DNS

pero no enumera dns para el dispositivo cscotun0. (Sin embargo, tampoco en 16.04). Además, nmcli enumera mi servidor dhcp (mi enrutador) como host IP4.DNS para mis conexiones eth / wlan. Usar dig @192.168.0.1 xxxpara cualquier dominio público funciona bien.

configuración

Hay algunos otros servidores DNS listados en mi /run/systemd/resolve/resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888
# Too many DNS servers configured, the following entries may be ignored.
nameserver 2001:4860:4860::8844

Estos no son atendidos por mi servidor DHCP. el archivo /etc/systemd/resolved.conf contiene solo líneas comentadas, excepto el encabezado de sección:

[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844

La página del manual para resolve.conf dice que

DNS = Una lista separada por espacios de direcciones IPv4 e IPv6 para usar como servidores DNS del sistema. ... Por razones de compatibilidad, si no se especifica esta configuración, los servidores DNS enumerados en /etc/resolv.conf se utilizan en su lugar, si ese archivo existe y algún servidor está configurado en él. Esta configuración por defecto es la lista vacía.

FallbackDNS = Una lista separada por espacios de direcciones IPv4 e IPv6 para usar como servidores DNS de reserva. Cualquier servidor DNS por enlace obtenido de systemd-networkd.service (8) tiene prioridad sobre esta configuración, al igual que cualquier servidor configurado a través de DNS = anterior o /etc/resolv.conf. Por lo tanto, esta configuración solo se usa si no se conoce otra información del servidor DNS. Si no se da esta opción, en su lugar se usa una lista compilada de servidores DNS.

Parece que el respaldo termina en /run/systemd/resolve/resolv.conf en mi caso.

EDITAR: No estaba seguro de cuál era el problema, y ​​para ser honesto, todavía no sé exactamente cómo funciona esto, pero al menos resultó que la solución en mi caso era deshabilitar el systemd-resolvedservicio. Pensé que era necesario el servicio, que era el componente que proporcionaba el servicio DNS a todas las aplicaciones locales, pero aparentemente hay algo más allí haciendo ese trabajo.

Experimenté problemas similares, por ejemplo, al agregar un dongle wifi USB adicional. Primero deshabilité dnsmasq en networkmanager como se describió anteriormente y detuve dnsmasq (servicio dnsmasq stop)

Noté que cuando la resolución se rompió durante mi conexión VPN, la tabla de enrutamiento se ve ligeramente diferente (salida del comando de ruta). El nombre de la puerta de enlace es DD-WRT en caso de que no funcione y simplemente 'puerta de enlace' cuando funciona. El resultado de esto no cambió:

nmcli device show wlp1s0 | grep IP4.DNS

Seguía mostrando la dirección IP de mi enrutador. Una solución alternativa para que funcione por un tiempo es reiniciar systemd-resolvd:

sudo service systemd-resolved restart

Dado que dnsmasq está fuera de la ecuación, es systemd-resolvd la causa del problema o algo que cambie la tabla de enrutamiento.

Entonces esta es la única diferencia que veo:

ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    601    0        0 

que funciona Y esto cuando NO funciona:

ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         DD-WRT          0.0.0.0         UG    601    0        0 wlp1s0

Y la misma diferencia de nombre en la línea VPN:

vpn-dns.name gateway         255.255.255.255 UGH   0      0        0 wlp1s0

¿Quién sabe qué puede influir en la tabla de enrutamiento? Sería genial si pudiéramos identificar esto para poder presentar un informe de error. Me estoy poniendo muy enfermo y cansado de buscar todos estos errores, pero me gustaría solucionarlos para que los futuros usuarios y nosotros seamos felices :).

[actualización] Parece que detener systemd-resolve puede arreglar esto y no afectar negativamente a otras cosas. Puedes intentarlo y hacerle saber si rompe cosas. Vi cuando ejecuté systemd-resolvd en depuración cuando se rompió:

Removing scope on link wlp1s0, protocol llmnr, family AF_INET
Removing scope on link wlp1s0, protocol llmnr, family AF_INET6
Removing scope on link *, protocol dns, family *

Deshabilitar:

sudo systemctl disable systemd-resolved.service

Actualicé el informe de Ubuntu con sugerencias. [/ actualización] Agregar: Nota: el informe de error: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317 tiene un parche para 17.04 para algunos problemas. Compruebe el informe de error y, si es posible, pruebe el parche. ¡Gracias!

[actualizar]

Compruebe el informe de error mencionado anteriormente, el problema parece estar resuelto para 17.10 y con un simple comando, la fuga de DNS también se puede deshabilitar.

[/actualizar]

El comportamiento de DNS durante la conexión OpenVPN mejoró de inmediato cuando seguí una sugerencia en ubuntuforums:

1. Abrir /etc/NetworkManager/NetworkManager.confen un editor con derechos de root.
2. Eliminar (o comentar con un hash #) la línea que dicedns=dnsmasq
3. Reinicie NetworkManager a través de sudo service NetworkManager restart

Me encontré con el mismo problema. De alguna manera debo haber instalado DNSmasq con alguna aplicación. Simplemente eliminar dnsmasq resolvió el problema por mí.

sudo apt-get remove dnsmasq 

Desde entonces, no hay más desconexiones o algunos sitios ya no pueden cargarse (he tenido un problema al cargar gmail, es decir, de repente no se pudo conectar a gmail, aunque otros sitios funcionaron).

Editar /etc/nsswitch.confy cambiar

hosts:          files mdns4_minimal [NOTFOUND=return] dns

a

hosts:          files dns mdns4_minimal [NOTFOUND=return]

Editar:

Tengo los mismos problemas desde hace bastante tiempo. Pude resolver nombres de dominio desde vpn pero no pude hacer ping o rizarlos o usarlos en otras aplicaciones. El cambio descrito anteriormente lo resolvió para mí.