Auteur Sujet: dig localhost => erreur "Got bad packet: FORMERR" (Lu 13184 fois)

« **Réponse #12 le:** 22 avril 2017 à 10:41:29 »

Bien sûr, mais cela n'explique pas le FORMERR (format error)!

Il faudrait donc enquêter.

alain_p · « **Réponse #13 le:** 22 avril 2017 à 10:45:11 »

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".

vivien · « **Réponse #14 le:** 22 avril 2017 à 10:58:03 »

Ubuntu 12.04 LTS

Fichier /etc/host.conf :

Code: [Sélectionner]

# The "order" line is only used by old versions of the C library.
order hosts,bind
multi on

Cela donne :

Code: [Sélectionner]

$ 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

vivien · « **Réponse #15 le:** 22 avril 2017 à 11:00:08 »

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)

Code: [Sélectionner]

$ 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

alain_p · « **Réponse #16 le:** 22 avril 2017 à 11:04:05 »

Citation de: vivien le 21 avril 2017 à 18:59:55

(dig localhost est appelé par smokeping pour une raison que j'ignore, ce qui le bloque vu le retour)

Le syslog :
Code: [Sélectionner]
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.

« **Réponse #17 le:** 22 avril 2017 à 11:07:28 »

Citation de: alain_p le 22 avril 2017 à 10:45:11

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!

alain_p · « **Réponse #18 le:** 22 avril 2017 à 11:14:43 »

A mon avis non, c'est le temps "query time \s+([0-9.]+)\smsec.*"

seb · « **Réponse #19 le:** 22 avril 2017 à 11:25:30 »

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 ?

vivien · « **Réponse #20 le:** 22 avril 2017 à 11:39:25 »

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 ......

« **Réponse #21 le:** 22 avril 2017 à 11:42:33 »

Citation de: alain_p le 22 avril 2017 à 11:04:05

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?

vivien · « **Réponse #22 le:** 22 avril 2017 à 11:51:08 »

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

Ce qu'affiche DIG :

Code: [Sélectionner]

$ 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                                        ......

alain_p · « **Réponse #23 le:** 22 avril 2017 à 11:58:09 »

Citation de: corrector le 22 avril 2017 à 11:42:33

Tu peux m'expliquer comment tu obtiens une date par le DNS?

Bah là :

;; WHEN: Sat Apr 22 11:37:33 CEST 2017