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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09A92129671 for <>; Fri, 3 Feb 2017 12:06:09 -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 c62kxoSU2e-W for <>; Fri, 3 Feb 2017 12:06:07 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B35D712950E for <>; Fri, 3 Feb 2017 12:06:07 -0800 (PST)
Received: by with SMTP id v184so2764696pgv.1 for <>; Fri, 03 Feb 2017 12:06:07 -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=Ntnp/XEhInunFMhf7iHLlTagQ7FOqXQ/F4AVnCYaLCI=; b=rEEXcY0ja7prN92S0Tcurd3cCA80FvzPYU3yRkM4pWYuwFD93BtUqx/XDbh3vgkWU+ pzcM0bxhc//lLX2RtR8xC//6aHzY9/aTx+X85xKSlsV+IvoojSI9zNNGp44K+6XdatdK 9bPAA2jRTZI1r6nH5TI7ui1pI78QG+WlZVcILL744F/wpv6WDMI4pNJcP8nLHUGYoDAU fHTd8p5BCKdAyoh7c+lkD8VzsJy8hkVewndXjIr4575BgRGxeHHQQNY8O6TyYymj5ACQ J9DtGANMCEGOmrQMeW7Txt6RRtoULAbVZQoIJQVxqRzbaWSSYMe3RXsiSup+il7Hzlbg xmRw==
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=Ntnp/XEhInunFMhf7iHLlTagQ7FOqXQ/F4AVnCYaLCI=; b=tU8azH0zr0T2u0wN70b3seOxzHvTAqN/J3nzsRQuZbhb4UHhQs0bjRdlUkyK+QwRew Mh3ajm55Ks/WBFLSqmG1QJEed6GHHlnYQ0GM9MkVRsAelHSgQp9mraS1s8/yV5NzyHz0 RuIGGwKTu961LKcwN9GKwc7aXNw2CIIjGnY5+HCZHA+oDv7b4gmIeDpHmTZEYhY8a02v JqBw/HYuAugjzs5v8GTQK5DdFyMLbJuRLwMtzRedP8R7miY5iyplCPbO9EfRnik/5zx1 7TScc/51XcFwAk2XYDB0etHXBb5AbO5PPWnxGzRBp8U0CWFBxY9Z27yXwMBrCz6LpwWF o5BQ==
X-Gm-Message-State: AIkVDXLMwXc5SucKLpnTBeSIKl6lTm7gI2znYKSJze4J1ysl0xN60K3XGgL9kzmI/gYpvg==
X-Received: by with SMTP id q6mr20008710pga.156.1486152367320; Fri, 03 Feb 2017 12:06:07 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id d29sm69168236pfk.83.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Feb 2017 12:06:06 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_76556992-E66F-4597-8088-5A9042B305D0"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Steve Crocker <>
In-Reply-To: <>
Date: Fri, 03 Feb 2017 12:06:05 -0800
Message-Id: <>
References: <>
To: Brian Dickson <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
X-Mailman-Approved-At: Fri, 03 Feb 2017 12:09:10 -0800
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:07:49 -0000

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