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

Kim Davies <> Sun, 12 November 2017 02:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08088124BFA for <>; Sat, 11 Nov 2017 18:51:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6LR9q1DsbIq6 for <>; Sat, 11 Nov 2017 18:51:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E5669127B52 for <>; Sat, 11 Nov 2017 18:51:07 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22DCFE01A5; Sun, 12 Nov 2017 02:50:55 +0000 (UTC)
Date: Sun, 12 Nov 2017 10:50:51 +0800
From: Kim Davies <>
To: Stephane Bortzmeyer <>
Cc: Matt Larson <>,
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 12 Nov 2017 02:51:09 -0000

Quoting Stephane Bortzmeyer on Friday November 10, 2017:
> > I'll note that from a technical/mechanical perspective, ICANN's and
> > Verisign's root zone management systems already know how to deal
> > with delegations. A DNAME in the root would require an unknown level
> > of development by both parties.
> I've never read the source code of the root zone management system,
> but it seems surprising that it could be a non-trivial level of
> development. I assume this system is complicated because it is highly
> sensitive, and because it needs to incorporate a lot of defenses
> against both mistakes and attacks, but they should be more or less the
> same for DNAME and NS/A/AAAA, no?
> Wild guess (and I pay beers if I'm wrong): the technical work will
> take much less time than the process one.

I suspect that would be a distinction without a difference. Any process
changes need to be mapped into technical changes to the systems, as
the whole business process from beginning to end is processed in the

Allowing DNAME records in the root zone is adding a new concept into
root zone management that hasn't been catered to before. 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.

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