In message <prayer.1.3.2.1004191302340.18...@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: c...@cam.ac.uk
>
> _______________________________________________
> bind-users mailing list
> bind-users@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: ma...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
