Re: [dnsext] DNSSEC, robustness, and several DS records

Doug Barton <> Thu, 12 May 2011 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF4F1E07C8 for <>; Thu, 12 May 2011 15:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5rxRb6Df1MCj for <>; Thu, 12 May 2011 15:33:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D85DCE0780 for <>; Thu, 12 May 2011 15:33:09 -0700 (PDT)
Received: (qmail 17645 invoked by uid 399); 12 May 2011 22:33:03 -0000
Received: from unknown (HELO ? ( by with ESMTPAM; 12 May 2011 22:33:03 -0000
Message-ID: <>
Date: Thu, 12 May 2011 15:33:02 -0700
From: Doug Barton <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Francis Dupont <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc:, Paul Hoffman <>
Subject: Re: [dnsext] DNSSEC, robustness, and several DS records
X-Mailman-Version: 2.1.12
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, 12 May 2011 22:33:10 -0000

Francis, FYI your peculiar style of quoting previous text makes your 
messages very hard to read. More so when they are part of a 
traditionally quoted message like this one.

On 5/12/2011 3:18 PM, Francis Dupont wrote:
>   In your previous mail you wrote:
>     A) Insert obligatory rant about why "should" and "may" should never be
>     used in standards documents.
> =>  I don't follow your idea...

"Should" and "may" introduce ambiguity and allow different implementors 
to follow different paths, leading to multiple implementations that all 
arguably follow the spec, but don't interoperate.

>     B) I don't think it takes even the smallest leap of imagination to say
>     that if the SHA-256 DS is invalid, and the SHA-1 DS is valid, the SHA-1
>     should be used and the SHA-256 should be ignored.
> =>  it is not a problem of imagination: either you implement what the
> spec says or you implement something else. And IMHO the first option
> is never a "bug".

And my point is that the language of the spec is unclear, which makes 
the proper implementation questionable.

>     I think we could have a fine "angels-on-the-head-of-a-pin" debate about
>     what "present" means in the RFC text
> =>  present == is an element of the set

My point was that the debate centers around whether or not a DS record 
can be said to be "present," "an element of the set," or whatever other 
equivalent term you want to use; if it doesn't work. If what you are 
saying is that if it exists in any form, functional or not, then it is 
said to be "present," that's where we disagree.

>     but I have a hard time believing that the intent of the text is
>     that if you have something that works it should be ignored in favor
>     of something that doesn't.
> =>  but it is the intent: this is why I wrote there is no "valid"
> in the spec (where my "valid" means your "works").

And I think one could argue just as effectively that if what is meant is 
what you're interpreting then a sentence to the effect of "This is true 
even if the SHA-256 record doesn't work." should have been included. Or 
maybe not. I recognize that I could be wrong, but I don't agree that 
things are as cut and dry as you make them out to be.

> So I don't expect to see bind or unbound to change their behavior
> unless/until a new rfc is published with another spec.

And now we get to the heart of why "should" and "may" are bad for 
technical requirements documentation. If I were an implementor I could 
very easily look at the spec and say, "Francis is right, I SHOULD skip 
the SHA-1 record here whether SHA-256 works or not. But I don't like 
that interpretation of the spec, so I won't." Such an implementation 
would be just as compliant, by the letter of the spec, as one that did 
skip the SHA-1.



	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)