Re: [dbound] [EXTERNAL] Re: RDBD 01 Comments

Grant Taylor <gtaylor@tnetconsulting.net> Fri, 22 March 2019 15:22 UTC

Return-Path: <gtaylor@tnetconsulting.net>
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 DB1C0130F2A for <dbound@ietfa.amsl.com>; Fri, 22 Mar 2019 08:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net
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 IXqHeUEHrCEk for <dbound@ietfa.amsl.com>; Fri, 22 Mar 2019 08:22:14 -0700 (PDT)
Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9::8849]) (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 84934130F28 for <dbound@ietf.org>; Fri, 22 Mar 2019 08:22:14 -0700 (PDT)
Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id x2MFMBCj031560 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <dbound@ietf.org>; Fri, 22 Mar 2019 10:22:13 -0500
ARC-Filter: OpenARC Filter v0.1.0 tncsrv06.tnetconsulting.net x2MFMBCj031560
Authentication-Results: tncsrv06.tnetconsulting.net; arc=none header.d=tnetconsulting.net
ARC-Seal: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1553268133; cv=none; b=ZhmaIYnAHyTuuCE849FBMvKP/1fM3AWYyJAsSrgAt15p4LAKpcF3oI7TOyknXQIiJkbEqNiMmiMhTtWxSIvTY5BDhqauU0F4jECrKAo8lSMsPsW/26A6Iljr6STkZciuSWNcSL3ASIbL0ZnKVSSfq53TRLtKC1xyloazc4Xi1lM=
ARC-Message-Signature: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1553268133; c=relaxed/simple; bh=94Jlj/44N6tzupzrV73orJ58HM7LCnIr+tVkieuR+Xs=; h=DKIM-Signature:Subject:To:From:Message-ID:Date:User-Agent: MIME-Version:Content-Type; b=hdXCXQ5nT6sqxc4C0YioApbe5DgeX58DXjqQrXTUu2d//u7QXkQpGDSo+c5HOscZ6GD9bWrjma/b+PSV+Ep8MQfwGQjJg/yj58VtU5gZ55Cra8Q5ORi5tv9HiJnDeOKoKciNvRFJgX7KHLvLHzrpTW1icqKEu/BfaK/lOD5uDho=
ARC-Authentication-Results: i=1; tncsrv06.tnetconsulting.net; none
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2019; t=1553268133; bh=94Jlj/44N6tzupzrV73orJ58HM7LCnIr+tVkieuR+Xs=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=dby565kJaIQqCFH9y30rQkHlqEzCyDWQm1fTYFfdJYBDV9vDPACTvSYU3FnyK+T9a dTcZcd4FkFqn3Elgf9DymFBTObyzs5eCkMH26Jbpho5FStMBueAFCkDFmzcmuUvCUH HBoBfZ0jibQpHy5/jOMqWOFGuZ8XVaekP54YzNQM=
To: dbound@ietf.org
References: <ac159edaa05641ffa59e7358209ea0a4@COPDCEX19.cable.comcast.com> <20190320180341.9885A20104BD45@ary.qy> <69eefc3fb8244b529ba9dcfea6c01489@COPDCEX19.cable.comcast.com>
From: Grant Taylor <gtaylor@tnetconsulting.net>
Organization: TNet Consulting
Message-ID: <8b1e7fb0-1fad-bcae-780e-3fcd127e32f3@spamtrap.tnetconsulting.net>
Date: Fri, 22 Mar 2019 09:22:11 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <69eefc3fb8244b529ba9dcfea6c01489@COPDCEX19.cable.comcast.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080700060007070304010305"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/cPUM4AKeowvUPQY3wclWQpAKgEE>
Subject: Re: [dbound] [EXTERNAL] Re: RDBD 01 Comments
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: Fri, 22 Mar 2019 15:22:17 -0000

On 3/22/19 7:01 AM, Brotman, Alexander wrote:
> The original intent was a providing a bit more of a hurdle to falsifying 
> responses.

I need to re-read things, but I don't recall why anything needs to be 
complex.  Why can't DomainA.example publish a (simple) record stating 
that it asserts a relationship with DomainB.example.  Ideally, vice versa.

> I didn't think we could realistically rely on DNSSEC as a requirement 
> (I'm imagining a situation where we have DNSSEC, and someone goes off 
> to Route53 to host a domain where DNSSEC is not supported last I knew),

IMHO, more and more things significantly benefit from (if not actually 
need) DNSSEC.  As such, I think we should quite coddling things that 
don't support DNSSEC.  Especially when we are designing things for the 
future.  Design for what we want.  At least unless there is a 
significant reason to not use something like DNSSEC.

Also, I do believe that if enough people want to use technologies that 
need DNSSEC, they can exert enough market pressure to get Route53 (et 
al.) to support DNSSEC.



-- 
Grant. . . .
unix || die