Skip to content
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: NXDOMAIN replies from a non-recursive server produce "server misbehaving" errors instead of "no such host" #12778

gplalonde opened this issue Sep 28, 2015 · 6 comments


Copy link

@gplalonde gplalonde commented Sep 28, 2015


if dns.rcode == dnsRcodeNameError && dns.recursion_available {

it looks like any NXDOMAIN reply where the server doesn't allow recursive queries is treated as "server misbehaving". I would expect this to be treated like any other case where the name doesn't exist and get a "no such host" error instead.

Any reason why we have the "&& dns.recursion_available" part of the condition?

@ianlancetaylor ianlancetaylor changed the title NXDOMAIN replies from a non-recursive server produce "server misbehaving" errors instead of "no such host" net: NXDOMAIN replies from a non-recursive server produce "server misbehaving" errors instead of "no such host" Sep 29, 2015
@ianlancetaylor ianlancetaylor added this to the Go1.6 milestone Sep 29, 2015
Copy link

@danp danp commented Nov 12, 2015

Is there agreement that the check should be removed?

In looking for prior art I found a similar check in glibc but it takes additional things into account (answer count == 0, no AA bit, additional record count == 0) before deciding to try another server, if my reading and interpretation are correct.

For maximum strictness the check makes sense: the Go stub resolver expects to talk to a recursor. If the server replied claiming a name doesn't exist but at the same time says recursion is not available maybe that is an issue. But if other stub implementations, such as glibc, don't care about that as much then maybe Go's shouldn't either.

Copy link

@ianlancetaylor ianlancetaylor commented Nov 12, 2015

I think there is agreement that something should be done. I don't know enough about the issue to know if simply removing that check is the right thing to do.

In the absence of more clever analysis emulating glibc sounds like a good way to go.

Copy link

@danp danp commented Nov 16, 2015

My reading and interpretation were a bit off!

The check I linked is for a different condition (rcode == NOERROR, mainly) and is used to signal a change to the next nameserver when trying a name. I believe in the current Go implementation the returning of this error when a response contains no useful answers does the same thing. I haven't found anywhere else in glibc where the RA bit factors in when deciding whether to accept an answer or not.

In addition to the one linked for this issue there is also this check that considers the RA bit. I think at least that part of the greater condition could be removed, if not reducing it to just if err == nil as it seems to duplicate checks that answer does already.

Will open a CL for this.

Copy link

@gopherbot gopherbot commented Nov 16, 2015

CL mentions this issue.

Copy link

@mdempsky mdempsky commented Nov 16, 2015

For what it's worth, djbdns's stub resolver also ignores whether the server sets RA when answering an RD query.

Copy link

@danp danp commented Nov 16, 2015

I have been meaning to check, thanks. At some point I think it would be good to dig for other behavior changes/improvements we could borrow from stub resolvers in the various libc's and djbdns. djbdns' reloading of resolv.conf after N requests (in addition to after N seconds which Go's does now), for example.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.