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

"Stephan Lagerholm" <> Thu, 10 March 2011 00:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86AA43A698A for <>; Wed, 9 Mar 2011 16:47:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id js58yirhAXto for <>; Wed, 9 Mar 2011 16:47:03 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 5AC6B3A67D9 for <>; Wed, 9 Mar 2011 16:47:03 -0800 (PST)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 0CC3CB837E; Wed, 9 Mar 2011 17:42:02 -0700 (MST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kBv2Z-YWIOGP; Wed, 9 Mar 2011 17:42:01 -0700 (MST)
Received: from ( []) by (Postfix) with ESMTPSA id 1693EB8377; Wed, 9 Mar 2011 17:42:01 -0700 (MST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=2010; t=1299717721; bh=Y2bbCor6CJ53fZxJR13y7A1k89DllrucPWXCC8kMIdI=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To; b=ucSbDUuH0JwZ8kjcncCJg TAMf9AlbcpsA7ICAH/tMHPJQz1fo+BZkggOvV/gZR6KBmpf/lNJEn3GpysTpgjJx6Yy J9i5UmnuZIQIDS+HgxPPWg0TsrCEsdIpcWRRVhLpK1ku50xAKnMiOtNkAoAncEgZIpV 3N0pfWdc+RLFPFhA=
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 09 Mar 2011 17:41:25 -0700
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [dnsext] CDS RRTYPE review - Comments period end Mar 29th
Thread-Index: AcveZCr4gZyNY42tTme1s+UeMVnddAAVuXxw
References: <> <><20110309133017.GA19809@odin.mars.sol> <>
From: Stephan Lagerholm <>
To: Olafur Gudmundsson <>,
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 00:47:04 -0000

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?
>> 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
>> understand that DS must be ignored by a client unless it's signed by
>> 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?
>> that could have been accomplished simply by saying that a DS on the
>> child side is ignored for validation purposes (it now becomes
>> (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
>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.