Subject: [DNSOP] Variant bad idea of the day

From: "John R Levine" <[email-masked]>
Date: 31 Dec 2018 19:28:47 -0500

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

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, [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 08:56:31 +0100

On 1 Jan 2019, at 1:28, John R Levine wrote:

> 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.

Hmm...you mean:

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

   Patrik