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: 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 59EE71317C2 for <ietf@ietfa.amsl.com>; Fri, 7 Jul 2017 11:18:46 -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=ham 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 Y1ymz6RD6e61 for <ietf@ietfa.amsl.com>; Fri, 7 Jul 2017 11:18:44 -0700 (PDT)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 52AFE1317E3 for <ietf@ietf.org>; Fri, 7 Jul 2017 11:18:12 -0700 (PDT)
Received: by mail-pg0-x233.google.com with SMTP id j186so20768727pge.2 for <ietf@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=Q9uKqNOP7wsxogw9ed0K9+Dd1ya3lCUafxwqWzkbg7MSiXFsrIJnWO67J4MAuWnQ36 TYsfTkhGmWTqgwdvID+D+UYtL0XrreMeikYP2IduZ5SaPvTcBlDKT3xBJuQMp3dmFkLP MOvrI6G4RpWOUD9QWCgc80bmZj2KHG1yMJiyXNPBgZ4Ht8gX3U79y9JlsrSHChtlijw4 Wx7wbJP/ZK7FECA57Fzgy6rW4TW0d/7VxDrVM4xzbQYhLAN+V7eeLhLXTSniH0diGQKs GgWA3nnvr7lQKv5gBo2dLTMh0zeoZtniloypgFmOBSZ17ZtHpIiAIUfpBZN95VlCDBMw R8BA==
X-Gm-Message-State: AIVw111ZxlExvXrdbhGSXXwLyM9o3BC0g3qDqgXojWTLPQOqa4o6vxJF +JHq0UYKps61NmVr
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, 07 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>
Subject: Re: [DNSOP] new DNS classes
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/ietf/LBUtAYDkZwR8eM1YIl2m6cYRhxQ>
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 18:18:46 -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