Résolution de noms très lente

Bonjour tout le monde,

J’ai en ma possession une machine virtuelle VMWare hébergée chez OVH en Debian 9. Celle-ci me permet d’héberger un petit site Internet donc j’ai la configuration suivante NGINX 1.10, PHP7.4, Joomla et MySQL 5.5.

Tout fonctionnait très bien la semaine dernière, mais depuis jeudi c’est la catastrophe. La résolution des noms est très lente voire n’aboutie pas du tout. Aucune action de ma part sur ce site / machine.

J’ai tenté quelques petites choses déjà comme modifier mes nameserver, ajouter des options dans le fichier resolv.conf (comme timeout, rotate), désactiver IPv6, redémarrer plusieurs fois ma VM… Pourtant rien n’y fait.

Si je ping 8.8.8.8, aucun souci. Si je ping google.fr ça ne passe plus. Un apt-get update n’abouti pas sur tous les serveurs (aléatoirement).

Tout ceci me provoque des erreurs PHP du type : Php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution

Ou encore des erreurs de passerelle 504 (bad gateway) sur NGINX.

Toute aide serait fortement appréciée. Je continue de chercher de mon côté.

Que contiennent les fichiers /etc/resolv.conf et /etc/nsswitch.conf ?
Que donne l’envoi de requêtes DNS aux adresses listées dans resolv.conf avec dig, host ou nslookup ?
Y a-t-il des règles de filtrage iptables ou nftables ?

Merci beaucoup.

Contenu de resolv.conf

search WORKGROUP
nameserver 208.67.222.222
nameserver 208.67.220.220

nsswitch.conf

passwd:         compat
group:          compat
shadow:         compat
gshadow:        files
hosts:          files dns
networks:       files
protocols:      db files
services:       db files
ethers:         db files
rpc:            db files
netgroup:       nis

Régles iptables : iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

dig google.fr :

; <<>> DiG 9.10.3-P4-Debian <<>> google.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58657
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.fr.                     IN      A
;; ANSWER SECTION:
google.fr.              300     IN      A       216.58.213.163
;; Query time: 11 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Mon Dec 14 11:06:30 CET 2020
;; MSG SIZE  rcvd: 54

nslookup google.fr :

Server:         208.67.222.222
Address:        208.67.222.222#53
Non-authoritative answer:
Name:   google.fr
Address: 216.58.213.163

Je n’ai pas nftables d’installé.

Ça a l’air de bien répondre. Que donne une requête de type AAAA (adresse IPv6) ?

Faut m’aider pour celle là, désolé. Que dois-je taper ?

J’ai normalement désactivé entièrement IPv6 en faisant ça :

sysctl -p
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.default.autoconf = 0

Il faut spécifier le type dans la commande, voir les pages de manuel pour les détails. Par exemple :

dig aaaa debian-fr.org
host -t aaaa debian-fr.org
nslookup -q=aaaa debian-fr.org

Non, ça ne désactive pas entièrement IPv6. Cela ne fait que désactiver l’utilisation d’IPv6 sur les interfaces réseau, mais d’une part cela n’empêche pas le gestionnaire de réseau de le réactiver sur une interface donnée en fonction de la configuration définie, et d’autre part cela n’empêche pas l’envoi de requêtes DNS de type AAAA.

Ok bon ça va, je m’attendais à plus complexe.

DIG :

; <<>> DiG 9.10.3-P4-Debian <<>> aaaa debian-fr.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51655
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;debian-fr.org.                 IN      AAAA
;; ANSWER SECTION:
debian-fr.org.          49      IN      AAAA    2a01:4f8:202:6091::100
;; Query time: 27 msec
;; SERVER: 208.67.220.220#53(208.67.220.220)
;; WHEN: Mon Dec 14 11:37:32 CET 2020
;; MSG SIZE  rcvd: 70

Host, 1ère tentative :

;; connection timed out; no servers could be reached

La deuxième :

debian-fr.org has IPv6 address 2a01:4f8:202:6091::100

Nslookup :

Server:         208.67.220.220
Address:        208.67.220.220#53
Non-authoritative answer:
debian-fr.org   has AAAA address 2a01:4f8:202:6091::100
Authoritative answers can be found from:

Ok compris pour IPv6, merci pour les explications.

Je constate que c’était 208.67.222.222 (listé en premier dans resolv.conf) qui répondait aux requêtes de type A (adresse IPv4), alors que c 'est 208.67.220.220 qui a répondu aux requêtes de type AAAA. Tu as changé l’ordre dans resolv.conf ? Sinon, il y a eu un délai avant la réponse ?

Non je n’ai rien changé du tout depuis qu’on discute ensemble. J’ai quand même vérifier.

Oui il y a eu un certains délai, effectivement, ça ne s’est pas fait en un claquement de doigt. D’ailleurs j’ai eu un timeout sur la première requête host.

Par contre je viens de voir dans le fichier /etc/network/interfaces :

gateway XXX.XXX.XXX.XXX
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 8.8.8.8
dns-search WORKGROUP

Est-ce que ça jouerait ? Je n’ai pas le même nameservers, je précise qu’au début de mon problème j’utilisais ceux de Google. J’ai changé /etc/resolv.conf avec ceux d’OpenDNS mais je n’ai pas changé dans ce fichier « interfaces ».

Dans ce cas il se pourrait que le délai soit causé par le premier serveur qui ne répond pas aux requêtes AAAA. Tu peux essayer de les permuter pour voir.

Seules les adresses inscrites dans /etc/resolv.conf sont utilisées par le résolveur DNS.

Par contre si le paquet resolvconf est installé et si l’interface à laquelle l’option dns-nameservers est attachée est activée, alors les adresses figurant dans cette option devraient être inscrites dans /etc/resolv.conf.

Ok j’ai fait l’inversion et repassé les commandes dig host et nslookup (en IPv6), ça a été beaucoup plus rapide. Voire instantané.

Pour autant toujours pas de ping sur un nom de domaine, mais ok sur une IP. Impossible de récupérer les sources lors d’un apt-get update.

J’essaie d’appeler OVH car une fois il y avait un problème sur leurs switchs (VM Network) lors d’une migration automatique. La conf n’avait pas suivi le changement.

Je n’ai pas grand espoir mais le caractère « soudain » de mon problème m’étonne quand même. Sachant que je seul à avoir accès à tout ça et que je n’ai absolument pas travaillé sur cette infra.

EDIT : un ping sur 8.8.8.8 est passé, un ping sur 8.8.4.4 ne passe pas, c’est vraiment très étrange.

Et en IPv4 (type A) ?

C’est-à-dire ? Quelle commande ? Que retourne la commande ?

Rien du tout en fait, je suis obligé d’interrompre.

root@SiteWeb:~# ping www.google.fr
^C
root@SiteWeb:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=4.02 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=4.04 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=4.04 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=113 time=4.07 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=113 time=4.01 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=113 time=4.04 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=113 time=4.03 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=113 time=4.03 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=113 time=4.04 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=113 time=4.07 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=113 time=4.05 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=113 time=4.07 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=113 time=4.02 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=113 time=4.04 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=113 time=4.06 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=113 time=4.03 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=113 time=4.09 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=113 time=4.40 ms
^C
--- 8.8.8.8 ping statistics ---
18 packets transmitted, 18 received, 0% packet loss, time 17019ms
rtt min/avg/max/mdev = 4.018/4.068/4.409/0.092 ms
root@SiteWeb:~# 
root@SiteWeb:~# ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
^C
--- 8.8.4.4 ping statistics ---
17 packets transmitted, 0 received, 100% packet loss, time 16383ms
root@SiteWeb:~# ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
^C
--- 8.8.4.4 ping statistics ---
47 packets transmitted, 0 received, 100% packet loss, time 47088ms

Ce sont des adresses IP, pas des noms de domaine.
8.8.4.4 ne répond pas au ping, c’est son droit le plus strict, et ça n’a rien à voir avec la résolution de noms.

root@SiteWeb:~# dig a debian-fr.org
; <<>> DiG 9.10.3-P4-Debian <<>> a debian-fr.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7377
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;debian-fr.org.                 IN      A
;; ANSWER SECTION:
debian-fr.org.          418     IN      A       148.251.85.151
;; Query time: 26 msec
;; SERVER: 208.67.220.220#53(208.67.220.220)
;; WHEN: Mon Dec 14 13:30:19 CET 2020
;; MSG SIZE  rcvd: 58
root@SiteWeb:~# 
root@SiteWeb:~# host -t a debian-fr.org
debian-fr.org has address 148.251.85.151
root@SiteWeb:~# 
root@SiteWeb:~# nslookup -q=a debian-fr.org
;; connection timed out; no servers could be reached
root@SiteWeb:~#

Il semblerait qu’un des deux serveurs DNS ne répond pas aux requêtes A et l’autre ne répond pas aux requêtes AAAA. Nous voilà frais…

Edit : Non, j’ai lu trop vite. En tout cas ils ne répondent pas tout le temps.

Change de serveurs DNS. OVH n’en fournit pas ?

Merci merci !

Je viens de raccrocher avec OVH (36 minutes au tel) ! Il y a effectivement un souci sur mon infra réseau (mes switchs virtuels et mes VLANs). En fait j’ai deux hôtes dans le même POOL, et ça bascule automatiquement de l’un à l’autre en fonction de la charge de chacun.

Tout fonctionne à nouveaux correctement dès lors où je désactive ce mécanisme automatique et force ma VM a être sur un hôte en particulier.

Ils m’en fournissent un de secours en remplacement du « problématique ». Pour le moment je suis donc sur une seule patte !

Ma VM et mon système ne sont pas en cause du coup.

En tout cas, mille merci pour on aide et ton temps. J’ai appris de nouvelles commandes aujourd’hui.

Salut ton message a attisé ma curiosité: quel soft vmware as tu installé sur ton vps?
Tu as une plateforme vmware sur laquelle tu as installé des vms dont celle qui te sert de serveur web?
Peux tu m’en dire plus peut etre ds ‹ trucs et astuces › car j’avoue avoir envisagé l’utilisation de containers pour une plateforme multisites mais jamais je n’aurais pensé que ovh permette ce que tu as fait…je suis curieux

Salut, un peu tardivement désolé.

Ce ne sont pas des produits type VPS dont je dispose, mais ce qu’ils appellent Private Cloud.
En fait tu choisis ton offre, dans mon cas j’ai deux hôtes avec 32Go de RAM sur deux sites, Roubaix et Strasbourg. Ces deux hôtes, sur chaque site, je les administre avec VMWare vSphere Client (la version Web pour Strasbourg et le client PC pour Roubaix). J’administre tout ça comme une infra virtuelle disons classique et je peux créer des VMs dessus peu importe le système que j’installe ensuite sur la VMs (J’ai du Linux, du Windows Server 2016, du FreeBSD). Faire des snapshots etc.
Il a fallu que j’achète chez eux aussi des blocs d’IPs pour pouvoir les lier à mes VMs. Avec ces IPs je peux lier à mes domaines, sous domaines, des VMs. Chose que je n’ai pas vraiment fait dans mon cas (enfin si deux). Mon site Internet est en frontal sur le web (celui qui me posait souci dans ce post) et les services que je mets à disposition de mes users lui est derrière un pare-feu qui lui s’occupe du routage vers la bonne VM derrière en fonction du port, des règles etc.

Entre les deux sites, j’ai également souscrit à Zerto, sur deux VMs en particulier dites « sensibles » chez moi. Ainsi grâce aux fonctionnalités inhérentes à VMWare, en fonction de la charge, cela bascule sur un hôte ou l’autre du même site (système DRS) et en plus de ça, si un site tombe, je peux basculer presque (j’ai bien dit presque) automatiquement sur l’autre site et continuer de fournir mon service.

Si un site tombe, le Zerto me permet d’avoir entre 10 et 15 secs d’écart entre les statuts des VMs. Selon la doc OVH…

Alors je n’ai pas vraiment de « trucs et astuces », j’ai découvert un peu sur le tas il y a deux ans maintenant.
Globalement je suis plutôt content des produits auxquels j’ai souscrit. Les problèmes que j’ai eu étaient surtout dus aussi au switch virtuel qui est avec et non les hôtes ou VMs à proprement parlé. Ce post était le deuxième cas de figure un peu compliqué à solutionner.

Ah si, lorsque tu créé la VM, tu as le choix entre deux types de stockage, un SSD et un classique. Une fois un SSD est tombé, bah rien à faire, j’ai tout perdu. Heureusement la VM n’était pas essentielle. Et on m’a juste répondu que ce type de stockage était plus soumis aux défaillances… Un peu léger. Elle n’était pas dans mon Zerto.

Et enfin pour faire court, bien ça s’administre et se configure comme une vraie infra virtuelle VMWare.

Pas de « trucs et astuces » mais un petit retour d’expérience…