Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange "bad rdata" #234

Closed
bortzmeyer opened this issue Jul 27, 2015 · 20 comments
Closed

Strange "bad rdata" #234

bortzmeyer opened this issue Jul 27, 2015 · 20 comments

Comments

@bortzmeyer
Copy link
Contributor

@bortzmeyer bortzmeyer commented Jul 27, 2015

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
Copy link
Owner

@miekg miekg commented Jul 27, 2015

[ 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
Copy link
Contributor Author

@bortzmeyer bortzmeyer commented Jul 27, 2015

@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
Copy link
Owner

@miekg miekg commented Jul 27, 2015

[ 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
Copy link
Contributor Author

@bortzmeyer bortzmeyer commented Jul 27, 2015

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

@miekg
Copy link
Owner

@miekg miekg commented Jul 27, 2015

[ 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
Copy link
Contributor Author

@bortzmeyer bortzmeyer commented Jul 27, 2015

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

@aabdnn
Copy link

@aabdnn aabdnn commented Jul 27, 2015

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
Copy link
Contributor Author

@bortzmeyer bortzmeyer commented Jul 27, 2015

@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
Copy link
Owner

@miekg miekg commented Jul 27, 2015

[ 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
Copy link
Contributor Author

@bortzmeyer bortzmeyer commented Jul 27, 2015

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

@miekg
Copy link
Owner

@miekg miekg commented Jul 27, 2015

[ 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 miekg closed this in c13d4ee Jul 27, 2015
@miekg
Copy link
Owner

@miekg miekg commented Jul 27, 2015

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

@bortzmeyer
Copy link
Contributor Author

@bortzmeyer bortzmeyer commented Jul 27, 2015

I confirm it works fine now, thanks.

@miekg
Copy link
Owner

@miekg miekg commented Jul 27, 2015

[ 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
Copy link
Contributor Author

@bortzmeyer bortzmeyer commented Jul 27, 2015

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

@miekg
Copy link
Owner

@miekg miekg commented Jul 27, 2015

[ 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
Copy link
Contributor Author

@bortzmeyer bortzmeyer commented Jul 27, 2015

@oerdnj
Copy link

@oerdnj oerdnj commented Jul 28, 2015

Thank you for debugging this and notifying us.

@miekg miekg mentioned this issue Aug 5, 2015
@miekg miekg reopened this Aug 5, 2015
@miekg
Copy link
Owner

@miekg miekg commented Aug 5, 2015

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

@miekg
Copy link
Owner

@miekg miekg commented Aug 5, 2015

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
@miekg miekg closed this Aug 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.