Re: [Bundled-domain-names] New Version Notification for draft-yao-bundled-name-problem-statement-01.txt

"John Levine" <johnl@taugh.com> Fri, 14 October 2016 16:57 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 4CC6C1294FE for <bundled-domain-names@ietfa.amsl.com>; Fri, 14 Oct 2016 09:57:44 -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 twymP5FajVrh for <bundled-domain-names@ietfa.amsl.com>; Fri, 14 Oct 2016 09:57:42 -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 5FB381294E1 for <bundled-domain-names@ietf.org>; Fri, 14 Oct 2016 09:57:42 -0700 (PDT)
Received: (qmail 40670 invoked from network); 14 Oct 2016 16:57:41 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Oct 2016 16:57:41 -0000
Date: Fri, 14 Oct 2016 16:57:19 -0000
Message-ID: <20161014165719.51673.qmail@ary.lan>
From: John Levine <johnl@taugh.com>
To: bundled-domain-names@ietf.org
In-Reply-To: <20161014144348.h7y6llfkafzpu37z@nic.fr>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/bundled-domain-names/TW7jRgTS7XiS6EpYzRep4i3sZEw>
Cc: bortzmeyer@nic.fr
Subject: Re: [Bundled-domain-names] New Version Notification for draft-yao-bundled-name-problem-statement-01.txt
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: Fri, 14 Oct 2016 16:57:44 -0000

>One is on the possible size of the "bundle". In french, even if you
>limit to the accented characters of the french language, a bundle of
>all possible variants for a name with three accented characters can be
>on the size of the thousand. It can be larger for other scripts. Is it
>a requirment that the solution (whatever it is) work with large
>bundles?

I'd think it has to.  The .CAT TLD bundles accented characters exactly
as you describe.  In languages with variant characters there are
likely to be variant names all over the DNS tree, which means there's
a combinational explosion if you do this in a naive way.

>The second is that you do not mention the solution that people use
>today, when the names are in different TLDs: rely on a clever
>provisioning system. Just automatically generate the config for all
>your domain names. (Hello, DevOps.)

This works sometimes.  Having done some scanning of .ONG and .NGO
which have parallel DNS, it doesn't work as often as it does, even in
what should be a trivally simple setup.  Also see the comment about
combinational explosion above.

>The third is about section 4, application issues. The idea of using at
>runtime a DNS request to decide which page to serve seem to me very
>bad: latency (there is a reason why Apache does not look up PTR by
>default), resiliency (what if the DNS is down), debugging (result of
>the HTTP request will depend on a third party).

This is my part so I guess I should explain.  Having looked at servers
in .CAT (which used to use dnames and now uses parallel DNS) and in
.NGO/.ONG I have found that in practice very few people configure
their web servers to handle variants correctly.

I'm sure that you and I could come up with a provisioning system to
produce parallel configurations for DNS, Web, and SMTP, install them
into the appropriate application servers, and update them all as
needed.  But you and I are not typical.  More typical is a setup where
DNS, Web, and mail are separate departments or even separate
subcontractors who talk to each other only when it is completely
unavoidable.

So if we want it to work, it has to work without configuring
individual servers, and the only way I can see to do that is to have
the application servers follow a single authority which is the DNS.
We are allowed to be smart about how we do it, so performance needn't
be a problem.  I'd think that when an application server sees a name
it doesn't recognize, it then does a few DNS probes to find the DNAME
or BNAME or CLONE or whatever which tells it about the entire mirrored
subtree and it remembers that subtree for the TTL of the DNS record.
The DNAME that ties together the two versions of the Chinese name of
Taiwan has a TTL of a day, which I think would be typical, so in any
sensible setup, the vast majority of mirrored names would be handled
with cached configurations, rather than new lookups.

This isn't bulletproof, but it seems likely to work a lot more often
than something that requires synchronized server updates to DNS, web,
mail, and other applications.

R's,
John