14 Oct
2022
14 Oct
'22
10:51 a.m.
Hi Team
Maybe some of you has already come over that issue and know how to fix.
Bind 9.18.4 fails to resolve the A record of: fd19g0409.drive.pro.io
Bind 9.11.36 works.
Both versions have DNSSEC Validation enabled and connected to a network
not restricting EDNS.
Bind Logs:
named[3156696]: end of file resolving '_.drive.pro.io/A/IN': 80.74.143.169#53
Dr. Google does not spit out any useful answer to this error.
Analyzing the traffic with Wireshark, shows the authoritative server for
this domain is answering and nothing jumps to my eye which could be
wrong with the answer I see in the trace.
I guess _.drive.pro.io is a dummy query performed to get OPTIONS.
So my usual attempt is to disable all options that might cause issues:
$ dig +noedns +nocookie +nodnssec +noednsnegotiation A fd19g0409.drive.pro.io
@{BIND-9.18.4-NS}
Error persists. Any help appreciated in a pointer to the possible cause.
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
16 Oct
16 Oct
1 p.m.
Hello Benoît
On 14.10.2022 10:51, Benoît Panizzon wrote:
Maybe some of you has already come over that issue and
know how to fix.
Bind 9.18.4 fails to resolve the A record of: fd19g0409.drive.pro.io
Bind 9.11.36 works.
Both versions have DNSSEC Validation enabled and connected to a network
not restricting EDNS.
My systems are with bind 9.16 as a local resolver using the root
nameservers, I get this:
batman:~ # dig fd19g0409.drive.pro.io
;; communications error to ::1#53: timed out
;; communications error to ::1#53: timed out
; <<>> DiG 9.18.7 <<>> fd19g0409.drive.pro.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35861
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 2f7b02654b3c7d3c01000000634bd959127589388c126a1d (good)
;; QUESTION SECTION:
;fd19g0409.drive.pro.io. IN A
;; Query time: 113 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Sun Oct 16 12:13:45 CEST 2022
;; MSG SIZE rcvd: 79
batman:~ #
But on the other hand this works (takes a while):
batman:~ # host fd19g0409.drive.pro.io
fd19g0409.drive.pro.io has address 94.126.19.162
fd19g0409.drive.pro.io has IPv6 address 2a00:1128:0:19::162
batman:~ #
Bind Logs:
named[3156696]: end of file resolving '_.drive.pro.io/A/IN': 80.74.143.169#53
I get this (sorry for the long line wrapping):
Oct 16 08:28:48 batman named[63587]: client @0x80f11b758 ::1#40913
(fd19g0409.drive.pro.io): view internal: query failed (timed out) for
fd19g0409.drive.pro.io/IN/A at query.c:7375
[... two repeated lines remove ...]
Oct 16 12:13:45 batman named[63587]: client @0x80356e358 ::1#44995
(fd19g0409.drive.pro.io): view internal: query failed (timed out) for
fd19g0409.drive.pro.io/IN/A at query.c:7375
[... two repeated lines remove ...]
Lines from a second dig:
Oct 16 12:15:52 batman named[63587]: client @0x807c15d58 ::1#59382
(fd19g0409.drive.pro.io): view internal: query failed (timed out) for
fd19g0409.drive.pro.io/IN/A at query.c:7375
[... one repeated lines remove ...]
Oct 16 12:15:52 batman named[63587]: client @0x80f2c2958 ::1#40749
(fd19g0409.drive.pro.io): view internal: query failed (SERVFAIL) for
fd19g0409.drive.pro.io/IN/A at query.c:6656
As the 'host' tool was working with a unusual delay using the same
server, I did try this (default timeout is 5 seconds):
batman:~ # dig fd19g0409.drive.pro.io +timeout=30
; <<>> DiG 9.18.7 <<>> fd19g0409.drive.pro.io +timeout=30
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41879
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 6317be730627999801000000634bdf600b277eb7be8c0697 (good)
;; QUESTION SECTION:
;fd19g0409.drive.pro.io. IN A
;; Query time: 10009 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Sun Oct 16 12:39:28 CEST 2022
;; MSG SIZE rcvd: 79
batman:~ #
Same also with 60 seconds timeout. But now host also fails (took 33 and
on a second try 40 seconds):
batman:~ # host fd19g0409.drive.pro.io
;; connection timed out; no servers could be reached
batman:~ #
Other things work and the answer is instant.
I do not see this problem from some other locations where I use the
resolver of the ISP or hoster. The answer is instant.
But more strange things, which work fine and instant:
batman:~ # dig -t ns pro.io
; <<>> DiG 9.18.7 <<>> -t ns pro.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40826
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: d7ad19c9d61a7a8a01000000634be1c9e9ed83950b13cd10 (good)
;; QUESTION SECTION:
;pro.io. IN NS
;; ANSWER SECTION:
pro.io. 1430 IN NS p.dnh.net.
pro.io. 1430 IN NS ch.pro.io.
pro.io. 1430 IN NS nl.pro.io.
;; ADDITIONAL SECTION:
ch.pro.io. 1430 IN AAAA 2a00:1128:1:1::143:169
nl.pro.io. 1430 IN AAAA 2001:41d0:8:1c8d::
ch.pro.io. 42235 IN A 80.74.143.169
nl.pro.io. 42235 IN A 151.80.197.88
;; Query time: 106 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Sun Oct 16 12:49:45 CEST 2022
;; MSG SIZE rcvd: 208
batman:~ # dig fd19g0409.drive.pro.io @80.74.143.169
; <<>> DiG 9.18.7 <<>> fd19g0409.drive.pro.io @80.74.143.169
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5649
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;fd19g0409.drive.pro.io. IN A
;; ANSWER SECTION:
fd19g0409.drive.pro.io. 120 IN A 94.126.19.162
;; Query time: 2 msec
;; SERVER: 80.74.143.169#53(80.74.143.169) (UDP)
;; WHEN: Sun Oct 16 12:50:04 CEST 2022
;; MSG SIZE rcvd: 67
batman:~ # dig fd19g0409.drive.pro.io @2a00:1128:1:1::143:169
; <<>> DiG 9.18.7 <<>> fd19g0409.drive.pro.io
@2a00:1128:1:1::143:169
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7153
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;fd19g0409.drive.pro.io. IN A
;; ANSWER SECTION:
fd19g0409.drive.pro.io. 120 IN A 94.126.19.162
;; Query time: 2 msec
;; SERVER: 2a00:1128:1:1::143:169#53(2a00:1128:1:1::143:169) (UDP)
;; WHEN: Sun Oct 16 12:50:17 CEST 2022
;; MSG SIZE rcvd: 67
batman:~ #
So I think something is/was temporary ugly with this domain and your
bind 9.18 and my resolver have cached some wrong entries with a too
large TTL. Other resolver which already did resolve this before (or
after) may be able to answer.
Error persists. Any help appreciated in a pointer to
the possible cause.
May check the issue tracker for bind at:
https://gitlab.isc.org/isc-projects/bind9/-/issues/?search=end%20of%20file%…
or create an issue if non of the existing match or it does not resolves
in the next few days.
Best regards,
Fabian
4:59 p.m.
On 14.10.22 10:51, Benoît Panizzon wrote:
Bind 9.18.4 fails to resolve the A record of:
fd19g0409.drive.pro.io
May it be this issue?
https://gitlab.isc.org/isc-projects/bind9/-/issues/3474
Beat
17 Oct
17 Oct
9:49 a.m.
Hi Beat
May it be this issue?
https://gitlab.isc.org/isc-projects/bind9/-/issues/3474
Thank you and all who took the time investigating the issue.
I'm not so sure it's bound to that issue. But nevertheless I now opened
an issue myself. Let's see.
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
10:32 a.m.
I'm not so sure it's bound to that issue. But
nevertheless I now opened
an issue myself. Let's see.
That was quick. Analzed by Ondřej:
No, BIND 9 is not broken. The upstream servers are:
$ dig +norec A _.drive.pro.io @151.80.197.88
=> Timeout
then it retries the query over TCP:
$ dig +tcp +norec A _.drive.pro.io @151.80.197.88
=> End of File (that's what I found in the bind logs)
That is because the upstream server closes the TCP connection after
accepting.
"As a temporary workaround, you can disable QNAME minimization on the
server.
And kudos to the pro.io for breaking the DNS in a new innovative way..."
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
232
days inactive
235
days old
4 comments
4 participants
participants (4)
-
Beat Siegenthaler -
Benoit Panizzon -
Benoît Panizzon
-
Fabian Wenk