Strange "bad rdata" #234

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

Comments

Projects
None yet
4 participants
@bortzmeyer
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@miekg

miekg Jul 27, 2015

Owner

[ 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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@bortzmeyer

bortzmeyer Jul 27, 2015

Contributor

@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?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@miekg

miekg Jul 27, 2015

Owner

[ 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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@bortzmeyer

bortzmeyer Jul 27, 2015

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@miekg

miekg Jul 27, 2015

Owner

[ 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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@bortzmeyer

bortzmeyer Jul 27, 2015

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@aabdnn

aabdnn 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/

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

This comment has been minimized.

Show comment
Hide comment
@bortzmeyer

bortzmeyer Jul 27, 2015

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@miekg

miekg Jul 27, 2015

Owner

[ 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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@bortzmeyer

bortzmeyer Jul 27, 2015

Contributor

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

Contributor

bortzmeyer commented Jul 27, 2015

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

@miekg

This comment has been minimized.

Show comment
Hide comment
@miekg

miekg Jul 27, 2015

Owner

[ 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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@miekg

miekg Jul 27, 2015

Owner

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

Owner

miekg commented Jul 27, 2015

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

@bortzmeyer

This comment has been minimized.

Show comment
Hide comment
@bortzmeyer

bortzmeyer Jul 27, 2015

Contributor

I confirm it works fine now, thanks.

Contributor

bortzmeyer commented Jul 27, 2015

I confirm it works fine now, thanks.

@miekg

This comment has been minimized.

Show comment
Hide comment
@miekg

miekg Jul 27, 2015

Owner

[ 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 :)

Owner

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

This comment has been minimized.

Show comment
Hide comment
@bortzmeyer

bortzmeyer Jul 27, 2015

Contributor

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

Contributor

bortzmeyer commented Jul 27, 2015

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

@miekg

This comment has been minimized.

Show comment
Hide comment
@miekg

miekg Jul 27, 2015

Owner

[ 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.. :)

Owner

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

This comment has been minimized.

Show comment
Hide comment
@oerdnj

This comment has been minimized.

Show comment
Hide comment
@oerdnj

oerdnj Jul 28, 2015

Thank you for debugging this and notifying us.

oerdnj commented Jul 28, 2015

Thank you for debugging this and notifying us.

@miekg miekg referenced this issue Aug 5, 2015

Merged

Fuzz rampage! #237

@miekg miekg reopened this Aug 5, 2015

@miekg

This comment has been minimized.

Show comment
Hide comment
@miekg

miekg Aug 5, 2015

Owner

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

Owner

miekg commented Aug 5, 2015

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

@miekg

This comment has been minimized.

Show comment
Hide comment
@miekg

miekg Aug 5, 2015

Owner

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
Owner

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