Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
net: NXDOMAIN replies from a non-recursive server produce "server misbehaving" errors instead of "no such host" #12778
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?
changed the title
NXDOMAIN replies from a non-recursive server produce "server misbehaving" errors instead of "no such host"
Sep 29, 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.
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
Will open a CL for this.
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