Re: [DNSOP] Current DNS standards, drafts & charter

Paul Vixie <> Mon, 26 March 2018 16:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23AC3126CC4 for <>; Mon, 26 Mar 2018 09:13:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EQvBAXMxM9Xu for <>; Mon, 26 Mar 2018 09:13:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 684EF124B17 for <>; Mon, 26 Mar 2018 09:13:34 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:4ca8:bd4c:848b:7427] (unknown [IPv6:2001:559:8000:c9:4ca8:bd4c:848b:7427]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 4B4A47594C; Mon, 26 Mar 2018 16:13:34 +0000 (UTC)
Message-ID: <>
Date: Mon, 26 Mar 2018 09:13:31 -0700
From: Paul Vixie <>
User-Agent: Postbox 5.0.24 (Windows/20180302)
MIME-Version: 1.0
To: bert hubert <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] Current DNS standards, drafts & charter
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Mar 2018 16:13:36 -0000

bert hubert wrote:
> ...
> So my first suggested action is: could we write a document that has a core
> introduction of DNS and then provides a recommended (not) reading list.
> Secondly, what we've been doing already, is grouping the various standards
> in categories.  Read this if you are doing X.  This could go in the first
> document.

i agree with your observations, and i like your first and second 
suggested actions.

> Thirdly, this may lead to a category of RFCs that you might be better off
> not reading or implementing. I don't know if writing a draft that
> specifically obsoletes record types or features that are never used is
> helpful. In fact, adding MORE documents to the pile (even if meant to make
> life easier) may be counterproductive. But simply noting that something
> should not be implemented anymore would do rhe trick.

let's consider marking some things as mandatory to implement, and then 
anything not so marked will be, by exclusion there, optional to 
implement. this is not the same as deprecation, and comports with your 
later observation as follows...

> Finally, with Job Snijders, I am very much in favour of mandating
> interoperable implementations as a requirement for standards action.
> There is a whole bunch of reasons for this.  For starters, how can we
> know if an idea is good without having tried it?

...but, i think that multiple interoperable implementations is already a 
minimum benchmark, and i think it's IETF-wide, not optional, and has 
always been in effect here.

what i'd like is something more. KEY, SIG and NXT had multiple 
interoperable implementations, but were not actually functional in any 
end-to-end way, and were thus replaced by RRSIG, DNSKEY, DS, and NSEC. 
later we moved the target and added NSEC3 and then NSEC3PARAM.

so while multiple interoperable implementations are a minimum benchmark, 
i'd like to see some kind of scale model as well. making something work 
on a whiteboard, or in a test lab, or on one's laptop, does not mean it 
will work on today's or tomorrow's internet.

this just amplifies my interpretation of your term, "having tried it."

> Secondly, getting implementations to support this is an instant damper on
> ideas which would not get traction with implementations later on.

sadly, this is not so -- thus the above "scale model" requirement.

> And thirdly, I think it is extremely educational to experience how a feature
> that is 'easy' on the authoritative side (say, DNS Multiple QTYPEs)
> absolutely sucks and leads to probing on the resolver side - requiring whole
> factors more code than the spec is actually about.

this again goes to scale modeling and the definition of "having tried it."

> Thoughts?

anybody can complain about the weather, but very few of us try to change 
it. thanks for your contribution to complexity considerations.

P Vixie