[Dnssec-deployment] synthesizing DS from DNSKEY in the parent
Ed.Lewis at neustar.biz
Wed May 4 10:51:49 EDT 2011
In the research phase of DNSSEC we tried a few different models to
handle cut points. This problem was harder to solve than how to sign
nothing (that is, how to apply DNSSEC to RFC 2308, which gave birth
to the NSEC and NSEC3 records) because there was something "squishy"
We tried keys at the parent but that failed because if a cache knew
the NS set of the child zone, there was no easy way to walk backwards
to find the parent. In fact, because we did not assume a world as
simple as it is today, we didn't know how many labels "up" we might
have to go to find the servers with the keys.
We tried a NULL key to "cut off" security. It became a unmanageable
mess, imagine COM without NSEC3-optout to start and then add a KEY
set for the 80 million unsigned names in it today. Not scalable and
a hinderance to DNSSEC.
About 5 or so years into this Olafur proposed the DS record. The
advantages of it were that it was uniquely from the parent, not at
both parent/child, and the parent could control the security
delegation. The NS set delegates the existence of names to other
servers, the DS delegates the security parameters to the child's
It's like this, if you are walking down the tree and can validate the
parent, you can then tell if the child is secured to your liking.
"You" are the cache that DNSSEC is there to help protect. Since we
are assuming you can have trust in the parent, you can set up
expectations of whether you trust the child. It's like speaking
French to the parent and trying to determine if the child speaks
French too or just Russian. Whether or not you speak Russian, if you
speak French you can be told "hey, he only speaks Russian" and you
then have to react accordingly.
So - there's an analogy between DS and NS in that the delegate. But
they delegate two different things. And how they convey the
information is different.
Note that the NS parent set does not have to be the same as the NS
child set. They should be, but at least in transition, they will
differ. DNS, to accomplish its goals, has to accept that this
situation happens. (We cannot ever expect multiple, distinct
authorities to act in concert as this limits resliance and
scalability.) DS records have to have this flexibility too, by the
way. Instead of having a child DS, there's a child DNSKEY.
If we were to go back to the dawn of DNS, the NS record is a bad
design. We should have a different record for the parent to hold
("Name Space Delegation") as opposed to what the child has. The
parent still has to direct queries there. Plus, the delegation
should not assume port 53. (Hey, maybe we just need to promote the
At 14:18 +0000 5/4/11, Paul Vixie wrote:
>perhaps if the DS RRset was like the NS RRset in being echoed in the
>parent and child, then automatic DS-tracking in the parents could be
>done without the parent having to build a new DS from a new DNSKEY.
>this kind of auto-tracking, similar to what we do with trust anchors
>like the root (RFC 5011), allowing both the parent NS and DS RRsets
>to track signed changes in the child zone, is going to be important
>for DNS scaling. it might not be time to start working on it yet,
>but knowing that this has to happen tells me that it's got to be OK
>for a parent to synthesize a DS from a DNSKEY, even in present times.
As a zone operator, I wouldn't want any automatic linking of my zone
to the parent. And in the vice versa, it wouldn't scale. This
auto-linking works against the independence of the DNS and creates a
bottleneck in the DNS. Both of these work against scaling.
NeuStar You can leave a voice message at +1-571-434-5468
Me to infant son: "Waah! Waah! Is that all you can say? Waah?"
More information about the Dnssec-deployment