resolver: Compress all DNS answers

[tsenart]

This patch makes mesos-dns compress all DNS answers. This improves
performance of many DNS questions which, when compressed, fit in 512
bytes. See https://tools.ietf.org/html/rfc1035#section-4.2.1

Fixes #170 because the native Go DNS resolver which is enabled when
statically compiling doesn't fallback to TCP when failing to decode
a UDP response larger than 512 bytes.

It isn't a perfect solution since an answer might be larger than 512
bytes even after compression but that's an issue with the client
resolver.

[tsenart]

Fixes #170.

[jdef]

My first inclination was to request that you file a miekg/dns issue (or perhaps a PR) to properly set the "truncated" flag on UDP responses (and only on UDP responses) that are greater than 512 bytes in length. From the spec:

Messages carried by UDP are restricted to 512 bytes (not counting the IP
or UDP headers). Longer messages are truncated and the TC bit is set in the header.

In the miekg/dns code the length is not checked and the message is returned as-is:

• https://github.com/miekg/dns/blob/bb1103f648f811d2018d4bedcb2d4b2bce34a0f1/msg.go#L1621

However it looks like he's rejected the idea of fixing this problem in the lib. So we might want to do the ugly thing suggested here for clients that don't advertise large enough payload size - they'd probably want the TC bit set if information was missing:

• server.go's WriteMsg doesn't account for message size miekg/dns#162 (comment)

And we probably want to allow payloads > 512 without setting the TC bit in some circumstances:

• https://tools.ietf.org/html/rfc6891#page-7
• https://tools.ietf.org/html/rfc6891#page-11

So I think our approach to resolving the problem more broadly needs a little more work. Thoughts?

[tsenart]

@jdef: The pure Go stdlib DNS implementation doesn't implement RFC6891. It also doesn't fallback correctly to TCP even if the TC bit is set in a UDP reply. What we can do on our side to fix #170 is to compress the responses in a best effort policy. For protocol compliance I'll add the code to also set the TC bit.

Now, if we want to support RFC6891 on our side, I think we should open a separate issue for that and wait for miekg/dns#223 to be implemented.

[jdef]

Sounds like a plan. Let's stop the bleeding with best effort compress and
set TC bit (if the compressed size > 512). And then file a separate issue
to track the miekg/dns issue.

On Thu, Jun 18, 2015 at 10:42 AM, Tomás Senart [email protected]
wrote:

Reopened #173 #173.

—
Reply to this email directly or view it on GitHub
#173 (comment).

[tsenart]

PTAL

[jdef]

would like to see some TODO comments here describing the pain point and the potential problems that a user will see until we resolve this properly. Perhaps even a reference to tickets 173 and 174.

[jdef]

minor doc nit, otherwise lgtm

[jameshartig]

Just an update to this since I'm running into this as well:

It also doesn't fallback correctly to TCP even if the TC bit is set in a UDP reply
It does support falling back to TCP if the TC bit is set: https://github.com/golang/go/blob/master/src/net/dnsclient_unix.go#L153

But you have to send back a response of < 512 in order to get to that check. There still hasn't been any traction yet on miekg/dns#223 but you can try and just use the Fit method from skydns: https://github.com/skynetservices/skydns/blob/master/server/msg.go in addition to setting the TC flag.