Re: [dbound] [art] [DNSOP] not DNAME, was Related Domains By DNS (RDBD) Draft

John C Klensin <john-ietf@jck.com> Thu, 28 February 2019 03:52 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 75E1E130DC4; Wed, 27 Feb 2019 19:52:22 -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 hvTYCFnITY5z; Wed, 27 Feb 2019 19:52:21 -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 DA5D312F18C; Wed, 27 Feb 2019 19:52:20 -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 1gzCk7-0000sy-0y; Wed, 27 Feb 2019 22:52:19 -0500
Date: Wed, 27 Feb 2019 22:52:13 -0500
From: John C Klensin <john-ietf@jck.com>
To: John R Levine <johnl@taugh.com>
cc: art@ietf.org, dbound@ietf.org
Message-ID: <49A2FC767B5A7146F39456B9@PSB>
In-Reply-To: <alpine.OSX.2.21.1902272038320.3336@ary.local>
References: <20190227172143.10303200F57CE0@ary.local> <1FFA1977E97DE99C390869DA@PSB> <alpine.OSX.2.21.1902272038320.3336@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/fUY-zK0Xpet_zlQOPHpsSxL8_Uo>
Subject: Re: [dbound] [art] [DNSOP] not DNAME, was 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: Thu, 28 Feb 2019 03:52:23 -0000


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

> On Wed, 27 Feb 2019, John C Klensin wrote:
>> at least one aspect of it is probably worth mentioning.  It
>> requires understanding "tree" but not any special
>> understanding of IDNs, variants, etc.
> 
> You don't even have to go that for.

Actually, you are identifying cases I was deliberately avoiding,
precisely because fixes have been proposed that might almost
work but that still don't solve, or allow solutions for, the
tree problem.

>  Let's say you do this:
> 
> foo.com. DNAME bar.org.
> 
> Then www.foo.com will be an alias for www.bar.org, but DNAMEs
> only affect names below themselves, so foo.com will remain
> undefined, and you can't put a CNAME and a DNAME on the same
> name.  This makes it useless for what most people imagine they
> want to use it for.

Yes.

> There's the additional issue that an MX with a target of a
> CNAME or DNAME doesn't work reliably,

"doesn't work reliably" may or may not be a synonym for "is
explicitly prohibited by SMTP" but the latter is true is any
event.

>  and the point you made
> that if you've got variants, you can get a very bushy tree
> every time a variant character appears in a label.

Yep.  And that raises several other issues with this proposal,
all of which I was trying to avoid because they are (i) more
complicated and (ii) involve more or less subtle DNS issues.

> This issue has been argued at great length with proposals like
> BNAME and CLONE so let's not redo it here.

Indeed.

    john