Re: new DNS classes

Mark Andrews <marka@isc.org> Fri, 07 July 2017 06:56 UTC

Return-Path: <marka@isc.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF6C126579; Thu, 6 Jul 2017 23:56:44 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3rum1OPm5FkA; Thu, 6 Jul 2017 23:56:42 -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 D2B8D131445; Thu, 6 Jul 2017 23:56:42 -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 7711E3493BB; Fri, 7 Jul 2017 06:56:40 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 511BD16004A; Fri, 7 Jul 2017 06:56:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 26D79160055; Fri, 7 Jul 2017 06:56:40 +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 C8rb3xHjmOAA; Fri, 7 Jul 2017 06:56:40 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id CC55D16004A; Fri, 7 Jul 2017 06:56:39 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EB9C07DBDEF2; Fri, 7 Jul 2017 16:56:37 +1000 (AEST)
To: Nico Williams <nico@cryptonector.com>
Cc: John C Klensin <john-ietf@jck.com>, dnsop <dnsop@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>, Paul Vixie <paul@redbarn.org>, IETF Rinse Repeat <ietf@ietf.org>
From: Mark Andrews <marka@isc.org>
References: <CACfw2hhx+-Z=7ZnnaOkToc+Bd7aKDpBFt+nFUxkt9sKqLn4D8Q@mail.gmail.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <E739C1CB-E60E-4B4B-99CF-1E6C68CB6926@rfc1035.com> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <CAMm+Lwjd6xVp-EDp=doevx=AP8qws_Mv++aL733yHEyUF72EMA@mail.gmail.com> <562EC659F89FA92A09CAC4DB@PSB> <20170706153955.GB3393@localhost> <20170706215236.99A8C7DB2FBA@rock.dv.isc.org> <20170707055315.GC3393@localhost>
Subject: Re: new DNS classes
In-reply-to: Your message of "Fri, 07 Jul 2017 00:53:16 -0500." <20170707055315.GC3393@localhost>
Date: Fri, 07 Jul 2017 16:56:37 +1000
Message-Id: <20170707065637.EB9C07DBDEF2@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/0shDtvBJQZFZQLbi0xYKwy0iSHg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jul 2017 06:56:44 -0000

In message <20170707055315.GC3393@localhost>, Nico Williams writes:
> On Fri, Jul 07, 2017 at 07:52:36AM +1000, Mark Andrews wrote:
> > In message <20170706153955.GB3393@localhost>, Nico Williams writes:
> > > So new classes will only be useful to extend the IN-class RR type
> > > namespace.  We won't get there.  New RR types can be very difficult to
> > > deploy due to lack of interest by registrars and domain hosting
> > > services.  TXT RRs forever.  :(
> > 
> > Or you could stop trying to reinforce the myth that new RR types
> > are hard to deploy.  They really aren't.  They actually get used
> > all the time.
> 
> I'm well aware that as to clients and servers, deploying new RR types is
> easy.  The hard part is the management backend and UIs.  Not all of them
> allow you to enter raw RDATA (hex-encoded or whatever).
> 
> We've struggled with this in KITTEN WG.  Deploying the URI RR type when
> you're using a hosting service can be anywhere from annoying (must enter
> raw RDATA) to impossible (the hosting service doesn't give a damn).  I
> suppose it's just a matter of time; perhaps things have improved since
> we last looked.

Then change domain hosting providers and tell them why or run you
own master server or use a service which allows for dynamic updates
which shouldn't care about the record types.  There are plenty of
DNS providers that will slave content.

As a DNS server vendor we get requests to add the new type within
days the type being allocated.  We usually already have code written
and merged to support the new type in all current branches before
those request come in as we poll the type registry daily.  It is
available over git to anyone that wants to pull it down support for
the new type prior to the next maintainence releases.  Adding a new
type is as simple as adding to files to the source tree and rebuilding
the tools.  Once that is done all the tools we ship support it.

Mark

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