Re: new DNS classes

Pete Resnick <presnick@qti.qualcomm.com> Sun, 09 July 2017 16:44 UTC

Return-Path: <presnick@qti.qualcomm.com>
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 3D77412EB13; Sun, 9 Jul 2017 09:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 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, URIBL_BLOCKED=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 P3ONop8iIGrT; Sun, 9 Jul 2017 09:44:06 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C2812EAF7; Sun, 9 Jul 2017 09:44:06 -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=1499618646; x=1531154646; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=GsoJscYUGW266ZkEqVmDpnkDzh0Io6q2ODnO8JWntiI=; b=RUKGoNvIsG2uV7eTJrKo7lTsSXlPIz6ALBzI1Sdc3KuRRgP305yp2STH AvCjnV74+lsqVnpDgm7tU0tGBHKXlIlW3smhcNXeydJhpI0aXc46V6UI4 x/E/g/Pdco9e15gGt0vpSb4vPZznj/NRFnrISkbPzZAYPqKfjwFfMbbWu A=;
X-IronPort-AV: E=Sophos;i="5.40,335,1496127600"; d="scan'208";a="111094214"
Received: from unknown (HELO Ironmsg03-L.qualcomm.com) ([10.53.140.110]) by sabertooth02.qualcomm.com with ESMTP; 09 Jul 2017 09:44:05 -0700
X-IronPort-AV: E=McAfee;i="5800,7501,8586"; a="1406799185"
X-MGA-submission: MDGlyaJpnhahzANAUX+TX1cQmzfjB57vHQdBjmYnjHtOuQhyj7FeSqcD0LUsQUqV9NvPH0Y2dQBeA8BhjxGbQ8H7X3n0mALBtOaRcbO5rE0RN4L5JcXvZw+JuJtLbVfQN57Ttf+gw4ZMziDDy4cqVjXA
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Jul 2017 09:44:05 -0700
Received: from [10.64.97.228] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 9 Jul 2017 09:44:04 -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>
Subject: Re: new DNS classes
Date: Sun, 09 Jul 2017 11:44:02 -0500
Message-ID: <D491DDB9-0788-41B4-AD63-586CCA98512E@qti.qualcomm.com>
In-Reply-To: <20170709015851.E5C877E07ADA@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> <EDFEF9A1-99CF-4F25-9C1C-051E78949967@qti.qualcomm.com> <20170709015851.E5C877E07ADA@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
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/ietf/X4EWp2biYDnZrM8J_rIgrMsdKHw>
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: Sun, 09 Jul 2017 16:44:08 -0000

On 8 Jul 2017, at 20:58, Mark Andrews wrote:

> In message <EDFEF9A1-99CF-4F25-9C1C-051E78949967@qti.qualcomm.com>, 
> Pete Resnic
> k writes:
>> On 7 Jul 2017, at 19:18, Mark Andrews wrote:
>>
>>> 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".
>
> Given Macs can register their own addresses in the DNS using UPDATE...

You mean an A or AAAA record, which the UI does support?

> ...Log a bug with Apple that the
> tool doesn't support all known types and that it doesn't support
> unknown types.

And in the meanwhile, you still say, "new RR types are not hard to 
deploy"?

> We supply user applications to manipulate the DNS.  Those tools are
> capable of updating yet to be defined types.  Putting a front end
> on those tools that takes the new type someone dreams up is easy.

To quote a favorite line of mine, I grant the point: If things were 
different, they wouldn't be the same.

Creating these front ends apparently has not happened, so how does this 
address the point that new RR types are hard to deploy?

> We also supply C libraries that can do the same thing.  No one needs
> to wait to use a new type.

I refer the honourable gentleman to the answer I gave some moments ago.

Sure, it would be easy to write code to make tools exist that would make 
it be easy to deploy. Those tools do not currently exist. It is 
therefore still hard to deploy.

> There are python and perl tools available that can also send update
> messages.

I refer the honourable gentleman to the answer I gave some moments ago.

> If you just want the new records to be a blob of text a shell script
> like this will convert the record to unknown format suitable to be
> used by nsupdate.
>
> % sh junk
> hello world
> \# 11 68656C6C6F20776F726C64
> % cat junk
> read record
> hex=`printf "%s" "$record" | hexdump -ve '/1 "%02X"'`
> length=`printf "%s" "$hex" | wc -c`
> length=`expr $length / 2`
> echo '\#' $length $hex
> %
>
> You can create all DNS records similarly.  Building them up
> field by field.
>
> One can do something similar in any scripting language.

I think you have proved my point exceedingly well there.

> So no it isn't hard to use a new type.

Nobody said "use". The word was "deploy". Until a huge number of hosting 
providers and OS vendors and tool writers get their act together writ 
large (and that includes tool vendors who require recompiles and/or fun 
shell scripts in order to have a remotely sane UI experience), 
deployment of a new RR type is hard.

> You just need to stop waiting
> for the stupid DNS hoster to do it for you and organise to do it
> yourself.

That does not solve the deployment problem.

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