Bug 744 - NSD replies with REFUSED for configured but unloaded zone
NSD replies with REFUSED for configured but unloaded zone
Product: NSD
Classification: Unclassified
Component: NSD Code
All All
: P5 minor
Assigned To: NSD team
Depends on:
  Show dependency treegraph
Reported: 2016-02-28 12:42 CET by Anand Buddhdev
Modified: 2016-03-01 10:43 CET (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Anand Buddhdev 2016-02-28 12:42:54 CET
When NSD has loaded a zone that subsequently expires (because the master isn't responding), the zone transitions to the "expired" state, and NSD replies with SERVFAIL for that zone. Here's an example of such a zone on our server:

# nsd-control zonestatus cm
zone:   cm.
        state: expired
        served-serial: "2015080522 since 2015-08-12T20:14:35"
        commit-serial: "2015080522 since 2016-02-17T10:34:42"

However, we have another NSD instance, which is newly installed. On this new server, NSD has never been able to transfer the zone from the master, and so its internal state is different:

# nsd-control zonestatus cm
zone:   cm.
        state: refreshing
        served-serial: none
        commit-serial: none

This NSD instance replies with REFUSED when queried for the zone.

I think this inconsistent behaviour is wrong. REFUSED should be reserved for responses for a zone that NSD isn't configured with. However, if NSD is configured for zone, then NSD should reply with SERVFAIL, regardless of whether the zone was loaded at some point and then expired, or was simply never loaded. This distinction in responses is important, because it helps us identify the difference between "zone not configured" and "zone configured but failed". Our monitoring uses this distinction to alert us to different problems, and NSD's response is confusing.

In comparison, BIND and Knot do the right thing. I'd appreciate it if this corner case is also fixed for NSD.
Comment 1 Wouter Wijngaards 2016-03-01 10:43:26 CET
Hi Anand,

Fixed this bug, the lookup started too high up in the zonetree and missed the zone itself.  The logic was there to give the right rcode.

Thanks for the report!  Most people don't see the rcode if its a failure.

Best regards, Wouter