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

william manning <chinese.apricot@gmail.com> Sun, 05 February 2017 13:22 UTC

Return-Path: <chinese.apricot@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D794E1294C4 for <dnsop@ietfa.amsl.com>; Sun, 5 Feb 2017 05:22:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt8sP8CFuaJR for <dnsop@ietfa.amsl.com>; Sun, 5 Feb 2017 05:22:16 -0800 (PST)
Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515AD127601 for <dnsop@ietf.org>; Sun, 5 Feb 2017 05:22:16 -0800 (PST)
Received: by mail-it0-x241.google.com with SMTP id e137so5896600itc.0 for <dnsop@ietf.org>; Sun, 05 Feb 2017 05:22:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eIFt8ZbwySSewKpaW64AHU0xv10UlgRs6cigW6gdBXA=; b=nRQjrMzD32w4YMHgkERArIIkXon0v+WgAfXtjD0chiDz3cWHRhMVWIBikW5WXGm35B DXuGNW37F2fapwuqs29GOX+/vw5TIFc0QgQll9RRqiuqS6VYV6B8ACOYfHalw4WL1UND w9Vh6fpCPifU4jL8sGOopSRV9L+T+Fqbk1nWBKeqx2KerMZGQfb+6qbCYg/9DrN/5vkJ vykX4XF54MYpeI2z7+M4b9upwkyejztRO7ep2KrfOz1lNF5ND9SdQwC4FDY4ShjyHDuG L2SVbOccHv+eZ23O4QuO5nQj2yxjApwJ5Z5T8FkVBL89fBwpAlr88O86ZyCvC0puCEyF xCIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eIFt8ZbwySSewKpaW64AHU0xv10UlgRs6cigW6gdBXA=; b=r1cybxvvUd+uUC9F+tqThKkWOlNZt/ETzOE0RJUWqAoLlqUHJ00J286K8izrYBcDYD qWMbvBzQ9KH/po0bJZreH9rxvkU/L6WYduMaM6kqpcc+nQIGYE5334QPyMtNQw2ff70k b6aWxYDdKX/6zBux1aIhxlADlu+Wh6bit+Yt8G4xOOHL+XwfD2aB83c+KwCzCyg+8k0n X55TsqUhS3ngSJC+pgtlUhqrAxdisaMAhBCloPIKSbqLnfgC1lttrbf7+FpzCFRYarbl +ywf3ssf6X1EOVmoK8uR3EMCqZqzHwr5EDlERIoYeMThNK0aY5SzjRr6LXluXe5Twevp 7UeA==
X-Gm-Message-State: AIkVDXJ99TQApAbwvb8sF3C6S/MzqzhyTk18CwZk/vwEAv9feo7Hbx9HW1P24evxG3B0dt3qKW6/SiJA+WJ5iw==
X-Received: by 10.36.77.10 with SMTP id l10mr3736508itb.59.1486300935547; Sun, 05 Feb 2017 05:22:15 -0800 (PST)
MIME-Version: 1.0
References: <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com> <5FD13D0D-57DE-4CED-B1A2-C823079B8D63@gmail.com> <CAH1iCiqMhky7r-kaMFTa41b2ZBfd3Fiffp0Rknx_4moaBx3t6w@mail.gmail.com> <74796240-46DA-4C8B-A715-DBC521EFA3F3@gmail.com> <CAH1iCipNK5OP3UijnZDmQZv9tb8dhVp1WP7zDJpLOFPfJNPKGw@mail.gmail.com> <A519902D-8B90-44A7-84BD-8A5FD1D15978@gmail.com>
In-Reply-To: <A519902D-8B90-44A7-84BD-8A5FD1D15978@gmail.com>
From: william manning <chinese.apricot@gmail.com>
Date: Sun, 05 Feb 2017 13:22:04 +0000
Message-ID: <CACfw2hgLmPaZHM9VTcFObaBmgvkYX6f1-51SX8LpFN_M2=ZX+A@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>, Steve Crocker <steve.crocker@gmail.com>
Content-Type: multipart/alternative; boundary=001a1144d0164aef800547c8670d
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JI4p2fu5FY7K0T__3lTaRQ6ATqc>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Feb 2017 13:22:19 -0000

DNAME was considered early in the IDN evaluations, so it's not exactly
unknown in the Icann community


On Fri, Feb 3, 2017 at 15:33 Steve Crocker <steve.crocker@gmail.com> wrote:

> 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 steve@shinkuro.com, but I am receiving
> mail without trouble.  Please continue to send mail to me at
> steve@shinkuro.com]
>
>
>
>
>
>
>
> On Feb 3, 2017, at 12:28 PM, Brian Dickson <brian.peter.dickson@gmail.com>
> wrote:
>
>
>
> On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker <steve.crocker@gmail.com>
> 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 anything.as112.arpa)
> 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 steve@shinkuro.com, but I am receiving
> mail without trouble.  Please continue to send mail to me at
> steve@shinkuro.com]
>
>
>
>
>
>
>
> On Feb 3, 2017, at 12:18 PM, Brian Dickson <brian.peter.dickson@gmail.com>
> wrote:
>
> The DNAME has an effect similar to delegation, except that in the case of
> the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 ) , the target is a
> well-known & published empty zone (as112.arpa.)
>
> (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 <steve.crocker@gmail.com>
> 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 steve@shinkuro.com, but I am receiving
> mail without trouble.  Please continue to send mail to me at
> steve@shinkuro.com]
>
>
> On Feb 3, 2017, at 12:02 PM, Brian Dickson <brian.peter.dickson@gmail.com>
> wrote:
>
> Stephane wrote:
>
> On Wed, Feb 01, 2017 at 03:28:29PM -0500,
>
>  Warren Kumari <warren at kumari.net> 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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> DNSOP mailing list
>
> DNSOP@ietf.org
>
> https://www.ietf.org/mailman/listinfo/dnsop
>
>