[DNSOP] Current DNS standards, drafts & charter

bert hubert <bert.hubert@powerdns.com> Mon, 26 March 2018 15:46 UTC

Return-Path: <bert@hubertnet.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F62124B17 for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 08:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Level:
X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awNgJGDRFQry for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 08:46:58 -0700 (PDT)
Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964A41277BB for <dnsop@ietf.org>; Mon, 26 Mar 2018 08:46:49 -0700 (PDT)
Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 9D6CE9FB8C for <dnsop@ietf.org>; Mon, 26 Mar 2018 15:46:45 +0000 (UTC)
Received: by server.ds9a.nl (Postfix, from userid 1000) id 571AAAC544E; Mon, 26 Mar 2018 17:46:45 +0200 (CEST)
Date: Mon, 26 Mar 2018 17:46:45 +0200
From: bert hubert <bert.hubert@powerdns.com>
To: dnsop@ietf.org
Message-ID: <20180326154645.GB24771@server.ds9a.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LUSl0U4YEB18FtiFXTQcRVXJgdE>
Subject: [DNSOP] Current DNS standards, drafts & charter
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2018 15:46:59 -0000

Hi everyone,

I've been looking at the amount of DNS out there, and I think we can do
several things with them. I've also concluded that the mediocrity of DNS
implementations outside of the well-known ones can not be fully blamed on
"stupid programmers". The fact that we've offered the world 1000-2000 pages
to read, with no guideline where to start, is also very likely to have
contributed.

In fact, to this day, if someone wanted to 'get' DNS to implement a server,
I can do no better than point them at 1034/1035 which are pretty archaic by
now and not easy to read. A bit like reading the original Shakespeare. It is
English, but a lot of the words are different. (also, still pretty
insightful stuff).

I am optimistic that if we had a better 'hello, and welcome to DNS' document
we could point to, implementations would get better.  Or if they didn't, we
could at least point at that document and blame them for not reading it. 
This may prevent implementations that get confused if they get anything
other than an A query.

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.

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.

Fourthly, on the currently active drafts aiming to become Internet Standards
(with page numbers):

DNS Multiple QTYPEs 6
Secret Key Transaction Authentication for DNS (TSIG)	21
Address-specific DNS Name Redirection (ANAME)	11
C-DNS: A DNS Packet Capture Format	58
Extended DNS Errors	8
A Root Key Trust Anchor Sentinel for DNSSEC	14
Let 'localhost' be localhost.	9
Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY	10
Security Considerations for RFC5011 Publishers	18
Serving Stale Data to Improve DNS Resiliency	9
DNS Stateful Operations	49
BULK DNS Resource Records	14
A DNS Query including A Main Question with Accompanying Questions	10
Returning extra answers in DNS responses.	8

These represent 245 pages of new reading material, or an increase of over
10% on the already impressive list of DNS standards.

I did a cursory read of the DNSOP charter, and I think at least some of
these drafts do no not fall under even a very broad interpretation of our
remit.

And the BCP/Informational/Experimental ones:
The ALT Special Use Top Level Domain	10	INFORMATIONAL
DNS Scoped Data Through '_Underscore' Naming of Attribute Leaves	8	BEST CURRENT PRACTICE
DNS Transport over TCP - Operational Requirements	14	BEST CURRENT PRACTICE
An Proxy Use Case of DNS over HTTPS	5	EXPERIMENTAL
Reverse DNS in IPv6 for Internet Service Providers	13	INFORMATIONAL
DNS Terminology	42	BEST CURRENT PRACTICE
DNS Catalog Zones	14	EXPERIMENTAL

Similarly, we might give these a good scan to see what we think of these.

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?

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

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.

Thoughts?

	Bert