Re: [dnsext] MAR proposal #2: Allowing pre-publishing of DNSKEYs

["Marc Lampo" <[e-mail]>]

(sorry for the late reply - catching up ...)

I am not in favour of publishing DS records (in the parent)
referring towards DNSKEY records that are not present (in the child zone).
 (is this change seems to propose)

Motivation :
As registry we try to protect the chain-of trust towards our customers
by validating DNSSEC information presented to us.
Up till now, we have had several cases where such "orphaned" DS records
actually turned out to be configuration errors.
As our validation warned about this, we did not contribute to a broken
chain-of-trust.

If orphaned DS records were to become common,
we can no longer easily distinguish between "normal" and "error"
situation.


Kind regards,

Marc Lampo

 
-----Original Message-----
From: Samuel Weiler [mailto:[e-mail]] 
Sent: 01 April 2011 04:28 PM
To: [e-mail]
Subject: [dnsext] MAR proposal #2: Allowing pre-publishing of DNSKEYs

This is a proposed change in DNSSECbis that changes the mandatory 
algorithm rules.  I'm posting this as a summary of what I understand 
some may support; I don't support this change myself. Please post in 
this thread with your support or lack thereof.

For additional operational and zone-signing flexibility, particularly
to allow the publication of a DNSKEY of a new algorithm before a zone
is fully signed with that algorithm, we propose to change these rules
to use ONLY the DS RRset for algorithm signalling, not the DNSKEY
RRset.

Zones will be required to be signed with each algorithm (though not
necessarily eack key) present in the zone's DS RRset or configured
trust anchors.

My opinion:

In retrospect, we probably could have used this mechanism when we 
first wrote these rules -- the choice to use both DS and DNSKEY for 
signalling may have been an artifact of history.  As it is, this 
change may cause zones signed under these new rules to fail validation 
in deployed code, including unbound.  That alone is enough to lead me 
to oppose this change.

-- Sam