La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: vivien le 21 avril 2017 à 18:59:55
-
J'ai un pb avec dig sur un serveur Ubuntu 16.04 LTS : la commande tout simple dig localhost renvoi l'erreur Got bad packet: FORMERR systématiquement.
$ dig localhost
;; Got bad packet: FORMERR
54 bytes
32 43 81 a0 00 01 00 01 00 00 00 01 09 6c 6f 63 2C...........loc
61 6c 68 6f 73 74 00 00 01 00 01 c0 0c 00 01 00 alhost..........
01 00 00 2a 30 00 04 7f 00 00 01 00 00 00 00 00 ...*0...........
00 00 00 00 00 00 ......
Mon fichier /etc/hosts contiens bien l'IP de localhost :
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Vous avez une idée d'où peut être le problème ?
(dig localhost est appelé par smokeping pour une raison que j'ignore, ce qui le bloque vu le retour)
Le syslog :
smokeping[1178]: * Starting latency logger daemon smokeping
smokeping[1178]: Sent data to Server and got new config in response.
smokeping[1178]: ERROR: output of '/usr/bin/dig localhost' does not match (?^i:query time:\s+([0-9.]+)\smsec.*)
smokeping[1178]: at (eval 71) line 1.
smokeping[1178]: ...done.
-
C'est quoi les DNS de la machine et le nom de domaine (domainname) ?
-
J'ai fait plusieurs changement de nom de a machine pensant que ce serait une solution.
Jusqu'à présent il n y avait pas de FQDN (Fully qualified domain name).
J'ai essayé en mettant un FQDN, même chose.
$ hostname
vivien2.testdebit.info
$ dig localhost
;; Got bad packet: FORMERR
54 bytes
4a 22 81 a0 00 01 00 01 00 00 00 01 09 6c 6f 63 J"...........loc
61 6c 68 6f 73 74 00 00 01 00 01 c0 0c 00 01 00 alhost..........
01 00 00 2a 30 00 04 7f 00 00 01 00 00 00 00 00 ...*0...........
00 00 00 00 00 00 ......
$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.022 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.024 ms
^C
--- localhost ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1004ms
rtt min/avg/max/mdev = 0.022/0.023/0.024/0.001 ms
vgu@vivien2:~$ ping vivien2.testdebit.info
PING vivien2.testdebit.info (127.0.1.1) 56(84) bytes of data.
64 bytes from vivien2.testdebit.info (127.0.1.1): icmp_seq=1 ttl=64 time=0.022 ms
64 bytes from vivien2.testdebit.info (127.0.1.1): icmp_seq=2 ttl=64 time=0.025 ms
^C
--- vivien2.testdebit.info ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1024ms
rtt min/avg/max/mdev = 0.022/0.023/0.025/0.005 ms
-
Mon fichier /etc/hosts contiens bien l'IP de localhost :
...
Vous avez une idée d'où peut être le problème ?
...
...
output of '/usr/bin/dig localhost'
Oui, le problème est que tu mélanges tout :
dig (domain information groper) is a flexible tool for interrogating DNS name servers
...
Unless it is told to query a specific name server, dig will try each of the servers listed in /etc/resolv.conf.
https://linux.die.net/man/1/dig
-
$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
Mais ping n'a aucun raison d'aller interroger les DNS!
ping n'est PAS un outil pour outil pour tester le DNS.
-
Non, mais ping interroge le DNS, pour 1/ traduire la query 2/ trouver un eventuel reverse DNS
-
Non, ping demande à la libc qui demande à l'OS de traduire un nom en adresse.
ping se contrefiche du DNS!
-
ping utilise /etc/nsswitch.conf pour savoir quoi utiliser pour trouver localhost.
Typiquement on regarde dans /etc/hosts puis le DNS. Dig regarde directement DNS normalement.
-
ping a juste besoin de convertir une chaîne de caractères passée par l'utilisateur (const char[]) en adresse IP (v6) et inversement de traduire des adresses IP en texte affichable : ping ne s'occupe pas des "DNS", il ne sait même pas ce qu'est un serveur DNS!
dig a pour fonction d'interroger le DNS. Il permet de définir la requête qui n'est pas forcèment convertir un texte en adresse.
-
Quand tu utilises dig sans indiquer de serveur DNS, la commande interroge directement le serveur DNS qui est configuré sur ton Ubuntu et donc n'interroge pas ton fichier host.
Il faudrait regarder du côté du serveur DNS qui est configuré sur ton Ubuntu et savoir pourquoi il ne répond pas 127.0.0.1.
-
Peut être parce que localhost n'est pas défini?
-
Chez moi, dig localhost ne fait pas d'erreur, mais ne renvoie rien, car effectivement localhost n'est pas défini. J'ai les DNS google dans ce cas, 8.8.8.8 et 8.8.4.4.
ubuntu-srv:~$ dig localhost
; <<>> DiG 9.10.3-P4-Ubuntu <<>> localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38370
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;localhost. IN A
;; AUTHORITY SECTION:
. 42469 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017042101 1800 900 604800 86400
;; Query time: 7 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Apr 22 10:06:04 CEST 2017
;; MSG SIZE rcvd: 113
-
Bien sûr, mais cela n'explique pas le FORMERR (format error)!
Il faudrait donc enquêter.
-
Oui, c'est pour cela que je demandais quels étaient les DNS interrogés. La réponse vient d'eux à priori. D'ailleurs un test serait d'interroger explicitement un DNS connu, comme "dig localhost 8.8.8.8".
-
Ubuntu 12.04 LTS
Fichier /etc/host.conf :
# The "order" line is only used by old versions of the C library.
order hosts,bind
multi on
Cela donne :
$ dig localhost
; <<>> DiG 9.9.5-3ubuntu0.14-Ubuntu <<>> localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30526
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;localhost. IN A
;; ANSWER SECTION:
localhost. 604800 IN A 127.0.0.1
;; AUTHORITY SECTION:
localhost. 604800 IN NS localhost.
;; ADDITIONAL SECTION:
localhost. 604800 IN AAAA ::1
;; Query time: 0 msec
;; SERVER: 91.194.96.11#53(91.194.96.11)
;; WHEN: Sat Apr 22 10:57:28 CEST 2017
;; MSG SIZE rcvd: 96
-
Avec Ubuntu 17.04 qui utilise systemd-resolved pour les requêtes DNS, c'est une nouveauté de cette version :
(au passage systemctl restart systemd-resolved.service pour vider le cahce)
$ dig localhost
; <<>> DiG 9.10.3-P4-Ubuntu <<>> localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40766
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;localhost. IN A
;; ANSWER SECTION:
localhost. 0 IN A 127.0.0.1
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Apr 22 10:59:57 CEST 2017
;; MSG SIZE rcvd: 54
-
(dig localhost est appelé par smokeping pour une raison que j'ignore, ce qui le bloque vu le retour)
Le syslog :
smokeping[1178]: * Starting latency logger daemon smokeping
smokeping[1178]: Sent data to Server and got new config in response.
smokeping[1178]: ERROR: output of '/usr/bin/dig localhost' does not match (?^i:query time:\s+([0-9.]+)\smsec.*)
smokeping[1178]: at (eval 71) line 1.
smokeping[1178]: ...done.
Je me demande si le dig localhost n'est pas utilisé simplement pour obtenir une date fiable, venant d'un serveur DNS. Ne sachant pas quel nom utiliser, il utilise localhost.
-
Oui, c'est pour cela que je demandais quels étaient les DNS interrogés. La réponse vient d'eux à priori. D'ailleurs un test serait d'interroger explicitement un DNS connu, comme "dig localhost 8.8.8.8".
La réponse attendue me semble être NXDOMAIN.
J'aimerais voir une trace de la résolution!
-
A mon avis non, c'est le temps "query time \s+([0-9.]+)\smsec.*"
-
Non, ça c'est ce que smokeping attend de trouver dans le résultat de sa commande dig.
C'est donc du coup toujours la même question : quel est le serveur DNS interrogé lorsque cette erreur est retournée ?
-
Ce qui est étonnant, c'est que lors de la première requête - plusieurs minutes sans l'avoir réalisé - c'est ok :
Là j'ai réalisé deux requêtes à la suite :
vgu@vivien2:~$ dig localhost
; <<>> DiG 9.10.3-P4-Ubuntu <<>> localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21173
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;localhost. IN A
;; ANSWER SECTION:
localhost. 10800 IN A 127.0.0.1
;; Query time: 131 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sat Apr 22 11:37:33 CEST 2017
;; MSG SIZE rcvd: 54
vgu@vivien2:~$ dig localhost
;; Got bad packet: FORMERR
54 bytes
40 d5 81 a0 00 01 00 01 00 00 00 01 09 6c 6f 63 @............loc
61 6c 68 6f 73 74 00 00 01 00 01 c0 0c 00 01 00 alhost..........
01 00 00 2a 30 00 04 7f 00 00 01 00 00 00 00 00 ...*0...........
00 00 00 00 00 00 ......
-
Je me demande si le dig localhost n'est pas utilisé simplement pour obtenir une date fiable, venant d'un serveur DNS.
Tu peux m'expliquer comment tu obtiens une date par le DNS?
-
Alors je n'avais pas bien regardé, une requête est bien faite vers la box, une 4G Box en l'occurrence.
192.168.1.100 => PC
192.168.1.1 => 4G Box
Voici la capture wireshark : 201704_dns_localhost.pcap (https://lafibre.info/images/wireshark/201704_dns_localhost.pcap)
(https://lafibre.info/images/wireshark/201704_dns_localhost.png)
Ce qu'affiche DIG :
$ dig localhost
;; Got bad packet: FORMERR
54 bytes
54 fb 81 a0 00 01 00 01 00 00 00 01 09 6c 6f 63 T............loc
61 6c 68 6f 73 74 00 00 01 00 01 c0 0c 00 01 00 alhost..........
01 00 00 2a 30 00 04 7f 00 00 01 00 00 00 00 00 ...*0...........
00 00 00 00 00 00 ......
-
Tu peux m'expliquer comment tu obtiens une date par le DNS?
Bah là :
;; WHEN: Sat Apr 22 11:37:33 CEST 2017
-
Je pense que SmokePing ne cherche pas la date, mais la durée de la requête, la ligne query time :
;; Query time: 131 msec
Par contre je n'ai pas demandé de faire ce type de stats...
-
Oui, c'est probablement cela : temps de réponse des serveurs DNS.
-
Voici une autre capture wireshark, réalisée, elle sur la loopback : 201704_dns_localhost_lo.pcap (https://lafibre.info/images/wireshark/201704_dns_localhost_lo.pcap)
Le résultat de Dig correspondant à la capture :
$ dig localhost
;; Got bad packet: FORMERR
54 bytes
df d7 81 a0 00 01 00 01 00 00 00 01 09 6c 6f 63 .............loc
61 6c 68 6f 73 74 00 00 01 00 01 c0 0c 00 01 00 alhost..........
01 00 00 2a 30 00 04 7f 00 00 01 00 00 00 00 00 ...*0...........
00 00 00 00 00 00 ......
-
Ce qu'affiche DIG :
$ dig localhost
;; Got bad packet: FORMERR
54 bytes
54 fb 81 a0 00 01 00 01 00 00 00 01 09 6c 6f 63 T............loc
61 6c 68 6f 73 74 00 00 01 00 01 c0 0c 00 01 00 alhost..........
01 00 00 2a 30 00 04 7f 00 00 01 00 00 00 00 00 ...*0...........
00 00 00 00 00 00 ......
Bref il y a 1 additional RR constitué uniquement d'une suite de 0.
Très bizarre!
-
C'est vrai que cet "Additional records" semble mal formé...
Additional records
<Root>: type Unused, class Unknown
Name: <Root>
Type: Unused (0)
Class: Unknown (0x0000)
Time to live: 0
Data length: 0
(https://lafibre.info/images/wireshark/201704_dns_localhost_2.png)
Voici la capture wireshark : 201704_dns_localhost.pcap (https://lafibre.info/images/wireshark/201704_dns_localhost.pcap)
-
Bah là :
;; WHEN: Sat Apr 22 11:37:33 CEST 2017
Ah, et du coup c'est pas plus simple d'utiliser simplement date?
-
vgu@vivien2:~$ dig localhost
;; Got bad packet: FORMERR
54 bytes
40 d5 81 a0 00 01 00 01 00 00 00 01 09 6c 6f 63 @............loc
61 6c 68 6f 73 74 00 00 01 00 01 c0 0c 00 01 00 alhost..........
01 00 00 2a 30 00 04 7f 00 00 01 00 00 00 00 00 ...*0...........
00 00 00 00 00 00 ......
[/tt][/color]
La trace, vivien, la trace!
-
La trace quoi ?
J'ai mis 8.8.8.8 comme DNS et là plus de soucis :
$ dig localhost
; <<>> DiG 9.10.3-P4-Ubuntu <<>> localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3924
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;localhost. IN A
;; AUTHORITY SECTION:
. 50819 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017042101 1800 900 604800 86400
;; Query time: 18 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sat Apr 22 12:24:42 CEST 2017
;; MSG SIZE rcvd: 113
Merci corrector pour avoir trouvé le fautif.
-
Je me demande si le dig localhost n'est pas utilisé simplement pour obtenir une date fiable, venant d'un serveur DNS. Ne sachant pas quel nom utiliser, il utilise localhost.
Si tu ne connais pas de nom valide, tu devrais utiliser "."
-
Ah, et du coup c'est pas plus simple d'utiliser simplement date?
Cela dépend si elle venait du serveur DNS (réponse horodatée ?), donc plus fiable, mais apparemment non. De toute façon, Vivien a trouvé, c'est le délai de la réponse qu'il cherche.
-
Bon, maintenant on voit que le serveur qui répondait au début aux requêtes, c'était 127.0.01, donc la machine même. Ce serait intéressant de savoir quel résolveur était installé, qui faisait une telle réponse.
;; SERVER: 127.0.1.1#53(127.0.1.1)
-
Cela dépend si elle venait du serveur DNS (réponse horodatée ?), donc plus fiable, mais apparemment non.
Il n'y pas de champs pour ça!
-
Il n'y pas de champs pour ça!
Bah oui, mea culpa, j'ai imaginé, n'étant pas un spécialiste de la trame DNS, qu'il pouvait y avoir un champ pour cela. Tu avoueras que faire un 'dig localhost', c'est quand même curieux, et quand j'ai vu qu'il cherchait le temps, j'ai fait une première hypothèse qu'il le faisait pour récupérer le temps d'un serveur plus fiable que le localhost justement. Mais Vivien a trouvé la bonne réponse, il cherche le temps de réponse DNS, et il utilise localhost, parce qu'il est sûr qu'il n'y aura pas de récursivité, et qu'il répondra direct, donc ce sera le temps le plus court...
-
Bah oui, mea culpa, j'ai imaginé, n'étant pas un spécialiste de la trame DNS, qu'il pouvait y avoir un champ pour cela. Tu avoueras que faire un 'dig localhost', c'est quand même curieux, et quand j'ai vu qu'il cherchait le temps, j'ai fait une première hypothèse qu'il le faisait pour récupérer le temps d'un serveur plus fiable que le localhost justement. Mais Vivien a trouvé la bonne réponse, il cherche le temps de réponse DNS, et il utilise localhost, parce qu'il est sûr qu'il n'y aura pas de récursivité, et qu'il répondra direct, donc ce sera le temps le plus court...
Je ne vois pas bien l'intérêt.
Et je ne suis pas non plus un expert!!!!!
-
Smokeping n'a pas un code propre au niveau requêtes DNS.
Je ne met presque que des IP en dur, car si on met un nom de domaine, il va faire la requêtes DNS toutes les 5 minutes (normal) mais aussi a chaque consultation de page (c'est ça qui fait la lenteur d'affichage des pages)
Si je perds le DNS sur mon serveur, la page smokePing ne s'affiche pas.
Pour la version 3 ils ont redémarré de zéro, j’espère que ce type de pb sera résolut.
Edit : Le développement de SmokePing 3 ne semble pas avancer : https://github.com/oetiker/smokeping-3.x
-
La trace quoi ?
La trace des requête DNS itératives, évidemment!
+[no]trace
Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled by default. When tracing is enabled, dig makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to resolve the lookup.
https://linux.die.net/man/1/dig
J'ai mis 8.8.8.8 comme DNS et là plus de soucis :
$ dig localhost
; <<>> DiG 9.10.3-P4-Ubuntu <<>> localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3924
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...
Merci corrector pour avoir trouvé le fautif.
Cela n'explique rien!
Déjà, ra = Recursion Available
OK, c'est normal.
MAIS dans la capture pcap :
Flags: 0x8120 Standard query response, No error
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 0... .... = Recursion available: Server can't do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..1. .... = Answer authenticated: Answer/authority portion was authenticated by the server
.... .... ...0 .... = Non-authenticated data: Unacceptable
.... .... .... 0000 = Reply code: No error (0)
Je vous annonce que cette histoire commence à me gonfler!
-
Bon, maintenant on voit que le serveur qui répondait au début aux requêtes, c'était 127.0.01, donc la machine même. Ce serait intéressant de savoir quel résolveur était installé, qui faisait une telle réponse.
;; SERVER: 127.0.1.1#53(127.0.1.1)
Il faudrait déjà savoir si c'est juste un forwarder!
-
Il n'y a pas de récursion réalisée par 127.0.0.1 ou par le DNS de la 4G box (192.168.1.1). C'est le DNS du FAI qui réalise la récursion.
(ok j'aurais pu configurer mon serveur pour le faire, mais ce n'est pas le cas)
-
;; SERVER: 127.0.1.1#53(127.0.1.1)
ca affiche 127.0.1.1 et pas 127.0.0.1 ...
127.0.1.1 c'est typique sur Ubuntu du Network manager qui configure un dnsmasq pour faire un dns forwarder local.
t'as quoi dans /etc/NetworkManager/NetworkManager.conf ?
-
Oui, tout à fait, il y a une interface graphique (LXDE) et Network Manager.
Je n'avais pas vu la subtilité du 127.0.1.1
Le contenu du fichier /etc/NetworkManager/NetworkManager.conf :
[main]
plugins=ifupdown,keyfile,ofono
dns=dnsmasq
[ifupdown]
managed=false
A noter que pour Ubuntu 17.04 et +, la section DNS disparaît, les DNS sont gérés par systemd-resolved.service avec un dnsmasq sur l'IP 127.0.0.53
Le contenu du fichier /etc/NetworkManager/NetworkManager.conf avec Ubuntu 17.04 :
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
-
J'avais aussi loupé le 127.0.1.1. Ce sont donc les DNS de Bouygues Telecom qui renvoient une erreur (ou un RR mal formé).
Avec Systemd et Network Manager, la configuration des DNS devient un peu trop subtile.
-
C'est une 4G box, mais j'ai mis une SIM FreeMobile. (La 4G Box n'est pas simlocké)
Le pb est probablement chez Huawei (FreeMobile c'est aussi une possibilité, mais moins probable)
-
Avec Systemd et Network Manager, la configuration des DNS devient un peu trop subtile.
D'autant que par défaut, systemd-resolved utilise les DNS Google si les DNS sont mal renseignées sur la machine.
-
Oui, tout à fait, il y a une interface graphique (LXDE) et Network Manager.
Je n'avais pas vu la subtilité du 127.0.1.1
Oui ce n'est pas 127.0.0.1 (aka "localhost"), et alors?
Je ne vois pas en quoi cette "subtilité" change l'analyse.
Cela n'explique absolument pas les messages d'erreurs.
-
oui il y a beaucoup de confusion dans ce post...
-
Quelqu'un a trouvé l'explication?