Strange "bad rdata"

[bortzmeyer]

When querying the name server yeti-dns01.dnsworkshop.org / 2001:1608:10:167:32e::53 for "SOA ." (it is part of the Yeti root testbed), Exchange() returns a "bad rdata" error. dig, drill and kdig see nothing abnormal. Using Wireshark on the pcap, I did not find a problem either. Bug in the dns package?

Here is a test with q (in exdns):

% ./q @2001:1608:10:167:32e::53 SOA .    
;; dns: bad rdata

[miekg]

[ Quoting notifications@github.com in "[dns] Strange "bad rdata" (#234)..." ]

When querying the name server yeti-dns01.dnsworkshop.org / 2001:1608:10:167:32e::53 for "SOA ." (it is part of the Yeti root testbed), Exchange() returns a "bad rdata" error. dig, drill and kdig see nothing abnormal. Using Wireshark on the pcap, I did not find a problem either. Bug in the dns package?

Here is a test with q (in exdns):

% ./q @2001:1608:10:167:32e::53 SOA .
;; dns: bad rdata

Yep, interesting.

/Miek

Miek Gieben

[bortzmeyer]

@miekg Isn't it? Reading the source code, it seems "bad rdata" can be sent only for compression errors (which explain why I see nothing, I'm dumb when it comes to DNS compression) but why no other program; complain?

[miekg]

[ Quoting notifications@github.com in "Re: [dns] Strange "bad rdata" (#234..." ]

@miekg Isn't it? Reading the source code, it seems "bad rdata" can be sent only for compression errors (which explain why I see nothing, I'm dumb when it comes to DNS compression) but why no other program; complain?

On of the 2 bit labels in one of the name is not valid: it will make the error
more explicit (or even ignore this?).

/Miek

Miek Gieben

[bortzmeyer]

I can also report to the people who manage the server if you tell me which name is incorrect.

[miekg]

[ Quoting notifications@github.com in "Re: [dns] Strange "bad rdata" (#234..." ]

I can also report to the people who manage the server if you tell me which name is incorrect.

Can you attached the pcap to this bug? Something, somewhere is weird, but I have
to see for myself.

My code seems to go off the rails early in the packet:

% ./q @2001:1608:10:167:32e::53 SOA .
;; dns: bad bitlabel 0x80 in name Q. at offset 27

/Miek

Miek Gieben

[bortzmeyer]

@miekg Apparently no, I cannot "Unfortunately, we don’t support that file type. Try again with a PNG, GIF, JPG. "

[aabdnn]

Just a different data point. If I run this same query, capture the packet trace with tcpdump, and feed it to "dnsrend", dnsrend manages to dissect the reply without barfing.

http://romana.now.ie/dnsrend/

[bortzmeyer]

@aabdnn By the way, the problem seems related to Knot (only happens with Knot name servers) but only 2.0 (k-root, which uses Knot 1.6, does not show the issue).

[miekg]

[ Quoting notifications@github.com in "[dns] Strange "bad rdata" (#234)..." ]

When querying the name server yeti-dns01.dnsworkshop.org / 2001:1608:10:167:32e::53 for "SOA ." (it is part of the Yeti root testbed), Exchange() returns a "bad rdata" error. dig, drill and kdig see nothing abnormal. Using Wireshark on the pcap, I did not find a problem either. Bug in the dns package?

Here is a test with q (in exdns):

% ./q @2001:1608:10:167:32e::53 SOA .
;; dns: bad rdata

Looking at the pcap you send privately I see:

• the root name is encoded is c0 0c, which is a compression pointer. For the
  label mind you! :)

Anyway I don't seem to deal well with those.

/Miek

Miek Gieben

[bortzmeyer]

@miekg Compressing . (a zero-length label) is a good idea :-)

[miekg]

[ Quoting notifications@github.com in "Re: [dns] Strange "bad rdata" (#234..." ]

@miekg Compressing . (a zero-length label) is a good idea :-)

Yeah, it seems to point to a strange place, offset = 12, which is 00 by
accident, but I would not call this a pointer to a label...

/Miek

Miek Gieben

[miekg]

offset = 12 btw, which is legit. It points to the root label of the question section.

[bortzmeyer]

I confirm it works fine now, thanks.

[miekg]

[ Quoting notifications@github.com in "Re: [dns] Strange "bad rdata" (#234..." ]

I confirm it works fine now, thanks.

cool and thanks for reporting. This was a fun one.
Still Knot should not do this :)

[bortzmeyer]

@miekg Did you make a formal bug report or do you prefer me to handle it?

[miekg]

[ Quoting notifications@github.com in "Re: [dns] Strange "bad rdata" (#234..." ]

@miekg Did you make a formal bug report or do you prefer me to handle it?

If you can handle it, yes please. Don't have enough time for this.. :)

[bortzmeyer]

@miekg Done in https://gitlab.labs.nic.cz/labs/knot/issues/398

[oerdnj]

Thank you for debugging this and notifying us.

[miekg]

Might have returned since latest pull to fix a boatload of issues - need to double check.

[miekg]

Still works OK

 ./q @2001:1608:10:167:32e::53 SOA .
;; opcode: QUERY, status: NOERROR, id: 28819
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 11, ADDITIONAL: 3

;; QUESTION SECTION:
;.  IN   SOA

;; ANSWER SECTION:
.   86400   IN  SOA bii.dns-lab.net. yeti.biigroup.cn. 2015080401 1800 900 604800 86400

;; AUTHORITY SECTION:
.   518400  IN  NS  bii.dns-lab.net.
.   518400  IN  NS  yeti.bofh.priv.at.
.   518400  IN  NS  yeti.ipv6.ernet.in.
.   518400  IN  NS  dahu1.yeti.eu.org.
.   518400  IN  NS  ns-yeti.bondis.org.
.   518400  IN  NS  yeti-ns.ix.ru.
.   518400  IN  NS  yeti-ns.tisf.net.
.   518400  IN  NS  yeti-ns.wide.ad.jp.
.   518400  IN  NS  yeti-ns.conit.co.
.   518400  IN  NS  yeti-ns.as59715.net.
.   518400  IN  NS  yeti-dns01.dnsworkshop.org.

;; ADDITIONAL SECTION:
bii.dns-lab.net.    518400  IN  AAAA    240c:f:1:22::6
yeti.bofh.priv.at.  518400  IN  AAAA    2a01:4f8:161:6106:1::10
yeti.ipv6.ernet.in. 518400  IN  AAAA    2001:e30:1c1e:1::333

;; query time: 18110 µs, server: [2001:1608:10:167:32e::53]:53(udp), size: 566 bytes