Re: [DNSOP] ALT-TLD and (insecure) delgations.

Steve Crocker <> Fri, 03 February 2017 20:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 415E8129521 for <>; Fri, 3 Feb 2017 12:33:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UAe9wo6c1lzN for <>; Fri, 3 Feb 2017 12:33:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4040212996C for <>; Fri, 3 Feb 2017 12:33:04 -0800 (PST)
Received: by with SMTP id 194so2817904pgd.0 for <>; Fri, 03 Feb 2017 12:33:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Hep0SGqTxP9bQ9zDIMbvrQapVvqRiIJubZzoGNkbAXA=; b=gshRtohHzJh709lC1IJDbSAIAEfSVfNBYdu6iQuhJANBUh6ibAP56TLPq6AiI4DfmM 5wUEjoUZOG8edUgxoC3+eap7TR3jZu+Yx3jXWDm6ABJvN2akPkK13/p0JRI6Negn+1AG eq5oxwOKEIumH9sUekt/UrUxNqKWK+0Gfq3VmPFigNNdH0eq7Qpb4xIe+ucvH7ZzT2m1 ZiuyGp0MZNUaCzoJrYiJ3pw653Tg80oHUXvMJa9bIjCy2pcU8aYWZPjpzypG353RPpFn o6C5SoZDfcXSLZ0bnZlFs/EDkILNGJQYCfITI1mAWPiduhk+lLLtVPTA3nBvEO4H1J0j Lu2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Hep0SGqTxP9bQ9zDIMbvrQapVvqRiIJubZzoGNkbAXA=; b=dJAG6U9lKFjL7BvtyR92NU6YuapaNKYPqYNwNXvhqUCtP1QO5+kQtV4l5QzmIQg+fR XjXE24t7Y1RCglPPMJp+airWZg2W9JUX4xolU1EbAQmLa7G3VCVjmFcnEBn/VLdjAY64 xGLhftjW3AG7/f1DfYt7xYqqEjHF7gf41FazdxR3yJd9KQdwmM5yjh6lZUngGSZwbOuN 0MUJTsjRpcUOEK/AK80r6L+MWBeqt8f9QsiM6V+nEJFRXzqXyJomErnqmj76Ci26DCGA 43hULc/57Mi4s/3D06LtJGVmu+iovDbWq9EJf2jkOibFe2AzQoqUNtcuLeohaEZOMjkH YGAA==
X-Gm-Message-State: AIkVDXLq+P2dO9Yx1kd5oWs0PxW7CYIih50LfSGDOWG7VizrS9vLQdqDENPEFJmg/HlRyg==
X-Received: by with SMTP id f19mr19988636pgk.158.1486153983780; Fri, 03 Feb 2017 12:33:03 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id j28sm69291751pfj.2.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Feb 2017 12:33:03 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_27E70A3C-33D4-40C0-A48C-4DDEC4C17177"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Steve Crocker <>
In-Reply-To: <>
Date: Fri, 03 Feb 2017 12:33:01 -0800
Message-Id: <>
References: <> <> <> <> <>
To: Brian Dickson <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: Steve Crocker <>, " WG" <>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Feb 2017 20:33:06 -0000

We (ICANN) have no mechanism or process for inserting a DNAME record into the root.  We do have a process for considering the general issue, but, so far as I know, no one has yet brought that idea into the ICANN/PTI arena.

Steve Crocker
[I am having trouble sending from, but I am receiving mail without trouble.  Please continue to send mail to me at]

> On Feb 3, 2017, at 12:28 PM, Brian Dickson <> wrote:
> On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker < <>> wrote:
> And just to stir the pot a bit, what would you have ICANN do if someone applies for .alt as a top level domain?  Is it ok if we say yes and delegate the name?  If not, what is the basis for us to say no?
> The insertion of the DNAME record in the root, instantiates the ALT domain. It says the ALT domain exists.
> However, the DNAME target of an empty zone, assures (with DNSSEC signatures) that no names below ALT exist.
> So, a query to a root server for "alt." would get the DNAME (if the query was for type DNAME or type ANY), or would get "NODATA" for any other RRTYPE.
> And a query to a root server for "anything.alt" would get the DNAME to AS112.ARPA, and the subsequent query (rewritten as would get NXD.
> As to the question about applying for "alt": it means no one can apply for .alt as a TLD, because it is taken. That is the basis for saying "no".
> Brian
> Steve Crocker
> [I am having trouble sending from <>, but I am receiving mail without trouble.  Please continue to send mail to me at <>]
>> On Feb 3, 2017, at 12:18 PM, Brian Dickson < <>> wrote:
>> The DNAME has an effect similar to delegation, except that in the case of the AS112++ RFC ( <> ) , the target is a well-known & published empty zone (
>> (Delegation and DNAME cannot coexist for the same owner name - that is one of the edicts for DNAME, similar to CNAME.)
>> Any local configuration of something.alt (as an authoritatively served zone) would be matched before checking the cache or attempting recursive resolution, per 103[345].
>> I don't have any desire or intention of local something.alt, I'm just pointing out that the existence of a signed NXD result (via DNAME to an empty zone) doesn't break such a set-up.
>> The reason for DNAME instead of delegation, is that it avoids the operators of AS112 instances from having to configure the new zone(s) whenever a new "delegation" occurs.
>> If, instead, a delegation were done, the specific zone (.alt) would need to be configured and served somewhere.
>> RFC7535 is designed to avoid the need for coordination in configuring such zones.
>> (RFC7535 also allows authorities for other places in the DNS tree to make use of AS112, but that is a non-sequitur.)
>> Brian
>> On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker < <>> wrote:
>> Are you also expecting ALT will never be delegated in the root?  If it were to be delegated in the root, what impact would that have on the uses you have in mind?
>> Steve Crocker
>> [I am having trouble sending from <>, but I am receiving mail without trouble.  Please continue to send mail to me at <>]
>>> On Feb 3, 2017, at 12:02 PM, Brian Dickson < <>> wrote:
>>> Stephane wrote: 
>>> On Wed, Feb 01, 2017 at 03:28:29PM -0500,
>>>  Warren Kumari <warren at <>> wrote 
>>>  a message of 103 lines which said:
>>> > or 2: request that the IANA insert an insecure delegation in the
>>> > root, pointing to a: AS112 or b: an empty zone on the root or c"
>>> > something similar.
>>> Here, people may be interested by draft-bortzmeyer-dname-root (expired
>>> but could be revived). The main objection was the privacy issue
>>> (sending user queries to the "random" operators of AS112.)
>>> My opinion on these issues are as follows, roughly:
>>> I am in favor of AS112 for ALT
>>> For AS112, I prefer the AS112++ method (DNAME)
>>> I do not see why the DNAME would/should not be DNSSEC signed
>>> Any local use of ALT can be served locally and signed using an alternative trust anchor
>>> I don't think there is any issue with having both the NXD from the root, and the local assertion of existence, both present (in cache and in authoritative data respectively)
>>> Maybe there are issues with specific implementations? 
>>> If anyone knows of such problems, it would be helpful to identify them along with the implementation and version
>>> For AS112 privacy, perhaps someone should write up a recommendation to set up local AS112 instances, to provide privacy, as an informational RFC?
>>> Even simply through resolver configurations, without a full AS112 "announce routes"?
>>> Do any resolver packages offer such a simple AS112 set-up?
>>> Maybe the efforts for privacy should start there (implement first, then document)?
>>> Do any stub resolver packages include host-local AS112 features/configurations?
>>> Overall, I'm obviously in favor of use of ALT, and for signing whatever is done for ALT, and for use of DNAME for ALT.
>>> Brian "DNAME" Dickson
>>> _______________________________________________
>>> DNSOP mailing list
>>> <>
>>> <>