web-dev-qa-db-fra.com

résolus par systemd ne résolvant pas des domaines spécifiques

J'ai un problème très étrange avec le serveur Ubuntu 18.04.1, où le résolveur par défaut, systemd-resolved, ne résout pas certains noms de domaine spécifiques.

Celui sur lequel il échoue de manière fiable est stephenreescarter.net:

valorin@wp:~$ Dig stephenreescarter.net

; <<>> Dig 9.11.3-1ubuntu1.3-Ubuntu <<>> stephenreescarter.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7015
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;stephenreescarter.net.         IN      A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Jan 27 20:01:05 UTC 2019
;; MSG SIZE  rcvd: 50

Mais le domaine lui-même est très bien et fonctionne partout ailleurs:

valorin@wp:~$ Dig stephenreescarter.net @1.1.1.1

; <<>> Dig 9.11.3-1ubuntu1.3-Ubuntu <<>> stephenreescarter.net @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45539
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;stephenreescarter.net.         IN      A

;; ANSWER SECTION:
stephenreescarter.net.  228     IN      A       104.28.2.92
stephenreescarter.net.  228     IN      A       104.28.3.92

;; Query time: 1 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Jan 27 20:00:52 UTC 2019
;; MSG SIZE  rcvd: 82

Et d'autres domaines fonctionnent bien, donc ce n'est pas simplement un cas où le serveur ne peut pas tout résoudre:

valorin@wp:~$ Dig google.com

; <<>> Dig 9.11.3-1ubuntu1.3-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24208
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             148     IN      A       74.125.24.100
google.com.             148     IN      A       74.125.24.101
google.com.             148     IN      A       74.125.24.102
google.com.             148     IN      A       74.125.24.113
google.com.             148     IN      A       74.125.24.138
google.com.             148     IN      A       74.125.24.139

;; Query time: 2 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Jan 27 20:00:57 UTC 2019
;; MSG SIZE  rcvd: 135

Le redémarrage du système parfois résout le problème, de même avec Sudo systemd-resolve --flush-caches. Cependant, ceux-ci ne fonctionnent pas toujours, ou doivent parfois être tentés plusieurs fois avant de commencer à travailler.

Je peux reproduire ce problème sur une gouttelette Ubuntu 18.04.1 DigitalOcean nouvellement créée dans la région SGP1.

De toutes autres manières, systemd-resolve semble fonctionner, donc je n'ai aucune idée de ce qui se passe.

Mise à jour - informations de débogage

valorin@wp:~$ ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Oct  3 16:43 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
valorin@wp:~$ cat /run/resolvconf/resolv.conf
cat: /run/resolvconf/resolv.conf: No such file or directory
1 valorin@wp:~$ cat /run/systemd/resolve/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 67.207.67.2
nameserver 67.207.67.3
1
Stephen RC

Je pense que votre /etc/resolv.conf le lien symbolique est incorrect.

Actuellement, vous montrez ...

~$ ls -al /etc/resolv.conf lrwxrwxrwx 1 root root 39 Oct 3 16:43 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Je pense que cela devrait indiquer resolv.conf, ne pas stub-resolv.conf. Pour le changer, nous allons le faire ...

Sudo rm -i /etc/resolv.conf # supprimer l'ancien lien symbolique

Sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf # recréer le lien symbolique

Voyez si cela aide de quelque façon.

1
heynnema

L'installation par défaut de 18.04 semble manquer le paquet libnss-resolver, dont l'installation corrige le fichier /etc/nsswitch.conf pour que la ligne des hôtes ressemble

hosts:          files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname  

Si vous analysez votre fichier/var/log/syslog, vous verrez probablement des lignes comme:

Jan 27 09:33:15 leno systemd-resolved[931]: Using degraded feature set (UDP) for DNS server 192.168.1.1.
Jan 27 10:06:12 leno systemd-resolved[931]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server 192.168.1.1.  

Ceux-ci indiquent que parfois vous utilisez une fonction réduite définie sur UDP et que les sorties importantes peuvent déborder du tampon habituel. Voir les bugs du tableau de bord 1804487 et 1805027. D'autres solutions de contournement comme la redirection du lien /etc/resolv.conf de /run/systemd/resolv/stub-resolv.conf vers le fichier .../resolv.conf ont essentiellement coupé systemd de la boucle, fournir un serveur de noms directement.


Vous avez testé la résolution avec 1.1.1.1, mais pas un 67 ... ip. Essayer:

Dig stephenreescarter.net @67.207.67.2  

Si cela échoue, le problème ne se trouve pas dans systemd-resolvd qui utilise ce serveur de noms. Ce serveur de noms ne fonctionne pas pour moi, mais ce n'est peut-être pas public.

1
ubfan1