16.10 ne parviennent pas à résoudre le DNS

Après avoir mis à niveau mon installation de 16.04 vers 16.10, j'ai des problèmes avec DNS.

Tout d'abord, j'ai eu quelques problèmes de connexion au WiFi alors que cela fonctionnait sur Ethernet. Maintenant, il semble que le WiFi fonctionne également. Je ne sais pas pourquoi, et si cela a un quelconque rapport avec le problème auquel je fais face maintenant:

Lors de la connexion à un hôte VPN avec Cisco Anyconnect VPN , une ligne est ajoutée dans '/etc/resolv.conf' . Je comprends que Ubuntu utilise maintenant systemd-resol , et la page de manuel indique qu’il existe trois modes de gestion de /etc/resolv.conf différents. Mon /etc/resolv.conf n’est pas un lien symbolique et ne répertorie pas 127.0.0.53 en tant que serveur DNS. Par conséquent, pour autant que je sache, systemd-resol devrait "le lire pour les données de configuration DNS". Cependant, il ne semble pas s'en soucier.

creuser

La chose étrange (pour moi) est que dig host.customer.tldrenvoie une bonne réponse avec une SECTION DE RÉPONSE indiquant l'adresse IP de l'hôte demandé, et fait référence au serveur DNS ajouté à /etc/resolv.conf par le client VPN en tant que SERVEUR. Lorsque la connexion VPN est désactivée, je ne reçois aucune réponse. Ie dig lit /etc/resolv.conf .

ping

Le navigateur, de l’autre côté, n’a pas accès à /etc/resolv.conf et n’est pas en mesure de résoudre le nom d’hôte. Soit dit en passant, ping / curl non plus.

nmcli

J'ai trouvé un article connexe et j'ai essayé de courir

nmcli device show <interfacename> | grep IP4.DNS

mais il ne répertorie pas de DNS pour le périphérique cscotun0. Cependant, nmcli répertorie mon serveur DHCP (mon routeur) en tant qu'hôte IP4.DNS pour mes connexions eth / wlan. Utiliser dig @192.168.0.1 xxxpour tout domaine public fonctionne bien.

configuration

Il existe d'autres serveurs DNS répertoriés dans mon /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

Ceux-ci ne sont pas servis par mon serveur DHCP. le fichier /etc/systemd/resolved.conf contient uniquement des lignes commentées, à l'exception de l'en-tête de section:

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

La page de manuel de resol.conf indique que

DNS = Liste d'adresses IPv4 et IPv6 séparées par des espaces à utiliser comme serveurs DNS système. ... Pour des raisons de compatibilité, si ce paramètre n'est pas spécifié, les serveurs DNS répertoriés dans /etc/resolv.conf sont utilisés à la place, si ce fichier existe et si des serveurs y sont configurés. Ce paramètre est défini par défaut sur la liste vide.

FallbackDNS = Liste d'adresses IPv4 et IPv6 séparées par des espaces à utiliser comme serveurs DNS de secours. Tous les serveurs DNS par lien obtenus à partir de systemd-networkd.service (8) ont priorité sur ce paramètre, comme tous les serveurs définis via DNS = ci-dessus ou /etc/resolv.conf. Ce paramètre n'est donc utilisé que si aucune autre information de serveur DNS n'est connue. Si cette option n'est pas donnée, une liste compilée de serveurs DNS est utilisée.

On dirait que la solution de repli aboutit dans /run/systemd/resolve/resolv.conf dans mon cas.

EDIT: Je ne savais pas quel était le problème et, pour être honnête, je ne sais toujours pas comment cela fonctionne, mais au moins, il s’est avéré que la solution dans mon cas était de désactiver le systemd-resolvedservice. Je pensais que ce service était nécessaire, que c'était le composant qui fournissait le service DNS à toutes les applications locales, mais apparemment, il y a autre chose qui fait ce travail.

J'ai rencontré des problèmes similaires, par exemple avec l'ajout d'un dongle wifi supplémentaire. D'abord, j'ai désactivé dnsmasq dans networkmanager comme décrit ci-dessus et j'ai arrêté dnsmasq (service dnsmasq stop)

J'ai remarqué que lors de la résolution d'une panne lors de ma connexion VPN, la table de routage est légèrement différente (sortie de la commande route). Le nom de la passerelle est DD-WRT dans le cas où cela ne fonctionne pas et simplement "passerelle" quand cela fonctionne. La sortie de cela n'a pas changé:

nmcli device show wlp1s0 | grep IP4.DNS

Il a continué à montrer mon routeur IP. Une solution de contournement pour le faire fonctionner pendant un moment consiste à redémarrer systemd-resolvd:

sudo service systemd-resolved restart

Puisque dnsmasq est hors de l’équation, c’est soit systemd-resolvd qui est la cause du problème, soit tout ce qui change la table de routage.

C'est donc la seule différence que je vois:

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 

qui fonctionne. Et ceci quand ça ne marche PAS:

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

Et la même différence de nom sur la ligne VPN:

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

Qui sait ce qui peut influencer la table de routage? Ce serait bien si nous pouvions l'identifier afin qu'un rapport de bogue puisse être déposé. Je commence à être sérieusement malade et fatigué de poursuivre tous ces bugs, mais j'aimerais les réparer afin que les futurs utilisateurs et nous-mêmes soyons heureux :).

[mise à jour] Il semble que l'arrêt de systemd-resol puisse résoudre ce problème et ne pas avoir d'impact négatif sur d'autres éléments. Vous pouvez essayer cela et le laisser savoir si ça casse des choses. J'ai vu lors de l'exécution de systemd-resolvd dans le débogage quand il s'est cassé:

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 *

Pour désactiver:

sudo systemctl disable systemd-resolved.service

J'ai mis à jour le rapport Ubuntu avec des suggestions. [/ update] Ajouter: Note: le rapport de bogue: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317 a un correctif pour 17.04 pour certains problèmes. Veuillez vérifier le rapport de bogue et si possible tester le correctif. Merci!

[mise à jour]

Veuillez vérifier le rapport de bogue mentionné ci-dessus, le problème semble être résolu pour 17.10 et avec une simple commande, la fuite DNS peut également être désactivée.

[/mise à jour]

Le comportement DNS lors de la connexion OpenVPN s'est amélioré immédiatement lorsque j'ai suivi une suggestion sur ubuntuforums:

1. Ouvrir /etc/NetworkManager/NetworkManager.confdans un éditeur avec droits root.
2. Supprimer (ou commenter avec un hachage #) la ligne qui litdns=dnsmasq
3. Redémarrez NetworkManager via sudo service NetworkManager restart

Couru dans le même problème. D'une manière ou d'une autre, j'ai dû installer DNSmasq avec une application. Supprimer simplement dnsmasq a résolu le problème pour moi.

sudo apt-get remove dnsmasq 

Depuis lors, plus aucun débranchement ni aucun site ne pouvant plus être chargé (j'ai eu un problème de chargement de gmail, c’est-à-dire que tout à coup, il ne pouvait plus se connecter à gmail, bien que d’autres sites aient fonctionné).

Editer /etc/nsswitch.confet changer

hosts:          files mdns4_minimal [NOTFOUND=return] dns

à

hosts:          files dns mdns4_minimal [NOTFOUND=return]

Modifier:

J'ai les mêmes problèmes depuis assez longtemps. J'ai été capable de résoudre les noms de domaine de vpn mais je n'ai pas été en mesure de les cingler ou de les curl, ni de les utiliser dans d'autres applications. Le changement décrit ci-dessus l'a résolu pour moi.