Re: [dbound] [art] [DNSOP] Related Domains By DNS (RDBD) Draft

John C Klensin <john-ietf@jck.com> Wed, 27 February 2019 20:54 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72EE130E77; Wed, 27 Feb 2019 12:54:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 gbjBvBn8f83u; Wed, 27 Feb 2019 12:54:28 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FC013112B; Wed, 27 Feb 2019 12:54:28 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1gz6Di-000PTj-56; Wed, 27 Feb 2019 15:54:26 -0500
Date: Wed, 27 Feb 2019 15:54:21 -0500
From: John C Klensin <john-ietf@jck.com>
To: John Levine <johnl@taugh.com>
cc: art@ietf.org, dbound@ietf.org
Message-ID: <1FFA1977E97DE99C390869DA@PSB>
In-Reply-To: <20190227172143.10303200F57CE0@ary.local>
References: <20190227172143.10303200F57CE0@ary.local>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/WtcMtX4ARU6JUPf2RhpUwwIVczk>
Subject: Re: [dbound] [art] [DNSOP] Related Domains By DNS (RDBD) Draft
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 20:54:30 -0000


--On Wednesday, February 27, 2019 12:21 -0500 John Levine
<johnl@taugh.com>; wrote:

> In article <A59F2895-6369-4E84-A86B-C6585AB29D83@nohats.ca>;
> you write:
>> If it is really only a variant, you should just DNAME it to
>> the other domain ?
> 
> I really wish people would stop saying this.  There is a long
> list of well known reasons that DNAME doesn't work for
> aliasing 2LD variants.

Because "let's throw DNAME (or a small variation) at variants"
comes up so often, while I agree with John about the long list,
at least one aspect of it is probably worth mentioning.  It
requires understanding "tree" but not any special understanding
of IDNs, variants, etc.

Suppose there is a relationship between two characters (fussy
definitions not required) X and Y such that one would like to
consider a label containing X but otherwise identical to a label
containing Y as making those labels "variants" of each other
(again, fussy definitions not required and this example works
for things like synonyms or even translations whether one calls
them "variants" or not.  Now suppose we have 
 
   abX.dXf.TLD   and
   abY.dYf.TLD

(or abX.ghi.dXf.TLD and abY.ghi.dYf.TLD)

These cases are going to be quite common with reasonable use of
such relationships if there is a predictable relationship
between X and Y that depends on local habits, different
languages using the same script, or the like.  Whether we are
talking about "variants" in the sense of RFC 3743 (the JET spec
that introduced the term), look-alike characters, different
spellings, or language translations, whatever principles cause a
need for such a pairing to occur at the second level are also
going to cause it to occur at the third level and below if the
same relationships hold.

The reasons why a cross-tree alias, like DNAME, between, e.g.,
dXf.TLD -> dYf.TLD either won't allow abY to exist and/or will
cause problems with whatever it is trying to accomplish are left
as an exercise, but the exercise should be very clear.
   
So I too wish that people would stop saying this, proposing
one-offs from DNAME, etc.

best,
    john