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