Re: [Bundled-domain-names] DNS resolution for bundled names

"John Levine" <johnl@taugh.com> Mon, 25 April 2016 03:58 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: bundled-domain-names@ietfa.amsl.com
Delivered-To: bundled-domain-names@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420F412D097 for <bundled-domain-names@ietfa.amsl.com>; Sun, 24 Apr 2016 20:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 DSLxTAX-5gjf for <bundled-domain-names@ietfa.amsl.com>; Sun, 24 Apr 2016 20:58:50 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA45212B063 for <bundled-domain-names@ietf.org>; Sun, 24 Apr 2016 20:58:49 -0700 (PDT)
Received: (qmail 46769 invoked from network); 25 Apr 2016 03:58:48 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 25 Apr 2016 03:58:48 -0000
Date: Mon, 25 Apr 2016 03:58:26 -0000
Message-ID: <20160425035826.40429.qmail@ary.lan>
From: John Levine <johnl@taugh.com>
To: bundled-domain-names@ietf.org
In-Reply-To: <2016042510132151839657@cnnic.cn>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/bundled-domain-names/C98fqP3yWgt_X2QszAxE9V_n0Ow>
Cc: yaojk@cnnic.cn
Subject: Re: [Bundled-domain-names] DNS resolution for bundled names
X-BeenThere: bundled-domain-names@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of \"bundled domain names\"" <bundled-domain-names.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bundled-domain-names>, <mailto:bundled-domain-names-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bundled-domain-names/>
List-Post: <mailto:bundled-domain-names@ietf.org>
List-Help: <mailto:bundled-domain-names-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bundled-domain-names>, <mailto:bundled-domain-names-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Apr 2016 03:58:51 -0000

>We hope to gather some interests for this issue to see whether we can do some standardlization work for it  in  IETF.
>Out initial plan is to have a bar bof in Berlin IETF meeting.

Thanks for taking this on.  It seems to me that the different bundling
scenarios can be addressed in different ways, and we might want to deal
with the easy ones first.

The easiest is probably parallel TLDs like .ONG/.NGO.  There's already
DNAMEs at the top level for the traditional and simplified versions of
Taiwan, and as far as I can tell, the DNS aspects work pretty well.
(As opposed to whether mail, web, and other servers do what you'd want
when the DNAME sends traffic their way.)

The .CAT domain bundles 2LD names, in their case an accented version
and ASCII version of the name.  They use a DNAME for the accented
version that points at the unaccented version, which works really
badly.  Partly that's because the DNAME doesn't redirect itself,
partly I've found from spot checking that even the 3LD names that the
DNAME does redirect rarely work in practice, with almost none of web
servers I checked handling them.

So one part of the work could be looking at BNAME or something like it
that could make parallel 2LD names work better, both within the same
TLD and within arbitrary places in the tree.

A separate issue is how one might arrange to have servers for web,
mail, and so forth automatically configure themselves to do something
reasonable when a BNAME or DNAME points at them.  Roughly speaking, when
they get a request for a domain they don't think they handle, they could
do a DNS lookup on the name and if there's a BNAME or DNAME redirect,
treat it as equivalent as the redirect target.  I realize that in some
contexts this has all sorts of security issues but I think it'd be
possible to carve out a useful subset that's not too dangerous and
still useful.

R's,
John