[dbound] RDBD Questions

"Brotman, Alexander" <Alexander_Brotman@comcast.com> Wed, 05 June 2019 14:36 UTC

Return-Path: <Alexander_Brotman@comcast.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 56548120146 for <dbound@ietfa.amsl.com>; Wed, 5 Jun 2019 07:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eUl3bUfsO-dl for <dbound@ietfa.amsl.com>; Wed, 5 Jun 2019 07:36:42 -0700 (PDT)
Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com []) (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 1BB18120145 for <dbound@ietf.org>; Wed, 5 Jun 2019 07:36:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1559745378; x=2423658978; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JPvynseOhjYcLnikh8Gy0P2xCjeICPooB1/hF7C8aK4=; b=6GaPI/Ln3cumuI7pho8gKtylfUTrfMzZwUExY54WM7jK5YBlVqhn7C6vDEFPQaj/ mXthbb++5OMEnEWzyI2T1ABJJW1svpH5ELopd7SoV7MLOZclGwMge6X9vN9oifok NV1PfPemw5ddQbCfrojcYPM018b4935oBgSHovd9UHceg4eeoIYhZxg6CK725xh7 0KLE6NHOqa+f5nCsYeGWXAmRpwTcrWIpAKyTL3mrlPQw3cQk9U51+nz8tHDiIO+a 0uQnHXcFWhEDkgaKA/lwdhLWdglstrHlRAmvZDNAhOQP90YXKJCK+6djbTccjiEu err47dPO/9CDcbp7sTBk0A==;
X-AuditID: a2962c47-cebff70000021564-75-5cf7d362394c
Received: from COPDCEX18.cable.comcast.com (copdcmhoutvip.cable.comcast.com []) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id D3.17.05476.263D7FC5; Wed, 5 Jun 2019 08:36:18 -0600 (MDT)
Received: from COPDCEX19.cable.comcast.com ( by COPDCEX18.cable.comcast.com ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 5 Jun 2019 08:36:26 -0600
Received: from COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380]) by COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380%19]) with mapi id 15.00.1473.004; Wed, 5 Jun 2019 08:36:26 -0600
From: "Brotman, Alexander" <Alexander_Brotman@comcast.com>
To: "dbound@ietf.org" <dbound@ietf.org>
Thread-Topic: RDBD Questions
Thread-Index: AdUbq/YfMyrF/wrcSlqq/9FGhGzr8A==
Date: Wed, 5 Jun 2019 14:36:26 +0000
Message-ID: <e90bf1c1071b4255841c6b99bd668cb8@COPDCEX19.cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsWSUDRnsm7S5e8xBlde8ljsunyN3YHRY8mS n0wBjFENjDYlGUWpiSUuqWmpecWpdlwKGMAmKTUtvyjVNbEopzIoNSc1EbsykMqU1JzMstQi fazG6GM1J6GLKeP76j3sBR94K9pnfmdpYGzk7mLk4JAQMJHo/+bRxcjJISRwmEli+hqRLkYu IPsgo0Tvo9msEM4JRomd0z6xgVSxCVhJvP3fzgxiiwioS7xfdQ7MFhaQkLj2tokNIi4r0XXj IhOErSfxeNsjVhCbRUBF4kPfHEYQm1fAS2L1ioPsIDajgJjE91NrwOqZBcQlbj2ZD2ZLCAhI LNlznhnCFpV4+fgfK4RtILF16T4WiAfkJT7OhWrVkViwG+JMZgFtiWULXzNDrBKUODnzCQtE q7jE4SM7WCcwis5Csm0WkvZZSNpnIWlfwMiyipHX0MxIz9DUQM/ERM/ccBMjMOIXTdNx38H4 4XzsIUYBDkYlHt4vh77HCLEmlhVX5h5ilOBgVhLhTbz9JUaINyWxsiq1KD++qDQntfgQozQH i5I47+HD32KEBNITS1KzU1MLUotgskwcnFINjL7lufv5pvyv9lzkyh04q3fOdpdVWdMTO/Yl ej63XBC6VTF006YF+gunc21YZ/9Bi8vT6oLVRX8h69lrhMv1PuxX0/oqtMNSLfRm7orIXp89 ZVahfQ8udSjdk+znsIkzeJ3zsKF+25qjZkrfjz4tmhK4dVNbrvHHzh37IrsmH+ksOj5lUfw2 aSWW4oxEQy3mouJEAFf2klH0AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/oMNWuQrftEZd9Id0jrt8HxQnvrQ>
Subject: [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: Wed, 05 Jun 2019 14:36:43 -0000

Hello all,

Stephen and I were able to sit down and discuss the feedback that was received during IETF and via the mailing list.  Based on that conversation, we're planning to make the following changes but would be happy to get any feedback before/as we do that.

1) A couple of people wanted a method for disavowing a relationship, i.e. making a negative assertion.  We believe we can achieve this by defining another tag within the RDBD RR.
2) As part of adding negative assertions, we're proposing that we make it so that any place where you might list a single name today, you could alternatively point to an HTTPS URL that points at a file containing a list of names.  When doing the negative assertion, this'd allow for an easier method to list numerous entries.
3) We'll explicitly document that the RDBD record type envisages multi-valued responses just to make it clear that both positive and negative records can be found at the same location.
4) We're not sure if there is a preference for the DNSSEC-style RR value we used in the 01 draft, or for the DKIM-style value that was used in the 00 draft. (We will of course stick with a new RRTYPE and not go back to abusing TXT:-) The end result is the same, but the format of the record value may make more sense to some parties in one format or the other.  For the DKIM-style, this is a familiar format to many who have worked with SPF/DKIM/DMARC records.  On the other hand, the DNSSEC-style might be more familiar to those managing the DNS systems. We've not yet decided which we prefer ourselves, so feedback on this is most welcome.

Thank you again for your feedback.

Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy