Re: [DNSOP] Tell me about tree walks

Paul Vixie <paul@redbarn.org> Thu, 12 November 2020 05:29 UTC

Return-Path: <vixie@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639EB3A141B for <dnsop@ietfa.amsl.com>; Wed, 11 Nov 2020 21:29:09 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 20zrnRECVKCk for <dnsop@ietfa.amsl.com>; Wed, 11 Nov 2020 21:29:08 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139443A1419 for <dnsop@ietf.org>; Wed, 11 Nov 2020 21:29:08 -0800 (PST)
Received: by family.redbarn.org (Postfix, from userid 716) id CDF16C3F03; Thu, 12 Nov 2020 05:29:07 +0000 (UTC)
Date: Thu, 12 Nov 2020 05:29:07 +0000
From: Paul Vixie <paul@redbarn.org>
To: Joe Abley <jabley@hopcount.ca>
Cc: Tony Finch <dot@dotat.at>, dnsop@ietf.org, John Levine <johnl@taugh.com>
Message-ID: <20201112052907.77ws4glvt6l5f4zr@family.redbarn.org>
References: <20201111181423.7B1A9262936D@ary.qy> <alpine.DEB.2.20.2011112128510.17264@grey.csi.cam.ac.uk> <20201111220822.34bia6nagfnimwuw@family.redbarn.org> <8D01ED99-7F80-4D0E-A791-7DFF84E0F75C@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8D01ED99-7F80-4D0E-A791-7DFF84E0F75C@hopcount.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RJUzWnSQVDTOC6B7hkzYOHwg-_8>
Subject: Re: [DNSOP] Tell me about tree walks
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2020 05:29:09 -0000

On Wed, Nov 11, 2020 at 05:45:52PM -0500, Joe Abley wrote:
> On 11 Nov 2020, at 17:08, Paul Vixie <paul@redbarn.org> wrote:
> 
> > if you guys are going to automate and secure the public suffix list
> > functionality, please spare a thought for automated / at-scale ("not
> > in whois") identification of the domain's registrar and registrant.
> 
> I understand the reason why being able to identify the registrar for a
> particular domain is useful (or "necessary" depending on your perspective).
> I don't understand the overlap between this problem and the problem that
> John is trying to solve, though. Could you explain?

i'm happy to try. otherwise i'll just be sheltering in place.

what the public suffix list does is keep track of a set of labels under
which responsibility has almost always shifted. for example, under COM,
unless it's verisign.com, the "." between example and com in example.com
represents a change-of-party. knowing when this happens is necessary for
a lot of security-related purposes, for example, same-origin web policies
where labs.fsi.io may want to emit a cookie for fsi.io or www.fsi.io but
should be prevented from emitting one for gandi.io ("won't be believed").

doing this syntactically failed, because of co.uk and a lot of other
things that aren't TLD's but act like them (subdomains belong to someone
other than the delegator.) the public suffix list avoids syntax limits
by simply listing all the domains whose subdomains belong to others.
this comes up in dynamic dns providers also; it's not just a TLD thing
or an "effective TLD" thing. however, the public suffix list should
remind us all of HOSTS.TXT, and we should remember why DNS was invented.

so, some signal pattern (e.g., an RRset) that was in-band (not in a file)
and available at-scale (subject to DNS caching) could at a minimum solve
the problem john brought up, asserting for example that "subdomains of COM
are different parties".

what i'm asking is that if we're going that far we overload this signal
pattern slightly by letting it assert that "the registrar for fsi.io is
gandi" or even "the registrant for fsi.io is farsight". an RP RR could
be used. if you find an RP at some dns vertex you can assume it's only
there because it differs from the parent, or you can tree walk to be
sure, if you care.

but where to find that RP isn't obvious. fsi.io may be a criminal who
does not want anyone to know who its registrar (or registrant) was. so
a cousin domain such as should have been used for DS might be specified:
look in at fsi._registrar._meta.io and fsi._registrant._meta.io for them.

this is many orders of magnitude more state mass than would be required
just for io (and com and co.uk and so on) to say "my subdomains belong
to other parties") but would provide a useful metric for service quality
differentiation among registrars, and would also solve for john's need.

people you (joe) know personally would love to be able to tell potential
customers that if they don't want their domains marked in this way, they
should find some registrar who cares less.

-- 
Paul Vixie