net: add EDNS0 support to builtin DNS stub resolver

[mikioh]

issue #6336 unveiled that we need minimum DNS transport support in build-in DNS resolver
for when we cannot rely on underlying stuff such as libc. For now, looks like EDNS0 is
the only missing piece.

[rsc]

Comment 1:

Why? What current C calls are we making that take advantage of EDNS0?

[rsc]

Comment 2:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 3:

Labels changed: added repo-main.

[garrickp]

+1

Ran into this while debugging a problem with pulling Docker images: we were unable to pull an image due to a DNS resolution error. It turns out our router was forwarding up to 4k DNS responses regardless of the state of the EDNS0 flag, and the Go DNS package was (correctly to the spec) choking on the larger than expected message. The ultimate fix was for the router itself, setting the window to back down to the RFC correct 512 byte size.

Again, this is not a bug with the Go implementation of DNS, but considering how broadly used EDNS0 is for avoiding a fallback to TCP for large DNS responses (which are more and more common), it might be worth implementing the EDNS0 DNS extension if only for that feature.

[bradfitz]

/cc @mikioh @mdempsky

[mikioh]

I still hesitate to say "yup, that's the way to go" because we are already not innocent.

• https://lists.dns-oarc.net/pipermail/dns-operations/2013-September/010704.html
• http://www.ietf.org/proceedings/87/slides/slides-87-saag-3.pdf
• http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf

I also understand that EDNS0 would be pretty useful under the well-configured, managed and secured environment. In addition, DNS stub resolver perhaps might avoid being affected by various attacks based on UDP over IP fragmentation. I mean, with DNSSEC it sounds pretty reasonable, but in other cases... still thinking.