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

Phillip Hallam-Baker <> Wed, 09 March 2011 14:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 687423A69CC for <>; Wed, 9 Mar 2011 06:26:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.564
X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TE0Dx+LbDDod for <>; Wed, 9 Mar 2011 06:26:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 784233A69BE for <>; Wed, 9 Mar 2011 06:26:42 -0800 (PST)
Received: by iwl42 with SMTP id 42so718488iwl.31 for <>; Wed, 09 Mar 2011 06:27:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Qt8EobUQ1nzOeKQYpm+fPaiAJB/eJxzE8nBb89HE3zw=; b=vDG2lj9bpLyjFjjUcSuLRS8xtANhWzixWPpwd83Q5eR+7oaIh/LwSudWVenJopYt6e i0dVtjfAHRqKc6pmkTa172oE0PvDJWhO4CHTtovIwcGLOFsF1irFsaVeKr0QFdjUV0bj hjvHfRNC6cFhIq1fmOeA9UgrQTSzL2Gn5io48=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QdaDZwlay3Ykz5HNAv8ZUnvwmdH70osBLYHHxJ7rmpQ1WCuFdKBNxvdE1PvFrB+e1F t8G2JsQ0CrDkrw1Gf6TQpRg73yNdF2IoRIbOTLzGIq1794URV2Hwxqnoc+BJFCYJhl1C 9nSfPE7B0y+ZpqAO46XcjOEh6/DbPiuoAYfTE=
MIME-Version: 1.0
Received: by with SMTP id f9mr6183503icp.233.1299680878737; Wed, 09 Mar 2011 06:27:58 -0800 (PST)
Received: by with HTTP; Wed, 9 Mar 2011 06:27:58 -0800 (PST)
In-Reply-To: <>
References: <> <> <20110309133017.GA19809@odin.mars.sol> <>
Date: Wed, 9 Mar 2011 09:27:58 -0500
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Andrew Sullivan <>
Content-Type: multipart/alternative; boundary=20cf303bff46193917049e0d895c
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: Wed, 09 Mar 2011 14:26:47 -0000

On Wed, Mar 9, 2011 at 8:57 AM, Andrew Sullivan <> 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

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.