nsd users - Jan 2014 - NSD 4.0.1: referral from parent instead of SERVFAIL

I have another observation about NSD4. I don't think this is new, but
I'm bringing it up again to stir discussion.

On our DNS cluster (which currently consists of one BIND, one Knot and
one NSD4 server), I have the following 2 zones configured:

109.in-addr.arpa
14.109.in-addr.arpa

The zone 14.109.in-addr.arpa has expired, because the master is not
providing us with an AXFR. If I query BIND/Knot, they both give me a
SERVFAIL response, which is what I expect:

; <<>> DiG 9.9.4-P2 <<>> +norec soa 14.109.in-addr.arpa
@ns1.ams.authdns.ripe.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52002
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;14.109.in-addr.arpa.		IN	SOA



However, NSD gives me a referral response (without the AA bit), as follows:

; <<>> DiG 9.9.4-P2 <<>> +norec soa 14.109.in-addr.arpa
@ns3.ams.authdns.ripe.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15286
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;14.109.in-addr.arpa.		IN	SOA

;; AUTHORITY SECTION:
14.109.in-addr.arpa.	172800	IN	NS	ns.ripe.net.
14.109.in-addr.arpa.	172800	IN	NS	nsrev00.dns.sfr.net.
14.109.in-addr.arpa.	172800	IN	NS	nsrev01.dns.sfr.net.

Why doesn't NSD do a closest match and return SERVFAIL?

On Tue, Jan 28, 2014 at 05:30:25PM +0100, Anand Buddhdev wrote:
> ;; AUTHORITY SECTION:
> 14.109.in-addr.arpa.	172800	IN	NS	ns.ripe.net.
> 14.109.in-addr.arpa.	172800	IN	NS	nsrev00.dns.sfr.net.
> 14.109.in-addr.arpa.	172800	IN	NS	nsrev01.dns.sfr.net.
> 
> Why doesn't NSD do a closest match and return SERVFAIL?
in this case, ns.ripe.net does not know about the zone, but the
other two servers respond authoritatively.  That means a resolver
starting at "ns.ripe.net" can recover only by using another one
of 109.in-addr.arpa's servers, whereas the NSD behaviour would
make possible a recovery one level below.  Not saying it is _the_
way to go, but it makes a lot of sense to me.  And then there's DNSSEC,
suggesting to be extra careful with child/grandchild zone interaction.

-Peter