[Dnssec-deployment] synthesizing DS from DNSKEY in the parent

Edward Lewis 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 
SRV record...somehow.)

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.

Edward Lewis
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?"
Son: "Waah!"

More information about the Dnssec-deployment mailing list