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

Olafur Gudmundsson <> Thu, 10 March 2011 22:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B25F3A6ADE for <>; Thu, 10 Mar 2011 14:16:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.552
X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KYw98BzKtkbs for <>; Thu, 10 Mar 2011 14:16:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7465E3A6A79 for <>; Thu, 10 Mar 2011 14:16:14 -0800 (PST)
Received: from [IPv6:::1] ( []) by (8.14.4/8.14.4) with ESMTP id p2AMHTrH058686; Thu, 10 Mar 2011 17:17:29 -0500 (EST) (envelope-from
Message-ID: <>
Date: Thu, 10 Mar 2011 17:17:22 -0500
From: Olafur Gudmundsson <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv: Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Stephan Lagerholm <>
References: <> <><20110309133017.GA19809@odin.mars.sol><> <> <3D41A425A17444EA8EEE8C78DD18D3E9@local> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on
Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Mar 2011 22:16:15 -0000

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

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 ......