36 votos

16.10 fallo al resolver DNS

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

Primero tuve problemas un par de veces al conectarme a WiFi, mientras que en ethernet funcionaba. Ahora parece que también funciona en WiFi. No estoy seguro de por qué, y si es de alguna manera relacionada con el problema que me enfrento ahora:

Al conectarse a un host VPN con Cisco Anyconnect VPN es añade una línea en '/etc/resolv.conf' . Tengo entendido que Ubuntu utiliza ahora systemd-resolve y la página de manual dice que hay tres modos diferentes de 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, así que por lo que entiendo systemd-resolved debería "leerlo para los datos de configuración DNS". Sin embargo, no parece importarle.

dig

Lo extraño (para mí) es que dig host.customer.tld Si la conexión vpn está deshabilitada, no obtengo respuesta, pero si la conexión vpn está deshabilitada, no obtengo respuesta. Cuando la conexión vpn está deshabilitada no obtengo respuesta. Es decir dig lee /etc/resolv.conf .

ping

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

nmcli

Encontré un post relacionado e intenté ejecutar

nmcli device show <interfacename> | grep IP4.DNS

pero no hay dns para el dispositivo cscotun0. (Aunque tampoco lo hace en 16.04.) Además, nmcli lista mi servidor dhcp (mi router) como IP4.DNS host para mis conexiones eth/wlan. Usando dig @192.168.0.1 xxx para 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

El archivo /etc/systemd/resolved.conf sólo contiene líneas comentadas, excepto la cabecera de la sección:

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

La página de manual de resuelto.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 este parámetro, los servidores DNS DNS listados en /etc/resolv.conf son usados en su lugar, si ese archivo existe y cualquier está configurado en él. Este valor por defecto es la lista vacía.

FallbackDNS \= Una lista separada por espacios de direcciones IPv4 e IPv6 que se utilizarán como servidores DNS de reserva. 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 mediante DNS= o mediante /etc/resolv.conf. Por lo tanto, esta configuración sólo se utiliza si no se conoce otra información del servidor DNS. DNS. Si no se da esta opción, una lista compilada de servidores DNS.

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

EDIT: Yo 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 el solución en mi caso fue desactivar el systemd-resolved servicio. Pensaba que ese servicio era necesario, que era el componente que proporcionaba el servicio DNS a todas las aplicaciones locales, pero aparentemente hay algo más ahí haciendo ese trabajo.

36voto

krlmlr Puntos 930

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

  1. Abrir /etc/NetworkManager/NetworkManager.conf en un editor con derechos de root.
  2. Borrar (o comentar con una almohadilla # ) la línea que dice dns=dnsmasq
  3. Reinicie NetworkManager mediante sudo service NetworkManager restart

15voto

user163217 Puntos 31

He experimentado problemas similares, por ejemplo al añadir un dongle wifi USB adicional. Primero deshabilité dnsmasq en networkmanager como se describe arriba y detuve dnsmasq (service dnsmasq stop)

Me di cuenta de que al resolver rompió durante mi conexión VPN, la tabla de enrutamiento se ve ligeramente diferente (salida del comando route). El nombre de la puerta de enlace es DD-WRT en el caso de que no funciona y simplemente 'puerta de enlace' cuando funciona. La salida de esto no cambió:

nmcli device show wlp1s0 | grep IP4.DNS

Seguía mostrando la IP de mi router. Una solución para conseguir que funcione durante 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 cualquier cosa que cambie la tabla de enrutamiento.

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 encaminamiento? Sería estupendo si pudiéramos identificar esto para poder presentar un informe de error. Me estoy cansando seriamente de perseguir todos estos bugs, pero me gustaría arreglarlos para que los futuros usuarios y nosotros estemos contentos :).

[actualización] Parece que detener systemd-resolved puede arreglar esto y no afectar negativamente a otras cosas. Puedes probar eso y avisar si rompe cosas. Vi cuando se ejecuta 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 *

Para desactivar:

sudo systemctl disable systemd-resolved.service

He actualizado el informe de Ubuntu con sugerencias. [/actualización] Añadir: Nota: el informe de errores : https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317 tiene un parche para 17.04 para algunos problemas. Por favor, comprueba el informe de errores y si es posible prueba el parche. Gracias.

[actualización]

Por favor, revise el informe de errores mencionado anteriormente, el problema parece estar resuelto para 17.10 y con un simple comando también se puede desactivar la fuga de DNS.

[/actualización]

3voto

Nitai Puntos 161

Me encontré con el mismo problema. De alguna manera debo haber instalado DNSmasq con alguna aplicación. Simplemente eliminando dnsmasq se solucionó el problema.

sudo apt-get remove dnsmasq 

Desde entonces, ya no hay desconexiones ni algunos sitios no se pueden cargar (he tenido un problema al cargar gmail, es decir, de repente no se podía conectar a gmail, aunque otros sitios funcionaban).

1voto

PaL Puntos 21

Editar /etc/nsswitch.conf y cambiar

hosts:          files mdns4_minimal [NOTFOUND=return] dns

a

hosts:          files dns mdns4_minimal [NOTFOUND=return]

Edita:

Tengo los mismos problemas desde hace tiempo. Yo era capaz de resolver los nombres de dominio de vpn, pero yo no era capaz de hacer ping o curl esos o utilizarlos en otras aplicaciones. El cambio descrito anteriormente lo resolvió para mí.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X