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

Stephane Bortzmeyer <> Fri, 10 November 2017 14:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 207B81205F1 for <>; Fri, 10 Nov 2017 06:28:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9jppE-pfMceN for <>; Fri, 10 Nov 2017 06:28:39 -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 86BB61267BB for <>; Fri, 10 Nov 2017 06:28:39 -0800 (PST)
Received: by (Postfix, from userid 10) id F2B1731D05; Fri, 10 Nov 2017 15:28:36 +0100 (CET)
Received: by godin (Postfix, from userid 1000) id 66249EC10C2; Fri, 10 Nov 2017 15:28:18 +0100 (CET)
Date: Fri, 10 Nov 2017 22:28:18 +0800
From: Stephane Bortzmeyer <>
To: Matt Larson <>
Cc: Stephane Bortzmeyer <>,
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
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: <>
Subject: Re: [DNSOP] 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: Fri, 10 Nov 2017 14:28:42 -0000

On Fri, Nov 10, 2017 at 08:53:06AM -0500,
 Matt Larson <> wrote 
 a message of 32 lines which said:

> 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?

> Adding new types of information to the root is certainly possible:
> I'm not trying to discourage that. But for planning and
> expectation-setting purposes, the community needs to take into
> account the long lead time that will be required for anything that
> requires technical modifications to the root zone management system.

Wild guess (and I pay beers if I'm wrong): the technical work will
take much less time than the process one.