Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Mar 9, 2011 at 8:57 AM, Andrew Sullivan <[e-mail]> wrote:

> No hat.
>
> On Wed, Mar 09, 2011 at 08:30:17AM -0500, Scott Schmit wrote:
>
> > I'm inclined to agree with this, but even if it's decided that the
> > DNSKEY RRs aren't sufficient, why not just use DS on the client side? I
> > see that RFC 3658 forbids it, but I'm not sure I understand why.
>
> I do not think this is the time to debate that design decision.  The
> design of DNSSEC uses different RRTYPEs at the parent side of the cut
> and the child side.  It is true that we use the same RRTYPE at the
> parent and child sides for the NS record.  But even if you think that
> was a good design (though I happen not to), the fact is that DNSSEC
> did not follow that direction, and it has rules stating that the DS
> isn't allowed on the child side.  We can't unmake that decision, and
> we can't change it now without introducing a backward incompatible
> change; so that is not an option open to us.
>

I think that a change in mid course here would be worse than merely
'incompatible'.

It would work maybe 90% of the time and fail in unpredictable and unexpected
ways the rest of the time.


We really need a design rule to help determine whether something should be a
new RR or not.

In my view, the design should attempt to:

1) Ensure that a query returns all the relevant information
2) Does not return irrelevant information


Here we have the DS record which gives the hash of key in the zone beneath.
I do not see a compelling use case that requires the hash of the subordinate
zone key to be returned at the same time as the hash of the zone key.

So according to the design rule above, this clearly requires separate
records - if there is a compelling use case for the actual record.


I have used the above design rules quite extensively in my attempt to
untangle the issues that result from the interference that occurs between
use of domain prefixes, aliases and wildcards.

-- 
Website: http://hallambaker.com/