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

Grant Taylor <> Fri, 22 March 2019 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB1C0130F2A for <>; Fri, 22 Mar 2019 08:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IXqHeUEHrCEk for <>; Fri, 22 Mar 2019 08:22:14 -0700 (PDT)
Received: from ( [IPv6:2600:3c00:e000:1e9::8849]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84934130F28 for <>; Fri, 22 Mar 2019 08:22:14 -0700 (PDT)
Received: from Contact-TNet-Consulting-Abuse-for-assistance by (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 <>; Fri, 22 Mar 2019 10:22:13 -0500
ARC-Filter: OpenARC Filter v0.1.0 x2MFMBCj031560
Authentication-Results:; arc=none
ARC-Seal: i=1; a=rsa-sha256;; s=2015; t=1553268133; cv=none; b=ZhmaIYnAHyTuuCE849FBMvKP/1fM3AWYyJAsSrgAt15p4LAKpcF3oI7TOyknXQIiJkbEqNiMmiMhTtWxSIvTY5BDhqauU0F4jECrKAo8lSMsPsW/26A6Iljr6STkZciuSWNcSL3ASIbL0ZnKVSSfq53TRLtKC1xyloazc4Xi1lM=
ARC-Message-Signature: i=1; a=rsa-sha256;; 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;; none
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; 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=
References: <> <20190320180341.9885A20104BD45@ary.qy> <>
From: Grant Taylor <>
Organization: TNet Consulting
Message-ID: <>
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: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080700060007070304010305"
Archived-At: <>
Subject: Re: [dbound] [EXTERNAL] Re: RDBD 01 Comments
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS tree bounds <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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