Re: [DNSOP] new DNS classes

Nico Williams <nico@cryptonector.com> Fri, 07 July 2017 16:35 UTC

Return-Path: <nico@cryptonector.com>
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 382891316BB; Fri, 7 Jul 2017 09:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] 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 MA1RWBtj8wMD; Fri, 7 Jul 2017 09:35:16 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E76E1316B2; Fri, 7 Jul 2017 09:35:16 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id DAED8C086D10; Fri, 7 Jul 2017 09:35:15 -0700 (PDT)
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 51E03C086D08; Fri, 7 Jul 2017 09:35:15 -0700 (PDT)
Date: Fri, 7 Jul 2017 11:35:13 -0500
From: Nico Williams <nico@cryptonector.com>
To: Mark Andrews <marka@isc.org>
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>
Message-ID: <20170707163511.GD3393@localhost>
References: <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> <20170707065637.EB9C07DBDEF2@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170707065637.EB9C07DBDEF2@rock.dv.isc.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QaSyiZ19Dk-XjTp4ilIH1Cc6x0s>
Subject: Re: [DNSOP] new DNS classes
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: Fri, 07 Jul 2017 16:35:18 -0000

On Fri, Jul 07, 2017 at 04:56:37PM +1000, Mark Andrews wrote:
> In message <20170707055315.GC3393@localhost>, Nico Williams writes:
> > 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.

That's easy enough if *I* am the user.  Of course I can change hosting
providers.  However, it's NOT easy when your *customer* is the user that
has to change hosting providers -- they'll balk, and you'll just work
around it.

In the KITTEN WG case there definitely was a vendor who needed to
support customers who use hosting providers that didn't support the URI
RR type.  Can you blame them for not wanting to go with the URI RR type?

Sure we should do it anyways -- it might help.  But that vnedor will
still have to cope with cases where URI is not available, and that
actually means falling back onto alternative, possibly slower, methods
that need to be specified too and which might have annoying knock-on
effects.

(In the KITTEN WG case the idea is to improve discovery of Kerberos KDC
services.  We currently use SRV RRs, but this requires multiple
requests, and every time we add a new transport we need to add more
requests.  One could parallelize the requests, but that's not
necessarily very nice, and anyways, it sucks from a resolver API
perspective.  A URI RR type would solve the problem.  But if you have to
fallback then you've slowed things down for what might be the common
case.)

> 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.

Of course.  *You* are NOT the problem.  That's great.  The problem is
always some knucklehead somewhere who doesn't care to fix *their* system.

Nico
--