[DNSOP] Variant bad idea of the day

"John R Levine" <johnl@taugh.com> Tue, 01 January 2019 00:28 UTC

Return-Path: <johnl@taugh.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 35B93126C7E for <dnsop@ietfa.amsl.com>; Mon, 31 Dec 2018 16:28:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=lEHIi6t2; dkim=pass (1536-bit key) header.d=taugh.com header.b=LS/SYj8U
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 6NVSrft7_M_v for <dnsop@ietfa.amsl.com>; Mon, 31 Dec 2018 16:28:50 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA9BE124BAA for <dnsop@ietf.org>; Mon, 31 Dec 2018 16:28:49 -0800 (PST)
Received: (qmail 88515 invoked from network); 1 Jan 2019 00:28:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=159c0.5c2ab440.k1812; bh=j87mus7legm3VEV9GlboaNNIpo01ExtY0+s6/kXrKJo=; b=lEHIi6t2kuZcuQvEkNPd0nlddenc0qIziq8xXX46coMN43U72my1YbGdl2bTy6ucVitPwrIUPgDLZ92yhdfijZIHUbSsA8hXPkmXCsXOqNWjCyP58IIqWWDTskEv6SfzqzEj5F7D1GqTKETHm46MXwtCWo+7wGiNK4S5aN2I5WLxy28dvsCz3HCaQr50abtvmWwpBzfnb2mBJNl09Mfgky5kzA6VjSySNeIYMpXU/vadgR0wh9R3lfVPcqQiZC65
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=159c0.5c2ab440.k1812; bh=j87mus7legm3VEV9GlboaNNIpo01ExtY0+s6/kXrKJo=; b=LS/SYj8Uf6X0VJ9JagBVwsi2y28DnmFFyVIcTa/Mvsrqyxsicw1sn4KUiwti8R9hVtkqSGebEHLEUCRT9crFcqD0EcKnsPUxnkoninUewoA1KokDZcwnSkRTtjB0CsOW6Qv/704GGjEHoRQRage+AriKB+H8Ycefqu0l8ttZ0Num8z6NgbRkY8dg76SetKtIdZHClH+ONrEeNZzqzbgr9qpB+1ERSf2wZpGIyELvT1YWB5vP9nxBRGD8c5P/Jr4P
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 01 Jan 2019 00:28:47 -0000
Date: Mon, 31 Dec 2018 19:28:47 -0500
Message-ID: <alpine.OSX.2.21.1812311912250.81953@ary.local>
From: John R Levine <johnl@taugh.com>
To: dnsop@ietf.org
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JlaZcq5HoN9xEOFo_bZlw4AeoqM>
Subject: [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: Tue, 01 Jan 2019 00:28:52 -0000

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, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly