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

Mukund Sivaraman <muks@isc.org> Sat, 31 March 2018 21:09 UTC

Return-Path: <muks@isc.org>
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 D68F81241F3 for <dnsop@ietfa.amsl.com>; Sat, 31 Mar 2018 14:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 Ltk57wQNMLal for <dnsop@ietfa.amsl.com>; Sat, 31 Mar 2018 14:09:18 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 67C59120227 for <dnsop@ietf.org>; Sat, 31 Mar 2018 14:09:18 -0700 (PDT)
Received: from jurassic (unknown [182.156.108.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id DB99C32C078E; Sat, 31 Mar 2018 21:09:12 +0000 (UTC)
Date: Sun, 01 Apr 2018 02:39:06 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Tim Wicinski <tjw.ietf@gmail.com>
Cc: Paul Vixie <paul@redbarn.org>, Matthew Pounsett <matt@conundrum.com>, Ondřej Surý <ondrej@isc.org>, Suzanne Woolf <suzworldwide@gmail.com>, dnsop <dnsop@ietf.org>
Message-ID: <20180331210906.GA11628@jurassic>
References: <20180326154645.GB24771@server.ds9a.nl> <CA3D81B6-164F-4607-A7E6-B999B90C4DA8@gmail.com> <5852643C-B414-4C3E-A1B9-553054D3DD46@isc.org> <CAAiTEH8aA3J1j4iUQDisDHiUJXopykKkssuhOK=v+iVV_XZWyA@mail.gmail.com> <5ABAB891.3010306@redbarn.org> <937cde61-3e8e-ea65-b2fd-ed4030f2e311@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <937cde61-3e8e-ea65-b2fd-ed4030f2e311@gmail.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/T8SBRRMoj0_cmKXs72hufzkHqNA>
Subject: Re: [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: Sat, 31 Mar 2018 21:09:20 -0000

On Wed, Mar 28, 2018 at 04:38:24AM -0400, Tim Wicinski wrote:
> 
> I have looked at the same problem Bert has, but he did present it much
> better than I could.  When I started thinking about this, I approached it
> from the point of view of "If I have to give a co-worker a document on how
> to build a DNS Server (Authoritative or Resolver), what would I need to give
> them".   I also have spent a lot of time watching the 793bis work in TCPM,
> which has been moving along slowly and methodically.  I felt what we would
> come up with would be
>     1. a DNSOP document which would be an implementation list for building
> an Authoritative or Resolver
>     2. a roadmap to work on 1034bis and 1035bis, which would be a new WG.

We go through this every year or so when new staff join and we have to
train them to become expert at the DNS protocol, to handle every type of
user problem that shows up.

I think RFCs from [1033, 1034, 1035] need a rewrite. It is filled with a
world that was current in 1987, but isn't the same today. They predate
BCP 14 and have casual language that cannot be so ambiguous for such an
important protocol.

I've been looking at what Bert has been doing which is friendly and good
material, but in my head, the RFCs' rewrite would be quite different.
They'd have to be redone with a different structure, starting with the
domain name tree (3.1 of RFC 1034) and incorporating parts of 1035 right
away, getting details pedantically right. They'd need to not contain so
much prose, but specification of what DNS is.

Just a "guide to the RFCs" won't be sufficient. Language has to be
corrected; large parts of RFC 1034 and 1035 have to be rewritten and
restructured, incorporating clarifications from newer RFCs. It would be
a big work, but IMHO, it is necessary.

		Mukund