Subject: Re: [DNSOP] Variant bad idea of the day

From: "John R Levine" <[email-masked]>
Date: 1 Jan 2019 12:00:28 -0500

> If you get a request that include any of the code points {n1, n2,...}, 
> return a CNAME where nM is replaced with foo?

Not just at foo, but do the same thing on any name under foo.  The idea is 
to publish the LGR for the subtree and the server can handle all of the 
variants from one zone.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 01 Jan 2019 19:03:47 +0100

On 1 Jan 2019, at 18:00, John R Levine wrote:

>> If you get a request that include any of the code points {n1, n2,...}, return a CNAME where nM is replaced with foo?
>
> Not just at foo, but do the same thing on any name under foo.  The idea is to publish the LGR for the subtree and the server can handle all of the variants from one zone.

Got it. As long as the query reaches this server of course. You also mean auth servers from delegated zones can query for this explicitly and load its internal LGR from its parent?

   Patrik

---

From: "John R Levine" <[email-masked]>
Date: 1 Jan 2019 13:23:20 -0500

On Tue, 1 Jan 2019, Patrik Fältström wrote:
> Got it. As long as the query reaches this server of course. You also 
> mean auth servers from delegated zones can query for this explicitly and 
> load its internal LGR from its parent?

I hadn't worked it out that far but it would be a good idea if servers 
could automatically find out what their default variant rules are.  It's 
rather unexplored territory since until now a name server doesn't know or 
need to know what the parent servers for its zones are.  We do have the 
example of DS above and DNSKEY below to prove that two servers are in the 
same chain of authority, but that doesn't tell us how the child can locate 
the parent other than chasing down from the root.

Regards,

---

From: Brian Dickson <[email-masked]>
Date: Wed, 2 Jan 2019 10:19:21 -0800

On Mon, Dec 31, 2018 at 4:29 PM John R Levine <[email-masked]> 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,
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "John R Levine" <[email-masked]>
Date: 2 Jan 2019 14:48:49 -0500

> owner name for all the RRtypes/RRsets?

Basically yes, it's the IDN version of ASCII upper/lower case equivalence. 
If you have a label ABCD in your zone, it'll match abcd and Abcd and 14 
other upper-lower combinations.

> letter-digit-hyphen format (a-label?), so for i18n stuff, xn--* format.

Unfortunately this is a WKBI for multiple reasons:

* DNAME only maps names below it, not the name itself.  This is why this 
approach completely failed in the .CAT TLD to try and map accented to
unaccented names.

* DNAME only maps one name at a time, but a name can have many variants 
and there can be variants at every level, e.g., if a name is FOO.BAR, 
there's 8 possible variants for each label.

* DNAME synthesized names are not equivalent to the original, particularly 
for mail since MX to CNAME is not allowed and the rule is spottily 
followed.

Taiwan has a DNAME to map the simplified .台湾 to .台灣.  It sort of
works.

$ dig xn--kprw13d. dname

;; ANSWER SECTION:
xn--kprw13d.            3600    IN      DNAME   xn--kpry57d.

> zone files by reference, rather than keep the parallel zones as separately

That's not exactly a WKBI, but it only solves a small part of the problem. 
You can use it to map equivalent zones line foo.ngo and foo.ong, but it 
doesn't handle variant names within the zone.  I use it in my DNS toaster 
for a user who has a lot of vanity zones and want them all to point to the 
same place.

Regards,