Problème de résolution DNS

Support Debian
#1

Bonjour,

J’ai une VM sous debian qui as un problème de DNS, et comme je suis une quiche dans ce domaine, je viens demander un coup de main

quand je ping 8.8.8.8, j’ai bien une réponse
mais quand je ping google.fr, pas de réponse.
C’est typique d’un problème DNS

voici la conf de /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens192
iface ens192 inet static
        address xxx.yyy.48.28
        gateway xxx.yyy.4.3
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers xxx.yyy.162.42

ici dns-nameservers est correcte, mais impossible de piguer des nom dns

avez vous une idée d’ou peut venir l’erreur

Merci de votre aide

#2

pour vérifier sa configuration dns, il faut utiliser l’outil dig
https://memo-linux.com/dig-outil-pour-tout-savoir-sur-les-resolveur-dns/
exemple

dig +trace microsoft.com

#3

Hello @grandtoubab

J’ai testé la commande sur le serveur lui même, voici ce que cela donne

dig +trace mondomaine.fr

; <<>> DiG 9.10.3-P4-Debian <<>> +trace mondomaine.fr
;; global options: +cmd
;; connection timed out; no servers could be reached

et pour microsoft

dig +trace microsoft.com

; <<>> DiG 9.10.3-P4-Debian <<>> +trace microsoft.com
;; global options: +cmd
;; connection timed out; no servers could be reached

J’ai testé d’un serveur qui est sur le même réseau

dig +trace mondomaine.fr

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.1 <<>> +trace mondomaine.fr
;; global options: +cmd
;; Received 17 bytes from xxx.yyy.162.37#53(xxx.yyy.162.37) in 1 ms

Pour microsoft

dig +trace microsoft.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.1 <<>> +trace microsoft.com
;; global options: +cmd
;; Received 17 bytes from xxx.yyy.162.37#53(xxx.yyy.162.37) in 1 ms

Je vois que c’est le serveur dns xxx.yyy.162.37 qui répond.
Dans le fichier /etc/network/interfaces j’ai remplacé xxx.yyy.162.42 par le xxx.yyy.162.37 même résultat

#4

Bonsoir,

Quel est le contenu du fichier /etc/resolv.conf ?

Cordialement

JP P

#5

hello @JPPO
Voici son contenu

# 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 127.0.0.1

Je n’ai pas osé le modifier à la main

#6

tu veux utiliser un dns local qui visiblement ne fait pas son travail

 nmcli | grep DNS -A2
DNS configuration:
	servers: 127.0.0.1 64.6.64.6 80.67.188.188
	interface: wlo2

voici un exemple de résultat ok

dig +trace microsoft.com

; <<>> DiG 9.16.4-Debian <<>> +trace microsoft.com
;; global options: +cmd
.			491450	IN	NS	c.root-servers.net.
.			491450	IN	NS	j.root-servers.net.
.			491450	IN	NS	h.root-servers.net.
.			491450	IN	NS	d.root-servers.net.
.			491450	IN	NS	f.root-servers.net.
.			491450	IN	NS	i.root-servers.net.
.			491450	IN	NS	l.root-servers.net.
.			491450	IN	NS	k.root-servers.net.
.			491450	IN	NS	e.root-servers.net.
.			491450	IN	NS	m.root-servers.net.
.			491450	IN	NS	b.root-servers.net.
.			491450	IN	NS	g.root-servers.net.
.			491450	IN	NS	a.root-servers.net.
.			514832	IN	RRSIG	NS 8 0 518400 20200715050000 20200702040000 46594 . dbU96OGa9bKOLMjIOt6FAMhKq+asCy+CuGv/5cWin3PkO+IZrN5ii3/n GMHHSsReJCz8Rxm0Hg3h5Oj4Dq4IvUBqSBO+h4fZqES7if2MVCpbuRBK 8ByC4nN8xB2ZJfgNZhAa0r1hm4AVF2wArPeg5kS9H10LjMmTorFE7X5U spBm0PsC2I3tlhnejNbT79WyyQ1I4LiJ7wafvX6GbDBd+tDQi2OOgE4m yo+cBrL7oJP9D/1h0LKVB6ksqWZc5EjI09qVmJCs2ymc29DfAM3QdwVm 8OO/qyBOHJPXkeFptJ8phPgsZI96L8liOEmqvAZJMstC57vAN31XWl1N ZTZoYQ==
;; Received 553 bytes from 127.0.0.1#53(127.0.0.1) in 39 ms

com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			86400	IN	DS	30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.			86400	IN	RRSIG	DS 8 1 86400 20200715050000 20200702040000 46594 . lsvp3YAd/6U6tZENmhQtkpFPa6FfSF8p3xfniqDhc9uhAlPQTLQKxosI Q2V4CZFuqD1KKVzN3VFwGki9V0RDWVhnFh65uGS6cpJtQTN/K8HApHXp zuTmUKWWT/zANlQOcgzVdeRLddYjLjufiSEYp4p+/V8X0oXQXot8Vd7k Tez2WRlDMVRzIVWIJ1ZMXnVSCdzZmRvrdP9OfxjwmshRa4QzZR6jJXpW rsGS/7BwzqgVoaPHiym7eSPER9/WxXXNPqhNILV6trnOMO8AzAlZGjEA dAurVnM8R7ieVHwNRL2C4X3cUEzRf0qH2MXcnSW9iphMWoMV4n2SeoC9 O1Qsvg==
;; Received 1201 bytes from 199.9.14.201#53(b.root-servers.net) in 151 ms

microsoft.com.		172800	IN	NS	ns1-205.azure-dns.com.
microsoft.com.		172800	IN	NS	ns2-205.azure-dns.net.
microsoft.com.		172800	IN	NS	ns4-205.azure-dns.info.
microsoft.com.		172800	IN	NS	ns3-205.azure-dns.org.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200708044206 20200701033206 39844 com. Pe4WH+HM8RD4b3qMPoAfhEkbj6JnLrT1USV0g7i9SHtSG5Cv2gIrWu4s xmR5ynjZKPFFSL6acHElnJxcLyaL3TGGc7CfALk911YAv21JYJ5cH7YB zdagPbI7qeLoQ1ggiq5uytI2/YaLwnOKa0t5Hd/3iKHe7W88Jjbel7DK 0lO9OVv/2356V4nTfrVbYgBghFm/fFwdt6Fs6MVQfl1eqQ==
TCQ6IPLI7J7L7J3CPR3ADIMGCRORNM0U.com. 86400 IN NSEC3 1 1 0 - TCQ86I9UF16SE5E0GDRCKG8J8B71NPL9 NS DS RRSIG
TCQ6IPLI7J7L7J3CPR3ADIMGCRORNM0U.com. 86400 IN RRSIG NSEC3 8 2 86400 20200709060743 20200702045743 39844 com. TpR4xiCQvJZxw7Bq2GS4Myo54GBDthAaNJEePmUU73fnt6RPbYI711uI kK7NjF/7059FFkgJhk1ke2F7niQRa12anLgB4jxeKdUZOSbiRgdiw/F9 vhYavmkF1RxqGOiwWjY/IBWgj57XJ0Yevxf7X6WCR65GlePl7EUBw7FN j7ZenuArZyAvjB4qsc/TWoSNGUeyRPodkhPY20Mb7BwNPw==
;; Received 773 bytes from 192.26.92.30#53(c.gtld-servers.net) in 43 ms

microsoft.com.		3600	IN	A	104.215.148.63
microsoft.com.		3600	IN	A	40.76.4.15
microsoft.com.		3600	IN	A	40.112.72.205
microsoft.com.		3600	IN	A	40.113.200.201
microsoft.com.		3600	IN	A	13.77.161.179
;; Received 122 bytes from 13.107.160.205#53(ns4-205.azure-dns.info) in 63 ms

voici comment j’ai construit ma conf

#7

Bonjour,

Utiliser nmcli sur un système où le réseau est configuré de manière statique avec /etc/network/interfaces ne va pas aider, pas plus que dig de cette façon…

Il faut déjà voir si tu peux atteindre un résolveur externe :

dig debian-fr.org @1.1.1.1

Et la même avec le résolveur que tu as spécifié dans ton fichier de configuration :

dig debian-fr.org @xxx.yyy.162.42
#8

Désolé pour le retard de ma réponse.

@anon70622873
Voici le résultat de la commande , j’ai juste modifié le serveur dns qui passe de xxx.yyy.162.42 à xxx.yyy.162.43

root@vm2:~# dig debian-fr.org @1.1.1.1

; <<>> DiG 9.10.3-P4-Debian <<>> debian-fr.org @1.1.1.1
;; global options: +cmd
;; connection timed out; no servers could be reached
root@vm2:~# dig debian-fr.org @1.1.1.1

; <<>> DiG 9.10.3-P4-Debian <<>> debian-fr.org @1.1.1.1
;; global options: +cmd
;; connection timed out; no servers could be reached
root@vm2:~# dig debian-fr.org @xxx.yyy.162.43

; <<>> DiG 9.10.3-P4-Debian <<>> debian-fr.org @xxx.yyy.162.43
;; global options: +cmd
;; connection timed out; no servers could be reached

si je fais la commande d’un autre serveur, sous centOS

 [root@vm1 ~]$ dig debian-fr.org @1.1.1.1

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> debian-fr.org @1.1.1.1
;; global options: +cmd
;; connection timed out; no servers could be reached


[root@vm1 ~]$ dig debian-fr.org @xxx.yyy.162.43

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> debian-fr.org @xxx.yyy.162.43
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3764
;; flags: qr rd ra; 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.		3600	IN	A	163.172.90.35

;; Query time: 62 msec
;; SERVER: xxx.yyy.162.43#53(xxx.yyy.162.43)
;; WHEN: ven. juil. 03 11:10:56 CEST 2020
;; MSG SIZE  rcvd: 58
#9

Est-ce que le ping sur les deux résolveurs fonctionne ?

ping -c2 1.1.1.1
ping -c2 xxx.yyy.162.43

Et retours de :

ip a
ip route
#10

effectivement il ne ping pas le résolver O_o

root@vm2:~# ping -c2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=2.31 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=2.32 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 2.313/2.316/2.320/0.048 ms


root@vm2:~# ping -c2 xxx.yyy.162.43
PING xxx.yyy.162.43 (xxx.yyy.162.43) 56(84) bytes of data.
From xxx.yyy.48.28 icmp_seq=1 Destination Host Unreachable
From xxx.yyy.48.28 icmp_seq=2 Destination Host Unreachable
#11

Le retour des deux autres commandes STP.

Pour le résolveur 1.1.1.1 il est atteignable par ICMP mais ne répond pas aux requêtes DNS ⇒ problème de pare-feu trop restrictif ?

Pour xxx.yyy.162.43 il n’est pas atteignable ⇒ problème de route ?

#12

Excuse, voici le résultat, sachant que xxx.yyy sont les mêmes

root@vm2:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:95:9d:a0 brd ff:ff:ff:ff:ff:ff
    inet xxx.yyy.48.28/16 brd xxx.yyy.255.255 scope global ens192
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:ssss:zzzz/64 scope link
       valid_lft forever preferred_lft forever
root@vm2:~# ip route
default via xxx.yyy.4.3 dev ens192 onlink
xxx.yyy.0.0/16 dev ens192 proto kernel scope link src xxx.yyy.48.28
#13

Si xxx.yyy.4.3 correspond bien à la machine qui sert de routeur/passerelle vers l’extérieur, cela me semble ok au niveau de la configuration réseau, reste le problème de pare-feu.
Est-ce qu’un pare-feu est activité sur la VM ou sur le routeur, et si oui avec quelles règles ?

#14

Oui, il y a un parfeu sur cette VM, mais en le désactivant c’est pareil
résolveur 1.1.1.1 est atteignable, comme le résolveur 9.9.9.9, quelques soit les VM.
Mais le 8.8.8.8 est Ok

root@vm2:~# dig debian-fr.org @8.8.8.8

; <<>> DiG 9.10.3-P4-Debian <<>> debian-fr.org @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61959
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;debian-fr.org.                 IN      A

;; ANSWER SECTION:
debian-fr.org.          3599    IN      A       163.172.90.35

;; Query time: 21 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jul 03 13:37:48 CEST 2020
;; MSG SIZE  rcvd: 58
#15

Il faut le désactiver, de toute façon cela ne sert à rien sur une VM.
Et aussi désactiver celui sur l’hôte de la VM.

#16

c’est désactivé, mais pareil.
J’ai oublié de mentionner que j’étais dans un réseau d’entreprise.
Mais, j’ai installé plusieurs application, et jamais eu ce soucis

#17

Je ne vois pas alors…
Il n’y a aucune raison que la résolution de noms fonctionne avec 8.8.8.8 et pas avec les autres (9.9.9.9 et 1.1.1.1) sauf règles de filtrage particulières. Ou alors il y a une erreur de configuration réseau que l’on voit pas avec tes IP masquées. Et pourquoi les masquer si ce sont des IP privées ?
Est-tu sûr que xxx.yyy.48.28 n’est pas attribué à une autre machine ?
As-tu essayé en précisant le masque réseau :

netmask 255.255.0.0

D’ailleurs est-ce bien un /16 ?

#18

Tu es sûr de la taille du préfixe /16 ? Je ne vois pas d’option netmask ni de préfixe explicite dans la configuration de /etc/network/interfaces, donc je suppose que ifup a pris la longueur de préfixe par défaut de l’ancienne classe à laquelle l’adresse appartenait (classe B pour /16).

Si le préfixe n’est pas bon, la machine ne fait pas correctement la distinction entre ce qui est joignable directement sur son réseau local et ce qui est joignable via son routeur par défaut.

C’est une plage d’adresses IP publiques ou privées ? Le préfixe me semble un peu petit pour un bloc public. Si c’est un bloc privé (192.168.*.*, 172.16-31.*.*, 10.*.*.*), ça ne sert à rien de caviarder les adresses qui sont inutilisables à l’extérieur de ce réseau et ne fait que gêner les lecteurs.

Ben voyons.

#19

Non je ne rentrerai pas dans cette polémique sur l’utilité ou pas du pare-feu :wink:

Là l’idée était surtout désactiver les règles de filtrage pour éliminer cette source de problème.

#20

@PascalHambourg

pour le /16 c’est ce que me donne la machine avec la commande ip a
Je suis aller sur des VM qui sont sur le même réseau xx.yyy.48.20 ou 48.24 et c’est un /18 qui est donné