I've noticed a difference in response behaviour between NSD, and Knot
and BIND, for queries for zones not configured.
If I query either BIND or Knot for a zone that is not configured at all,
they give me REFUSED. However, if they are configured for a zone, but it
has not loaded for some reason (failure to parse, expired, etc), then
they give me SERVFAIL for that zone.
On the other hand, NSD gives me SERVFAIL for a zone that is not even
configured. It also gives SERVFAIL if the zone did not load properly.
To me, BIND and Knot's responses seem more logical. They distinguish
between the cases where a zone has simply not been configured, versus
the case where the zone has gone bad for some reason. With NSD, one
can't tell. Is there a reason NSD returns SERVFAIL for unconfigured zones?
To me, BIND and Knot's responses seem more logical. They distinguish
between the cases where a zone has simply not been configured, versus
the case where the zone has gone bad for some reason. With NSD, one
I agree and I'd also like to see REFUSED for queries into deliberately not
served space, at least as a compile time option, or as a config parameter.
can't tell. Is there a reason NSD returns SERVFAIL for unconfigured zones?
To me, BIND and Knot's responses seem more logical. They distinguish
between the cases where a zone has simply not been configured, versus
the case where the zone has gone bad for some reason. With NSD, one
can't tell. Is there a reason NSD returns SERVFAIL for unconfigured zones?
How do resolvers react to SERVFAIL versus REFUSED, is there a
difference in behaviour? Intuitively I would assume that upon
SERVFAIL a resolver would retry with another authoritative
nameserver for the zone in question, with REFUSED I'm not
so sure, do resolvers give up immediately or retry as well?
If resolvers give up immediately with REFUSED, then NSD's
behaviour would actually be very sensible. Imagine a scenario
where zone deployment to authoritative nameservers went awry,
e.g. one nameserver wasn't reachable when a new zone was deployed.
I'd much rather answer with SERVFAIL in such a scenario,
directing resolvers to the other authoritative nameservers.
Tried to look up in RFC 1035 how resolvers behave upon REFUSED
but I find the language in section 7.2 to be somewhat ambiguous:
- If a resolver gets a server error or other bizarre response
from a name server, it should remove it from SLIST, and may
wish to schedule an immediate transmission to the next
candidate server address.
[ Quoting <lukas@wunner.de> in "Re: [nsd-users] REFUSED vs SERVFAIL..." ]
Hi,
> To me, BIND and Knot's responses seem more logical. They distinguish
> between the cases where a zone has simply not been configured, versus
> the case where the zone has gone bad for some reason. With NSD, one
> can't tell. Is there a reason NSD returns SERVFAIL for unconfigured zones?
How do resolvers react to SERVFAIL versus REFUSED, is there a
difference in behaviour? Intuitively I would assume that upon
SERVFAIL a resolver would retry with another authoritative
nameserver for the zone in question, with REFUSED I'm not
so sure, do resolvers give up immediately or retry as well?
I think this difference is mostly important for monitoring tools.
Miek is right. As far as I know, well-written resolvers treat REFUSED
and SERVFAIL the same way, ie. they move on to another servers for the zone.
But monitoring tools get confused. Since we have so many zones
configured on our systems, we have scripts that query our name servers
for all the zones, and look at the response code to figure out what has
happened to a zone (did it fail to get provisioned, or has it expired?)
So the distinction of REFUSED vs SERVFAIL is important to us.
How do resolvers react to SERVFAIL versus REFUSED, is there a
difference in behaviour? Intuitively I would assume that upon
SERVFAIL a resolver would retry with another authoritative
nameserver for the zone in question, with REFUSED I'm not so
sure, do resolvers give up immediately or retry as well?
I think this difference is mostly important for monitoring
tools.
Miek is right. As far as I know, well-written resolvers treat
REFUSED and SERVFAIL the same way, ie. they move on to another
servers for the zone.
But monitoring tools get confused. Since we have so many zones
configured on our systems, we have scripts that query our name
servers for all the zones, and look at the response code to figure
out what has happened to a zone (did it fail to get provisioned, or
has it expired?) So the distinction of REFUSED vs SERVFAIL is
important to us.
Out analysis at NLnet Labs agrees, we'll implement REFUSED for
out-of-zone queries. (in future releases). The major implementations
behaving the same on the wire is good. We think for monitoring it may
be useful. We think for resolvers it makes little to no difference
(for unbound there is no difference, it becomes SERVFAIL to unbound's
clients if only out-of-zone servers exist).