New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: add EDNS0 support to builtin DNS stub resolver #6464

Open
mikioh opened this Issue Sep 23, 2013 · 8 comments

Comments

Projects
None yet
6 participants
@mikioh
Contributor

mikioh commented Sep 23, 2013

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

This comment has been minimized.

Contributor

rsc commented Sep 24, 2013

Comment 1:

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

This comment has been minimized.

Contributor

rsc commented Dec 4, 2013

Comment 2:

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

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 4, 2013

Comment 3:

Labels changed: added repo-main.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

@garrickp

This comment has been minimized.

garrickp commented Apr 30, 2015

+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

This comment has been minimized.

Member

bradfitz commented Apr 30, 2015

@mikioh

This comment has been minimized.

Contributor

mikioh commented Jun 5, 2015

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

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.

@mikioh mikioh changed the title from net: add EDNS0 support to built-in DNS resolver to net: add EDNS0 support to builtin DNS stub resolver Jun 5, 2015

@danp

This comment has been minimized.

Contributor

danp commented Nov 17, 2015

Related to #13279

@gopherbot

This comment has been minimized.

gopherbot commented Jun 29, 2017

CL https://golang.org/cl/47170 mentions this issue.

gopherbot pushed a commit to golang/net that referenced this issue Mar 30, 2018

Mikio Hara
dns/dnsmessage: add basic support for EDNS(0)
This change introduces OPTResourse type to support DNS messages
containing various extension options as defined in RFC 6891.
Parsing and building OPT pseudo records requires allocations like TXT
records.

Also adds DNSSECAllowed, ExtendedRCode and SetEDNS0 methods to
ResourceHeader for convenience.

Updates golang/go#6464.
Updates golang/go#16218.

Change-Id: Ib72cea277201e4122c6b5effa320084ff351c886
Reviewed-on: https://go-review.googlesource.com/47170
Reviewed-by: Ian Gudger <igudger@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment