Problem with an unsigned private subzone of a signed public zone

[Mark Andrews]

In message <Prayer.1.3.2.1004191302340.18726 at hermes-2.csi.cam.ac.uk>, Chris Thompson writes:
> 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?

Just sign the private zone and distribute trust anchors for
it.
 
> -- 
> Chris Thompson
> Email: cet1 at cam.ac.uk
> 
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org