Re: [dbound] [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 03 April 2019 19:49 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 13A22120639; Wed, 3 Apr 2019 12:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 F1dpEDOYagev; Wed, 3 Apr 2019 12:49:27 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17FE120633; Wed, 3 Apr 2019 12:49:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 04C10BE58; Wed, 3 Apr 2019 20:49:19 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9qMws_3Qodx; Wed, 3 Apr 2019 20:49:14 +0100 (IST)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8368BBE55; Wed, 3 Apr 2019 20:49:14 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554320954; bh=8Ig524TwrnH/RFwIEiUmeZqI1ybBrTcu1l42CCtgm3Q=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=Wsv2HtitbfdM/yvP4dibJMB180NhHjF1zQvq83aSUTDzvTV6y9O+hSu3ME7PF6qA8 4znVIapoOS0D18pHPkoUhKUmu4n6a9V58CBg4XN2p9vYWkCEaF//eH3pZ7ZVqY8OB5 awDSE1pCWe9gTjaIDAbUG8y2Rv+j6S+HuChJ34s0=
To: tjw ietf <tjw.ietf@gmail.com>, John R Levine <johnl@taugh.com>
Cc: dmarc@ietf.org, dcrocker@bbiw.net, dbound@ietf.org
References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <alpine.OSX.2.21.1904031430270.21189@ary.qy> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> <alpine.OSX.2.21.1904031459480.21189@ary.qy> <AFE01C0B-E47E-4D4E-B60C-FA0810BBE8F8@gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <d89a2bf0-2fd3-7be9-e75f-33f565748c92@cs.tcd.ie>
Date: Wed, 3 Apr 2019 20:49:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <AFE01C0B-E47E-4D4E-B60C-FA0810BBE8F8@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZTmRrlWH5ErvqJ0DRDkrYhiEbzl9QUB07"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/fC9q-7fUJJchmwu9QJ7okVR64LU>
Subject: Re: [dbound] [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
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, 03 Apr 2019 19:49:30 -0000

Far from widely deployed, but the latest ESNI draft introduced a
new RRTYPE from an experimental range, and it "just worked," which
was a pleasant surprise for me. (And is partly why I am happy to
try that route for RDBD.)

"just worked" here meaning: no registrar web-GUI involved, but
whacking the ascii hex encoding of binary RR values into a zonefile
on a hidden master, having that transferred to the visible NS's and
accessing it from elsewhere using dig with and without DNS/TLS (DoT-
flavoured via stubby) all did really just work. Only hard thing was
finding the docs to say how to refer to the new RRTYPE in zonefile
and dig command line. (I added some notes on that in a readme for my
ESNI code - go to [1] and search down for RRTYPE if you're curious.)

I think that tends to back up John's argument that today, registrar
GUIs are perhaps the main barrier for new RRTYPEs that don't change
the DNS semantically. But there may also be development environment
issues, e.g. I don't know if you can easily query for new RRTYPEs
from e.g. PHP or python code.

Lastly, on Dave's draft itself, I'd be happy if something like that
were deployed, and don't think it overlaps much with or competes
with RDBD. (At least I hope these aren't seen as competing ideas.)

In early chats about RDBD Alex and I did think about the PSL, but we
ended up deliberately not trying to aim for a DNS equivalent. Without
trying to speak for Alex, personally I think emulating the PSL in DNS
is too big a leap to attempt in one step and isn't likely to succeed,
despite it being an outcome that'd be good to (eventually) see.

That's partly how we ended up with (what I'd claim) is the more modest
initial goal of RDBD.

Cheers,
S

[1] https://github.com/sftcd/openssl/tree/master/esnistuff


On 03/04/2019 20:19, tjw ietf wrote:
> I was going to say CAA but that’s 6 years old. 
> 
> 
> 
> From my high tech gadget
> 
>> On Apr 3, 2019, at 20:06, John R Levine <johnl@taugh.com>; wrote:
>>
>>> On Wed, 3 Apr 2019, Dave Crocker wrote:
>>> Now, about /end to end/ support, not just publishing...
>>>
>>> Please provide some examples comparable to your proposed use case.  That is, what are new RRs that are getting well-scaled, on-going use, defined in say the last 5 years?
>>
>> There aren't many other than maybe CDS and CDSKEY.  TLSA was defined in 2012 and Viktor says it's getting pretty wide use now, particularly considering that it needs DNSSEC.
>>
>> On the other hand, there hasn't been anything with new server semantics since NSEC3 in 2008.
>>
>> This is really an argument for dnsop, not dmarc or dbound.
>>
>> Regards,
>> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
>> Please consider the environment before reading this e-mail. https://jl.ly
>>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
> 
> _______________________________________________
> dbound mailing list
> dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound
>