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

[Olafur Gudmundsson <[e-mail]>]

On 10/03/2011 2:48 PM, Stephan Lagerholm wrote:
> George B and Mark A,
>
>> In either case the software that signs zones has to be updated.
>
> If adding a new flag to DNSKEY and if the software already supports the
> DNSKEY RR with arbitrary flags, then no update is needed. For example, I
> could use an old version of ISC dig and still make sense out of the
> DNSKEY record even if a new flag was added. But I had to upgrade ISC dig
> if I wanted to figure out details about the CDS record.
>
>> If the output is in text format, the generic text format of RFC3597
> section 5
>> may be used if the serving software for the master server has not been
> updated.
>
> The RDATA field would still just be a "blob". How would I for example be
> able to verify the Key Tag, Algorithm or Digest Type field unless the
> software you are using is programmed to understand that the format the
> same as for the DS record?
>
>> The software for secondary servers does not need to be updated in any
> case,
>> assuming it implements RFC3597 ( that is it can handle unknown types ),
>> which is of course the case for all mainstream implementations.
>
> Agreed, I'm taking about software that interacts with humans and try to
> display something meaningful for them (provisioning system, IPAM,
> debugging tools, etc)
>
> (For the record, I'm positive to this draft other than using a new RR
> type. I would rather like to see an "embryonic" flag to the DNSKEY
> similar to what the revoked flag is doing for old keys is RFC5011)
>
> /S
>
>
>

Stephan,
there is a problem with using a flag as
the flag field is covered both by DNSKEY keytag calculation and DS 
digest calculation.
Thus changing the flag will "revoke" the key and/or its signatures,
unless validators know how to handle the flag change.

For all practical purposes the key flag field is a wasted space
I tried to have it killed when we did the type code rollover
(KEY ---> DNSKEY) along with the protocol field, but ......

	Olafur