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?

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

Hi Anand, Peter,

;; 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?

It does a code-particularity, and this is why it attempts to return
this data. In a different expired case it might have given servfail.

It has now been fixed to behave like Bind, Knot: it returns SERVFAIL,
even if there is a parent zone.

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.

Yes, it could be useful, but would take different action to make that
work all of the time. I can certainly implement it, the question is
what is right. Right now, I'll do what the other two do for
compatibility.

Best regards,
   Wouter