Re: [DNSOP] new DNS classes

Pete Resnick <presnick@qti.qualcomm.com> Sat, 08 July 2017 16:05 UTC

Return-Path: <presnick@qti.qualcomm.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 6BE1E129B72; Sat, 8 Jul 2017 09:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.002
X-Spam-Level:
X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 DFjkZawNxUxb; Sat, 8 Jul 2017 09:05:05 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86F0127873; Sat, 8 Jul 2017 09:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1499529905; x=1531065905; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=C/YtHOKCp+1yWmIkJHw7H3uj3Imrt3EFdinJ+CoKWu4=; b=FsjpRpnHSeLyAYBlgIbNbqsoynLjF8rc35q5cQSMyCRa1YbMfDCJtT0D LD9FVUm5d12xXvQlEpEfznhAUqTS0htUNXuahcFIoBWhnvwc2/bN0rBuG lbIwCVMyYu36WhFGVIdr244FJLg73+mynWHW8sJzgRD1pzhuh/qRTLCrC c=;
X-IronPort-AV: E=Sophos;i="5.40,329,1496127600"; d="scan'208";a="109989335"
Received: from unknown (HELO Ironmsg03-R.qualcomm.com) ([10.53.140.107]) by sabertooth01.qualcomm.com with ESMTP; 08 Jul 2017 09:05:04 -0700
X-IronPort-AV: E=McAfee;i="5800,7501,8585"; a="1402247209"
X-MGA-submission: =?us-ascii?q?MDHQ+L3s0NEb7pK1EW4NTcei0QGSZiUiwzMYFX?= =?us-ascii?q?131AlYLHxHjCegMKiA9rU2RXqlmPKMooa6tVFiFe7+PhUvRXPov5M9Yz?= =?us-ascii?q?c25xlifZd/XgAjvBysxidP16/QlPtoRZ4pJLRgPYWqrFYj3h1cmDyJqY?= =?us-ascii?q?vj?=
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Jul 2017 09:05:04 -0700
Received: from [10.64.110.227] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 8 Jul 2017 09:05:03 -0700
From: Pete Resnick <presnick@qti.qualcomm.com>
To: Mark Andrews <marka@isc.org>
CC: Nico Williams <nico@cryptonector.com>, John C Klensin <john-ietf@jck.com>, dnsop <dnsop@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>, Paul Vixie <paul@redbarn.org>, IETF <ietf@ietf.org>
Date: Sat, 8 Jul 2017 11:05:01 -0500
Message-ID: <EDFEF9A1-99CF-4F25-9C1C-051E78949967@qti.qualcomm.com>
In-Reply-To: <20170708001825.2FB117DFD520@rock.dv.isc.org>
References: <m2podgxq97.wl-randy@psg.com> <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <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> <A94C17CD-DC4B-43C9-AD3D-69735FC6B2BC@qti.qualcomm.com> <20170708001825.2FB117DFD520@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed; markup=markdown
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4-QWil52eQPLpffawPy-U7hHOwY>
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: Sat, 08 Jul 2017 16:05:07 -0000

On 7 Jul 2017, at 19:18, Mark Andrews wrote:

> In message <A94C17CD-DC4B-43C9-AD3D-69735FC6B2BC@qti.qualcomm.com>;, 
> Pete Resnick writes:
>>
>> On 6 Jul 2017, at 16:52, Mark Andrews wrote:
>>
>>> 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 running the latest version of MacOS Server. I can't get a new RR
>> type into the UI. Even if I use the command line "dnsconfig" tool, I
>> can't add a record of a type it doesn't know about; I only get A, 
>> AAAA,
>> CNAME, NS, MX, PTR, SRV, and TXT. Yes, I could go hacking around in 
>> the
>> BIND configs that underly their implementation. And at that point I 
>> say,
>> "New RR types are hard to deploy; not a myth." Telling me I can use a
>> different operating system or not use a validating UI is not a
>> reasonable response.
>
> Well use nsupdate.  That also ships with the Mac.

Of course doing that likely means I'll have records that don't show up 
in the server UI. Not entirely thrilling. And I could accomplish exactly 
the same thing by directly editing the BIND config files, so I'm not 
sure what that gains me in terms of "not hard to deploy".

>> The fact is the DNS doesn't provide a way for implementations to
>> dynamically update the RR types to provide sensible UI; it's left as 
>> an
>> exercise for each individual implementer. (Yes, I know about
>> draft-levine-dnsextlang; it doesn't seem to have gotten anywhere.) 
>> You
>> can't much complain about the difficulty of deployment when the
>> community won't provide the tools to make deployment easier.
>
> Well BIND is designed to allow new types to be added easily.  It
> may require recompiling rather than updating a text file but it is
> not beyond people to do because we see people doing just that.

¬(∃𝑥𝐶(𝑥) → ∀𝑥𝐶(𝑥))

Just because you you see some people recompiling does not mean that all 
(or most, or a significant number) can. Set that aside, it is nowhere 
near reasonable for knowing how to recompile a piece of code to be 
required in order for me to add a new RR type. Set that aside, this is 
the epitome of "hard to deploy": Some implementations can't do it at 
all, some implementations you have to go hacking around in hidden config 
files, and some implementations you have to recompile the binary to get 
a reasonable UI experience.

This is the problem with DNS being considered a system service rather 
than a user application. It's got both aspects. Until the user 
experience for configuring the DNS with a new RR type does not require 
the skills of someone able to recompile code, it is absolutely going to 
be the case that new RR types are hard to deploy, and calling it a myth 
is not helpful.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478