Re: [DNSOP] new DNS classes

David Conrad <drc@virtualized.org> Fri, 07 July 2017 18:18 UTC

Return-Path: <drc@virtualized.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 00EF11317C2 for <dnsop@ietfa.amsl.com>; Fri, 7 Jul 2017 11:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-org.20150623.gappssmtp.com
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 vrudpv5apgYt for <dnsop@ietfa.amsl.com>; Fri, 7 Jul 2017 11:18:45 -0700 (PDT)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600F5131803 for <dnsop@ietf.org>; Fri, 7 Jul 2017 11:18:12 -0700 (PDT)
Received: by mail-pg0-x235.google.com with SMTP id t186so20904192pgb.1 for <dnsop@ietf.org>; Fri, 07 Jul 2017 11:18:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=INc4g4aQKmd8qjvTeOIoFypi3Nz/yXLa0WXXgnb3AD4=; b=sbK2trJB/uXopVoA7BurAuKp1jFllSvWPKoaPiZ+C0sjdRNOepOyry+GaCmJg7nGvj lpewim2LsOpkxQZJRIsdnU1eWlhI5ZBxcHj5V260hKdeQ2tDYsvSfXwcmyGzDxSv5oXZ e8EF+UT+ohUd6cKiGOHg9s5VFDc9dmt2OP7aWmBRaFPZc4B355v19QGL5mwt4kvue10a WM6G1ldDb0YhaZVH6MuEL2m4P3huDSQSdcxY9lAax8jgy43/z3jTP7XHtSCdIi5LvB16 dAi43ZTQZ/uG+mNHE/Hm00/N4gPSVmZ8Z+bH1rWaoTUKE061W59AziLCZKq+K8Kc6dNt v2cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=INc4g4aQKmd8qjvTeOIoFypi3Nz/yXLa0WXXgnb3AD4=; b=UJiB1BFIuZdWB8XUs3PLwoAHTHy2zqE1+nO5xlCiMv7zuF8CMLd2TYIJT/llQ+alzG g72CqCn6tTDvlo5tTFfY6+ozpSEyxQoAOSl0bZnHNzuGNQlevqFNNJAGXLQu/Au9lyv0 2hxClrDbuZb1nddimfiCLIigk/A+b1I+/Xi5Hql05QfjKvYtqAS1LV2eNIuV3aosg2KY JDbDDfaPGYzDdT4bXb8ZEWsRhSGETRKtRqIsBzSda3sor73F3p6BQEvELSFIJ9EHoJqh 1heUH1Wk+g5ZEpo+7gTMRzhI4SzCI7zot3YJn5Fpe4fgc5bwH8EOurQzSBlQAYh4LKs6 8F3A==
X-Gm-Message-State: AIVw1116w6nFkScNc80OSRgL0ghC0TuNW1UbLtcePBji6hRf2mYK/Ks+ 01hrDQvCBQU+c//4
X-Received: by 10.84.215.135 with SMTP id l7mr4429955pli.194.1499451491804; Fri, 07 Jul 2017 11:18:11 -0700 (PDT)
Received: from [192.168.7.50] (c-24-6-172-77.hsd1.ca.comcast.net. [24.6.172.77]) by smtp.gmail.com with ESMTPSA id s64sm10021276pfd.77.2017.07.07.11.18.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 11:18:10 -0700 (PDT)
Date: Fri, 7 Jul 2017 09:32:09 -0700
From: David Conrad <drc@virtualized.org>
To: Nico Williams <nico@cryptonector.com>, 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: <61283000-0504-43f5-a0b0-65e48e399efc@Spark>
In-Reply-To: <20170707065637.EB9C07DBDEF2@rock.dv.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> <20170707065637.EB9C07DBDEF2@rock.dv.isc.org>
X-Readdle-Message-ID: 61283000-0504-43f5-a0b0-65e48e399efc@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="595fd061_6b8b4567_624"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cSURM1_sXdZ0Ey3frgWO2QhrWEM>
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 18:18:47 -0000

Mark,

On Jul 6, 2017, 11:56 PM -0700, Mark Andrews <marka@isc.org>;, wrote:
> > > Or you could stop trying to reinforce the myth that new RR types
> > > are hard to deploy. They really aren't.

Please stop trying to minimize the amount of work here. They really are. Not for you, but for the folks who make domain names available for use by non-technical types.

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

The number of folks who even understand what you've written above, much less can actually do it, is insignificant in the context of seeing significant adoption of new RRs.

> As a DNS server vendor

You need to look at the wider world.

The DNS server side of deploying a new RR is the easiest part and while necessary, it's no where even close to sufficient to getting a new RR deployed. It's like trying to move the automobile industry to hydrogen fuel: building a car that runs on hydrogen is easy, relatively speaking. However to actually do anything useful with that car, you need need to modify the fuel delivery infrastructure, which is vastly harder, involves a vastly larger set of players, very few of which have any sort of financial incentive to make the change. Standard chicken-or-egg problem.

ICANN funded John Levine to develop https://metacpan.org/release/JRLEVINE/Net-DNS-Extlang-0.1 to try to make it easier to break the chicken-or-egg problem by hopefully giving the folks who provide the UIs by which domain names are managed by non-geeks better tools. However, that's just the first step -- the domain name managers still need to be encouraged to use them.  Pretending this is an easy problem isn't helping.

Regards,
-drc