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

Suzanne Woolf <suzworldwide@gmail.com> Fri, 01 March 2019 13:49 UTC

Return-Path: <suzworldwide@gmail.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 259C9130E79 for <dbound@ietfa.amsl.com>; Fri, 1 Mar 2019 05:49:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 nUnZ_Zo2iXkV for <dbound@ietfa.amsl.com>; Fri, 1 Mar 2019 05:49:19 -0800 (PST)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16DEE124BAA for <dbound@ietf.org>; Fri, 1 Mar 2019 05:49:19 -0800 (PST)
Received: by mail-qt1-x830.google.com with SMTP id z39so27788395qtz.0 for <dbound@ietf.org>; Fri, 01 Mar 2019 05:49:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Izs/PxD2+eAASDTMxiBBVrq6Ss3DXLn3FfRa4h9oR10=; b=MyuIu0q4WhAw/XUypQqqRu0aD2cyZdBOKBh6DXKepDHpZHdoX+dloIYPEgW0dA2i29 Puxn/I0M/y536hCKU9rIx5gCrBfOgWTa0qqg01RuU41jKg7bjQ54k15F+OeEg9+3Yn3l H5Idx3JwilWBNg7+xfwtBvmOHYKamL8VgfGPmWjF4hasGQWxD6BSP6dVTj/ZLE2TcHqK IDl8LcXXb69wfPVlUUedosoo28sesXTiDvnQV02Ey8sxzZR/2T1PKQGmAaP9BRYdfGOe Z14ZKg9GuNJng0of3ZYcO/ttzf0FMFmCDd/s53A3mW41snZ9TWQB+ixo1fVE74vAM9Se fKuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Izs/PxD2+eAASDTMxiBBVrq6Ss3DXLn3FfRa4h9oR10=; b=P7yQeh9wTit0Ale7TKv2ykl62uB12+3yaKMoOLIH7cfE0MW+UuLDd1gRRwySpSudFF 5FlqJxuVMVf7DPKYdKqBV+FAcAWB6DpWzKUWEqBAqIwzPafA3k6e6LB8QAOwHTK15M07 xdOGmogvfx5gFrzz4blxGsMM1jsM1fA7PXt4Yk56hpf9iMOkxYt+Toocqguu6JEbFtnl 73KsNv4UCg3wkSs2Yvf/J47rlF4NwE35QnB9Lr+76pgOVBnefBHTXtusCmoeCgPsugcb 74MP1OPfoTRkNJ5HBy71FXdOMCVJ/lKXls6GVS45wM3asFt65FsgP+dQlnqMPrM14EzS 8pdw==
X-Gm-Message-State: APjAAAXNWztSer4sxAPW4AMSqkeECkwL3xICnV+35sgigfoTNwhsGB3x QzpGoMLNQMgrHZPK7jhy3QolQjy8
X-Google-Smtp-Source: APXvYqxHdaVJbFsX91qqdFyGBtgYZCgK/FdfFQjMGFrg1QtWRf3YLATHIW4rdD2hTi5O7x2i4D1PgQ==
X-Received: by 2002:a0c:d2d4:: with SMTP id x20mr1120042qvh.227.1551448157745; Fri, 01 Mar 2019 05:49:17 -0800 (PST)
Received: from ?IPv6:2601:181:c381:29fe:55e7:7561:af61:cbf1? ([2601:181:c381:29fe:55e7:7561:af61:cbf1]) by smtp.gmail.com with ESMTPSA id f29sm16308253qte.11.2019.03.01.05.49.16 for <dbound@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Mar 2019 05:49:16 -0800 (PST)
From: Suzanne Woolf <suzworldwide@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 01 Mar 2019 08:49:15 -0500
References: <20190227172143.10303200F57CE0@ary.local> <1FFA1977E97DE99C390869DA@PSB> <alpine.OSX.2.21.1902272038320.3336@ary.local> <49A2FC767B5A7146F39456B9@PSB>
To: dbound@ietf.org
In-Reply-To: <49A2FC767B5A7146F39456B9@PSB>
Message-Id: <A4E532F7-484E-4605-8D77-8E0A20A15014@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/jo_vmqkZ_l8Eh4PdkroJTblE3Vc>
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: Fri, 01 Mar 2019 13:49:22 -0000

Hi,

(I realize the current draft is a -00, so comments are intended to be helpful towards a -01, not complaints that a -00 isn’t cooked yet.)

> On Feb 27, 2019, at 10:52 PM, John C Klensin <john-ietf@jck.com> wrote:
> 
> 
> 
> --On Wednesday, February 27, 2019 20:48 -0500 John R Levine
> <johnl@taugh.com> wrote:
> 
> 
>> This issue has been argued at great length with proposals like
>> BNAME and CLONE so let's not redo it here.
> 
> Indeed.
> 

One high-level upshot of all this is that the usability of any mechanism that’s ever been proposed to implement notions like “related to” or “variant of” or “alias for” in the DNS depends a lot on exactly what behavior is desired for servers, resolvers, and applications….and what tradeoffs, in terms of security and administrative burden, are acceptable. 

The RDBD mechanism feels like it’s intended to be a building block to something else, maybe several somethings, but the effort to be simple and generally applicable means it’s hard to tell exactly what applications or use cases would benefit from it.

Previous discussions along these lines, as some comments upthread might make clear, tended to bog down in the fact that there are lots of nuances of behavior that people want in their “aliases” or “variants” or “related names,” and it can be hard to get the description right-- but otherwise, all too often it turns out that use cases that seem intuitively similar actually aren’t. Even conversations about “variants” in the context of IDNA tend to lead to sudden discoveries that in situations that are seemingly alike in all the important ways, the desired behavior is still very different for particular applications or users.

I’m not sure how to make this better, except the proposal as currently written is reminding me that previous attempts started simple and didn’t stay that way because the longer people looked at the set of problems they cared about, the more bells and whistles they felt they needed. This is a hard tendency to resist and requires a lot of clarity on the goals actually being pursued. (DNSOP discussions on proposals like ANAME and BNAME have demonstrated the same thing.)

My memories of DBOUND are not reliable but I do recall a distinct sense that people thought they were talking about "the same thing" and repeatedly discovering that maybe they weren’t.

Accordingly, I’d like to see an example or two of how you’d expect an application to use the kind of connection between domains established by the RDBD mechanism. 

I’m looking forward to reading the -01.




Suzanne