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

Closed
gplalonde opened this issue Sep 28, 2015 · 6 comments

Comments

Projects
None yet
5 participants
@gplalonde
Copy link

commented Sep 28, 2015

From:

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

@danp

This comment has been minimized.

Copy link
Contributor

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.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

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.

@danp

This comment has been minimized.

Copy link
Contributor

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.

@gopherbot

This comment has been minimized.

Copy link

commented Nov 16, 2015

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

@mdempsky

This comment has been minimized.

Copy link
Member

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.

@danp

This comment has been minimized.

Copy link
Contributor

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.
You can’t perform that action at this time.