Re: [dbound] RDBD Questions
Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 22 July 2019 22:57 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 658BC1200BA for <dbound@ietfa.amsl.com>; Mon, 22 Jul 2019 15:57:43 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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=Fn8QLCqO; dkim=pass (1024-bit key) header.d=yitter.info header.b=GErDLoUl
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 Hfsw2OI__xQ5 for <dbound@ietfa.amsl.com>; Mon, 22 Jul 2019 15:57:41 -0700 (PDT)
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 0AEA21200DE for <dbound@ietf.org>; Mon, 22 Jul 2019 15:57:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 216AABCD30 for <dbound@ietf.org>; Mon, 22 Jul 2019 22:57:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1563836260; bh=FKqfDhfqBYfq39hzsWVbZq42g0ThZj0Xd6pab3PuvsM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Fn8QLCqOAcRSA9nEfwm/lWpZjSt+VrYEfLv+Bu/LKak6anoeTChsO/qmwiSFTr+Pr nye8fE/mw5KWeZkCJU0ZOIHGneNsXm/DrV7MF6c0zkTtvUpQpoLh/pVNFoDd1m5S1Q ZX4yYlgZOoFYulX0MWVldGxHpTrZmM2xfwxjzyr4=
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 OXoqbyZgn08B for <dbound@ietf.org>; Mon, 22 Jul 2019 22:57:38 +0000 (UTC)
Date: Mon, 22 Jul 2019 18:57:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1563836258; bh=FKqfDhfqBYfq39hzsWVbZq42g0ThZj0Xd6pab3PuvsM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=GErDLoUl+uYIIBROM/kWLDSZBLaGr9RHCDGFw6FWceYujjthMSOUVfci4ef5MiD8d eZyZVZ8mDpDA6e/DlHisxe/PWH73CVuBmhQ1DHSvhHy+qmAxVc2kSlpkbG21bZIZMP SXn5p/jtZYvvfRwwCEzNfVKgJC+7Huk6jiTlPikY=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20190722225736.4nz4xziuogtvpapo@mx4.yitter.info>
References: <e90bf1c1071b4255841c6b99bd668cb8@COPDCEX19.cable.comcast.com> <75544bed-e393-b9f6-04c4-00164169f5ea@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <75544bed-e393-b9f6-04c4-00164169f5ea@cs.tcd.ie>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/ePq3On0wqDsSYVACUf1MY3jKko4>
Subject: Re: [dbound] RDBD Questions
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: Mon, 22 Jul 2019 22:57:44 -0000
Hi, As usual, though I happen to be employed by the Internet Society, I'm speaking for myself here. On Mon, Jul 08, 2019 at 05:00:22PM +0100, Stephen Farrell wrote: > To add to your reading pleasure on I-D cutoff > day, we've updated the draft [1] as described > below. Comments welcome as always. I've read this. As you might imagine, I rather like what this draft is trying to do. I also like the symmetry with the CDNSKEY trick, though I'm not sure it's going to work. Thanks for doing this, in any case, because I'm happy to see someone trying to solve this problem. One of the things that I think the draft would benefit from is some terminological distinctions that I think have long been missing. I think this shows up right in the introduction: Determining relationships between registered domains can be one of the more difficult investigations on the Internet. In some sense, of course, this is plainly false. "Is an ancestor of" and "is a descendent of", in the strict graph-theoretic sense of the meaning of "relationship", is easy to decide. All other relationships, in the DNS, are _from the point of view of the DNS_, not that interesting. The problem the draft is trying to address, however, is _not_ a DNS relationhip. Instead, it's an attempt to affirm that there is a _policy_ relationship between two domains. This is reasonably clear if you look at the use cases in the bullet list. I think that some of the conceptial material might be lifted from https://tools.ietf.org/html/draft-sullivan-dbound-problem-statement-02 or maybe https://www.ietf.org/archive/id/draft-sullivan-domain-policy-authority-02.txt or https://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02 (I tried, fruitlessly, more than once, as you can see :) ) One of the potential snags I see in here is a possible trap involving the nature of domain names. It's contained in this observation: "RDBD is intended to declare or disavow a relationship between registered domains, not individual hostnames." The problem is, basically, that inside the DNS there's actually no way to specify that distinction without querying for a bunch of SOA records, because every valid domain name is also trivially a valid owner name for an A or AAAA record and also a valid point for there to be a delegation. Indeed, a domain can also be a hostname easily. (It might be worthwhile having a look at https://tools.ietf.org/html/rfc8499 to see whether the terminology aligns really, though I suspect so. The real problem is the ambiguity in the relationship between domain names and hostnames.) I totally do not understand this claim: RDBD relationships are uni-directional. If bi-directional relationships exist, then both domains can publish RDBD RRs and optionally sign those. The relationships in question are necessarily policy relationships. In that sense, it is simply impossible for the relationship to be unidirectional, because it is a way of the "setting" side of making claims that are somehow supposed to be satisfied by the "setted" side of the relationship. Moreover, whenever you have a domain that appears to be a relating-domain that makes an assertion about a putatively related-domain, it seems to me that you need to check at the related-domain to see whether the putatively related-domain actually in fact has a repudiating record. It strikes me that the lookup loop problem in 6.3 happens precisely because of the unidirectionality of the definition. That is, if you had a bidirectional requirement, then it would be effectively impossible to have the chained loop described because the bidirectionality would cut that off. This would also avoid adding the somewhat arbitrary limit of how many lookups one ought to do. (I observe also that this SHOULD in section 6.3 doesn't really comport with the 2119 meaning of SHOULD, though I'm not one of the bossypants people about these uses.) Hope these comments are useful. A -- Andrew Sullivan ajs@anvilwalrusden.com
- [dbound] RDBD Questions Brotman, Alexander
- Re: [dbound] RDBD Questions Stephen Farrell
- Re: [dbound] RDBD Questions Andrew Sullivan
- Re: [dbound] RDBD Questions Stephen Farrell
- Re: [dbound] RDBD Questions Andrew Sullivan
- Re: [dbound] RDBD Questions Stephen Farrell
- Re: [dbound] RDBD Questions Murray S. Kucherawy
- Re: [dbound] RDBD Questions Tim Wicinski