Re: [DNSOP] draft-wkumari-dnsop-internal and DNAME

Stephane Bortzmeyer <bortzmeyer@nic.fr> Sun, 12 November 2017 12:10 UTC

Return-Path: <bortzmeyer@nic.fr>
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 997FA12941D for <dnsop@ietfa.amsl.com>; Sun, 12 Nov 2017 04:10:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Ergs-b83mjNW for <dnsop@ietfa.amsl.com>; Sun, 12 Nov 2017 04:10:58 -0800 (PST)
Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE991292D3 for <dnsop@ietf.org>; Sun, 12 Nov 2017 04:10:58 -0800 (PST)
Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 281B631D12; Sun, 12 Nov 2017 13:10:57 +0100 (CET)
Received: by godin (Postfix, from userid 1000) id AEE99EC0B85; Sun, 12 Nov 2017 13:05:44 +0100 (CET)
Date: Sun, 12 Nov 2017 20:05:44 +0800
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Kim Davies <kim.davies@icann.org>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, Matt Larson <matt@kahlerlarson.org>, dnsop@ietf.org
Message-ID: <20171112120544.GA30240@laperouse.bortzmeyer.org>
References: <20171110121241.GA2621@laperouse.bortzmeyer.org> <0C063F76-BFBD-4E54-AFBE-51B00678020B@kahlerlarson.org> <20171110142818.GB4062@laperouse.bortzmeyer.org> <20171112025047.GA69215@dhcp-9fc3.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20171112025047.GA69215@dhcp-9fc3.meeting.ietf.org>
X-Transport: UUCP rules
X-Operating-System: Ubuntu 16.04 (xenial)
X-Charlie: Je suis Charlie
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4nBSqiaIdWwl91EAADq_PzIpiLM>
Subject: Re: [DNSOP] draft-wkumari-dnsop-internal and DNAME
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: Sun, 12 Nov 2017 12:10:59 -0000

On Sun, Nov 12, 2017 at 10:50:51AM +0800,
 Kim Davies <kim.davies@icann.org> wrote 
 a message of 32 lines which said:

> Just one of the many things that would need to be looked at is how
> to transmit DNAME provisioning requests via EPP. I don't know if
> there is even an EPP mapping for this.

Interesting remark. I indeed did not find one. It should probably be a
small extension of RFC 5731:

   C:      <domain:create
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.1">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:period unit="y">2</domain:period>
   C:        <domain:dname>empty.as112.arpa</domain:dname>
   C:        <domain:registrant>jd1234</domain:registrant>
   C:        <domain:contact type="admin">sh8013</domain:contact>
   C:        <domain:contact type="tech">sh8013</domain:contact>
   C:        <domain:authInfo>
   C:          <domain:pw>2fooBAR</domain:pw>
   C:        </domain:authInfo>
   C:      </domain:create>

I'll ask regext tomorrow about it :-)

> We haven't studied what would be involved, but I feel confident in
> predicting the whole exercise would be non-trivial.

But there is no choice. If we decide to delegate .internal to AS112
(*if*: see Joe Abley's message), we cannot use NS records because the
AS112 servers won't recognize the new TLD, and there is no way to
change them all these servers (RFC 7535, section 1).