Problem with an unsigned private subzone of a signed public zone

[Chris Thompson]

We have a forward zone (private.cam.ac.uk) and reverse zones (e.g.
16.172.in-addr.arpa) for a subset of RFC1918 addresses that are
routed throughout, but not outside, the university network. Access
to these zones is restricted to that network, as the results would
not be meaningful elsewhere.

The public zone cam.ac.uk does *not* contain a delegation for
private.cam.ac.uk. The original justification for this, I think,
was along the lines of "well, 172.in-addr.arpa obviously can't
have a delegation to our 16.172.in-addr.arpa, so we shouldn't
have one for the corresponding forward zone either".

Nowadays, cam.ac.uk is signed but private.cam.ac.uk is not. This
doesn't create any problems for recursive nameservers that slave
them, or forward all requests to servers that do. But there is
one setup which fails: a recursive nameserver that accesses the
private zones via stubs

zone "private.cam.ac.uk" {
        type stub; file "stub/private.cam.ac.uk";
        masters { 131.111.12.37; 131.111.8.37; }; };
zone "16.172.in-addr.arpa" {
        type stub; file "stub/16.172.in-addr.arpa";
        masters { 131.111.12.37; 131.111.8.37; }; };
[etc.]

and also have DNSSEC validation turned on (via dlv.isc.org, but I
don't think that matters - the point is that the parent zones are
in the chain of trust).

Then queries about private.cam.ac.uk give SERVFAIL (unless +cd
is used, so its definitely a validation failure) but to my surprise
ones for 16.172.in-addr.arpa do not. That's although 172.in-addr.arpa
is just as much trusted (via the ARIN trust anchors imported into
dlv.isc.org) as cam.ac.uk is.

I think the reason is that although 172.in-addr.arpa does not,
of course, contain a delegation to *our* 16.172.in-addr.arpa, it
does contain one to blackhole-{1,2}.iana.org, and of course this
is not signed. So BIND has a proof of non-existence of the DS
record for 16.172.in-addr.arpa.

Of course, it could also prove there is no DS record for
private.cam.ac.uk, but the absence of NS records as well
apparently makes it think that private.cam.ac.uk is bogus.

Have others encountered problems like this, and if so what have
they done about it? Should I just give in and put a delegation
to private.cam.ac.uk in the parent zone, even though external
clients will get REFUSED is they try to follow it?

-- 
Chris Thompson
Email: cet1 at cam.ac.uk