DNSSEC and child zones on same authoritative NS. Expert help needed.

Gary Wallis wgg1970 at gmail.com
Tue Mar 16 01:40:13 UTC 2010


Let's say I have this setup :

BIND 9.4 named.conf includes a master.zones file with the following:

...
         zone "ns1.yourdomain.com" {
                 type master;
                 file "master/external/n/ns1.yourdomain.com.signed";
         };

         zone "ns2.yourdomain.com" {
                 type master;
                 file "master/external/n/ns2.yourdomain.com.signed";
         };

         zone "yourdomain.com" {
                 type master;
                 file "master/external/y/yourdomain.com.signed";
         };
...

More background for question below:

The yourdomain.com is I gather the zone APEX for all featured zones 
above. (Is this the correct use of the term APEX?)

I am learning via trial and error about transitioning from DNS to DNSSEC 
and we have these child zones (is ns1.yourdomain.com really a child 
zone, as regards the setup above?) that currently have precedence over 
the parent zone yourdomain.com for conflicting A records. For example:

If

ns1 A 123.123.123.123

is placed in yourdomain.com zone.

And a similar RR is placed in ns1.yourdomain.com zone, like:

ns1 IN A 10.0.0.1

And named reloaded.

dig @localhost ns1.yourdomain.com A +short

will return 10.0.0.1, the parent A RR is ignored.

Questions:

If I sign these three zones with their own KSK and ZSK pairs will DNSSEC 
be broken? Or will it work as above?

Would the chain of trust be broken, unless we provide the external 
parent (in this example case .com TLD ) with all public keys? (Or the 
keys wrapped in a single key?)

Is this a case where we would use DS RRs or some similar scheme in the 
apex zone?

Or should we just not allow child zones at all on our authoritative NS? 
That of course would make this mess (and my confusion about it) go away.

But it would be great to hear from a BIND expert about this. And please 
correct my probable confusion and incorrect use of DNSSEC jargon.

Best regards,
Gary




More information about the bind-users mailing list