Re: [DNSOP] Variant bad idea of the day

[Brian Dickson <[e-mail]>]

On Mon, Dec 31, 2018 at 4:29 PM John R Levine <[e-mail]> 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, [e-mail], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>