[dnssec-deployment] dot MUSEUM implemented DNSSEC
mcr at sandelman.ottawa.on.ca
Mon Sep 22 13:23:53 EDT 2008
>>>>> "Andrew" == Andrew Sullivan <ajs at commandprompt.com> writes:
>> True, but the failure normal scenario is that you get a lame
>> delegation. You then have, as Olaf explains, as many bullets in
>> your canon as you have NS records. As long as one "works", the
>> client will get data back.
Andrew> This is true, but you can do something similar with key
Andrew> records. There's nothing that says you can't have more than
Andrew> one DS in the parent, corresponding to more than one key in
Andrew> the child. And the RFCs as currently written require every
Andrew> one to be tried until one succeeds or they're all used up.
Having multiple DS records pointing at different KSKs that point at
different ZSKs that have different DNSSIG records, is very much akin to
having multiple NS records pointing at two servers that each think they
are a master.
(Some people do this, I'm told. I imagine most TLDs would populate
each server directly from a database rather than making them
And clients have to be able to cope with these two "views" as that may
well happen during key rollover. However, the difference is that when
you do key rollover, we make sure that the new DNSSIG/etc. are in place
first, otherwise, the client that asks different servers gets different
answers and may be unable to verify DNSSIG records if it has cached
a DNSKEY record from the other server.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
More information about the Dnssec-deployment