Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problem with an unsigned private subzone of a signed public zone

5 views
Skip to first unread message

Chris Thompson

unread,
Apr 19, 2010, 8:02:34 AM4/19/10
to Bind Users Mailing List
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: ce...@cam.ac.uk

Mark Andrews

unread,
Apr 19, 2010, 10:06:35 AM4/19/10
to ce...@cam.ac.uk, Bind Users Mailing List

Just sign the private zone and distribute trust anchors for
it.



> --
> Chris Thompson
> Email: ce...@cam.ac.uk
>

> _______________________________________________
> bind-users mailing list
> bind-...@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

Chris Thompson

unread,
Apr 19, 2010, 3:40:52 PM4/19/10
to Chris Thompson, Bind Users Mailing List
On Apr 19 2010, I wrote:

[...]


>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.

More experiments indicate that something changed between
9.6.1-P3 and 9.6.2rc1 - previously the "type stub" setup
worked OK without a delegation in the signed parent.

Tony Finch

unread,
Apr 19, 2010, 5:35:18 PM4/19/10
to ce...@cam.ac.uk, Bind Users Mailing List

On 19 Apr 2010, at 20:40, Chris Thompson <ce...@cam.ac.uk> wrote:

> On Apr 19 2010, I wrote:
>
> [...]
>> 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.
>
> More experiments indicate that something changed between
> 9.6.1-P3 and 9.6.2rc1 - previously the "type stub" setup
> worked OK without a delegation in the signed parent.

This change has broken a configuration that I was on the verge of
deploying :-(

Tony (on his iPod).
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/

0 new messages