Getting "dns: overflow unpacking uint32" about dns HOT 20 CLOSED

This appears to have something to do with the number of responses I send as well. If I send fewer records, the issue goes away.

from dns.

[ Quoting [email protected] in "[dns] Getting "dns: overflow unpack..." ]

I'm getting an error decoding a response with the client "dns: overflow unpacking uint32". The response is being generated with the same library, and contains a combination of SRV and A records. Nothing crazy as far as I can tell. Below is the binary buffer after packing that is being sent:

Can send some code? Or a test?

A did some work on msg.Len() this week, to make it fit better, but this might
have led to a buffer that is too small.

grtz Miek

from dns.

[ Quoting [email protected] in "[dns] Getting "dns: overflow unpack..." ]

I'm getting an error decoding a response with the client "dns: overflow unpacking uint32". The response is being generated with the same library, and contains a combination of SRV and A records. Nothing crazy as far as I can tell. Below is the binary buffer after packing that is being sent:

Haven't decoded the buffer you sent, but is Compress true?

Grtz Miek

from dns.

Here is a minimal test case: https://gist.github.com/armon/9008541

If MAXREC is 3, then it works. Setting it to numbers above 3 causes different errors.

from dns.

I don't explicitly enable Compress, not sure if it defaults to true

from dns.

[ Quoting [email protected] in "Re: [dns] Getting "dns: overflow un..." ]

Here is a minimal test case: https://gist.github.com/armon/9008541

If MAXREC is 3, then it works. Setting it to numbers above 3 causes different errors.

Yeah, then it runs out of its buffer. Btw, can you pull the lastest master I
reverted some commits I wasn't too happy with.

I'll checkout your gist.

grtz Miek

from dns.

[ Quoting [email protected] in "Re: [dns] Getting "dns: overflow un..." ]

I don't explicitly enable Compress, not sure if it defaults to true

No default is false.

grtz Miek

from dns.

I tried latest master with the reverts now. Still breaks if MAXRECS is 4 or 5, but 6 is somehow okay.

from dns.

[ Quoting [email protected] in "Re: [dns] Getting "dns: overflow un..." ]

I tried latest master with the reverts now. Still breaks if MAXRECS is 4 or 5, but 6 is somehow okay.

Yeah, I'm checking your code. Don't know yet where the mistake is...

grtz Miek

from dns.

It would be great if we could add this sample as a regression test as well to guard against future changes

from dns.

[ Quoting [email protected] in "Re: [dns] Getting "dns: overflow un..." ]

I tried latest master with the reverts now. Still breaks if MAXRECS is 4 or 5, but 6 is somehow okay.

Ok, I've added this to the tests but I'm not sure if its worth adding, albeit I
might return more descriptive errors.

You're returning more than 512 bytes in an udp message, that breaks your client. It
might be worth to allow a client to set this directly instead of using EDNS0.

If you use "tcp" for the client and server it "just" works.

Pondering what to change and what to fix.

1. error reporting can be better, adding this
2. client UDPSize might be worthwhile to add
3. ... ?

grtz Miek

from dns.

[ Quoting [email protected] in "[dns] Getting "dns: overflow unpack..." ]

I'm getting an error decoding a response with the client "dns: overflow unpacking uint32". The response is being generated with the same library, and contains a combination of SRV and A records. Nothing crazy as far as I can tell. Below is the binary buffer after packing that is being sent:

Basically you have written an evil server :)

Miek Gieben

from dns.

Is there a reason the client does not attempt to receive a 64K packet? Even with standard MTU, 1500 bytes should be okay

from dns.

I restrict the number of responses, but I thought up to 1500 bytes would've worked fine (unless there is something more subtle about DNS I'm missing)

from dns.

Or even better, the client could at least return a useful message about truncation which makes it clear what the issue is

from dns.

[ Quoting [email protected] in "Re: [dns] Getting "dns: overflow un..." ]

I restrict the number of responses, but I thought up to 1500 bytes would've worked fine (unless there is something more subtle about DNS I'm missing)

Uh, yeah :) DNS is from 1983 and then 512 was considered big, so the default
limit is still 512, unless you use something like EDNS0 which allows larger
sizes. On the internet 4096 bytes is usually in use.

Your other options is "tcp".

Miek Gieben

from dns.

[ Quoting [email protected] in "Re: [dns] Getting "dns: overflow un..." ]

Or even better, the client could at least return a useful message about truncation which makes it clear what the issue is

Yes, adding that now, because this also send me on a wild goose chase.

Miek Gieben

from dns.

Thanks! Sorry about the false positive.

from dns.

[ Quoting [email protected] in "Re: [dns] Getting "dns: overflow un..." ]

Thanks! Sorry about the false positive.

no worries! A difficult to use library is not a good library, so thanks for
your report.

Miek Gieben

from dns.

[ Quoting [email protected] in "Re: [dns] Getting "dns: overflow un..." ]

Or even better, the client could at least return a useful message about truncation which makes it clear what the issue is

There is one snag with this... with udp I don't now there is more data to come.
So... I can work around this, but it becomes ugly and I don't think it is worth
adding it.

I will keep the new test case. Thanks for that.

grtz Miek

from dns.