Re: [dbound] draft-brotman-rdbd

Andrew Sullivan <ajs@anvilwalrusden.com> Thu, 28 February 2019 10:59 UTC

Return-Path: <ajs@anvilwalrusden.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 E1E0512D4E8 for <dbound@ietfa.amsl.com>; Thu, 28 Feb 2019 02:59:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=JF2aQVM0; dkim=pass (1024-bit key) header.d=yitter.info header.b=P4F5nccb
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 MfawZJFeBBLo for <dbound@ietfa.amsl.com>; Thu, 28 Feb 2019 02:59:09 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5984128BCC for <dbound@ietf.org>; Thu, 28 Feb 2019 02:59:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 88767BCBCC for <dbound@ietf.org>; Thu, 28 Feb 2019 10:59:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1551351548; bh=fx3OkYkyz6HFyZcOBU2csI74KZuNsGnY0ij+cay85ao=; h=Date:From:To:Subject:References:In-Reply-To:From; b=JF2aQVM0ADhrsS9jYU9X8w/loE2Eo8zRBWqNM9qqzkXdOnsiE8+HabNEl+HlPRd6Y GAAyEnoBzr0jGXxDzA8muAhRLuRDrm3YHErxUYpPIjxsgYRmE+OZKf19R6d/jvwMwG UzmpJ334n7OSJwTxB45V1sFQbNu4FD6fZlNKvIzI=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZ1PyBTW_977 for <dbound@ietf.org>; Thu, 28 Feb 2019 10:59:07 +0000 (UTC)
Date: Thu, 28 Feb 2019 05:59:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1551351547; bh=fx3OkYkyz6HFyZcOBU2csI74KZuNsGnY0ij+cay85ao=; h=Date:From:To:Subject:References:In-Reply-To:From; b=P4F5nccb5dlckHzQFVlokMgYnUzqWd7mQPb5Qb31XnwQs+UO8cP76CW0IAjm35i+a EgWTAicsWSl5boG8SXCMjhkeArNnfdV215VRbrseRINPSNxAXVsOpFlGD8oHmqgYua d1Q5UTe+7k3zJEo2KdCTiJCVs+xJwS2FO+kfik4A=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20190228105902.4z3o6x7lavkhd4xk@mx4.yitter.info>
References: <20190228084640.vgexxwltqmshkf4q@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190228084640.vgexxwltqmshkf4q@mx4.yitter.info>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/5_olPey7JvzXKYZ9K2nC-hrmrL8>
Subject: Re: [dbound] draft-brotman-rdbd
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 10:59:12 -0000

Hi,

Since this is the place, I read draft-brotman-rdbd-00 and have a few
observations.

I'm slightly concerned at the way this is being conceived, because I
think it has a conceptual separation in it that is troublesome.  It's
found here:

   RDBD is intended to demonstrate a relationship between registered
   domains, not individual hostnames.  That is to say that the
   relationship should exist between "example.com" and "dept-
   example.com", not "foo.example.com" and "bar.dept-example.com".

The problem, of course, is that foo.example.com, bar.dept-example.com,
and really.long.set.of.labels.example.com are all _perfectly good_
domains.  Now, maybe what the above intends to communicate is that
RDBD is intended to demonstrate a relationship between the owner name
at an apex and all the subsidiary names in that zone (i.e. up until
any subordinate zone cut), and the owner name at an apex and all the
subsidiary names in _that_ zone.  Alternatively, maybe what the above
intends to communicate is that RDBD is intended to demonstrate a
relationship between owner names immediately below a so-called public
suffix.  I can imagine use cases for either, though I am not sure
they're as general purpose as people might think.

I am more than a little worried about the parent/secondary split.
(Also, both of these are already well-used terms in the DNS, so I
really strongly urge some other terms.  We have enough trouble with
overloading DNS terms without doing so with two of the most frequently
used terms in DNS operations, particularly when this mixes terms from
delegation and from zone transfers.)  It isn't clear to me, from the
discussion, that it is obviously true in most of the use cases people
have that one of the domains people want to talk about is "the main
one".  More importantly, it is quite likely that someone trying to
query this will have a different idea about which is "main" than the
domain operator, so if this isn't a fully bidirectional operation
(which it's not in -00) there could easily be problems in use.  (This
is part of why SOPA was proposed to be two-way.)

If you're going to do this with TXT records, then you definitely need
an underscore label, or the apex name is going to be a mess.  But that
will mean that this won't work for DNAME.  That consideration is part
of why SOPA defined a new RRTYPE and put the RR at the name that was
supposed to be related.

I hope these comments are useful.  I have limited cycles to spend on
IETF stuff these days, but this was always a topic close to my heart
(and I'm super annoyed the DBOUND WG failed), so I'll try to keep up.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com