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

Brian Dickson <> Fri, 03 February 2017 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41B2E1298B9 for <>; Fri, 3 Feb 2017 12:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4c3o65WcqEM4 for <>; Fri, 3 Feb 2017 12:18:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED89A129456 for <>; Fri, 3 Feb 2017 12:18:31 -0800 (PST)
Received: by with SMTP id e137so2706858itc.0 for <>; Fri, 03 Feb 2017 12:18:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gORdDh1JRRKw48GIMjpV6E2NnzDvkmsTnRNWJJIUw5Q=; b=BN0ua7rjUVJKhVdgANyYr4MbK+SqxklwdqCXhPsUXKLrA0wNdKFRZ58bPyJvs5OXP3 dK1DzVqUPgMtY5vuO59zLGq9UCohx09bzA5w2Q9sgyDXwmlmfVRbXUjLf61Sq2WxA2+l V+Fp3t53B6oUfdYTzbXEafvsig5jlVBeEBHZ0s8Ie7MnVk0/IXG87C0DQIdCYncWGy6U 1oAMNCPckNfYUVjFcL0WNRM91b/yByhJq8sutHmQkY4l1OsfhofGVw/g5btwbkxDVnd9 6bJSzstPLKKSzedaTXbRf/qlqEFHatl/G2RSXJbPuM7DDQhhcnQmKjjnxF2GclNBerQi /msQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gORdDh1JRRKw48GIMjpV6E2NnzDvkmsTnRNWJJIUw5Q=; b=YraaWlP8Oy4KDse5MGQLlozPGYe3xfLGDrn8s2ZFkXF5dKdzyZmLWP8LXoBBr4pQPj b57c2fKA26KV+FkMOzlPoexP8q15sgUIAxkCUnr26EcBmKqC7G7EKfPjvh25FMeGJ05k tnvj0BqLqV5ScpkbFjyDVqVhRlQn7SGE+2aUNk67cQw2Xg1LDFk6E7kR0Cqoqo+wmZhZ EogGT78j+CGF1t+TApI2GFF/+LN9n4/3NQ0rlU/W0XKeN+uw1Pi+EPm2PFQlgSpfMVke bqR3wZE5Dn9+93wDYxnd1faquhQlwTos0cq1hSdigRICeNJNUGnZp4AUVYHw6FJUXw43 wW6A==
X-Gm-Message-State: AIkVDXIx/aRbEl26j48SiiBctDigBGCPZ7rhYSNJMHF612E56zNTQ4MiHsF12vez4W1+MmcRAzKNffTbyT3oXA==
X-Received: by with SMTP id v11mr2575292iti.101.1486153111106; Fri, 03 Feb 2017 12:18:31 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 3 Feb 2017 12:18:30 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Brian Dickson <>
Date: Fri, 03 Feb 2017 12:18:30 -0800
Message-ID: <>
To: Steve Crocker <>
Content-Type: multipart/alternative; boundary="f403045fbba84522c10547a5fcda"
Archived-At: <>
Cc: " 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:18:34 -0000

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

(RFC7535 also allows authorities for other places in the DNS tree to make
use of AS112, but that is a non-sequitur.)


On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker <>

> 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