Re: [dbound] [DNSOP] Related Domains By DNS (RDBD) Draft

Paul Wouters <paul@nohats.ca> Wed, 27 February 2019 16:52 UTC

Return-Path: <paul@nohats.ca>
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 81F3613100F; Wed, 27 Feb 2019 08:52:24 -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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 1Is88ExoKWNF; Wed, 27 Feb 2019 08:52:23 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E521310ED; Wed, 27 Feb 2019 08:51:52 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 448hY25d53zD0B; Wed, 27 Feb 2019 17:51:50 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1551286310; bh=1oY9dTxQ0JxsdXArs2/xibi16IT2WHpwHX0qaUwllIo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=nhhlYx63R4ek0Z3YwUeW9Z1MOT75wvm35SUMeD548TG/kPRpJkNb+vsD3/Dr+LHt4 naKzHGTY5XrZ8vZ8uewK2i/Psc6kfqbr4QgVskxRu6L0dVbO+4+oSK2Ar9swbrC3a6 fbNHXl2ywLUP5I/HrHqeL8gCZTW7ZiA9PwR3gtQ4=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id C3He0oqEqrRR; Wed, 27 Feb 2019 17:51:49 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 27 Feb 2019 17:51:49 +0100 (CET)
Received: from [192.168.8.34] (nat05.wpe01.151FrontStW01.YYZ.beanfield.com [66.207.198.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id AB6DF5C85B; Wed, 27 Feb 2019 11:51:48 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca AB6DF5C85B
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Paul Wouters <paul@nohats.ca>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <804a305f4d1b40daa6e9ca9b3e97f96d@verisign.com>
Date: Wed, 27 Feb 2019 11:51:48 -0500
Cc: "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>, "Alexander_Brotman@comcast.com" <Alexander_Brotman@comcast.com>, "art@ietf.org" <art@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, "dbound@ietf.org" <dbound@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A59F2895-6369-4E84-A86B-C6585AB29D83@nohats.ca>
References: <5de9ba1c3ae34edb9c7f39e0e9c3b143@PACDCEX19.cable.comcast.com> <alpine.LRH.2.21.1902270920580.8896@bofh.nohats.ca> <alpine.LRH.2.21.1902271037500.21061@bofh.nohats.ca> <alpine.LRH.2.21.1902271053200.21061@bofh.nohats.ca> <d8ac67de-35ec-648c-df0e-662439463ec3@cs.tcd.ie> <804a305f4d1b40daa6e9ca9b3e97f96d@verisign.com>
To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/DQhNFhP1Z0EPNR6O7WqTaXVdopY>
Subject: Re: [dbound] [DNSOP] 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: Wed, 27 Feb 2019 16:52:25 -0000

If it is really only a variant, you should just DNAME it to the other domain ?

Sent from mobile device

On Feb 27, 2019, at 11:37, Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org> wrote:

>> -----Original Message-----
>> From: DNSOP <dnsop-bounces@ietf.org> On Behalf Of Stephen Farrell
>> Sent: Wednesday, February 27, 2019 11:15 AM
>> To: Paul Wouters <paul@nohats.ca>; Brotman, Alexander
>> <Alexander_Brotman@comcast.com>
>> Cc: art@ietf.org; dnsop@ietf.org; dbound@ietf.org
>> Subject: [EXTERNAL] Re: [DNSOP] [dbound] Related Domains By DNS (RDBD)
>> Draft
>> 
>> 
>> Hiya,
>> 
>>> On 27/02/2019 15:54, Paul Wouters wrote:
>>> How is this data being consumed by the enduser ?
>> 
>> Very good question. Sorry for what's likely a longer answer than you want:-)
>> 
>> Alex and I chatted about that and I think ended up
>> figuring: a) there are many potential semantics that could be associated with
>> such a linkage, b) we don't yet know what'd be useful, but c) no, we are defo
>> not trying for an EV-like thing and lastly d) we really want to keep this as
>> simple as possible - given there's a lot of feature-creep potential here, and
>> that'd likely be fatal.
>> 
>> My own use-case for this relates more to surveys, where I'd like to get a hint
>> that two names are related so I could take that into account. Alex's is more
>> business like (as you'd expect:-) he'd like to be able to feed this kind of
>> linkage information into mail processing, e.g. perhaps to treat some mails as
>> less-likely spam if he sees a link, compared to if he doesn't (with all the other
>> mail processing foo that'd clearly be required to not do that kind of thing
>> stupidly of course). We guess that there'd be other uses too but finding out if
>> this is seen as useful enough that people would publish RR's is part of why
>> we shot out the draft now.
>> 
>> We also considered whether or not to e.g. try to add some kind of flag to
>> indicate semantics but reckoned we don't know enough to do that for now.
> 
> This might also be useful for IDN variants where some downstream consumer would like to know that two different IDNs are actually "the same". The relationship between variants isn't a parent-child relationship (they're more commonly siblings), but perhaps the concept could be extended to identify sibling relationships, too.
> 
> Scott
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop