Hi NSD developers and users, 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? Anand
Hi Anand,> 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, oneI 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?See appendix B.1 of doc/REQUIREMENTS. -Peter
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? 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. Kind regards, Lukas