[dns] support TCP fall-back for very large DNS responses

[bboreham]

Per RFC1123 section 6.1.3.2

DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP

This could be necessary if a user of weave mapped lots of IP addresses to the same DNS name, or, more likely for a DNS request outside of the weave network which goes via fall-back to the host's DNS server.

[inercia]

Not sure if this is the best solution for large DNS responses. I think TCP support in DNS servers is only there for clients with limited connectivity, where UDP connection cannot get through a firewall. In fact, "bind" is configured by default for accepting just a few TCP connections (about 50). Should we look for an alternative solution?

[rade]

I think TCP support in DNS servers is only there for clients with limited connectivity, where UDP connection cannot get through a firewall.

I am far from an expert on the subject, but the RFC quoted above states that "If the Answer section of the response is truncated and if the requester supports TCP, it SHOULD try the query again using TCP." So the purpose of TCP connectivity is to deal with large responses. As per the subject of this issue. And, I believe @bboreham also confirmed this in experiments.

[inercia]

You are right, it seems that TCP is also used for long responses. Then I could try to implement this...

[bboreham]

Just to note a conversation with @rade where we felt, for fall-back, if the query came in to us over UDP we should always use UDP to the upstream DNS, and if it came in over TCP then always use TCP. If a UDP response came back truncated we should pass it on truncated to the caller. This way we will maintain the functionality required by the RFC without having to implement any complex logic.

[bboreham]

Also note that it would be very hard to generate a weave.local response that is too big for UDP, until we implement #338 and/or #226

[inercia]

@bboreham You are right when you say that it would be very difficult to generate such long responses until we solve those other issues. Anyway, it has served me for knowing more about the DNS code...

Regarding truncated responses coming from the upstream DNS server, I'm concerned about weaveDNS becoming a TCP proxy: if multiple clients ask about a long name that must be resolved with the upstream server, those clients would fallback to our TCP port, and then we should establish TCP connections to the upstream server. I'm not sure whether this is a good idea, I think DNS servers should not do this kind of thing. At least we should limit the number of outgoing TCP connections: otherwise a malicious client could DoS our server quite easily...

[bboreham]

I don't think we need to position this service as bulletproof, but if we do want to make it more resistant to attack there's a good article here on attacks and mitigations: https://developers.google.com/speed/public-dns/docs/security

[rade]

This was closed by #392.