Re: [DNSOP] Variant bad idea of the day

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 02 January 2019 18:19 UTC

Return-Path: <brian.peter.dickson@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 1829D130EE0 for <dnsop@ietfa.amsl.com>; Wed, 2 Jan 2019 10:19:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 8mvXj1-pxruG for <dnsop@ietfa.amsl.com>; Wed, 2 Jan 2019 10:19:34 -0800 (PST)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 4D97F130EE3 for <dnsop@ietf.org>; Wed, 2 Jan 2019 10:19:34 -0800 (PST)
Received: by mail-qt1-x829.google.com with SMTP id y20so34349148qtm.13 for <dnsop@ietf.org>; Wed, 02 Jan 2019 10:19:34 -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=tB/weZPyfOoEZEKyrTYRCkFM9lhJGg11VMNYt63/CjM=; b=U+k85kUQDzg81vDobFc+G5AFm2XR0WyOueUAJQ9Arp4Uaz+pu8ma5l1t91N4j/4UtI 0U8MO69DVdCWCDRSeeaJUIei7U7nPIrhLfm8vR6xd01L3AjCbw47E0gOVe/uW92uORVm 829SijlZSqKmFmx9dcVjFFPxY5Jxh8s1XHv7UrqgXHMo4K4ne0i2T+vsx3MAFqCsKSss VnDurZZ0eqApDxzFxcTVlF9DRtRXm02ukMl69QhM2lnFPePmz9Q17+cMQs4Ko49aXjuX WrBAfz86A+w88LWM8dIqPHPN9woGdZsqJuMZvCk8PNAFqJ/Car7tJ+/Si8xNKtGNFiHq caUQ==
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=tB/weZPyfOoEZEKyrTYRCkFM9lhJGg11VMNYt63/CjM=; b=qCy4W9jOc4m2nkAy494JywiVDw5YsLx4XU+AbcoQPQjhs0oFrwQOq+MeMRNCywswNW AD9aWDrX+HAKTDJXpfcwZSRuYH4B6jmS18jFh6lF9mLt9tJ5JIxtycpOD33Zk3k9bBrl Y6L9zUgIbNRCHCoW5qO2EMpbVfNWQl/CWjymWakKZCtdIfLl+kcAa0f9w4Rm1mUS7Sd2 SipW7tRlEkCCKDmOWvTEzV5IE8LG6HNIeHDnnQyXGaLULkLLwNFCV5G0UsVMdeMsXIVh spuGGl4y4k2hWtdmF8E545bDsnFKGzKUglTeae7IwhCVd7JtmVaoMHcE9QGv1KPhajXr QLNQ==
X-Gm-Message-State: AJcUukdaZeBb6PluNiaAKbdlzo5gy+8fJbAI/vdnYOXYA+jZvu48EYOC jbE9PgYiwD3+Ufj0RGwKRi4d/7Bu6RIhgSFWBybS3g==
X-Google-Smtp-Source: ALg8bN43icHWccVonBRkXSg6PYtr4X9CH/Tz3dbo+yrTyg6A+BIb+98Dh0Dh3VDYJBmkVPEbdcMjiXreeuRgt4akfmc=
X-Received: by 2002:a0c:9dc6:: with SMTP id p6mr44796812qvf.217.1546453173263; Wed, 02 Jan 2019 10:19:33 -0800 (PST)
MIME-Version: 1.0
References: <alpine.OSX.2.21.1812311912250.81953@ary.local>
In-Reply-To: <alpine.OSX.2.21.1812311912250.81953@ary.local>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 2 Jan 2019 10:19:21 -0800
Message-ID: <CAH1iCiqokZ-6t+=URdqN97fTJ9hyF6ube7zGkxYoeA6bkdx0Dg@mail.gmail.com>
To: John R Levine <johnl@taugh.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000de598057e7db081"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wB2EZdbZyNgwwuaX14R4YUKGpJc>
Subject: Re: [DNSOP] Variant bad idea of the day
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 02 Jan 2019 18:19:37 -0000

On Mon, Dec 31, 2018 at 4:29 PM John R Levine <johnl@taugh.com>; wrote:

> Let's assume for the purposes of argument that we have a DNS server that
> knows how to translate between A-labels an U-labels.  Then I invent this
> DNS record
>
>
Can I ask you to please describe in lay-persons terms what you are trying
to achieve, generally?

Is it the case that you have a bunch of labels that you want to have
treated as equivalent, and that at the terminus of any given FQDN involving
a sequence of equivalence-sets of labels, there is a single "canonical"
owner name for all the RRtypes/RRsets?

I think this can be solved today, using a couple of different methods
(where the distinction between them depends on whether you want/need things
like compatibility with other "stupid DNS tricks" like GeoIP).

The first method scales well, I think, at least on the authority side, but
might not play well with GeoIP.

This is to use DNAMEs for all of the variants, with all names being
letter-digit-hyphen format (a-label?), so for i18n stuff, xn--* format.

You would have, at each level of the equivalence region, things like:
xn--{n1's a-label} DNAME foo
xn--{n2's a-label} DNAME foo
...
xn--{nM's a-label} DNAME foo.

Generating/instantiating this at each level of a given FQDN with these
aliases is a bit of a pain, but basically only needs to happen once, and
only on the provisioning side of the house.
This works with all authoritative and recursive servers, AFAIK, since it is
just vanilla DNS.

The second method also scales pretty well, I think, but provides the
ability to make things like GeoIP work wherever in the {tree,forest,mess}
it is needed.

This is to use authority-size zone file references, and pull in identical
zone files by reference, rather than keep the parallel zones as separately
maintained entities.
This has a penalty for DNSSEC, since the owner name is part of the RRSIG,
and you have to sign the same zone file multiple ways.
The benefit is you can pick and choose places to break the symmetry, if
required.

This is to do server-side stuff instead of client-side stuff. (DNAME and
CNAME are client-side mechanisms). The downside of client-side is you lose
the ability to break out distinctly identifiable zones below a zone cut.

It's difficult to keep track of this without working some examples, so I'll
provide a few example namespaces first, and then use those to illustrate
the differences.

If the variants follow a pattern like www.{foo1,foo2,foo3}.{bar1,bar2,bar3}.
example.net, then the named.conf file would have things like:
zone "bar1.example.net" master file bar-master.example.net
zone "bar2.example.net" master file bar-master.example.net
...
zone "foo1.bar1.example.net" master file foo-master.bar-master.example.net"
etc

Then at arbitrary depths in your tree, you would still be able to have
distinct zone files (rather than common *-master files).
Since the clients don't get forced to rewrite their queries into once
branch of the namespace, the stupid DNS tricks can be applied on both the
client's IP and on the QNAME used, which continues to be distinct depending
on what the client application was asking for.

It can be made to scale using automation, but isn't completely "free",
especially if you make heavy use of stupid DNS tricks.

The canonical example for the second mechanism would be where the aliasing
isn't glyph based, but is language/translation based, such as the same word
in different languages, like "school" (english) and "ecole" (french, minus
accents). You might have a tree of equivalent terminology in different
languages, but at the leaf nodes you might want the RRs to be distinct on
the basis of which language is used for the leaf node itself. If you do any
client-side mechanism, you lose the ability to maintain those sets of
records as language-specific zones, and are forced to combine all the
languages into a single large zone.

This is probably not a good example, and I think is not generally useful
for the glyph-based stuff.

However, the former (first method) may work well, or well enough, to
preclude putting anything u-label-based into DNS, or any requirement for
handling that on authority servers, or for updating resolvers to handle
anything new.

Brian


> foo VARIANT n1 n2 n3 n4 ...
>
> The fields are 32 bit ints, each of which is interpreted as a UTF-32 code
> point.  The meaning is that in the subtree at and below this name, n1 is a
> canonical code point and the rest are variants.  If you get a request with
> an a-label that doesn't exist, turn it in to a u-label, replace any of the
> variants n2..nx with canonical n1, turn it back into an a-label and try
> again.  It might synthesize new RRs for the requested name, or CNAMEs give
> or take the CNAME at the apex issue.
>
> The idea is to have a bunch of VARIANT records at the apex that describe
> the LGR variants for the zone, and the server applies them to all of the
> names in the zone.  With lots of names and lots of variants, this lets the
> server handle a potentially exponential set of names without an
> exponential set of records.
>
> Bad things:
>
> * It's really ugly, crosses the boundary between A-label and U-label
> * The set of VARIANT records could be pretty big, thousands to handle
> traditional and simplified Chinese (although in a zone without dynamic
> updates you could prune it to the characters that occur in names in the
> zone)
> * Needs online signing
> * Could get kind of strange delegating sets of names across an NS
> * Doesn't handle conditional stuff in LGRs although I'm not sure how
> important that is in this case.
> * Not obvious how to signal to the client what the base version of a
> synthesized name was, if the client wants to treat all the variants "the
> same"
>
> Good things:
>
> * Handles M**N names with linear number of records.
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>