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

["Stephan Lagerholm" <[e-mail]>]

On Wednesday, March 09, 2011 8:20 AM Olaf Gudmundsson wrote:
>>> Why not just use the child zone's SEP DNSKEY RRs for this purpose?
>>
>> 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.  We
>> don't have CNS in addition to NS, so why should DS be different? I
can
>> understand that DS must be ignored by a client unless it's signed by
the
>> parent, but if that check doesn't already exist, we're already in
>> trouble.
>
>Using SEP bits in DNSKEY records does not work when a zone wants to
>retire an algorithm, the DS MUST be removed before the corresponding
>DNSKEY record is removed.
Good point. For the DNSKEY strategy to work, then it would have to be a
new flag.

>> So, maybe they didn't think of the use case this draft is trying to
>> address and forbade it to keep the software implementations simpler?
But
>> that could have been accomplished simply by saying that a DS on the
>> child side is ignored for validation purposes (it now becomes
pointless
>> (but harmless) to include it, except as a way to securely send DS
>> records from the child to the parent).
>
>RFC3658 specified for the first time a record that can only live at the
>parent and this required major changes to resolution algorithm
>implementations.
>If there is anything we have learned in the last 25+ years of DNS is
>this: "If the same information can appear in two places it will not be
>the same and you have no idea which version resolvers will use"
>Just look at what different resolvers do when the parent and child NS
>records differ.
I agree.

>> I can understand the motivation of introducing a new RRTYPE to avoid
>> needing to alter existing MUST NOTs, but CDS just seems unnecessary.
>>
>> Maybe there's another reason to forbid DS on the child side that I've
>> overlooked?
>>
>
>see above, and new types a cheap, and this gives the child full control
>over the changes in the DS in parent. Similarly this can be used to
>update trust anchors for an Island of security.
For whom do you feel that new types are cheap? Any provisioning program
that parses/constructs a zone file will have to be rewritten to be able
to understand this new type to be able to display/add/edit/remove it in
a meaningful way. I disagree that this is cheap.

We are just starting to see support in different tools for DNSKEY and
DS. Hopefully they made the flag field configurable. Adding a new flag
to DNSKEY would be cheaper.

/Stephan