DNS fonctionne avec l'hôte, mais pas avec wget

TL; DR

J'ai une situation étrange où je peux faire des recherches DNS sur certains hôtes mais pas sur d'autres. Cela semble être lié à resolv.conf ayant une entrée de serveur de noms pointant vers mon serveur de noms et une autre qui est probablement liée à Docker, mais je ne sais pas comment le corriger.

Le problème

J'ai lu l'excellente introduction de Stéphane Graber à LXD et je voulais l'essayer. Par conséquent, j'ai fait:

$ sudo usermod -a -G lxd <myusername>
$ newgrp lxd
$ sudo lxd init

Je l'ai configuré avec tous les paramètres par défaut. J'ai ensuite tapé:

$ lxc image list images:
error: Get https://images.linuxcontainers.org/streams/v1/index.json: lookup images.linuxcontainers.org: no such host

Quelques tests

J'ai essayé d'accéder à cette adresse à partir d'un navigateur Web sur un autre PC et cela a bien fonctionné. J'ai donc pensé que quelque chose devait mal se passer avec la configuration DNS, mais:

$ host images.linuxcontainers.org
images.linuxcontainers.org is an alias for canonical.images.linuxcontainers.org.
canonical.images.linuxcontainers.org has address 91.189.91.21
canonical.images.linuxcontainers.org has address 91.189.88.37
canonical.images.linuxcontainers.org has IPv6 address 2001:67c:1560:8001::21
canonical.images.linuxcontainers.org has IPv6 address 2001:67c:1562::41

J'ai donc essayé wget:

$ wget https://images.linuxcontainers.org/streams/v1/index.json
--2016-11-10 15:56:22--  https://images.linuxcontainers.org/streams/v1/index.json
Resolving images.linuxcontainers.org (images.linuxcontainers.org)... failed: Name or service not known.
wget: unable to resolve host address "images.linuxcontainers.org"

ce qui m'a fait penser qu'il y avait un problème avec ma connexion Internet, mais si j'utilise us.images.linuxcontainers.org (dont j'ai vu la mention quelque part sur le web):

$ wget https://us.images.linuxcontainers.org/streams/v1/index.json
--2016-11-10 15:57:26--  https://us.images.linuxcontainers.org/streams/v1/index.json
Resolving us.images.linuxcontainers.org (us.images.linuxcontainers.org)... 91.189.91.21, 2001:67c:1562::41
Connecting to us.images.linuxcontainers.org (us.images.linuxcontainers.org)|91.189.91.21|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3086 (3.0K) [application/json]
Saving to: "index.json"

index.json                                100%[==================================================================================>]   3.01K  --.-KB/s    in 0s

2016-11-10 15:57:26 (8.36 MB/s) - "index.json" saved [3086/3086]

J'ai également essayé canonical.images.linuxcontainers.org, qui (selon hostci-dessus) est ce que images.linuxcontainers.org est un alias de et cela a fonctionné aussi, il ressemble donc à la hostrecherche d'images.linuxcontainers.org, tandis que wgetet lxcne peut pas, mais wget peut accéder à canonical.images.linuxcontainers.org et à la plupart des autres sites que j'ai essayés.

$ wget https://canonical.images.linuxcontainers.org/streams/v1/index.json
--2016-11-10 16:02:28--  https://canonical.images.linuxcontainers.org/streams/v1/index.json
Resolving canonical.images.linuxcontainers.org (canonical.images.linuxcontainers.org)... 91.189.91.21, 91.189.88.37
Connecting to canonical.images.linuxcontainers.org (canonical.images.linuxcontainers.org)|91.189.91.21|:443... connected.
ERROR: no certificate subject alternative name matches
        requested host name "canonical.images.linuxcontainers.org".
To connect to canonical.images.linuxcontainers.org insecurely, use `--no-check-certificate'.

$ wget --no-check-certificate https://canonical.images.linuxcontainers.org/streams/v1/index.json
--2016-11-10 16:02:37--  https://canonical.images.linuxcontainers.org/streams/v1/index.json
Resolving canonical.images.linuxcontainers.org (canonical.images.linuxcontainers.org)... 91.189.88.37, 91.189.91.21
Connecting to canonical.images.linuxcontainers.org (canonical.images.linuxcontainers.org)|91.189.88.37|:443... connected.
WARNING: no certificate subject alternative name matches
        requested host name "canonical.images.linuxcontainers.org".
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://uk.images.linuxcontainers.org/streams/v1/index.json [following]
--2016-11-10 16:02:37--  https://uk.images.linuxcontainers.org/streams/v1/index.json
Resolving uk.images.linuxcontainers.org (uk.images.linuxcontainers.org)... 91.189.88.37, 2001:67c:1560:8001::21
Connecting to uk.images.linuxcontainers.org (uk.images.linuxcontainers.org)|91.189.88.37|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3086 (3.0K) [application/json]
Saving to: "index.json.1"

index.json.1                              100%[==================================================================================>]   3.01K  --.-KB/s    in 0s

2016-11-10 16:02:38 (96.5 MB/s) - "index.json.1" saved [3086/3086]

J'ai également essayé wget -4et wget -6exclu les problèmes IPv6, mais les résultats étaient les mêmes dans les deux cas. Enfin, j'ai essayé d'autres programmes comme, w3mmais aucune différence non plus.

Il me manque évidemment quelque chose; quelqu'un peut-il me conseiller sur les raisons pour lesquelles je ne parviens pas lxcà télécharger la liste d'images?

Le PC

Le PC est une installation relativement nouvelle exécutant Ubuntu Server 16.10 avec très peu de packages supplémentaires installés sur l'hôte principal. Docker est installé et fonctionne mais aucun conteneur n'est en place. Fait intéressant, j'ai récemment redémarré le noyau 4.8.6 pour tester un autre problème que j'avais et avec ce noyau, je pouvais accéder à images.linuxcontainers.org, mais Docker ne démarrerait pas, donc je me demande si cela pourrait être lié à Docker .

Configuration

/etc/resolv.confressemble à ceci (mais pour une raison que je ne connais pas, est en fait un lien symbolique vers /run/resolvconf/resolv.conf):

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.254
nameserver 127.0.0.53
search lan

Si j'interroge le premier serveur de noms répertorié, j'obtiens le même résultat que si je n'ajoute pas l'adresse du serveur de noms:

$ host images.linuxcontainers.org 192.168.1.254
images.linuxcontainers.org is an alias for canonical.images.linuxcontainers.org.
canonical.images.linuxcontainers.org has address 91.189.91.21
canonical.images.linuxcontainers.org has address 91.189.88.37
canonical.images.linuxcontainers.org has IPv6 address 2001:67c:1560:8001::21
canonical.images.linuxcontainers.org has IPv6 address 2001:67c:1562::41

Si j'interroge le second, il expire sans atteindre un serveur:

$ host images.linuxcontainers.org 127.0.0.53
;; connection timed out; no servers could be reached

Si j'interroge le second mais que j'utilise le nom canonique, cela fonctionne, puis expire ???

$ host canonical.images.linuxcontainers.org 127.0.0.53
Using domain server:
Name: 127.0.0.53
Address: 127.0.0.53#53
Aliases:

canonical.images.linuxcontainers.org has address 91.189.88.37
canonical.images.linuxcontainers.org has address 91.189.91.21
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached

Modifier 1:

/etc/nsswitch.conf ressemble à ça:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat
gshadow:        files

hosts:          files resolve [!UNAVAIL=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Modifier 2

Le nsswitch.conf modifié ressemble maintenant à ceci:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat
gshadow:        files

hosts:          files resolve dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Modifier 3

Contenu de /etc/systemd/resolved.conf:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
#Domains=
#LLMNR=yes
#DNSSEC=no
#Cache=yes

— DrAl
source

/etc/resolv.confest généralement un lien symbolique sur Ubuntu, c'est normal. Que /etc/nsswitch.confcontient-il?

— muru

@muru Je l'ai ajouté ci-dessus (celui-ci n'est pas un lien symbolique)

— DrAl

@ThatGuy Merci pour cela. Cela ne fonctionnera pas avec tous les serveurs (car cela dépend si le serveur recherche le nom de domaine) - dans ce cas, je pourrais simplement utiliser canonical.images.linuxcontainers.org car cela semble fonctionner. Cependant, je devrais également persuader lxc image listet lxc launchutiliser cela au lieu de l'adresse intégrée.

— DrAl

@DrAl, c'est la première fois que vous voyez le resolvemot-clé des hôtes, cela semble faux. Vous devriez avoir quelque chose comme hosts: files dns [!UNAVAIL=return]ou si vous avez installé mDNS files dns mdns4_minimal [NOTFOUND=return] mdns4. vous pouvez supprimer [NOTFOUND=return]ou [!UNAVAIL=return], c'est de toute façon l'action par défaut s'il ne reste plus rien à interroger.

— user.dz

@ user.dz, j'ai essayé de le supprimer (bien qu'il s'agisse de la configuration par défaut de mon installation car je n'ai jamais touché ce fichier auparavant). Cela semble permettre à wget de fonctionner (quoique après quelques secondes de retard "résolution d'images.linuxcontainers.org). Merci! Vous avez une idée pourquoi cela a pu être ajouté à mon /etc/nsswitch.conf? La liste des paquets que j'ai installé sur le serveur est répertorié dans un lien dans la section "Le PC" ci-dessus.

— DrAl

C'est la première fois que vous voyez le resolvemot-clé hosts, cela semble faux. Vous devriez avoir quelque chose comme
```
hosts: files dns [NOTFOUND=return]
```
ou si vous avez installé mDNS
```
hosts: files dns mdns4_minimal [NOTFOUND=return] mdns4
```
Vous pouvez supprimer [NOTFOUND=return]ou [!UNAVAIL=return], c'est de toute façon l'action par défaut s'il ne reste plus rien à interroger.

Eh bien, après avoir creusé, j'ai pu constater qu'il y avait un module NSS nouveau pour moi

libnss-resolve

nss module to resolve names via systemd-resolved

nss-resolve is a plugin for the GNU Name Service Switch (NSS) functionality
of the GNU C Library (glibc) providing DNS and LLMNR resolution to programs via
the systemd-resolved daemon (provided in the systemd package).

Installing this package automatically adds resolve to /etc/nsswitch.conf.

Vous pourriez finir par l'installer d'une manière ou d'une autre et non avec les packages que vous avez mentionnés. Aucun paquet n'en dépend.

~$ apt-cache rdepends libnss-resolve
libnss-resolve
Reverse Depends:

Mais je ne peux rien dire pour l'instant, pourquoi systemd-resolvedn'était pas fiable. Il vaut mieux le signaler comme bug dans systemd.

— user.dz
source

Intéressant, merci. J'ai essayé de supprimer "résoudre" et cela a wgetété beaucoup plus rapide, donc il semble que c'est ce qui a causé le problème. Ma ligne d'hôtes dans le nsswitch.conf a maintenant juste "fichiers DNS".

— DrAl

J'avais l'habitude dpkg-query -l '*resolve*'de vérifier et de trouver qu'il libnss-resolveétait installé, alors j'ai installé aptitudeet j'ai couru aptitude why libnss-resolveet ça dit i ubuntu-standard Recommends libnss-resolve.

— DrAl

@DrAl, de quelle version s'agit-il? J'ai U16.04 pas une telle dépendance entre ubuntu-standard& libnss-resolve.

— user.dz

Cela nous donne un peu de lumière sur la configuration actuelle, mais vous avez le dernier correctif, ce qui signifie qu'il s'agit d'un autre bogue (la résolution de systemd / la résolution de nss n'est pas fiable). Avez-vous son service en cours d'exécutionsystemctl status systemd-resolved.service

— user.dz

@DrAl, donc il utilise les valeurs par défaut, from man resolved.conf, cela signifie que nous sommes de retour à /etc/resolv.conf: /. resolvedevrait avoir le même effet que dnsdans nsswitch.conf.

— user.dz