Re: [DNSOP] type numbers, was Brief addition to terminology-bis draft

Mark Andrews <marka@isc.org> Mon, 10 September 2018 23:54 UTC

Return-Path: <marka@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 47637130FF7 for <dnsop@ietfa.amsl.com>; Mon, 10 Sep 2018 16:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 h18FUq6NPvcU for <dnsop@ietfa.amsl.com>; Mon, 10 Sep 2018 16:53:59 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86358130FF2 for <dnsop@ietf.org>; Mon, 10 Sep 2018 16:53:59 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5737B3AB03F; Mon, 10 Sep 2018 23:53:59 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 18DA516007E; Mon, 10 Sep 2018 23:53:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EACFA16007D; Mon, 10 Sep 2018 23:53:57 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hTjXH52xcZSn; Mon, 10 Sep 2018 23:53:57 +0000 (UTC)
Received: from beetledviscorg7.home.lan (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 2D04416005B; Mon, 10 Sep 2018 23:53:56 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <alpine.OSX.2.21.1809101836300.80755@ary.qy>
Date: Tue, 11 Sep 2018 09:53:56 +1000
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <247AF5E0-8214-4312-B362-431C56E4FD6E@isc.org>
References: <20180910213903.8FA5B20042D108@ary.qy> <5DE059C1-B475-40B8-A523-A56B7E1B367B@isc.org> <alpine.OSX.2.21.1809101836300.80755@ary.qy>
To: John R Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hNuoCytg-KKwBp2AtIFFolqLgM8>
Subject: Re: [DNSOP] type numbers, was Brief addition to terminology-bis draft
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 10 Sep 2018 23:54:02 -0000


> On 11 Sep 2018, at 8:51 am, John R Levine <johnl@taugh.com>; wrote:
> 
> On Tue, 11 Sep 2018, Mark Andrews wrote:
>>> Since the type code is a 16-bit field, if we allocate a new type every
>>> week, it'll take over a thousand years to run out.  I think this is one we
>>> can safely ignore.
>> 
>> If we end up with a type per protocol because people want wildcards to work
>> we will burn through types much faster.  We don’t know exactly what the future
>> will bring.
> 
> Uh, what?  In the past 30 years we've assigned under 100 rrtypes.  If that rate increases by an order of magnitude, we still have a thousand years of them.  Sure we don't know exactly what the future will bring, but we can make some reasonable guesses.

We have assigned 100 types with the myth that it is hard to deploy a new type slowing
down the rate of assignment.

>> I do know that saying that classes can’t work is self defeating and will take a lot, lot, lot more of work to undo than just continuing to support multiple classes.
> 
> Classes were a mistake.  We should deprecate every class except IN, perhaps keeping the one special case for CH server.bind.  That doesn't require changing any of the bits on the wire.

And keeping classes working doesn’t changing any bits on the wire.  Using a second
class is almost all administrative.  The resolver libraries I’ve been using for last
30 years have supported lookups in different classes.  The recursive servers we have
been delivering support multiple classes.  Now the one thing that needs to be done
with a new class is to define what a A record means in that class.

QUERY supports multiple classes.
UPDATE supports multiple classes.
DNSSEC supports multiple classes.
NOTIFY supports multiple classes.

There are no reasons to kill multiple class support.  

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org