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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
