From nobody Mon Apr 1 01:11:34 2019 Return-Path: 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 302FC1200CE for ; Mon, 1 Apr 2019 01:11:33 -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 1ZgPb6DbMo1L for ; Mon, 1 Apr 2019 01:11:30 -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 08B6312009E for ; Mon, 1 Apr 2019 01:11:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7D8E1BE2E; Mon, 1 Apr 2019 09:11:26 +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 3ZY2L8RT6x_o; Mon, 1 Apr 2019 09:11:24 +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 28555BE24; Mon, 1 Apr 2019 09:11:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554106284; bh=UG6hxTOHGFGgn2HMYCn7pPWr3TxqdL0gy3MAhis7Agk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QTCy/nOtPEygdoFTx1Rxv9Aaj+Hc2zWsqyNGmz7In7/pnocRUqJ8cuf1YmtVGFjSP zu6SKE6E+pMeBj0eNKUSi9FeA7Q1pBXeOZvRpdxmUiDh4DLG7F3W3/AKD1LxDfVcSp O1ZT8WT6uMvCyz37WVDZ5cma8KgOBaT7pKtWgoI4= To: Scott Kitterman , dbound@ietf.org References: <6145507.lIgk3o490W@kitterma-e6430> From: Stephen Farrell 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: <2395e7bc-f634-a882-9229-147fa7febf37@cs.tcd.ie> Date: Mon, 1 Apr 2019 09:11:22 +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: <6145507.lIgk3o490W@kitterma-e6430> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FOHTjj0K9WpgI4Ij4zngTYoHassEyoIyL" Archived-At: Subject: Re: [dbound] draft-brotman-rdbd X-BeenThere: dbound@ietf.org 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: Mon, 01 Apr 2019 08:11:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FOHTjj0K9WpgI4Ij4zngTYoHassEyoIyL Content-Type: multipart/mixed; boundary="yaefUdceRBjqrCOnsARAfEpF1ouvmDcEN"; protected-headers="v1" From: Stephen Farrell To: Scott Kitterman , dbound@ietf.org Message-ID: <2395e7bc-f634-a882-9229-147fa7febf37@cs.tcd.ie> Subject: Re: [dbound] draft-brotman-rdbd References: <6145507.lIgk3o490W@kitterma-e6430> In-Reply-To: <6145507.lIgk3o490W@kitterma-e6430> --yaefUdceRBjqrCOnsARAfEpF1ouvmDcEN Content-Type: multipart/mixed; boundary="------------21CE222760AD1476214570EC" Content-Language: en-GB This is a multi-part message in MIME format. --------------21CE222760AD1476214570EC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/04/2019 04:51, Scott Kitterman wrote: > On Monday, April 01, 2019 03:44:46 AM Stephen Farrell wrote: >> On 01/04/2019 03:38, John R. Levine wrote: >>> I suppose that if there were some very high value application that >>> depended on rdbd records there might be more of an incentive to use D= NS >>> attacks to fake them, but it all seems like a lot of extra work for >>> utterly speculative benefits. >> >> Questioning the efficacy of rdbd signatures is reasonable but not >> at all the same as a claim to not understand 'em. >> >> I agree that the efficacy of these signatures isn't a slam dunk. >> The draft says as much. I'd be happy to improve the explanation >> in the text wrt that. >> >> But the signatures are optional. So if I'm wrong that they're >> useful, then that's ok, you'll be right and they'll not be used. >> Equally, if OTOH but unexpectedly, I'm not wrong, then there'll >> be a method for signing defined as part of the spec. >> >> What's wrong with that? >=20 > It adds some significant complexity to the design. True. > If the crypto bits have significant utility, then baking the needed pro= tocol=20 > elements for smooth key rollover (e.g. for DKIM you use a new selector = and=20 > leave both the old and new keys live for $TIME to allow everything that= was in=20 > process to be received and validated before the old key is removed). A= re=20 > multiple RDBD and RDBDKEY records allowed per domain? Yes. > If not, particularly due to cache misalignment, a smooth key rollover w= ill be=20 > very hard. >=20 > Multiple records per domain would also allow for algorithm agility (pub= lish=20 > both RSA and Ed25519 for transition as needed). >=20 > Libraries implementing RDBD would need more dependencies and be more co= mplex=20 > to deploy. >=20 > My suggestion would be to think hard if it's really needed and if so, t= hen=20 > make it a MUST. If not, take it out. =20 Also a reasonable position. > It can be added easily enough later,=20 > right? Not sure TBH. I think adding rdbd-signatures later would mean defining another RRTYPE, which is about as much work as this. I've no idea how that'd affect deployment either. >=20 > I do think the explanation could be clearer. I was following along wit= h John=20 > Levine's argument pretty well. It took me several scans of the draft t= o=20 > realize that the signature (RBDB record) is published by the relating d= omain=20 > and the public key (RDBDKEY record) is published by the related domain.= Once=20 > I realized that, it made sense. A signed record, to the extent you can= 't=20 > spoof both domains simultaneously or nearly so, would give added confid= ence=20 > that the related domain agrees that that relationship is valid and not = just=20 > examp1e.com claiming to be related to example.com. >=20 > As a more general comment, RFC 8301 is the reference for the minimum ke= y size=20 > of 1024 bits (RFC 6346 is 512). Also, it might be worth looking at RFC= 8463=20 > (which added Ed25519 to DKIM) to see if there's guidance on putting Ed2= 5519=20 > public keys in DNS that can be reused. Will try clarify those issues, thanks. > Personally, I think I like the crypto bit, but if it's in, I'd like to = see it=20 > be a MUST. =20 Fair enough. Other inputs on this topic appreciated! I guess the choices are: 1. take out rdbd-signatures entirely, as per John L I guess 2. leave rdbd-signatures optional, as per -01 3. make rdbd-signatures mandatory, as per Scott K (I consider those are independent of DNSSEC as we're signing across and not downwards with rdbd-signagures.) > Also, do we really need RSA? There are plenty of Ed25519=20 > implementations available. Personally, I think it's simpler to deal wi= th (and=20 > the public keys are way smaller, which is nice for DNS). True, but I'd argue to keep RSA for now at least as e.g. openssl's command line tools don't yet have ed25519 (for internal API reasons, so not clear when that'll be fixed). RSA could get dropped along the way I guess if things change sufficiently before this draft is done. Cheers, S. > Scott K >=20 > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound >=20 --------------21CE222760AD1476214570EC Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------21CE222760AD1476214570EC-- --yaefUdceRBjqrCOnsARAfEpF1ouvmDcEN-- --FOHTjj0K9WpgI4Ij4zngTYoHassEyoIyL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyhx6sACgkQWrL68XsX K+rIBw/+LL/ROX1Kh2+6YlANboFS2hjkKQxJsUYyFopSCNUTJMI1osceeh9vumjk rvyV144rj1RJairE4Exm2EeSqK30eKr1CmYMvBzKmZ/+Vhz5DGgvpk/HNppaltS9 hXa6ceWFgPeUDgMJrQArQOG1sGMGu/Iq4TUKQzYrW+aGAMB8s9fuWrI9mVXT2FTo GcPp/nsEJHoartICRqkSnHFw5XJVyyMHyKLRpRiHb42g1REBkj2ZVuyw7RYa41dA ptQIGc5q2745aierpd0kW/w1KQ/cg2lavA4ahGwHkxar7WmSh1JFt6cHWoAKFZgp BdWvozsUBJg51oXJyOnaaeCS6KJldQPpn62daoM+xgl4qnnd3NJmE871tThDxrYY LjYfmY64blYErETljTXWRYlUPvjKIuItEmvRBOGJjKvY362gWbwN7dyysAdNkVHz kh8A2kImNZDr8tRnAUcjbuJsnwSHhtn34UhK3O11Y60qB0507/euptC9HCrhMWJW htvnZoPVBRYsBsVTAcpyYH3fico/v2SEhSsMhp5u2U7pokiZ+eYORa0NRtYkPBrL SG6IG/IfF3k8SqgvofH9Vifr0uFrlBzhYDW2CIFBQ+bY5T9TvyTgDF4mcD13HRH2 BwmRVXw0eSAzjex9eOiiiGbLCfYdqYklaMPsLZIdIyNkv6aDLzo= =bXtD -----END PGP SIGNATURE----- --FOHTjj0K9WpgI4Ij4zngTYoHassEyoIyL-- From nobody Mon Apr 1 03:46:43 2019 Return-Path: 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 937EF12007A for ; Mon, 1 Apr 2019 03:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lABECLSmrVmJ for ; Mon, 1 Apr 2019 03:46:37 -0700 (PDT) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A328F12008F for ; Mon, 1 Apr 2019 03:46:37 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id d13so10136976qth.5 for ; Mon, 01 Apr 2019 03:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b7cT/5xz5WqYnroi1VrMQmM8/ClY0/lXbxCPjdbCoos=; b=X1TUOggyClTRM+Tj4ZbsKafBk1RAdIeC8fT/LTQJ4lAuG2w6DVwTS3fYhCjOpMRs6J lJu1zaP+HGM+HH2zd1LakZnkjKlnSkjCDTtT0mFxbxM5ueN82VhvYguy05Ty4sA8rJWe ccUixJYetAMQu9Vmcqt4UsWwhAENDbEsptg6PCigtZrN73SDzNWhO/JWZT/7zqQk5uv4 3Mjl2wSZUcckPe39oTggYrdDSTTOktJIPI+CpKgAcrKGBq9cYDZmiv+Oo5h3ggBE3x2d sU/wk7oOHO8Cw05/4zjAeY67mxEozfNpJhYTV9mdu0JkHfQjq1hXd2GplxeTUc9W2ZXm 7jcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b7cT/5xz5WqYnroi1VrMQmM8/ClY0/lXbxCPjdbCoos=; b=RKrXw4cs8IAsgIk1nGXo6dPN6q0tKSKRRXnzUeN+dJrxjhpSz78od/gHhicMk1DWdB B8UG0ACwtfF5OyDgU6rekNHsjcNdGK2IGNzXDG7A+o1stmDvUceTJ5u+RTfC9HQ6XDha 5EqB/KXjyo6TH2zynMxGntrl1XbgLv+1T3/951ofXJ9gb8Cz4l6s8eTHVUTMFHjPKa8y wFGWOWa1bJZNtf+Chvot4HgCcIggiQmmtWMQBigijfHxzRBKoAHxHa0lwtInQlXiIG4x Ogvwjgmci9eCMADsiCu2aBtFPdiOASjHeimRLG8YJCYNy8Cz9JwQu6ie6CviqfKtpyrV ww1A== X-Gm-Message-State: APjAAAVY++oQHhrQjcQz33TACMqyoQYhPx6us6We1EkL1cw+kNIwgATy Q06Xk3lUnFHUgx6nj3WPbqA8npnkihK534yprIQ= X-Google-Smtp-Source: APXvYqxQxnut7fuqsvO9yLdohh26EAUTJaW5+LK7qtIVKZGazzmxgFs7lHo3S+qBJiPC5Qhww04p8zw0PPQQqDZqikI= X-Received: by 2002:a0c:9666:: with SMTP id 35mr52743887qvy.30.1554115596772; Mon, 01 Apr 2019 03:46:36 -0700 (PDT) MIME-Version: 1.0 References: <7d34857c-a99b-389a-90e5-2e4fe6f4e736@cs.tcd.ie> In-Reply-To: <7d34857c-a99b-389a-90e5-2e4fe6f4e736@cs.tcd.ie> From: Brian Dickson Date: Mon, 1 Apr 2019 03:46:23 -0700 Message-ID: To: Stephen Farrell Cc: "A. Schulze" , dbound@ietf.org Content-Type: multipart/alternative; boundary="00000000000015e95b058575bc54" Archived-At: Subject: Re: [dbound] draft-brotman-rdbd X-BeenThere: dbound@ietf.org 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: Mon, 01 Apr 2019 10:46:41 -0000 --00000000000015e95b058575bc54 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 31, 2019 at 3:57 PM Stephen Farrell wrote: > On 29/03/2019 17:06, A. Schulze wrote: > > > And, yes, DNSSEC shouldn't be optional. Re-using existing DNSKEYs may > make the signature/validation stuff easier. > > I'm afraid I don't agree that DNSSEC can be a requirement here. RDBD > by itself is not sufficiently compelling to cause a DNSSEC deployment. > And DNSSEC is just not sufficiently deployed to make it a requirement. > I'd like to better understand the rationale for the general/specific sentiment. I think the disconnect starts with the question about the purpose, or alternatively, explicit limitations, of RDBD: - Does the existence of RDBD records change the trust by any actor, any system, any mechanisms, anything? If the answer is no, then I don't see the compelling value for RDBD, and really have no interest here. Sorry. (However, I also don't think this is the case.) If the answer is yes, then IMHO, RDBD may REALLY need to check its assumptions regarding DNS cache poisoning. (Hint: if DNS were a pre-industrial world map, the cache would be labeled "Here there be dragons".) The strongest defense known against DNS cache poisoning, AFAIK, is DNSSEC. Any others are at most weak hacks to marginally increase entropy. Using any other type of crypto keys stored in DNS, without protecting those with DNSSEC, is also vulnerable to cache poisoning. They are just DNS records. So, without using DNSSEC, successful cache poisoning can subvert RDBD, whether or not any other signature stuff is used: - The attacker only needs to subvert the DNS entries for all the RDBD records , i.e base RDBD record(s) with signatures, and corresponding RDBDKEY record(s). - This is addressed as a security concern currently in the draft, but understates/underestimates the risk or effort, IMHO significantly (or even fatally). - Since this is a DNS cache attack against both the key and signature, it does not require the RDBDKEY (as published on the authority server(s)) to be compromised. In contrast, use of DNSSEC makes any other signature redundant/moot, at best; it makes key management problematic on top of DNSSEC key management, at worst. Here's why: DNSSEC signing a record which contains a domain name meets all the requirements of the RDBD. Using the ZSK as the RDDBKEY devolves the RDBD record trivially: - All the stuff after the relating domain name in the current draft, is basically an RRSIG (with a few fields elided). The gist of the above is: if you have deployed DNSSEC for a zone, the RDBD RRTYPE does not need to consist of anything more than a domain name (FQDN). This is not to say that an RDBD does not have value; in fact, I believe there is significant value here. That value can be maximized by streamlining the encoding, re-using the signature work from DNSSEC, and keeping the RDBD RRTYPE easy to understand and use. Rationale, explanation, & disclaimer regarding cache poisoning weakness: I've made assertions previously in a variety of venues, about the level of effort required for cache poisoning being very low generally. At some point I should probably write up the details, so it is clear to the IETF crowd doing DNS (previously this has been shared at DNS-OARC but not by me in the DNS-related WGs). The root source of the weakness has been published elsewhere by others , and presented by them in (IIRC) the security area general session. See: Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", Technical Report 13-03, March 2013, < http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf>. My claim is that that report underestimates the degree of vulnerability of caches to such attacks. If the authors of RDBD would like a private detailed explanation, I'd be happy to share it. I am reluctant to publicly share the details just now, as I believe this would require appropriate responsible disclosure with abundant time to fix the underlying issues. In particular, it is really critical to have necessary fixes deployed in nearly all the authority operators' and recursive operators' networks, prior to any details being published openly. (You may not agree with the above, without me explaining the particulars. My suspicion is you will probably agree with the above after I explain it. Please contact me off-list for the explanation.) Here's my opinion generally of what RDBD should be composed of: - DNSSEC signed RDBD records consisting of only the related-domain names. - Matching mutual claims of relationships should be a requirement (or at least a SHOULD with explanation of the security risks of relying on unmatched claims). - Ability of a domain to explicitly exclude all relationships (thus preventing any matches). Completely unambiguous encoding is required for this. - Optional URI record(s) pointing at some well-defined semantic blob(s) for what the trust implies, for whoever the consumer of RDBD is. (Probably out of scope for the core RDBD spec.) Brian --00000000000015e95b058575bc54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Mar 31, 2019 at = 3:57 PM Stephen Farrell <st= ephen.farrell@cs.tcd.ie> wrote:
=
On 29/03/2019 17:06, A. S= chulze wrote:

> And, yes, DNSSEC shouldn't be optional. Re-using existing DNSKEYs = may make the signature/validation stuff easier.

I'm afraid I don't agree that DNSSEC can be a requirement here. RDB= D
by itself is not sufficiently compelling to cause a DNSSEC deployment.
And DNSSEC is just not sufficiently deployed to make it a requirement.
<= /blockquote>

I'd like to better understand the ratio= nale for the general/specific sentiment.

I think t= he disconnect starts with the question about the purpose, or alternatively,= explicit limitations, of RDBD:
  • Does the existence of RDB= D records change the trust by any actor, any system, any mechanisms, anythi= ng?

If the answer is no, then I don'= t see the compelling value for RDBD, and really have no interest here. Sorr= y. (However, I also don't think this is the case.)

=
If the answer is yes, then IMHO, RDBD may REALLY need to check its ass= umptions regarding DNS cache poisoning.=C2=A0
(Hint: if DNS were = a pre-industrial world map, the cache would be labeled "Here there be = dragons".)

The strongest defense known agains= t DNS cache poisoning, AFAIK, is DNSSEC. Any others are at most weak hacks = to marginally increase entropy.=C2=A0

Using any ot= her type of crypto keys stored in DNS, without protecting those with DNSSEC= , is also vulnerable to cache poisoning. They are just DNS records.
So, without using DNSSEC, successful cache poisoning can subvert RDBD, w= hether or not any other signature stuff is used:
  • The atta= cker only needs to subvert the DNS entries for all the RDBD records , i.e b= ase RDBD record(s) with signatures, and corresponding RDBDKEY record(s).
    • This is addressed as a security concern currently in the draft, b= ut understates/underestimates the risk or effort, IMHO significantly (or ev= en fatally).
  • Since this is a DNS cache attack against both the= key and signature, it does not require the RDBDKEY (as published on the au= thority server(s))=C2=A0to be compromised.
In contrast,= use of DNSSEC makes any other signature redundant/moot, at best; it makes = key management problematic on top of DNSSEC key management, at worst.
Here's why: DNSSEC signing a record which contains a domain na= me meets all the requirements of the RDBD.
Using the ZSK as the R= DDBKEY devolves the RDBD record trivially:
  • All the stuff = after the relating domain name in the current draft, is basically an RRSIG = (with a few fields elided).
The gist of the above is: i= f you have deployed DNSSEC for a zone, the RDBD RRTYPE does not need to con= sist of anything more than a domain name (FQDN).

This is not to say that an RDBD does not have value; in fact, I believe = there is significant value here.
That value can be maximized by s= treamlining the encoding, re-using the signature work from DNSSEC, and keep= ing the RDBD RRTYPE easy to understand and use.

Ra= tionale, explanation, & disclaimer regarding cache poisoning weakness:<= /div>
I've made assertions previously i= n a variety of venues, about the level of effort required for cache poisoni= ng being very low generally.
At = some point I should probably write up the details, so it is clear to the IE= TF crowd doing DNS (previously this has been shared at DNS-OARC but not by = me in the DNS-related WGs).
The = root source of the weakness has been published elsewhere by others=C2=A0, a= nd presented by them in (IIRC) the security area general session. See:
=C2=A0Herzberg, = A. and H. Shulman, "Fragmentation Considered Poisonous", Technica= l Report 13-03, March 2013, <http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.= pdf>.
My claim is that that report underestimates the de= gree of vulnerability of caches to such attacks.
If the authors of RDBD would like a private detail= ed explanation, I'd be happy to share it.
I am reluctant to publicly share the details just now, as I b= elieve this would require appropriate responsible disclosure with abundant = time to fix the underlying issues.
In particular, it is really critical to have necessary fixes deployed in= nearly all the authority operators' and recursive operators' netwo= rks, prior to any details being published openly.

(You may = not agree with the above, without me explaining the particulars. My suspici= on is you will probably agree with the above after I explain it. Please con= tact me off-list for the explanation.)

Here's my opinion generally of wha= t RDBD should be composed of:
  • DNSSEC signed RDBD records = consisting of only the related-domain names.
  • Matching mutual claims= of relationships should be a requirement (or at least a SHOULD with explan= ation of the security risks of relying on unmatched claims).
  • Abilit= y of a domain to explicitly exclude all relationships (thus preventing any = matches). Completely unambiguous encoding is required for this.
  • Opt= ional URI record(s) pointing at some well-defined semantic blob(s) for what= the trust implies, for whoever the consumer of RDBD is. (Probably out of s= cope for the core RDBD spec.)
Brian
--00000000000015e95b058575bc54-- From nobody Mon Apr 1 04:42:54 2019 Return-Path: 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 33D5D1200FD for ; Mon, 1 Apr 2019 04:42:44 -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 aZ6jOO85agIa for ; Mon, 1 Apr 2019 04:42:40 -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 A767B120127 for ; Mon, 1 Apr 2019 04:42:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A0A43BE24; Mon, 1 Apr 2019 12:42:34 +0100 (IST) 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 Aqz9u6hF9WiZ; Mon, 1 Apr 2019 12:42:34 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5C398BDCF; Mon, 1 Apr 2019 12:42:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554118954; bh=YNA7eo40SA16odmONZsBZszO8JNHWF5kPIZ6V/e3IaQ=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=sDp1LH+NYL3OqainRJNAt4CMry/JiuOq7nDmCSMcPRuH+MjpBoGnVnracn5zO+A4z mKxQzV/7S28aOA6JhPND+v/bKJ5qc1c7H+7gCnmAFC+Rr05VG4ZmV2PCHZkPL/FFD2 yHjIWtnO2X2fMOt6fCvSpfFC6j/ihEbFLeF4ZTjQ= To: Brian Dickson Cc: dbound@ietf.org, "A. Schulze" References: <7d34857c-a99b-389a-90e5-2e4fe6f4e736@cs.tcd.ie> From: Stephen Farrell 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: Date: Mon, 1 Apr 2019 12:42:32 +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: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6M5xKf0gFdtblCUdUoXk6NGruuyssEcEU" Archived-At: Subject: Re: [dbound] draft-brotman-rdbd X-BeenThere: dbound@ietf.org 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: Mon, 01 Apr 2019 11:42:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6M5xKf0gFdtblCUdUoXk6NGruuyssEcEU Content-Type: multipart/mixed; boundary="xlnloeAoNCYKu8P1klNqeBVYv042IhdaS"; protected-headers="v1" From: Stephen Farrell To: Brian Dickson Cc: dbound@ietf.org, "A. Schulze" Message-ID: Subject: Re: [dbound] draft-brotman-rdbd References: <7d34857c-a99b-389a-90e5-2e4fe6f4e736@cs.tcd.ie> In-Reply-To: --xlnloeAoNCYKu8P1klNqeBVYv042IhdaS Content-Type: multipart/mixed; boundary="------------9FB97045A32556C4F0234F48" Content-Language: en-GB This is a multi-part message in MIME format. --------------9FB97045A32556C4F0234F48 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/04/2019 11:46, Brian Dickson wrote: > On Sun, Mar 31, 2019 at 3:57 PM Stephen Farrell > wrote: >=20 >> On 29/03/2019 17:06, A. Schulze wrote: >> >>> And, yes, DNSSEC shouldn't be optional. Re-using existing DNSKEYs may= >> make the signature/validation stuff easier. >> >> I'm afraid I don't agree that DNSSEC can be a requirement here. RDBD >> by itself is not sufficiently compelling to cause a DNSSEC deployment.= >> And DNSSEC is just not sufficiently deployed to make it a requirement.= >> >=20 > I'd like to better understand the rationale for the general/specific > sentiment. >=20 > I think the disconnect starts with the question about the purpose, or > alternatively, explicit limitations, of RDBD: >=20 > - Does the existence of RDBD records change the trust by any actor, = any > system, any mechanisms, anything? >=20 >=20 > If the answer is no, then I don't see the compelling value for RDBD, an= d > really have no interest here. Sorry. (However, I also don't think this = is > the case.) >=20 > If the answer is yes, then IMHO, RDBD may REALLY need to check its > assumptions regarding DNS cache poisoning. > (Hint: if DNS were a pre-industrial world map, the cache would be label= ed > "Here there be dragons".) Fully agree that cache poisoning is a relevant threat for any application that would use RDBD values read from DNS without sufficient additional local validation to make a decision. In my use-case (better counting in surveys) that's not so much of a deal. I think in Alex's mail use-case, it's also less of a deal as this is just one of many inputs that would be seen over time so they'd not be making decisions based on just seeing one RDBD value one time. But I do agree that if people publish RDBD records, then someone will indeed write code to make such decisions no matter what we tell them to (not;-) do. > The strongest defense known against DNS cache poisoning, AFAIK, is DNSS= EC. > Any others are at most weak hacks to marginally increase entropy. True. > Using any other type of crypto keys stored in DNS, without protecting t= hose > with DNSSEC, is also vulnerable to cache poisoning. They are just DNS > records. Sure. And the draft needs to document that (probably better than it currently does - more/better text is welcome). > So, without using DNSSEC, successful cache poisoning can subvert RDBD, > whether or not any other signature stuff is used: >=20 > - The attacker only needs to subvert the DNS entries for all the RDB= D > records , i.e base RDBD record(s) with signatures, and corresponding= > RDBDKEY record(s). > - This is addressed as a security concern currently in the draft,= but > understates/underestimates the risk or effort, IMHO > significantly (or even > fatally). > - Since this is a DNS cache attack against both the key and signatur= e, > it does not require the RDBDKEY (as published on the authority > server(s)) to be compromised. >=20 > In contrast, use of DNSSEC makes any other signature redundant/moot, at= > best; it makes key management problematic on top of DNSSEC key manageme= nt, > at worst. Not quite (but see below). > Here's why: DNSSEC signing a record which contains a domain name meets = all > the requirements of the RDBD. > Using the ZSK as the RDDBKEY devolves the RDBD record trivially: >=20 > - All the stuff after the relating domain name in the current draft,= is > basically an RRSIG (with a few fields elided). >=20 > The gist of the above is: if you have deployed DNSSEC for a zone, the R= DBD > RRTYPE does not need to consist of anything more than a domain name (FQ= DN). Not quite. The above is true if DNSSEC is deployed for both zones involved in an RDBD relationship. If only one of them is signed, then it's not exactly the same, and the additional RDBD-signature can offer some value if the relating domain's zone is DNSSEC-signed. Again, I don't want to overstate that value, but I reckon it has non-zero value. It is entirely valid to wonder if the complexity of that additional signature is or is not worthwhile. I guess, but cannot prove, that it is worthwhile to define RDBD-signatures as an optional thing, perhaps esp. if the related domain is the kind of thing setup by some marketing person for example. If neither zone is signed, then we're in the same position as most DKIM deployments. People do seem to have derived some value from that, despite the lack of a requirement for DNSSEC. > This is not to say that an RDBD does not have value; in fact, I believe= > there is significant value here. > That value can be maximized by streamlining the encoding, re-using the > signature work from DNSSEC, and keeping the RDBD RRTYPE easy to underst= and > and use. I would entirely agree if DNSSEC deployment were further along. However, that is not the case. As it happens, for the dozen or so small zones I manage, I have deployed DNSSEC and it's been pretty easy once we figured out how to automate re-signing and getting DS records to the parent. (I've yet to do CDS/CDNSKEY stuff but that should improve it some when the parent registry supports it.) But I have also spoken to quite a few people who say they cannot deploy DNSSEC or who think DNSSEC doesn't offer them enough to be worth the costs. >=20 > Rationale, explanation, & disclaimer regarding cache poisoning weakness= : >=20 > I've made assertions previously in a variety of venues, about the level= of > effort required for cache poisoning being very low generally. > At some point I should probably write up the details, so it is clear to= the > IETF crowd doing DNS (previously this has been shared at DNS-OARC but n= ot > by me in the DNS-related WGs). > The root source of the weakness has been published elsewhere by others = , > and presented by them in (IIRC) the security area general session. See:= >=20 > Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", > Technical Report 13-03, March 2013, < > http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf>. >=20 > My claim is that that report underestimates the degree of vulnerability= of > caches to such attacks. >=20 > If the authors of RDBD would like a private detailed explanation, I'd b= e > happy to share it. > I am reluctant to publicly share the details just now, as I believe thi= s > would require appropriate responsible disclosure with abundant time to = fix > the underlying issues. > In particular, it is really critical to have necessary fixes deployed i= n > nearly all the authority operators' and recursive operators' networks, > prior to any details being published openly. >=20 > (You may not agree with the above, without me explaining the particular= s. > My suspicion is you will probably agree with the above after I explain = it. > Please contact me off-list for the explanation.) I don't need to be convinced that caches can be poisoned;-( >=20 > Here's my opinion generally of what RDBD should be composed of: >=20 > - DNSSEC signed RDBD records consisting of only the related-domain n= ames. If we dropped the RDBD-signature, and a zone has DNSSEC that'd be almost true, with just the rdbd-tag field being there in addition. (See below for more on that rdbd-tag.) > - Matching mutual claims of relationships should be a requirement (o= r at > least a SHOULD with explanation of the security risks of relying on > unmatched claims). I'd argue that the point above conflicts with the point below. And I also don't get what's wrong with unidirectional assertions. Can someone explain? (I do understand that some people want assertions in both zones, which is entirely possible, but I don't get the downside of doing that via two unidirectional assertions. Requiring changes in two zones also seems to be more brittle in general.) > - Ability of a domain to explicitly exclude all relationships (thus > preventing any matches). Completely unambiguous encoding is required= for > this. Yep, we'll include that in -02 for sure, it's a good idea. I think assigning an rdbd-tag value for that might work. I'm less sure how to handle the other thing people seemed to want which was to explicitly list other names that are not related. (Mostly as that could be a big list.) I guess one could simply have a bunch of RDBD RR values each of which says that there's no relationship, but I don't know when the numbers there would become a problem. (Anyone able to say? Would 100 RR values be an issue? 10^3? 10^4?) > - Optional URI record(s) pointing at some well-defined semantic blob= (s) > for what the trust implies, for whoever the consumer of RDBD is. (Pr= obably > out of scope for the core RDBD spec.) In -01 we added the rdbd-tag for that, with tag value 0 meaning "some unspecified relationship." Other tag values can be assigned later, with whatever semantics are right for those. One of those could I think do what you want here, e.g., rdbd-tag=3D=3DN could mean to go look for a URI RR value in some well-defined place to find a well-defined blob of JSON perhaps.) I'd also note that such additional specifications could be where one makes a statement that DNSSEC is required - that needn't necessarily be done for all uses of RDBD. Cheers, S. >=20 > Brian >=20 >=20 > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound >=20 --------------9FB97045A32556C4F0234F48 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------9FB97045A32556C4F0234F48-- --xlnloeAoNCYKu8P1klNqeBVYv042IhdaS-- --6M5xKf0gFdtblCUdUoXk6NGruuyssEcEU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyh+SgACgkQWrL68XsX K+r1oA//dTV42sZHkKmYPZBkao38mUbSYVR+LAI2QUHi828YYteSQcwpEEo9EWjA hYviKBuT62FGjapjc9EVNyEiPT6vLzZ93FZD6aNnGZYBcSezXzVBcHfg+BHlpRdD U2YRVuIIrPFZI8nMl8NDMkXV+j+DPwvFVUgWYTZG0RoNCibS6ok+oI5HUtZ0zJmT 93GoOuobz/ljAE4m+elvuWEIcDCBG2ct00RDez9dcpEtzci8smRK/dlyFYkp2RYG PrtzlL6SJdBZZSURTF1IER+s+menwbHSDmcsNf3hMfIr2JubISvnVBNMRp4EIcnN BffN1+eeIto2HxPKzb0KRkmNexRplPul+N6k8+yKgoMU2GJmc0pchKdzjcPr8GO8 R8m+hzWK714nW/WYyK62eOfmSM9h3a8BSVncXV2cm8ADeNc0mPQlRFwHg7g1fo/P JVHuT5B0K65IyUh45DBUCqYZ9sT18oJAtf3xKI5LBBkO8jLbeGDwH7e/GZnSoNxt q59a/kZC/9J5paL0xu3GBiu78PdlWmi2eaZnyLrQBdrKQtLagJQ3TrLnO4ATtvjP XUpc0dXvMqtTUP2kpL+V3AjLfmtz+ujn+ZO0lYXJsuraV16bTrml833QWbod4Y/F x11oD+apNfpbOXLA3KLHUhciUfCaZim+1olAZfjNurwjvW7jves= =T33Z -----END PGP SIGNATURE----- --6M5xKf0gFdtblCUdUoXk6NGruuyssEcEU-- From nobody Mon Apr 1 09:19:07 2019 Return-Path: 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 154A512032F for ; Mon, 1 Apr 2019 09:19:05 -0700 (PDT) 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=09GLyhwq; dkim=pass (1536-bit key) header.d=taugh.com header.b=ZK6jzFd4 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 Pvl9KUzVi_CI for ; Mon, 1 Apr 2019 09:19:03 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 D66E112031F for ; Mon, 1 Apr 2019 09:19:02 -0700 (PDT) Received: (qmail 11065 invoked from network); 1 Apr 2019 16:19:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2b37.5ca239f4.k1904; bh=+Eh5RdVTz1XAUySaMvnBn6cHOVtzFeU0VPZ2wJ4N8WA=; b=09GLyhwqmR6J1M/urbqlfjwOpK8vlZl4en4d/xl2sO54p8M1Un22CiYNDFC+VDGrmQtiGeqBvbilo2YWYENetmN9snlePLvQJhF7Tj9WPS6CCCnENTqXn22Ga9nht006YzvXTCUu46q0T4nNUJvHWa5xf8dUoaECDqtaXGLn/jyOrv+0WTXwRsq6Rmxtmo03K+Twi6jJotNnzeR36gk1PG+u5qfQWzdC7JdmgQkKNJaTPFVdr8sh0gpLZbER5rbD DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2b37.5ca239f4.k1904; bh=+Eh5RdVTz1XAUySaMvnBn6cHOVtzFeU0VPZ2wJ4N8WA=; b=ZK6jzFd4BktD05wZagqSzt4cx9Q3pZaCABJ6h1D+u92aFIfDnb8Nep0iYc0CtT4Lanws/EoIe9ChMY/C8RST8ViaL0py6zuJMlv4Qjpg2K6R6CEmRKu50CMYp+pPHGTaay3aisuiRjOYUAiXAtXCoieTB2OuOLPj9riHHsseI6JSO84SfuuWrZXZ0krK9cxwdqDVck6pXOSpzRlsltwoMkpm0XhAx2Re5PD7IUNPVLfu5Hi5YDE5iFkBRnXLGm8T Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 01 Apr 2019 16:19:00 -0000 Received: by ary.qy (Postfix, from userid 501) id 764062011356DA; Mon, 1 Apr 2019 12:18:59 -0400 (EDT) Date: 1 Apr 2019 12:18:59 -0400 Message-Id: <20190401161900.764062011356DA@ary.qy> From: "John Levine" To: dbound@ietf.org Cc: stephen.farrell@cs.tcd.ie In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dbound] draft-brotman-rdbd X-BeenThere: dbound@ietf.org 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: Mon, 01 Apr 2019 16:19:05 -0000 In article you write: >Fully agree that cache poisoning is a relevant threat for any >application that would use RDBD values read from DNS without >sufficient additional local validation to make a decision. Could you give some concrete examples of additional local validation, other than DNSSEC? As far as I can tell nobody does anything like that for DKIM keys. From nobody Mon Apr 1 10:17:21 2019 Return-Path: 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 31865120187 for ; Mon, 1 Apr 2019 10:17:20 -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 ptyxcEkwLlfm for ; Mon, 1 Apr 2019 10:17:17 -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 C55F21203F2 for ; Mon, 1 Apr 2019 10:17:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D26CBBE24; Mon, 1 Apr 2019 18:17:13 +0100 (IST) 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 0TZizbNnkRt7; Mon, 1 Apr 2019 18:17:13 +0100 (IST) Received: from [134.226.63.124] (cswireless63-124.scss.tcd.ie [134.226.63.124]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 90E15BE20; Mon, 1 Apr 2019 18:17:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554139033; bh=C4DRbgqzh/4Vzmx81UJMo6YmRFXjlvnZYlRZo2AJk98=; h=Subject:To:References:From:Date:In-Reply-To:From; b=bqNIDcdAXdReys3suXETdRVZia8qk9btDDeREs5LbD4JMjml3TrrSNUa6tfvYg+xs sZtnoBzX4Z3369SfjOqKf7ZEnIKOuWou15zfb6M951a+E//UMn0MTiN7cH5Klgzujy w3iu7XiSdD0+xbGzHcbw7JtkTX1HkpINrbyjFubg= To: John Levine , dbound@ietf.org References: <20190401161900.764062011356DA@ary.qy> From: Stephen Farrell 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: <71b8a4dd-8bd6-c24c-e8fd-e76c27bee06a@cs.tcd.ie> Date: Mon, 1 Apr 2019 18:17:07 +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: <20190401161900.764062011356DA@ary.qy> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w5p6PJBcbFVpn28J4uFjqnUWRkwx8HJu2" Archived-At: Subject: Re: [dbound] draft-brotman-rdbd X-BeenThere: dbound@ietf.org 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: Mon, 01 Apr 2019 17:17:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --w5p6PJBcbFVpn28J4uFjqnUWRkwx8HJu2 Content-Type: multipart/mixed; boundary="M7Wi0NSCCTW2fxQ9ZvXVzqxdbwCUMSnYw"; protected-headers="v1" From: Stephen Farrell To: John Levine , dbound@ietf.org Message-ID: <71b8a4dd-8bd6-c24c-e8fd-e76c27bee06a@cs.tcd.ie> Subject: Re: [dbound] draft-brotman-rdbd References: <20190401161900.764062011356DA@ary.qy> In-Reply-To: <20190401161900.764062011356DA@ary.qy> --M7Wi0NSCCTW2fxQ9ZvXVzqxdbwCUMSnYw Content-Type: multipart/mixed; boundary="------------424131663192B33163B4F516" Content-Language: en-GB This is a multi-part message in MIME format. --------------424131663192B33163B4F516 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/04/2019 17:18, John Levine wrote: > In article you write: >> Fully agree that cache poisoning is a relevant threat for any >> application that would use RDBD values read from DNS without >> sufficient additional local validation to make a decision. >=20 > Could you give some concrete examples of additional local validation, > other than DNSSEC? Sure. In my use-case (surveys), I keep the keys used from one scan to the next, so e.g. I have about 4 scans of Irish and other SMTP servers taken over the last 18 months and can see when some keys do or don't change. Were RDBD deployed, I'd do the same for those keys, if they got used. (To be clear, I've not been doing that for DKIM keys to date, but for TLS and SSH server keys.) > As far as I can tell nobody does anything like that for DKIM keys. I don't know if anyone does, but wouldn't be surprised if some anti-abuse folks reacted to a mail provider switching from one long-lived key selector to a new one not seen anywhere before. (But I'm speculating there, others who do that kind of thing for real would need to confirm that or not.) Cheers, S. >=20 >=20 > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound >=20 --------------424131663192B33163B4F516 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------424131663192B33163B4F516-- --M7Wi0NSCCTW2fxQ9ZvXVzqxdbwCUMSnYw-- --w5p6PJBcbFVpn28J4uFjqnUWRkwx8HJu2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyiR5MACgkQWrL68XsX K+poEQ//cD6xUULOP3ou/fBsQd7JaF1PKCIoRhShdQuU+mEPFleNLU1v8FK7444D /QXdCBC7QCuKn/KaGri6mTJwNhPMZTRH7yC776faP6hYPdc9h9TtfCU2Pt5ktRNJ uHfK9bFjJOmCLwP0BdEyvhh15VQgixvpCZSI5XuVLO3M4Dgbptwppq8vXWs/xLVc n6Z4V0SFCFO4pQEc1uAfesNJFZwH/dj0zJy499kcjrZX9DfAVAosr6aI6xFp0hNE DLSxOoE0OUTYjeQJRIPRgTVoTn9Ep6nugjnvAP9qDpc1hstIgJucb8/DOBohvuVH 5FkM3osnDwAzoeBMF2OemEMfHWPWzTKaWZc38JHYQz5TyRzjcnMc0CQq2JheBrYe JwrMqcvARWR6yBmoHLFNxPcnn8p0ScyquPZIIhS1ymEzXKdvbcuRwnhPDWIUEgZg JkXm5ojNlLRo7b9l58UB3njyLxBWbxQ668C+owdQetaZdqdOvIcTXwlZIrwZlfdQ 0yxVKc047lOqCdbb1/HDTpNnqjnrPqxuSj73tHz1k/wDX9LFGyMssHhKT7LxY/Tg Qr8ULmDg0W1K3ah40ercQJxlZSia+ogURFtOlF+FGvPdYwPTmAAfNm69uxRgtfMz DynyPzAYzcezYODJpC1BSYXE7E0O7sKkLfhyc33nK+rTLp2idiw= =27kT -----END PGP SIGNATURE----- --w5p6PJBcbFVpn28J4uFjqnUWRkwx8HJu2-- From nobody Mon Apr 1 11:19:01 2019 Return-Path: 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 3542712011C for ; Mon, 1 Apr 2019 11:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CeNbrIWnmjdd for ; Mon, 1 Apr 2019 11:18:56 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03BA120075 for ; Mon, 1 Apr 2019 11:18:56 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id w5so11761900qtb.11 for ; Mon, 01 Apr 2019 11:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rYCqD2VO3twFVoiXNwVZ7dIpTUS1ha/3kfpQUUC7hLw=; b=tLbZnz8fKNIZbSChyw8MceFRXb9Mtw1vqHzkKFHFo62OwpLDbmbRCvyga/IJ9zCCix vUz5kmLCbkwMx8eQJ+MiF+CPZvge2aANrdiEMxe5uiMEQtyYDjjThs8UMGGQNZAZQph0 SW6aJ00lcKVWAYIuNwy/0IcrbdxFFLzGtqXRnF/48LVr6ZLIt3b4g+WFocC/XA7BzpRc /RmqbRTR4HSRBic5ashxCsKmji8fCBNDWEqEhCSrLZsPlTadidEzrNOrp44PehY/x8UR SCRWYZaZHP24kq0ZkJDeRwQfHRGjNWpSvu6OsVRCefi5fRiyQqkNQrG0vUMC2xbDf/zH DLgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rYCqD2VO3twFVoiXNwVZ7dIpTUS1ha/3kfpQUUC7hLw=; b=OdUnYJBRaSD+oViVovCCb4qwGZfymsHKxZNBazZCFEqqNnOC0wDnR/NDLukeezxgYc d4yxXGJ4UTX6eL1XkM4WOO5gESEms4jmYuRs+zF72i33H6vn342aVL2HNI5flw3vD2WS uNaM4BzjV2APZWKNVA31HZz+h5BJkX4EuvNxSLI8OIfzv5CgrzTb1it4bJkSiis6wTru GscqaDUb76EuaAtt0cqBR2EHZK5AwHYDzOlg1sgRT2QC5JrzTauFOmb07H0SLOae2kg7 s2JZPeoRs2/UzfPPdWE2t9BRrZBIRHgt+YkTa8VBKomUYWYcDDo8grn4QqqabEZ0HP3h YYHw== X-Gm-Message-State: APjAAAUdr0Mp0qpvsof+CBUFwOoMW56Bh999zVCMK/HRIuLQ6JABLai9 ZoSkUKF7WoTKkO6T/o+nu/3tsF5q82hbmz0IKCOcoQ== X-Google-Smtp-Source: APXvYqxNkbhDCN7iBhFHtVlsFfTyScYAPv6CP5oPg17+4jzhyHB3uEtDC7dGzMEu8XfCvV+e7M4Z3xe+r6Pr35G0LDY= X-Received: by 2002:a0c:91cc:: with SMTP id r12mr53752481qvr.35.1554142735784; Mon, 01 Apr 2019 11:18:55 -0700 (PDT) MIME-Version: 1.0 References: <7d34857c-a99b-389a-90e5-2e4fe6f4e736@cs.tcd.ie> In-Reply-To: From: Brian Dickson Date: Mon, 1 Apr 2019 11:18:43 -0700 Message-ID: To: Stephen Farrell Cc: dbound@ietf.org, "A. Schulze" Content-Type: multipart/alternative; boundary="000000000000b25fd705857c0d53" Archived-At: Subject: Re: [dbound] draft-brotman-rdbd X-BeenThere: dbound@ietf.org 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: Mon, 01 Apr 2019 18:18:59 -0000 --000000000000b25fd705857c0d53 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 1, 2019 at 4:42 AM Stephen Farrell wrote: > > > I would entirely agree if DNSSEC deployment were further along. > However, that is not the case. > > As it happens, for the dozen or so small zones I manage, I have > deployed DNSSEC and it's been pretty easy once we figured out > how to automate re-signing and getting DS records to the parent. > (I've yet to do CDS/CDNSKEY stuff but that should improve it > some when the parent registry supports it.) > > But I have also spoken to quite a few people who say they cannot > deploy DNSSEC or who think DNSSEC doesn't offer them enough to > be worth the costs. > So, just so I understand it, you are saying the deployment of DNSSEC on the authoritative side is the problem/issue, in terms of scale of deployment, and in terms of costs and ease of user, reliability, etc? Do you see other areas where DNSSEC deployment is problematic? I suspect resolver validation needs some boosting, but IMHO, once authority use becomes more common, that should sort itself out. My observation is that what you are stating (about the authoritative DNSSEC) is mostly anecdotal. I'd prefer to be informed by statistical information, if it is available. Or, I'd like to at least provide information (i.e. existence proofs) on reliability, ease of use, cost, and scale, that might help make the case that DNSSEC deployment issues are mostly about communication issues, awareness, and motivation. E.g. There are large-scale operators of managed DNS services who offer DNSSEC at little or no extra cost, trivially easy use, proven reliability, etc. This would seem to partly contradict the deployment thing, if the only thing they need to do is turn it on. (Estimated coverage: 60% of zones.) There are certainly cases where DNSSEC is incompatible (at least currently), such as CDNs, geo-ip, potential ANAME (and provider-specific ANAME-like things currently in use). But aside from those, the barriers to entry have been lowered considerably, at least in the managed DNS space. Brian --000000000000b25fd705857c0d53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 1, 2019 at 4:42 AM Stephe= n Farrell <stephen.farrell@= cs.tcd.ie> wrote:


I would entirely agree if DNSSEC deployment were further along.
However, that is not the case.

As it happens, for the dozen or so small zones I manage, I have
deployed DNSSEC and it's been pretty easy once we figured out
how to automate re-signing and getting DS records to the parent.
(I've yet to do CDS/CDNSKEY stuff but that should improve it
some when the parent registry supports it.)

But I have also spoken to quite a few people who say they cannot
deploy DNSSEC or who think DNSSEC doesn't offer them enough to
be worth the costs.

So, just so I under= stand it, you are saying the deployment of DNSSEC on the authoritative side= is the problem/issue, in terms of scale of deployment, and in terms of cos= ts and ease of user, reliability, etc?
Do you see other areas whe= re DNSSEC deployment is problematic? I suspect resolver validation needs so= me boosting, but IMHO, once authority use becomes more common, that should = sort itself out.

My observation is that what you a= re stating (about the authoritative DNSSEC) is mostly anecdotal.
= I'd prefer to be informed by statistical information, if it is availabl= e.
Or, I'd like to at least provide information (i.e. existen= ce proofs) on reliability, ease of use, cost, and scale, that might help ma= ke the case that DNSSEC deployment issues are mostly about communication is= sues, awareness, and motivation.

E.g. There are la= rge-scale operators of managed DNS services who offer DNSSEC at little or n= o extra cost, trivially easy use, proven reliability, etc.=C2=A0
= This would seem to partly contradict the deployment thing, if the only thin= g they need to do is turn it on. (Estimated coverage: 60% of zones.)
<= div>There are certainly cases where DNSSEC is incompatible (at least curren= tly), such as CDNs, geo-ip, potential ANAME (and provider-specific ANAME-li= ke things currently in use).
But aside from those, the barriers t= o entry have been lowered considerably, at least in the managed DNS space.<= /div>

Brian
--000000000000b25fd705857c0d53-- From nobody Mon Apr 1 13:40:07 2019 Return-Path: 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 EF4B91201B1 for ; Mon, 1 Apr 2019 13:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=xw7YtWt2; dkim=pass (1536-bit key) header.d=taugh.com header.b=F7pxF+Wl 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 E2FFS8PUD3GI for ; Mon, 1 Apr 2019 13:39:54 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 19DD3120502 for ; Mon, 1 Apr 2019 13:39:44 -0700 (PDT) Received: (qmail 56952 invoked from network); 1 Apr 2019 20:39:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=de76.5ca2770f.k1904; bh=v+DbTskWAjK5OTdevx201iwMB0iIPIJ/gbU6sxTBa7k=; b=xw7YtWt2WUceSIEa1aubxi5GptfWZbuXm7zKMsF4/1+xjtiseHVNA3K0uVpPsX6EGz+YhSeUnBJL3FuWI5/bWCikEpibsCrsoVTCIDCfxQTQHr9WPTFPkLYIgWy8m2j53k+blZaCsUIyapQQcOMd4jYn4aSEu8m11rWPcb8RVL0NwP6DbWYmi+XNv6PTzl4Qw0ls084OMEDQ/Ctl31JTWjbxuJ38dsyJsp0qpy8oN6OcgNj0YJVklATPyGOyxDDR DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=de76.5ca2770f.k1904; bh=v+DbTskWAjK5OTdevx201iwMB0iIPIJ/gbU6sxTBa7k=; b=F7pxF+WlSRhuwgkecko3VuokLpga+gISd9SP1x9dcZrhQwnyycIXaorEBBG1aeiO/nf+IYqeLxa4Sg244FVgj+jLP88/uZ6xJ8DLK0xQYh1xQm4omBSxANVipyFSGh3zCbwifz2GD7e0NgG276+cls5zs+QDsGAof0ll6kkPeZAsTBkVcn+ADdfdr0Ikkhlwlh45X5OsVyb716qOrJ0NctHZOjZq6UF4gZQ/AQPCGmLcqrpd+bKd9CmAwr03RREV Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 01 Apr 2019 20:39:43 -0000 Date: 1 Apr 2019 16:39:42 -0400 Message-ID: From: "John R Levine" To: "Stephen Farrell" Cc: dbound@ietf.org In-Reply-To: <71b8a4dd-8bd6-c24c-e8fd-e76c27bee06a@cs.tcd.ie> References: <20190401161900.764062011356DA@ary.qy> <71b8a4dd-8bd6-c24c-e8fd-e76c27bee06a@cs.tcd.ie> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dbound] draft-brotman-rdbd X-BeenThere: dbound@ietf.org 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: Mon, 01 Apr 2019 20:40:06 -0000 >> As far as I can tell nobody does anything like that for DKIM keys. > > I don't know if anyone does, but wouldn't be surprised if some > anti-abuse folks reacted to a mail provider switching from one > long-lived key selector to a new one not seen anywhere before. (But I'm > speculating there, others who do that kind of thing for real would need > to confirm that or not.) That's more likely to be taken as a positive signal, that they finally got their key rotation working. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Apr 1 14:25:41 2019 Return-Path: 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 EAA14120114 for ; Mon, 1 Apr 2019 14:25:40 -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 a9m96OgIzjdG for ; Mon, 1 Apr 2019 14:25:37 -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 701A012000E for ; Mon, 1 Apr 2019 14:25:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6BD56BE24; Mon, 1 Apr 2019 22:25:35 +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 s_XVUEULceip; Mon, 1 Apr 2019 22:25:33 +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 2CA6BBE20; Mon, 1 Apr 2019 22:25:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554153933; bh=UWdwq/kJ1M16LGVsTMS7EPNjacLsbmrbxOZssunoAe4=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=3Uiq7PBn8IYM+7yLayBZY5rDIdgGO21cHhi1B3/wKOYlD+KBCbf+l0lz1Js8KoYf9 9iJ0KuP+LlrNZC9UtLn8XrrTyX9i47AGqv2Jj2q4NhgcTAF1uheMlpMJMqwa175d76 cJsGFsoEqZmQQNbHPx7Hpz/3V0QI5AUYqxSV5PJw= To: Brian Dickson Cc: dbound@ietf.org, "A. Schulze" References: <7d34857c-a99b-389a-90e5-2e4fe6f4e736@cs.tcd.ie> From: Stephen Farrell 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: <4561e898-4446-c4bd-75d8-1c49a75184ad@cs.tcd.ie> Date: Mon, 1 Apr 2019 22:25:32 +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: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Iv9auoZex6k7MBl2849KNRxIdLNxFEyc7" Archived-At: Subject: Re: [dbound] draft-brotman-rdbd X-BeenThere: dbound@ietf.org 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: Mon, 01 Apr 2019 21:25:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Iv9auoZex6k7MBl2849KNRxIdLNxFEyc7 Content-Type: multipart/mixed; boundary="8Jjqt8F1TdCott1a15ZurEjgWafB8U6Cs"; protected-headers="v1" From: Stephen Farrell To: Brian Dickson Cc: dbound@ietf.org, "A. Schulze" Message-ID: <4561e898-4446-c4bd-75d8-1c49a75184ad@cs.tcd.ie> Subject: Re: [dbound] draft-brotman-rdbd References: <7d34857c-a99b-389a-90e5-2e4fe6f4e736@cs.tcd.ie> In-Reply-To: --8Jjqt8F1TdCott1a15ZurEjgWafB8U6Cs Content-Type: multipart/mixed; boundary="------------11415B07B4B9BC3D12CAE29D" Content-Language: en-GB This is a multi-part message in MIME format. --------------11415B07B4B9BC3D12CAE29D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/04/2019 19:18, Brian Dickson wrote: > On Mon, Apr 1, 2019 at 4:42 AM Stephen Farrell > wrote: >=20 >> >> >> I would entirely agree if DNSSEC deployment were further along. >> However, that is not the case. >> >> As it happens, for the dozen or so small zones I manage, I have >> deployed DNSSEC and it's been pretty easy once we figured out >> how to automate re-signing and getting DS records to the parent. >> (I've yet to do CDS/CDNSKEY stuff but that should improve it >> some when the parent registry supports it.) >> >> But I have also spoken to quite a few people who say they cannot >> deploy DNSSEC or who think DNSSEC doesn't offer them enough to >> be worth the costs. >> >=20 > So, just so I understand it, you are saying the deployment of DNSSEC on= the > authoritative side is the problem/issue, in terms of scale of deploymen= t, > and in terms of costs and ease of user, reliability, etc? > Do you see other areas where DNSSEC deployment is problematic? I suspec= t > resolver validation needs some boosting, but IMHO, once authority use > becomes more common, that should sort itself out. Seems a bit of a side-issue for this discussion but happy to discuss off-list. (I do think launching into each of our ideas as to what's good or bad about DNSSEC would be distracting here and more on-topic e.g. for dnsop and not this list.) >=20 > My observation is that what you are stating (about the authoritative > DNSSEC) is mostly anecdotal. Sadly not. [1] seems to show that <1% of .com 2lds are signed and barely more than 1% of .net 2lds. [2] provides a bit of a basis for limited optimism but still shows around about 1 million signed 2lds despite some ccTLDs offering small financial incentives to those who sign. A 2018 peer-reviewed paper [3] ([4] for non-paywall) including Roland Van Rijswijk-Deij as an author (whom I at least would trust on this) says that "The security extensions to the DNS (DNSSEC) currently cover approximately 3% of all domains worldwide." (Which I guess can be consistent with the above given depth inside signed zones.) FWIW my general position is that we ought be making DNSSEC easier to use where we can, and we should encourage deployment but we cannot really make it a dependency for pretty much any new protocol, or that new protocol will be extremely constrained in where it can be deployed. (The optional RDBD signature mechanism is consistent with that, in that it kinda tries to spread the benefits of DNSSEC to an RR from the related domain, if the relating domain is DNSSEC signed but the related domain is not.) Cheers, S. [1] https://www.statdns.com/ [2] https://stats.dnssec-tools.org/ [3] https://ieeexplore.ieee.org/abstract/document/8406223/ [4] https://research.tue.nl/en/publications/economic-incentives-on-dnssec-dep= loyment-time-to-move-from-quanti > I'd prefer to be informed by statistical information, if it is availabl= e. > Or, I'd like to at least provide information (i.e. existence proofs) on= > reliability, ease of use, cost, and scale, that might help make the cas= e > that DNSSEC deployment issues are mostly about communication issues, > awareness, and motivation. >=20 > E.g. There are large-scale operators of managed DNS services who offer > DNSSEC at little or no extra cost, trivially easy use, proven reliabili= ty, > etc. > This would seem to partly contradict the deployment thing, if the only > thing they need to do is turn it on. (Estimated coverage: 60% of zones.= ) > There are certainly cases where DNSSEC is incompatible (at least > currently), such as CDNs, geo-ip, potential ANAME (and provider-specifi= c > ANAME-like things currently in use). > But aside from those, the barriers to entry have been lowered considera= bly, > at least in the managed DNS space. >=20 > Brian >=20 --------------11415B07B4B9BC3D12CAE29D Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------11415B07B4B9BC3D12CAE29D-- --8Jjqt8F1TdCott1a15ZurEjgWafB8U6Cs-- --Iv9auoZex6k7MBl2849KNRxIdLNxFEyc7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyigcwACgkQWrL68XsX K+oGrQ//ZeTHFzs4M66nSgcwlJ43q301qZu7bqGZ2X/zeU0ndjneVeLjOm/jCh6Y HkJZv05VKqS/nwf7HlgphIvaPH2q2QqqOmSZi9uXJ6zhR1UvHW/oSr0yV8YpdxTf 3NM+xqNI5EQxIg9fJw7c19y1TP0AmAEVHGmtal9rvkQFQnVxRus+Jx45HeKnARct NhLJl6S/nMaplRmRbn61n7/3KgRTXzYV+x8Pl4fLKqe8o+5+CoqKuStUpqKimExn C5CDkYWmJxoKkAzK+zdEyo8IWjckql+VnjHLe7c7M/gyBYbumGogp1NgzcoKeOiJ PgHl/DtvwKlqI0oFpr5j3JyfTr1iSY0OZPOgQQc9uGev6lkyq25aCJiqcrNi94gs V9jxIArAE82cjdDjaXvIdY2iFnVxB0EFn1jJtlrpFCMGCNfJeii0BMQz9EuDdaxu hHgyI0JieY5hT/ph6BtwgrO7ibJ1WSoWgknmiVrnohz3fbcj+jguajRjrQkgoKib 2ikK8MaZc9C25e0Ma6NjJHSXDh9q0YddU1UnllNctYXN00kpPEVjMpKZgKohgi9N lfJex4pa/nA80SM+UK8atQjAurZhAqG51FCj6bucTa3wXqzEkBD65va07KQZrO9/ IlYrEiY3X9VdbbPuEWl0X14wCA9XOkVrN+ADG8YcSFy2kDyg6jM= =/qsJ -----END PGP SIGNATURE----- --Iv9auoZex6k7MBl2849KNRxIdLNxFEyc7-- From nobody Tue Apr 2 17:38:00 2019 Return-Path: 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 8BDEF1203C4 for ; Tue, 2 Apr 2019 17:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=dcrocker.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 TLBL3Mfk3yzj for ; Tue, 2 Apr 2019 17:37:56 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 946CD1203D9 for ; Tue, 2 Apr 2019 17:37:56 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x330dcbL008051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Apr 2019 17:39:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554251979; bh=n7LvFLO2lAglJuJ7b/luZqjqwPtME22j9ZTSzPMESwo=; h=From:Subject:Reply-To:To:References:Date:In-Reply-To:From; b=gHU03tKfP4tv+FPqbvVOfaQISdCOwATZ3rxm5rnWtC5K5x+J7D7wsgRLCVFhsRYch LZNJoqc8UTdRAIb24ooPBqAry5daZXeJ2zZieQiUrhjS7exLEConQGqrd928KAsNio 6zAL1JYB5XoTJ7ZxDPQebS/b3nkDh1j1VT1bNvPU= From: Dave Crocker Reply-To: dcrocker@bbiw.net To: dbound@ietf.org References: <155425099487.6400.1606471852874664183.idtracker@ietfa.amsl.com> Organization: Brandenburg InternetWorking Message-ID: <3f9c52d2-fbfc-fc8c-2251-62b5b8bc6cc4@dcrocker.net> Date: Tue, 2 Apr 2019 17:37:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155425099487.6400.1606471852874664183.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dbound] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 00:37:59 -0000 Hi. Just posted this... (I'm separately sending this to the dmarc list, but figure cross-posting isn't productive.) Comments eagerly sought, of course. d/ -------- Forwarded Message -------- Subject: New Version Notification for draft-dcrocker-dns-perimeter-00.txt Date: Tue, 02 Apr 2019 17:23:14 -0700 From: internet-drafts@ietf.org To: T. Adams , D. Crocker , Dave Crocker A new version of I-D, draft-dcrocker-dns-perimeter-00.txt has been successfully submitted by D. Crocker and posted to the IETF repository. Name: draft-dcrocker-dns-perimeter Revision: 00 Title: DNS Perimeter Overlay Document date: 2019-04-02 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-dcrocker-dns-perimeter-00.txt Status: https://datatracker.ietf.org/doc/draft-dcrocker-dns-perimeter/ Htmlized: https://tools.ietf.org/html/draft-dcrocker-dns-perimeter-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-dcrocker-dns-perimeter Abstract: The Domain Name System (DNS) naming syntax provides no meta-data for indicating administrative transitions through the hierarchy. For example, it does not distinguish the higher-level portions that operate as public registries, versus those that operate as private organizations. This specification creates a basic overlay mechanism for defining a logical Perimeter between administrative entities through the naming hierarchy. The mechanism can then be applied for a variety of independent administrative indications. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 10:58:25 2019 Return-Path: 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 B912412010C for ; Wed, 3 Apr 2019 10:58:23 -0700 (PDT) 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=6MQBOjhJ; dkim=pass (1536-bit key) header.d=taugh.com header.b=DXbCf9Yl 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 fmTZbdK2tO-A for ; Wed, 3 Apr 2019 10:58:22 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 C360B120166 for ; Wed, 3 Apr 2019 10:58:21 -0700 (PDT) Received: (qmail 91600 invoked from network); 3 Apr 2019 17:58:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=165cd.5ca4f43c.k1904; bh=CJ5DceGTkrg3/JuZKhQOIl8xArSYrf8l3zcWIfW1OWM=; b=6MQBOjhJBhCgMTAMcrytb4BEpaCcN3aNytxAKOAa3X2CH4VmLKs9vl5uT1rs1SW8IzZUyo0NGAc/3ecRFtUSaboMOT9F2eQTjPRmsnDc+fQ/uBV/+QsrWM99r8OadP37iJtnPfzWCiWIvBOTqSmdtOWl8a+Bp21xN/7EfeaEPObjL0jXEW1msbeUPevHjJegOFi9+ERO1DqtLNcSqgar0Fni+O+3kfg5Gkz15Wj7tAuDZRjf+o0Dwb/nIhO8Gb8f DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=165cd.5ca4f43c.k1904; bh=CJ5DceGTkrg3/JuZKhQOIl8xArSYrf8l3zcWIfW1OWM=; b=DXbCf9YlnSlRZxE3SV+YLhhNt+1xXVZ2kC3k/A1fSlhT9b9vTuvnyXqaay4K9D+nWq9Ngj+kefOehlnGmrPH81iD8Nrs4/hnzciDbCsLj/mpymplsc+xI3ElUzTNrofuGvzPXIQOiJ/7ASDCASGJqiBLLMkrEHRFp1iN6td0Yjf57JhZCS5ani1HF6FMu9mgf5UygaEes98Tgdh8RBpZyKcrq06z+S5AOap2nmjZVASo0r/2VRM0OTRD0qld92L9 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 03 Apr 2019 17:58:20 -0000 Received: by ary.qy (Postfix, from userid 501) id 8391420115F376; Wed, 3 Apr 2019 13:58:19 -0400 (EDT) Date: 3 Apr 2019 13:58:19 -0400 Message-Id: <20190403175820.8391420115F376@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net, dbound@ietf.org In-Reply-To: <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 17:58:24 -0000 In article <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> you write: >Comments eagerly sought, of course. This seems sorta kinda like my dbound draft, only with _tagged TXT records rather than a new rrtype, and (unless I missed something) a hope that somehow you can use a yet to be invented cache to avoid walking up the tree, where mine used wildcards to do one lookup per boundary regardless of the tree depth. I can see that the tradeoffs are different but I don't see why they're better. R's, John >A new version of I-D, draft-dcrocker-dns-perimeter-00.txt >has been successfully submitted by D. Crocker and posted to the >IETF repository. > >Name: draft-dcrocker-dns-perimeter >Revision: 00 >Title: DNS Perimeter Overlay >Document date: 2019-04-02 >Group: Individual Submission >Pages: 20 >URL: >https://www.ietf.org/internet-drafts/draft-dcrocker-dns-perimeter-00.txt From nobody Wed Apr 3 11:23:06 2019 Return-Path: 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 D670C120123; Wed, 3 Apr 2019 11:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=dcrocker.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 Lu1SfZN4tquC; Wed, 3 Apr 2019 11:22:58 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 C5CBA12010C; Wed, 3 Apr 2019 11:22:58 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x33IOf5L001971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 11:24:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554315882; bh=BkahvQtoi62nxdS+sC5YrM1Z3uYJVGP9lhzIYvO2PKU=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=Ml8IIRWXhhN5SPG0lTEf9kyvIzNgbLv5KZxxhyBlYGzchb5mrzZTQusZfOVJ6yVux eVeOVgJ6jusheFlqhvgF9jhORMRfKjIgfBQ6Sh3T+n9eKznDuzJXlgC/ppYWYIwroR an5bFMZTDzi4pkWGtIOLgfh0DHaaYnhpYhRPwKwg= To: John Levine , dmarc@ietf.org Cc: dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> Date: Wed, 3 Apr 2019 11:22:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190403175820.8391420115F376@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 18:23:00 -0000 On 4/3/2019 10:58 AM, John Levine wrote: > In article <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> you write: >> Comments eagerly sought, of course. > > This seems sorta kinda like my dbound draft, only with _tagged TXT > records rather than a new rrtype, and (unless I missed something) a > hope that somehow you can use a yet to be invented cache to avoid > walking up the tree, where mine used wildcards to do one lookup per > boundary regardless of the tree depth. Section 7's suggestion for using Additional information does not rely on caching. Reliance on existing wildcard depends on propagation of a new RR, which continues to be problematic. There's a reason the Attrleaf table has so many entries... And while there is certainly conceptual overlap with your earlier proposal, the current one has differences I'd class as significant. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 11:45:15 2019 Return-Path: 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 3B936120163 for ; Wed, 3 Apr 2019 11:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=nVmUezbn; dkim=pass (1536-bit key) header.d=taugh.com header.b=mkR/I07n 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 6XqIF2JlrzJ2 for ; Wed, 3 Apr 2019 11:45:04 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 1049412013F for ; Wed, 3 Apr 2019 11:45:03 -0700 (PDT) Received: (qmail 4640 invoked from network); 3 Apr 2019 18:45:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=121e.5ca4ff2e.k1904; bh=RiWjXqdi02tRtFWsHlf5LML/zSn96MpMpbLP1+SIZbU=; b=nVmUezbnKNk554YMNKuTkUyX3Y67z4wPtq8jGogwjz5ZsWwg7SeKd5/8w33VlOzJBBeC6rYb0t8x6a5mDWfVBPy0WAD5UtAx+EnNk+xly5eJ0zkfEzQtO8j8nWdKcWOvcQ1OYqwd745VxPTXWHAXlco1k8yibLj3A69n5TzUC59A/hrFgbeqwGx5AZSH6HpHVKsyhgv7RQnmg3L/O3AuMJMU+N2fIGhCAELwxjNMnBV2wh03n+v7DNA009cWJ+K7 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=121e.5ca4ff2e.k1904; bh=RiWjXqdi02tRtFWsHlf5LML/zSn96MpMpbLP1+SIZbU=; b=mkR/I07nmTaHAfvqTrVzSVUQCbMZUovHINjOvdYiAE/ZnhPeRyAPMrSPn6e/aoOPm1dc6PVKArc7J4OE8P5CgWEzJBJwe3UMljYqQ8yg8m0aV1YXgtp5FQ30vIxOtY4oEQta+MNtY2JYeqsvMGLNyH3dVKT4l6XX/8CiYudR/S1cEnwvSJ/DrnA4JITrzccQsXlVOHodG7wTVEnmD8rE1JOeoev9oGtmKJdkYsiz/zbGcwQubpCdGr2RKASFII4d Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 03 Apr 2019 18:45:02 -0000 Date: 3 Apr 2019 14:45:01 -0400 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net Cc: dmarc@ietf.org, dbound@ietf.org In-Reply-To: <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 18:45:07 -0000 On Wed, 3 Apr 2019, Dave Crocker wrote: > Section 7's suggestion for using Additional information does not rely on > caching. > > Reliance on existing wildcard depends on propagation of a new RR, which > continues to be problematic. There's a reason the Attrleaf table has so many entries... Now we're having a discussion about which is the frying pan and which is the fire. In my experience, these days getting a new rrtype that doesn't have extra semantics into DNS servers happens pretty quickly. It's an entry in a table or a new short stylized parse/unparse routine. DNS caches don't have to change at all. The problem is the web provisioning crudware, which is what I have tried with limited success to address with my DNS extension language work. My dbound draft has no new DNS semantics, just ordinary wildcards and an ordinary rrtype. To put anything into the additional section, you're asking the DNS servers to treat a _perim name specially if there are TXT records under the name and to go search through the zone to find the extra stuff and put it in the additional section. DNS caches have to change too, to treat the additional stuff as non-hostile and pass it through, since caches throw away unrecongnized additional sections to prevent cache poisoning (the Kashpureff bug.) You should run this by dnsop where I expect you'll get a great deal of pushback and references to the DNS Camel for anything with new semantics. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Apr 3 11:52:07 2019 Return-Path: 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 8307A12013F; Wed, 3 Apr 2019 11:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=dcrocker.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 5kj1xJBNt3wJ; Wed, 3 Apr 2019 11:51:57 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 02330120163; Wed, 3 Apr 2019 11:51:56 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x33Irdee004165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 11:53:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554317620; bh=oYp3+ESlg1TZsFS+AAMMYcb1cJVZ+kEfzAgEJrxLYZs=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=kzBzdafWGhM4KJHi0wY2qEMB2SresZurjKCmwvsQTa7deSeGNJQOY1iVsAB6VtRB1 NYs9HLsB+FxXuP7qpYgzO6Mik1QOPOCxTSLBm+2s+ATi614GHT+A6wGDN8JBXCfMfB 0+Oqc26tMgtwK34KFl9sJ7Di3Dm+xx0/nqLXtzyY= To: John R Levine Cc: dmarc@ietf.org, dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> Date: Wed, 3 Apr 2019 11:51:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 18:51:59 -0000 On 4/3/2019 11:45 AM, John R Levine wrote: > On Wed, 3 Apr 2019, Dave Crocker wrote: > In my experience, these days getting a new rrtype that doesn't have > extra semantics into DNS servers happens pretty quickly. 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? >   My dbound draft has no new DNS > semantics, just ordinary wildcards and an ordinary rrtype. I noted that. > To put anything into the additional section, you're asking the DNS > servers to treat a _perim name specially if there are TXT records under I noted that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 11:53:07 2019 Return-Path: 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 D067012019E for ; Wed, 3 Apr 2019 11:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jothan-com.20150623.gappssmtp.com 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 qw0WP7_iSke5 for ; Wed, 3 Apr 2019 11:53:01 -0700 (PDT) Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0160912017B for ; Wed, 3 Apr 2019 11:53:00 -0700 (PDT) Received: by mail-vs1-xe43.google.com with SMTP id g127so10631375vsd.6 for ; Wed, 03 Apr 2019 11:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jothan-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TmN/qrPhRhV1GHX/Sn1HgNa+l66ldBWUCuTHxO6PdO4=; b=EGg3/sVfEi4QVDsYs3oojakuwOArbJQj8diDQu8pcfWE5uJATlHUTNtk9PFwcc3Jdg IsqD26gDAUtVNysBDDCKUvZqBsZ3ECPkZ1xdcA8bQqRGPZaNHaxwPie7x+a5RuZl0+eo x6AB7h4/lWV7fRpx+ocw9SVXQM6mVUfQEnWeDbk4W1UrRYlPrmlx8o/c37Fv2SG5YSdz 8+OowI0KcN1Uh6Gdh/CrAQffjSzDcIe+PVL33ZDcRRtbaS5HjdSYkqUBXAX+T3Gfo2pA GlKLY5hfWSd1LEF/1Ka1OWvXFkE/hYAOzI9hX9q6FP7WQo/TvJxcdBsoni6w6t5ITEFH BjCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TmN/qrPhRhV1GHX/Sn1HgNa+l66ldBWUCuTHxO6PdO4=; b=NGBoSkMpbj6kPbKl7I+Ba9wiMu5O7cVsnRE3IX7l5c+It5BAip1jMLSHw1TMW0REMQ wU8AnysdZLg86vP4cTH5YYcrJK7g2CGEPzb3T0xORdGROg1A9apXlZaokOaJGy9sa9L7 xqLCLaR8jDoqHZO+HV+bOBYnmofQcvoOl8M1aiQyVqtJeiOw/LFNAvE59rFNYq2hJa5e U5rw5biXgE8Q2gvxDaVdFYAsIstf66IL6Y+UG6ogDBI+MwHUgLDocUSo+5sTqGW8obja 6L+L4KRB27bnAbKxOIIKTuYxjFa2kjurml5nMhM2jL5aFBkoQ75Qucj46U6W65Eks36Q H5XQ== X-Gm-Message-State: APjAAAWbI7r03SRkG8ZGHtz9mtT0XIpLsRlnOLoNZEoeGXqwzwK8p9qI NtD1wvF9RV+2or4sqlm0TjqL/aDzcSg5GYerXIw1tg== X-Google-Smtp-Source: APXvYqyQd7Vo9aU1pH11vPWKShBswFBM+sGGCwIh1q8z2jRniO0mvlb4C+Xz2cugK15Fb+gGK6v9fpmezmiIX6jFYpE= X-Received: by 2002:a67:eb41:: with SMTP id x1mr1449705vso.84.1554317579930; Wed, 03 Apr 2019 11:52:59 -0700 (PDT) MIME-Version: 1.0 References: <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> <20190403175820.8391420115F376@ary.qy> In-Reply-To: <20190403175820.8391420115F376@ary.qy> From: Jothan Frakes Date: Wed, 3 Apr 2019 11:52:31 -0700 Message-ID: To: John Levine Cc: dmarc@ietf.org, Dave Crocker , dbound@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 18:53:04 -0000 I appreciate the time you invested in this Dave. I definitely like that we're thinking in terms of how to leverage DNS and its distributed model vs emulating the hosts.txt situation, and PSL is essentially a hosts.txt situation. Some assert there is a benefit to being able to contain some form of static list locally for speed. This happens at the trade-off of potentially stale data, which we experience as maintainers receiving energy from expressive TLD admins describing their grief over their domains being directed at search instead of resolving in DNS because their pc, tablet or mobile device runs a browser software that did not contain their TLD. So in those cases (and potentially others) getting things into DNS _might_ be better. I think that a TLD administrator being able to make direct updates in their own zones is vastly better because it would both alleviate the arduous process of validating authority of requests, and streamline the requesting process to near zero on their updates, and enable more direct and exacting control by the registry operators. That said, we fail the community unless the potential replacements take into consideration the many constituent / subjective uses of PSL that have evolved across the years before we tick the box next to any particular solution meeting the diverse needs. We have to tread carefully here. I have great respect for the IETF and the many wise and noble experts that have donated their experience, time and wisdom towards solutions and standards. It is a process that requires patience and I have been told by many in the developer community that it is not always one that is inclusive or able to meet the pace of some development cycles and product or service evolution. The PSL basically came into existence outside of the IETF process, borne of real practical needs, and those needs have forked and matured. There is a 'lenticular' / perspective issue in how different stakeholders are using the PSL. PSL is included in software libraries, which incorporate it without prescribing how a developer might use it. Some care only about the private section of the list, some only about the "ICANN" section. Some integrators of the PSL omit certain elements, or even maintain their own supplementary sections for their project or service needs. Think it is safe to assert variety is present - each have an entirely different need and application of some or all of the PSL's contents than a browser program, search engine, security professional, anti-spam, reporting, SSL Cert, or other use. We (maintainers) don't prescribe specifically how it gets used as volunteer community maintainers, we just try to guide community entries and validate them (and focus on ICP-3 or other I* integrity). PSL is expanding - which grows the file size each time. As potential solutions are presented from web developers or even the IETF (or both) that might help to organize or better architect solutions that could help PSL from heading towards something that emulates the transition from the SRI hosts.txt challenges, I fear that unless we can ensure that some of the dependencies are met by those proposals, the proposals will not endure, and we'll remain using the PSL in a status quo manner. -Jothan Jothan Frakes On Wed, Apr 3, 2019 at 10:58 AM John Levine wrote: > > In article <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> you write: > >Comments eagerly sought, of course. > > This seems sorta kinda like my dbound draft, only with _tagged TXT > records rather than a new rrtype, and (unless I missed something) a > hope that somehow you can use a yet to be invented cache to avoid > walking up the tree, where mine used wildcards to do one lookup per > boundary regardless of the tree depth. > > I can see that the tradeoffs are different but I don't see why they're better. > > R's, > John > > >A new version of I-D, draft-dcrocker-dns-perimeter-00.txt > >has been successfully submitted by D. Crocker and posted to the > >IETF repository. > > > >Name: draft-dcrocker-dns-perimeter > >Revision: 00 > >Title: DNS Perimeter Overlay > >Document date: 2019-04-02 > >Group: Individual Submission > >Pages: 20 > >URL: > >https://www.ietf.org/internet-drafts/draft-dcrocker-dns-perimeter-00.txt > > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound From nobody Wed Apr 3 12:02:58 2019 Return-Path: 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 427D8120603; Wed, 3 Apr 2019 12:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=dcrocker.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 F1A1q1DMtzUj; Wed, 3 Apr 2019 12:02:52 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 8A3A9120651; Wed, 3 Apr 2019 12:02:52 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x33J4Z28005680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 12:04:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554318275; bh=cEholvvSqRkifT9cJkCKmgEWU6I8zWxhsjwYz67GWaY=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=QnoHdB8tTryF8z1r7WvpiL2L/r5mdK7H0O7rCT71FvF962sngfbC1bwqUqUsRxlIg OQ2LnPKvtrDSBDpanUPOc+kDE1eOLziY7t3YvBHRAjZa2/sWaMPvZShaGtae5LGSiD EQCz0z/Hsy4X3m0hKjfs3yMKR8+6Yfc9x22JX2pY= To: Jothan Frakes Cc: dmarc@ietf.org, dbound@ietf.org References: <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> <20190403175820.8391420115F376@ary.qy> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 3 Apr 2019 12:02:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 19:02:58 -0000 On 4/3/2019 11:52 AM, Jothan Frakes wrote: > I fear that unless we can ensure > that some of the dependencies are met by those proposals, the > proposals will not endure, and we'll remain using the PSL in a status > quo manner. Jothan, Thanks for adding comments so quickly after the draft was released. As the draft notes, it attempts to cover PSL use cases but needs far more experienced eyes and minds to find where the PSL emulation needs more work. To that end, anything that documents the dependencies you cite is sure to help. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 12:06:20 2019 Return-Path: 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 DD73712016D for ; Wed, 3 Apr 2019 12:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=GdUa8KR1; dkim=pass (1536-bit key) header.d=taugh.com header.b=ZHORJZHD 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 hxDAhwQjcj4c for ; Wed, 3 Apr 2019 12:06:05 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 7BAC7120178 for ; Wed, 3 Apr 2019 12:06:04 -0700 (PDT) Received: (qmail 12597 invoked from network); 3 Apr 2019 19:06:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3131.5ca5041b.k1904; bh=9Iw+6xP6Dct64Xmu3aWDaRvlhTAO/EYBtfnqwgEGOMY=; b=GdUa8KR11U1QEDmfYIlOJmZRXvt9vr16xZQQKMRebhAEA47eT0ztJBJRpmtxclvwxLfJl7ibVdLtJMIYzcQhPCKIC2o0PKMwiGfV24amERGBCzkgd0sauDLHBZSDz/IlIODVCA2Dea7T65U2qIhoAuzdsjGoSv6NDaQ0W60LR3cenXc4/77LtvGMQYxFUnOKv6CHx2/DPJJpiov5ExHCp9poqzSZWbJWOqFWkBwHvFU8i6tJe0vPwGJxThA5iJiU DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3131.5ca5041b.k1904; bh=9Iw+6xP6Dct64Xmu3aWDaRvlhTAO/EYBtfnqwgEGOMY=; b=ZHORJZHD9Dj0cMYyu92cQT6eDzdTVsfz+yMfmo4ihGMPbpu7ReKoStd1deA3AanGCz/LFpObXSA+azsxnf6VTlAXHVJ9OMHMU7Csv3Khy58B5NMOB3gY7iMoAUmaTxwMcST2cZVDM2IrFdZz3dGGWJkmatyFGFgUjsYq3DDOyI4+60ibRUlAy74scm+kudDNXOMXVkBnqd1MuXb4L28x4SaKLmLGb8imDSKijFMpReyWrnXna6TCtmeuRNEQc36M Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 03 Apr 2019 19:06:03 -0000 Date: 3 Apr 2019 15:06:02 -0400 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net Cc: dmarc@ietf.org, dbound@ietf.org In-Reply-To: <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 19:06:07 -0000 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 From nobody Wed Apr 3 12:20:00 2019 Return-Path: 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 CBE9712017A; Wed, 3 Apr 2019 12:19:51 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yqeVKHvVRD8z; Wed, 3 Apr 2019 12:19:50 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F165D120172; Wed, 3 Apr 2019 12:19:49 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id w24so2119881plp.2; Wed, 03 Apr 2019 12:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zQmHF4nLMHqRVtIre9MxcEK3ViqSxg+LKRr5uLnfndI=; b=BvmvDayD4CksoGLGNj2wBgPfSb+r0wnRTQVxcNqaqftJmzRBXQn7VWZDqGNAiitwcF BEctn8O7vt8oX56WaJp6AsY+Ygat4rvHkKIbtUBcjCPEbtKcKsnfHM7tIU7PqQ3kHSsI CwWn6BvBm0SPkmHEI39iTFkrEywdJdDXVzWeCEKOuGRXpXJcpdNHZAyVWyFLtDiFHaWI QPogA5gX+PlYBWR8ookQcKkb0++057r3Hgzf48G3kKLnb0My4Fj0VNxTHhjopCo3Bcu8 f65Pkbfp2iNI0zCNkzK3KVolkt9OPHk5mx4LPmjAxtcBWc8oD4QXjWEu60OEhDD5yI6B 9gPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zQmHF4nLMHqRVtIre9MxcEK3ViqSxg+LKRr5uLnfndI=; b=bCIXqByJHAP/wZQR6yb+CDeWAeZznOfHE0GzhM73qyHhG/qO87nVBdewTzwfa9IWwB h0hghYPTMHmvTtz0uYEIrjBnC190vVeqBHTRCrLePtqoIIFMsVSAPuHYQgkB/bWqBOcV bgOlvaXSO6sNYB456eLQaMoLEYPJGuZY/hq0cWPB0BxXrgY53k/dVayq2zdBigQipLQp xgsvyUYUYA3QGA/vChRxStv1GWKRfFYehatGGtUcxdrT4cUZiJIDvAKUnyIZD+Hcj9uS IVSEHLWfcaXQLt2WSXIeQMgZNr+uGIjcbzY3P2YokHjBAAcokkCqvYRcSaDswvpItIpR cn7A== X-Gm-Message-State: APjAAAU5wwsZW8TJYOBIJnydsD57ZjEMkXb46ZYiwl0VNMccFwfpyJ0a TugpYoW/P1jnRjslvzxy22o= X-Google-Smtp-Source: APXvYqw8L4yQPQV30Gi9ZwHdQmhIsaF/hvFpd7wiPHlfUemnnHbrfiotULATjk7UAAbBhgBjlftOhw== X-Received: by 2002:a17:902:7841:: with SMTP id e1mr1688893pln.303.1554319188729; Wed, 03 Apr 2019 12:19:48 -0700 (PDT) Received: from [172.19.248.162] ([104.153.224.169]) by smtp.gmail.com with ESMTPSA id i2sm24400685pfo.9.2019.04.03.12.19.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Apr 2019 12:19:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: tjw ietf X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Wed, 3 Apr 2019 20:19:41 +0100 Cc: dcrocker@bbiw.net, dmarc@ietf.org, dbound@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> To: John R Levine Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 19:19:52 -0000 I was going to say CAA but that=E2=80=99s 6 years old.=20 =46rom my high tech gadget > On Apr 3, 2019, at 20:06, John R Levine wrote: >=20 >> On Wed, 3 Apr 2019, Dave Crocker wrote: >> Now, about /end to end/ support, not just publishing... >>=20 >> Please provide some examples comparable to your proposed use case. That i= s, what are new RRs that are getting well-scaled, on-going use, defined in s= ay the last 5 years? >=20 > There aren't many other than maybe CDS and CDSKEY. TLSA was defined in 20= 12 and Viktor says it's getting pretty wide use now, particularly considerin= g that it needs DNSSEC. >=20 > On the other hand, there hasn't been anything with new server semantics si= nce NSEC3 in 2008. >=20 > This is really an argument for dnsop, not dmarc or dbound. >=20 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Apr 3 12:49:37 2019 Return-Path: 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 , John R Levine Cc: dmarc@ietf.org, dcrocker@bbiw.net, dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> From: Stephen Farrell 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: 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: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZTmRrlWH5ErvqJ0DRDkrYhiEbzl9QUB07" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 19:49:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ZTmRrlWH5ErvqJ0DRDkrYhiEbzl9QUB07 Content-Type: multipart/mixed; boundary="kAXCG537LYwE0YL2xJzEwhklxe6ljydYL"; protected-headers="v1" From: Stephen Farrell To: tjw ietf , John R Levine Cc: dmarc@ietf.org, dcrocker@bbiw.net, dbound@ietf.org Message-ID: Subject: Re: [dbound] [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> In-Reply-To: --kAXCG537LYwE0YL2xJzEwhklxe6ljydYL Content-Type: multipart/mixed; boundary="------------5D07C1BDC25D6FEFA8A7B3A3" Content-Language: en-GB This is a multi-part message in MIME format. --------------5D07C1BDC25D6FEFA8A7B3A3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=E2=80=99s 6 years old.=20 >=20 >=20 >=20 > From my high tech gadget >=20 >> On Apr 3, 2019, at 20:06, John R Levine 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. T= hat is, what are new RRs that are getting well-scaled, on-going use, defi= ned in say the last 5 years? >> >> There aren't many other than maybe CDS and CDSKEY. TLSA was defined i= n 2012 and Viktor says it's getting pretty wide use now, particularly con= sidering that it needs DNSSEC. >> >> On the other hand, there hasn't been anything with new server semantic= s 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= =2Ely >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >=20 > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound >=20 --------------5D07C1BDC25D6FEFA8A7B3A3 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------5D07C1BDC25D6FEFA8A7B3A3-- --kAXCG537LYwE0YL2xJzEwhklxe6ljydYL-- --ZTmRrlWH5ErvqJ0DRDkrYhiEbzl9QUB07 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlylDjkACgkQWrL68XsX K+pF0RAAnfCFfUlZyZdD9t8JKY1BMpGN5E+jcZDOs7lIMnOXU4DhUCrMlzgAxjVA 5Xhc/DeHYXp2qiOmDkiQ10XpgbS2TmGaNZlbXGXOdxN4Fm2M7DswFn1kn25ltwgT p3Z6m28UQyhI1uvl346Z0pPCGDcqbwpzjpAemco56HY6hlYzZwJ4meG8TLWphuva wRQV7xo2CD5IoLHe1MsEtby63DXbAyuhn+wi0wkScLHBmTrpvbp6olXKG9qHWVVl ycLuKzgDM4sRvizOwAl8MGuVH6wQl23L5E12QQGl0FyTHUh5pI2fiIzxJ5VfAsJL +kjia8kP9ftxQsHlKLKjb4xuM1OCd7PEOmja7aHx4D7MbRGXjwBqW71dX6D2MIcL 2V0fEF0eQt+KBqbIi0ImxUIW8SCRd43eF23K/bYRsdz3CLnH69VAH4F9g4EiT2FN kLXDqwOFb/3z8yoQeb3acOMAeZnH/GKBkhDaP4ZGJOdrk46wbsfT6Fzsd9+Zdbee 5JHS+6AKOuRos6WHMziT8chDIO+Lf8NRR27f/ely51c3rdbK6SwUQ+ZlbZH4KaU8 ra5VEAf7tylp/jmBV4PVXkcoU1X0gt7H2KKGC1Kh7tKpsMHaAtPTd6iXtlNWgwqT ZORYBSS+miRez11yHnWfAHsGonVInvW4NgdrGMRnNze17q2iquw= =ihaW -----END PGP SIGNATURE----- --ZTmRrlWH5ErvqJ0DRDkrYhiEbzl9QUB07-- From nobody Wed Apr 3 13:20:22 2019 Return-Path: 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 167721201AC for ; Wed, 3 Apr 2019 13:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jothan-com.20150623.gappssmtp.com 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 7qKmxU5_2a44 for ; Wed, 3 Apr 2019 13:20:20 -0700 (PDT) Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F301912011C for ; Wed, 3 Apr 2019 13:20:19 -0700 (PDT) Received: by mail-vs1-xe42.google.com with SMTP id f22so10779796vso.7 for ; Wed, 03 Apr 2019 13:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jothan-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CwjlInjtZCaIUsv6RvkmS4aC9HRscDK9Gw9M4bj8O5Y=; b=rnB2xR6HUcBUWrCMAYBBSw2/Z7phe13/rlN7lLLzd/exFCgV7e0CLoS9zSW45g7Pcc mbfhhsDUOOtiQX6P+hXyIfhf+0CQ8iR85eB9OD6mej5ZAx8ggG2lj7TB3z1C7OCImY03 EeEXQrYxHZ5x7u6u48Hmr5NK5xwg0HooO+nFjyz/75fSD1NBc5KOozvV9ArWk6BO0b2L dZnhYNg3PNm+lCpxnja8cenGt8B18tEUMm/j+pnfz1hnWR67HNKotHPypB4kMG25SIX4 QTzb6phDi3SDnZwS0U7JI/cx4cuupRyIpr+875tzCyTqD+zc1hAd8WllW52oTB/BUNc4 fkIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CwjlInjtZCaIUsv6RvkmS4aC9HRscDK9Gw9M4bj8O5Y=; b=t8neLzUtvmXjSnuJ8tevN1YslYD2ARghI/6gq7NF8RTOGvmqSRKSz0Ur8cPAIT6Ulv jz3mbciW2pfoJ4YSasa2vhbsckjUz1ADwRQB6IhTp5H1TwmEUG6FXoeZAW1whV9s97rN 8GrwKAHFPBJGb2FmivcZA5oKUbuAnJal9q/6MhjaAQ9g2Xyq3RlCUxLUl1NAH3/vkHvx u9rC5XBEZSOailse5LrvZshm3d/tCRcPs30gmFN40egmipdn6nI9AU3OdWThtnC0ql4U PTPsH4oLpjuPyQqaqwfA/L56dGB9yIpytXvlYOYvSRDGQHbcws+Wi+Lh1NoIoaARXWi0 HsDw== X-Gm-Message-State: APjAAAVlENGbDJXixgbAfiG9iyu6GWTCbg+iuoaWa1SgWAudprHTEs+n /dhoV/h/Mv6FYQj5u3xkhSHdeaLz/W+hXnUNqZrmng== X-Google-Smtp-Source: APXvYqxMBE7+UXfqMmur3VH3TFi3RgD9nKf6LeT47kyrfFDQVSbXPrBjW1j+XQ+GaD4b1QucWZLWaeE24JAgRx2Y6fA= X-Received: by 2002:a67:76d7:: with SMTP id r206mr1656907vsc.25.1554322819015; Wed, 03 Apr 2019 13:20:19 -0700 (PDT) MIME-Version: 1.0 References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> In-Reply-To: From: Jothan Frakes Date: Wed, 3 Apr 2019 13:19:47 -0700 Message-ID: To: Stephen Farrell Cc: tjw ietf , John R Levine , dmarc@ietf.org, Dave Crocker , dbound@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 20:20:21 -0000 > ... registrar > GUIs are perhaps the main barrier for new RRTYPEs ... s/registrar/DNS Management/ these are often not one in the same - and the only reason I make that pedantic distinction is that the frequent situation where DNS Management != registrar heavily impedes DNSSEC end-to-end configuration, because it needs config harmony within the registration path (registrar) and the resolution path (DNS) Hope that made sense. Just want to ensure these are not conflated to avoid drag on efforts From nobody Wed Apr 3 13:30:53 2019 Return-Path: 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 325681201F1; Wed, 3 Apr 2019 13:30:51 -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 X7NBQjoHRQ_c; Wed, 3 Apr 2019 13:30:49 -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 9A72912011C; Wed, 3 Apr 2019 13:30:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1DFB0BE55; Wed, 3 Apr 2019 21:30:45 +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 rAD8F_NUi60w; Wed, 3 Apr 2019 21:30:43 +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 2124CBE2F; Wed, 3 Apr 2019 21:30:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554323443; bh=PWc1izpf7Yx0h1jTJSo7dMN3OzWXPdFypWXzFCjzXSc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=bTBy9zzusoMNvx17KonvrgCNb1ZnFvbG0fleeU83bgoxWWgbpllNv/uCYa2dkglAh 3MV0O+v8HKcJduVHMKk90oMWg+Y6BN8O4WauB12MoKVTf78mb3GrqPXyqJgx+Asd61 DFQy7GvwqWNkzI3XETclksgkyKpWYyTj5FifBwZA= To: Jothan Frakes Cc: tjw ietf , dmarc@ietf.org, John R Levine , Dave Crocker , dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> From: Stephen Farrell 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: <7e3b2eb8-3ab8-5dda-1523-c15589486a4b@cs.tcd.ie> Date: Wed, 3 Apr 2019 21:30:42 +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: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6zDiGNveidexOnkjkVYNEqaLLR7Lm9BzE" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 20:30:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6zDiGNveidexOnkjkVYNEqaLLR7Lm9BzE Content-Type: multipart/mixed; boundary="oDLHWUm1wtKH92DiK8xnXrUbWJyWsrHog"; protected-headers="v1" From: Stephen Farrell To: Jothan Frakes Cc: tjw ietf , dmarc@ietf.org, John R Levine , Dave Crocker , dbound@ietf.org Message-ID: <7e3b2eb8-3ab8-5dda-1523-c15589486a4b@cs.tcd.ie> Subject: Re: [dbound] [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> In-Reply-To: --oDLHWUm1wtKH92DiK8xnXrUbWJyWsrHog Content-Type: multipart/mixed; boundary="------------7E01A62664094D51509BFA37" Content-Language: en-GB This is a multi-part message in MIME format. --------------7E01A62664094D51509BFA37 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/04/2019 21:19, Jothan Frakes wrote: >> ... registrar >> GUIs are perhaps the main barrier for new RRTYPEs ... >=20 > s/registrar/DNS Management/ >=20 > these are often not one in the same - and the only reason I make that > pedantic distinction is that the frequent situation where > DNS Management !=3D registrar > heavily impedes DNSSEC end-to-end configuration, because it needs > config harmony within the registration path (registrar) and the > resolution path (DNS) >=20 > Hope that made sense. Just want to ensure these are not conflated to > avoid drag on efforts Fair point. Ta, S. >=20 > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound >=20 --------------7E01A62664094D51509BFA37 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------7E01A62664094D51509BFA37-- --oDLHWUm1wtKH92DiK8xnXrUbWJyWsrHog-- --6zDiGNveidexOnkjkVYNEqaLLR7Lm9BzE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlylF/IACgkQWrL68XsX K+qdkQ//TqiWEKR/R9eemXJQnb3VaJM1x+VJCc88Pn2KGlm2ITXb3rvSdDwfFj01 d+Z7QJMbW2OrFFl4LlDVkPL0wjoZr3dpQEXmeQn9x+BvH4tblyE/sxbI6oGvdZPX tVaUJzOi2Hkl+S2C4/Iupw/G4uf62RrIYq4PWCEWQeBqHuTVr82TO9aBPNR5cgV1 gC8BcmMMRiBIxcQiGWCPW1UVewcyCPeXQ4t3ZGx95XnPJSaB5DtLlKe66qkD8Qg0 FBG+4194WakHXHXyF6PkpQBWUXf2trveM4y7tbxOTEmyq8HEdomR3RTDnQjc+QzF N0Q6h4qvMfCaj0xy4+sJjNxwL/WvehInybPxoIKu7GVJjYEE3A4knnfY/YoPQi1Y aoVbtufq538C4Qrri84X3ReiGBPIfgwvd6WJMwMDCbnYGRYbzT6GCL31XP0l7R8D 6MShqxNqpMOcL6Nb3EFlVTimtQOtFVA13yA8hCGO2yQ2SjNQH59YNpaJpznKN3qV HIcXALi/V6xN35eElNa2R0Y2aP1pJjWU/3WIlQOIDoQ4NSQH4kv07zJwv2POpQXR FkxPL9HKypu9j0sjZSQh8Rd+8VWGtCDlviMjHjz4LAeotrqX/GHVig7zKLW7xlXd rmzwiTRv17CSgyQKF863YX6vBpxY28x38ceuUiZ6IdmZsU+x96U= =W/U0 -----END PGP SIGNATURE----- --6zDiGNveidexOnkjkVYNEqaLLR7Lm9BzE-- From nobody Wed Apr 3 14:07:25 2019 Return-Path: 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 1176F120281; Wed, 3 Apr 2019 14:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=dcrocker.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 Z1htL9QiX0Ik; Wed, 3 Apr 2019 14:07:21 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 C41F712027F; Wed, 3 Apr 2019 14:07:21 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x33L93A3017670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 14:09:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554325744; bh=B0Bjay4xvc/1GJ7cS/roMAIoU0vrInnY/YOaPsBbWVk=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=HvcnpbXeNtvMcAnArg6I0bG+D3Frgan/Axnr7r/LUlMuUEuaNQUI9WMbmJokaAI86 S2eKtPnSG4kERMbT7yJEfzV/w1g8HWZRjoh9CQj4TeQ4Va4Y4M4CrQoM+GmanqUwxI dVf9oR99FvcucoJnVTbUmEUEHRXBxhKz3ilTxI4M= To: tjw ietf Cc: dmarc@ietf.org, dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> Date: Wed, 3 Apr 2019 14:07:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 21:07:23 -0000 On 4/3/2019 12:19 PM, tjw ietf wrote: > I was going to say CAA but that’s 6 years old. 5 was a random number. I was merely meaning 'recent'. But suggesting CAA in response to my query means that you think RFC 6844 has received widespread -- ie, at scale -- end to end adoption and use. Yes? Please forgive my skepticism. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 14:09:20 2019 Return-Path: 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 3795A120285; Wed, 3 Apr 2019 14:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=dcrocker.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 rlu2sW1KxEnL; Wed, 3 Apr 2019 14:09:11 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 1593512027F; Wed, 3 Apr 2019 14:09:11 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x33LAs7t017791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 14:10:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554325854; bh=kx391p1EJdWjU2MGzsyPqFs1kpGfK0+aymhzU4uUis0=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=aSeKxHsDbczJfgo2SD5jOLv5GSyXBzT5a2eAIyd3CEPaKuymVHr3BB/9nWtkaDFGa d9627PdmgYhs0sg22G6X2nL5jgafjf7mkx1ufvJIKP69e1bIbB+3sCg44THCuXYeg+ 6ShpUk+7aFCorfg3aBYipr/1F6I2AuatetxTMsNs= To: dmarc@ietf.org, dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <07a9df2c-1a2c-9dc4-c6ca-a93f5bffd1e0@dcrocker.net> Date: Wed, 3 Apr 2019 14:09:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dbound] cross-posting (was Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 21:09:12 -0000 May we quickly settle on a single mailing list for discussing this draft? I assume dbound is the right choice but don't really care, as long as it is only one. Absent objection, I propose that this note be the last one cross-posted. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 18:00:53 2019 Return-Path: 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 86956120357 for ; Wed, 3 Apr 2019 18:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com 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 mvf32TpLIhhE for ; Wed, 3 Apr 2019 18:00:49 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 2F4E612034F for ; Wed, 3 Apr 2019 18:00:49 -0700 (PDT) Received: (qmail 1539 invoked from network); 4 Apr 2019 01:00:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5ff.5ca5573f.k1904; bh=gG0TH3j1rv64bO/9jkcDMnh3vkoJo5XJSgAfChW5ng8=; b=iPH39DOotyN11SZq91tybzAxfTdbQNSIR7XaWaXxITULHU0SK3UMDqwnGDdDcNw1X8IvIR8IhyBUmENkCo/4iTKVmy27UJOrzuN0SCTHaEpbhqL0EGr1BdinLi+i/CYxAJOXdE2W0y23jWi9vzfosmbPb/JGHptAqZ6/EE/W7lA4BJtaj0BztsZ7sM+D8Ki1Pjw0rD/hf3ExMyNbTyD8IsyeNcHlrt2A34Hj1H7PF7SQ1edWQ3scYC+GhP470ig+ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 04 Apr 2019 01:00:47 -0000 Date: 3 Apr 2019 21:00:46 -0400 Message-ID: From: "John R. Levine" To: dcrocker@bbiw.net Cc: "tjw ietf" , dbound@ietf.org In-Reply-To: <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1256902744-1554339647=:22661" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 01:00:52 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1256902744-1554339647=:22661 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 3 Apr 2019, Dave Crocker wrote: > On 4/3/2019 12:19 PM, tjw ietf wrote: >> I was going to say CAA but that’s 6 years old. > 5 was a random number. I was merely meaning 'recent'. > > But suggesting CAA in response to my query means that you think RFC 6844 has > received widespread -- ie, at scale -- end to end adoption and use. Every CA is supposed to check CAA records before issuing a cert to see if they're allowed to issue it. I know Let's Encrypt does and I suppose I can ask them how many CAA records they see. > Please forgive my skepticism. Well, OK, here's a question for you: when's the last time an RFC added a feature to the DNS that puts records in the additional section triggered by a specific label in the query? I'm reasonably sure the answer is "never" but you might ask dnsop to be sure. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly --0-1256902744-1554339647=:22661-- From nobody Wed Apr 3 18:24:14 2019 Return-Path: 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 ABFAA1201B2 for ; Wed, 3 Apr 2019 18:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=bbiw.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 wNjzNBIEDsKU for ; Wed, 3 Apr 2019 18:24:10 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 2A1C11201B1 for ; Wed, 3 Apr 2019 18:24:10 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x341PmMf007140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 18:25:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bbiw.net; s=default; t=1554341148; bh=Ol2LD5KWeV4qdN1DLyvkDQFd+HsggusOr3vGqojBVqM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=W2UN++0r6U6BctNg6W4vKLYRkXIq23nWbQgK3ysPhTC02R6rT86NFcgVQgEnRMC/G 0BV8ad7uPw4E7QtBAj4MdvS5Df/7PxyZ3MSMkSd7n3XIehXfo5P1isFlkpcfZUYfUz YcVv6Pg5Z1ccG2UpyHuwYUnOLYWFNmSnVXSWm3XM= To: "John R. Levine" Cc: tjw ietf , dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> From: Dave Crocker Message-ID: Date: Wed, 3 Apr 2019 18:23:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 01:24:13 -0000 On 4/3/2019 6:00 PM, John R. Levine wrote: > Well, OK, here's a question for you: when's the last time an RFC added a > feature to the DNS that puts records in the additional section triggered > by a specific label in the query?  I'm reasonably sure the answer is > "never" but you might ask dnsop to be sure. my proposal does not 'add a feature to the DNS'. It uses existing DNS mechanisms and does not change the DNS protocol or its formats. Your original phrasing was better, because it was in terms of requiring a 'modification' to the server. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 18:25:19 2019 Return-Path: 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 6B4FE1201B1 for ; Wed, 3 Apr 2019 18:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=dcrocker.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 Kq8MVF6_4Kf9 for ; Wed, 3 Apr 2019 18:25:16 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 021951201A6 for ; Wed, 3 Apr 2019 18:25:15 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x341QsTb007214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 18:26:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554341214; bh=fJv/5F+6nnpV6ydKDhz2h9fog+ydnZ1rrr5R2HDuh78=; h=From:Subject:To:Cc:References:Reply-To:Date:In-Reply-To:From; b=ACDrnvbhUVmXisqIzNFJ74iI0P496jlNHg4NABcCEsTbzxBp4ZG+pT+rPfYgcfQEZ dsa8irhZG235DaNz0xgZlXifTxDj0hAI8iwGrPzc2b3wWR5xOosMU+nt5eI/i8l3YB 8JNuIgQw/qCwGREa5bofUmhp9LqBT6Kmjy+Gk3jE= From: Dave Crocker To: "John R. Levine" Cc: tjw ietf , dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <8ca4dde0-2ac2-fc95-7670-3d0188e65499@dcrocker.net> Date: Wed, 3 Apr 2019 18:25:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 01:25:17 -0000 On 4/3/2019 6:00 PM, John R. Levine wrote: > Well, OK, here's a question for you: when's the last time an RFC added a > feature to the DNS that puts records in the additional section triggered > by a specific label in the query?  I'm reasonably sure the answer is > "never" but you might ask dnsop to be sure. my proposal does not 'add a feature to the DNS'. It uses existing DNS mechanisms and does not change the DNS protocol or its formats. Your original phrasing was better, because it was in terms of requiring a 'modification' to the server, which of course, my proposal does do, as an optimization. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 18:27:59 2019 Return-Path: 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 699C312034A for ; Wed, 3 Apr 2019 18:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com 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 GUMcHYnSvxzs for ; Wed, 3 Apr 2019 18:27:56 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 393C11201B2 for ; Wed, 3 Apr 2019 18:27:56 -0700 (PDT) Received: (qmail 8770 invoked from network); 4 Apr 2019 01:27:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=223a.5ca55d9a.k1904; bh=tDDMwmS5YfzWb0T+reXEpnmn2UDgmBXyvbxM1sM1jv8=; b=jgaakiLDno87qnkC65wrzp0TxU/8HWGRMI9TLUx95UJWI0Q8B3AOQ96/KQtZu68JaLfEguxfpst2Bj7Xl8HV4T1lazMRkHswSKcWfnI/jbZHCTGat5SC6qH+OE61yjlG2/jzhlYHjTpmb/DKFDNmp0yDo+QCJtWXIo8abSrrgF7Z3XT03ty0CzO6PCM3EPmFaC2DL0XrBA7Mmgp25BQM4pSjCDkLeEks0iMt5Lu1nzJxkW3HjH/3b/7UvvaCA6OC Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 04 Apr 2019 01:27:54 -0000 Date: 3 Apr 2019 21:27:53 -0400 Message-ID: From: "John R. Levine" To: "Dave Crocker" Cc: "tjw ietf" , dbound@ietf.org In-Reply-To: References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1738157732-1554341274=:22887" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 01:27:58 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1738157732-1554341274=:22887 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT >> by a specific label in the query?  I'm reasonably sure the answer is >> "never" but you might ask dnsop to be sure. > > my proposal does not 'add a feature to the DNS'. It uses existing DNS > mechanisms and does not change the DNS protocol or its formats. New additional section processing would absolutely be a new feature in the DNS, one that would require potentially significant code changes to every DNS server and cache. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly --0-1738157732-1554341274=:22887-- From nobody Wed Apr 3 18:36:19 2019 Return-Path: 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 80CD2120353 for ; Wed, 3 Apr 2019 18:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=bbiw.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 gCwIW5DHuViV for ; Wed, 3 Apr 2019 18:36:17 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 205F312034A for ; Wed, 3 Apr 2019 18:36:17 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x341btXc008000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 18:37:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bbiw.net; s=default; t=1554341876; bh=np1BaEqvnuVhKTBeZPMCPpI0b3lmnMzdguLonVqP8hI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kmnw8cdBMvquhHrVM7QOKMpnMQjsySg+NgsN2yaJCbhF/grVhWzSlKby0OJ7zfwg+ rE/W4AdEeNKd8En/nSIc/5J8QUxc7FgO4xQ4YNGcoY3MuKxAnEG5wwLjC7uPg8B/We ezA82sLIakrRdOdJkOsUdicCAx0FlobuwW2oiwk4= To: "John R. Levine" Cc: tjw ietf , dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> From: Dave Crocker Message-ID: Date: Wed, 3 Apr 2019 18:36:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 01:36:19 -0000 On 4/3/2019 6:27 PM, John R. Levine wrote: >>>  by a specific label in the query?  I'm reasonably sure the answer is >>>  "never" but you might ask dnsop to be sure. >> >> my proposal does not 'add a feature to the DNS'.  It uses existing DNS >> mechanisms and does not change the DNS protocol or its formats. People often confuse additions to /use/ of a service with changes /to/ the service. This would be the former, not the latter. Or perhaps you can point to the DNS specs and registries, showing where they specify the constrained set of Additional responses that I'm calling for modifying? I'm not finding such a list. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 3 19:14:55 2019 Return-Path: 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 D8547120198 for ; Wed, 3 Apr 2019 19:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com 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 vtnbMhHpbKoi for ; Wed, 3 Apr 2019 19:14:52 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 EB60D120195 for ; Wed, 3 Apr 2019 19:14:51 -0700 (PDT) Received: (qmail 21565 invoked from network); 4 Apr 2019 02:14:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=543a.5ca56899.k1904; bh=JYHiKGfuvimZSCeLHemZ6BpGAT3vw7bqKWDtYGz7518=; b=efRbE/Hc7swfkmD6zhg5LggzM4CQ30sy93IA+gAMQ9LhsDCRn07IhjeAuN+OZXLMGm61DQ/m3sE1JaZ20jxDHLbxnIP7LbwslDfMyKavFtgPNhuM66KS+OuI0F21eBNDp/8S3IUoNBTK+g04nuApQtESTaZLeKg0uwX0gTbsePL/+Z8BFCICP8mktd3OwTj0ZL7/MHFnkT0He9uzBPdKdvBDadBbWN16IFwzk/3+p+bhIimgOtf30At3ZzHWQtyM Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 04 Apr 2019 02:14:49 -0000 Date: 3 Apr 2019 22:14:48 -0400 Message-ID: From: "John R. Levine" To: "Dave Crocker" Cc: "tjw ietf" , dbound@ietf.org In-Reply-To: References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 02:14:54 -0000 > Or perhaps you can point to the DNS specs and registries, showing where they > specify the constrained set of Additional responses that I'm calling for > modifying? I'm not finding such a list. This is getting very strange. Your draft says: Another approach is use of the DNS Additional section in the server response. When there is a query for a Perimeter node, the server would include the associated Perimeter BEGIN record from earlier in the hierarchy, if the queried node is within that hierarchy -- that is, is above the actual or virtual END record. (As for any information supplied through the Additional section, the responding server will need to be modified to provide this enhanced information for specific kinds of queries.) That bit in the parentheses, who does the modifying, and how does it get into the running versions of BIND and NSD and PowerDNS and all the other DNS servers and caches that people use? Although now that I think about it, it won't work anyway. For one thing, if you ask for _perim.a.b.c.tld, and there is only _perim.c.tld, the DNS response will be an NXDOMAIN and I don't think that DNS clients expect to find additional records in an NXDOMAIN response. Or if we wave our hands some more and somehow make it a NODATA (positive response with no records), the fact that there's _perim.c.tld in the additional section doesn't mean that there wouldn't also be _perim.b.c.tld if you asked for it. There's another whole set of failures if there's a zone cut between the name you ask for and the _perim above it. So you're back to a tree walk, which is poor form in the DNS. Don't take my word for it, ask in dnsop. Or perhaps Tim has some opinions. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Apr 3 19:54:27 2019 Return-Path: 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 13F46120153 for ; Wed, 3 Apr 2019 19:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=dcrocker.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 kEP79dq5SAAQ for ; Wed, 3 Apr 2019 19:54:23 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 7B1C31200F1 for ; Wed, 3 Apr 2019 19:54:23 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x342u1k7013845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Apr 2019 19:56:01 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554346562; bh=FLlYN4FSnr4VR+s8HFghhV5sB9HSY4ZYLKez461noQc=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=MgOswz3M3Aq7dfmCunhOfx7R0zqSeAO7cFiszh6Z3EacplR6ctAdvCHcRaLtPks8g LcZ6ioAYclj+Xh8x0cVNWkDHLddta6rEJY2iQuzEDo2K5GRuTl5LBpbiuaO6FALlPv qQyTUC5kfd0oMBlp2jwUTXkgqcAEBmFiGTiJGDpI= To: "John R. Levine" Cc: tjw ietf , dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <0ccf632e-aade-3611-3beb-15b81e35679a@dcrocker.net> Date: Wed, 3 Apr 2019 19:54:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 02:54:26 -0000 On 4/3/2019 7:14 PM, John R. Levine wrote: > That bit in the parentheses, who does the modifying, and how does it get > into the running versions of BIND and NSD and PowerDNS and all the other > DNS servers and caches that people use? You appear to be confusing 'adding to an implementation' with 'changing the protocol'. Modifying the protocol is changing DNS. Adding code might or might not be and in this case, it isn't. It is adding a /use/ of /existing/ DNS mechanisms. That's not 'changing the DNS'. > Although now that I think about it, it won't work anyway.  For one > thing, if you ask for _perim.a.b.c.tld, and there is only _perim.c.tld, > the DNS response will be an NXDOMAIN and I don't think that DNS clients > expect to find additional records in an NXDOMAIN response.  Or if we > wave our hands some more and somehow make it a NODATA (positive response > with no records), the fact that there's _perim.c.tld in the additional > section doesn't mean that there wouldn't also be _perim.b.c.tld if you > asked for it.  There's another whole set of failures if there's a zone > cut between the name you ask for and the _perim above it. The NXDomain looks like an interesting bit of inconvenience. Have to think about it some more. And yes, zone boundaries are always fun. But since these are names that are, by definition, within a single administrative scope, I suspect that's solvable too. > Don't take my word for it, ask in dnsop.  Or perhaps Tim has some opinions. I already sent a note to dnsop, inviting them to dbound for this discussion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 4 06:43:56 2019 Return-Path: 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 4E17D1205F7 for ; Thu, 4 Apr 2019 06:43:53 -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 (1536-bit key) header.d=iecc.com 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 4H9XZ0i-U3Vc for ; Thu, 4 Apr 2019 06:43:51 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 20EA11205DD for ; Thu, 4 Apr 2019 06:43:50 -0700 (PDT) Received: (qmail 41914 invoked from network); 4 Apr 2019 13:43:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a3b6.5ca60a14.k1904; bh=VYa3wT1hV2Ca3wfRVFSxqhEm5MxICKRVru7+F/ZjPKU=; b=dsVofiYgBk82fvljpjKLB+CBm/G33QC5Le2IdgEg7LuwtdRjW1zj3IE0Cj2yRX4ANzGwYHSelmDsHdgZIsCkKtzayJfmDH1z6UY5zgJueTNgFFHlPd1CC4QkiqfeOnSNEHlu9oI9/0gGZQ6CjInSMsZ0gDNwPzNHMSy60FRTGnRveImAnS+TuV7IYk5u+SVgvFJ5VwRtoj9fC3w9yHChUts4aIhn5tO/lOQeLxgAv6G1P+1QIvKdOo+9niFkVsb4 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 04 Apr 2019 13:43:47 -0000 Date: 4 Apr 2019 09:43:47 -0400 Message-ID: From: "John R. Levine" To: dcrocker@bbiw.net Cc: "tjw ietf" , dbound@ietf.org In-Reply-To: References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1347384637-1554385427=:24158" Archived-At: Subject: Re: [dbound] department of poor memory, was 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 13:43:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1347384637-1554385427=:24158 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT I just reread my draft draft-levine-dbound-dns-01 and see that I'd forgotten that it says that the design would work the same with TXT records as with a new rrtype, since the nodes are all under prefixed _bound names. See section 9 on page 8. If you want to compare apples to apples, you might want to adjust the draft to compare your prefixed TXT records to my prefixed TXT records. R's, John On Wed, 3 Apr 2019, John R. Levine wrote: > On Wed, 3 Apr 2019, Dave Crocker wrote: >> On 4/3/2019 12:19 PM, tjw ietf wrote: >>> I was going to say CAA but that’s 6 years old. >> 5 was a random number. I was merely meaning 'recent'. >> >> But suggesting CAA in response to my query means that you think RFC 6844 >> has received widespread -- ie, at scale -- end to end adoption and use. > > Every CA is supposed to check CAA records before issuing a cert to see if > they're allowed to issue it. I know Let's Encrypt does and I suppose I can > ask them how many CAA records they see. > >> Please forgive my skepticism. > > Well, OK, here's a question for you: when's the last time an RFC added a > feature to the DNS that puts records in the additional section triggered by a > specific label in the query? I'm reasonably sure the answer is "never" but > you might ask dnsop to be sure. --0-1347384637-1554385427=:24158-- From nobody Thu Apr 4 07:14:31 2019 Return-Path: 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 CAC5F1206FA for ; Thu, 4 Apr 2019 07:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=dcrocker.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 VQt05r4KeOxb for ; Thu, 4 Apr 2019 07:14:20 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 BF16D1206EA for ; Thu, 4 Apr 2019 07:14:20 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x34EFxqx000346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Apr 2019 07:15:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554387360; bh=6f6PUJePzDlNKYXKM6AD15qBRJynvZgMV8y/2o3r7i0=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=Ou4QRC7P9FyrQ3ytdjPq8yg1Q39L0IgSAUuyGEQigIVf19ewp/8CmStMxgeZiPGA7 xCzgZ9oWFV+QMu0mNYqot8X49xMhe5T65DRBVCw1Fj/V4JP+3kHpiuxe0e+0YG9vIY TEmoPKMoeWdcrg2paJtMYOYjmME/iZHsuk/gMilA= To: "John R. Levine" Cc: tjw ietf , dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <09cdb203-f926-70cd-3f7b-b06cdc48a11b@dcrocker.net> Date: Thu, 4 Apr 2019 07:14:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dbound] department of poor memory, was 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 14:14:29 -0000 On 4/4/2019 6:43 AM, John R. Levine wrote: > If you want to compare apples to apples, you might want to adjust the > draft to compare your prefixed TXT records to my prefixed TXT records. What specific wording changes to the draft are you suggesting? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 4 07:18:17 2019 Return-Path: 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 799451206B6 for ; Thu, 4 Apr 2019 07:18:15 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 u_FhDv-QEfYs for ; Thu, 4 Apr 2019 07:18:13 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA97C12061B for ; Thu, 4 Apr 2019 07:18:12 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id p14so2257312ljg.5 for ; Thu, 04 Apr 2019 07:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AIPinxLk94Dgbq68McUlPpYw4I24OYtz0ivRi5g5wZo=; b=sbjyXh0TWtelD2xmTCe0ZAk+CAdaq6hDNr/XS+UjkMnEKg3igxUndduPOyfoiDXexG 2W3bJykX6CK4PFHHnLJGxzx+BDn7ge0QuK4LjZx+Epij3f3v2j1YtHIWZwpBjDtd7Shy qYC+5xInvOdsoFRfGxETOirZeaXJVTy/BCa5UVdzkzlONXNtICvlR/IIq7dGTczmqBWi jK2up4Je7N2t1Vaje3W9MF68x5DiCdALgbZOTXTK51EG3NMIKPTKal1rsa6QJs2452cS NnsyHeB65WtpHLtl3B2chCqzBbbyFpM8ppxGJ5Zdc4pnFyw9q+qS0Co1P0WxkK9w2NE0 Q7xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=AIPinxLk94Dgbq68McUlPpYw4I24OYtz0ivRi5g5wZo=; b=FvP1ccVk3zTGywEnW3TceHXzCvVvRH68PKZGKJmOQOYIs0sbblStfBdhTZCBhJRaDK nfEfhFOSNHrPW7B9QF/ddWTIe6CDVrnMwkX3gAfScVG+HNhwv7WN0K547TEd5lIJmtjv j1/QtbXNX/YN4YhZYtI+nbHsFSnMSrnm0CeBjxc1ryptluW95NcfFneJwNLH5yPwN01H wzQ861nM563ZCLVgUc8UtyTy5u/dPjKc/dJyqt7WYMf1W0HG+ffbDHvaoydLOadNEMmM n+4lcyZOySXDKNhIrCfTTZg6R83pJ608ec/XtAbyo/fn/w9kEfH+d7UmH7se02PyH7MP z6Sw== X-Gm-Message-State: APjAAAV8FPafgHgP5sY3XiiswrO8NNUKbc9KgCp+8PCiRSr9ePzyIu+M atZNf53zSqElapDasNosgg2SVWrggDpY8EuLY8Sy6vU81+s= X-Google-Smtp-Source: APXvYqyqS3vJvbxZTDp1J/idIRNiAGXIy7rsiIhXOuA9fInheOv9PdmlvxJHBS7D3WFrXmpcpORNPTsBLU1JzaunTyY= X-Received: by 2002:a2e:128a:: with SMTP id 10mr3565073ljs.170.1554387490686; Thu, 04 Apr 2019 07:18:10 -0700 (PDT) MIME-Version: 1.0 References: <03202426-5fa7-de6a-688d-491bde7402a8@dcrocker.net> In-Reply-To: <03202426-5fa7-de6a-688d-491bde7402a8@dcrocker.net> From: Bob Harold Date: Thu, 4 Apr 2019 10:17:59 -0400 Message-ID: To: Dave Crocker , dbound@ietf.org Content-Type: multipart/alternative; boundary="00000000000039e3b80585b50a0f" Archived-At: Subject: Re: [dbound] [DNSOP] Over on the dbound list: draft-dcrocker-dns-perimeter-00 X-BeenThere: dbound@ietf.org 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: Thu, 04 Apr 2019 14:18:16 -0000 --00000000000039e3b80585b50a0f Content-Type: text/plain; charset="UTF-8" (Replying to the dbound list) On Wed, Apr 3, 2019 at 3:07 PM Dave Crocker wrote: > Howdy. I've posted a draft that might be of interest to folk in this > group. > > It's best venue is almost certainly the dbound mailing list, where it is > already starting to get discussion (and cross-posted to the dmarc list.) > > Discussing it here, on a third list, doesn't seem advisable, but it's > already been noted on the dbound discussion that the draft raises issues > that might be of concern to the dnsop community. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net I have two questions: If I want to separate these levels: example. a.example. b.a.example. Then a.example is both a 'begin' and 'end' node. Do I put in two records, one for 'begin' and one for 'end'? Secondly, if I have: a.example. b.a.example. c.a.example. d.a.example. ... z.a.example. And I want to separate z.a.example, but not the others, and there are often changes to the list. Without having to mark every one, how can I (as a.example), mark above the cut that z.a.example is separate? -- Bob Harold --00000000000039e3b80585b50a0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Replying to the dbound list)

On Wed, Apr 3, 2019 at 3:07 PM Dave Crocker <<= a href=3D"mailto:dhc@dcrocker.net">dhc@dcrocker.net> wrote:
Howdy. I've posted a= draft that might be of interest to folk in this
group.

It's best venue is almost certainly the dbound mailing list, where it i= s
already starting to get discussion (and cross-posted to the dmarc list.)
Discussing it here, on a third list, doesn't seem advisable, but it'= ;s
already been noted on the dbound discussion that the draft raises issues that might be of concern to the dnsop community.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net


If I want to separate these levels:
example.
a.e= xample.
b.a.example.

Then a.example is b= oth a 'begin' and 'end' node.=C2=A0 Do I put in two records= ,=C2=A0 one for 'begin' and one for 'end'?

Secondly, if I have:
a.example.
b.a.example.
c.a.example.
d.a.example.
...
z.a.ex= ample.

And I want to separate z.a.example, but not= the others, and there are often changes to the list.=C2=A0 Without having = to mark every one, how can I (as a.example), mark above the cut that z.a.ex= ample is separate?

--=C2=A0
Bob Harold

--00000000000039e3b80585b50a0f-- From nobody Thu Apr 4 07:54:25 2019 Return-Path: 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 8077B1200FF for ; Thu, 4 Apr 2019 07:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=dcrocker.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 MLaz_OSD8TUK for ; Thu, 4 Apr 2019 07:54:22 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 E69601200EC for ; Thu, 4 Apr 2019 07:54:21 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x34Eu5EM002344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 4 Apr 2019 07:56:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554389765; bh=+kNz+P0C1MrvmQOO8xPGPdxJISE1Alykh74rz/XS5oM=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=YtW+GjxVrrgFHQP2kgWq3w5pf1ChsNki2s8mYqq11emqJAhNaS7gHPnRdQ9ao9Yeh IKucCjH34aOL//UiOYHVYy0QjRUyckI97Wo4UtzLMJ8PVuDHRV73x35mI/hjZibtJt 53QOePtERfGIXbqOvFWhsT/ZSzPv6Eyv2OA1MNvM= To: dbound@ietf.org References: <03202426-5fa7-de6a-688d-491bde7402a8@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <17bd278f-17b4-7b77-f209-253a290cfde7@dcrocker.net> Date: Thu, 4 Apr 2019 07:54:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dbound] [DNSOP] Over on the dbound list: draft-dcrocker-dns-perimeter-00 X-BeenThere: dbound@ietf.org 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: Thu, 04 Apr 2019 14:54:24 -0000 Bob, On 4/4/2019 7:17 AM, Bob Harold wrote: > I have two questions: > > If I want to separate these levels: > example. > a.example. > b.a.example. > > Then a.example is both a 'begin' and 'end' node.  Do I put in two > records,  one for 'begin' and one for 'end'? First, note that Perimeters are actually /between/ node names. So the above would be: > example. {perimeter} > a.example. {perimeter} > b.a.example. Some choices for marking these will depend upon the specific Schema that is defined. So, for example, I could imagine a Schema that demands an 'end' above a 'begin' and I could imagine a Scheme that merely requires either one to be in place, or requires a specific one. So for a simple hierarchy there might a schema specification might merely mandate that each perimeter down a hierarchy be marked by a new 'begin': {perimeter} > example. \ ._perim TXT begin {perimeter} > a.example. \ ._perim TXT begin {perimeter} > b.a.example. \ ._perim TXT begin Each _perim record, in the above sequence, for example., is declaring that there is a Perimeter above the associated DNS node name. but yes, the requirement might be for more verbosity: {perimeter} > example. \ ._perim TXT begin ._perim TXT end {perimeter} > a.example. \ ._perim TXT end ._perim TXT begin {perimeter} > b.a.example. \ ._perim TXT end ._perim TXT begin And my having to write this response makes me suspect there's some benefit in adding an end-begin shorthand to the specification, to reduce the verbosity and permit a single record to declares Perimeters both above and below the node. It's purpose would be for Perimeter hierarchy have a one-name level, such as your example (and I suspect would be a common use.) > Secondly, if I have: > a.example. > b.a.example. > c.a.example. > d.a.example. > ... > z.a.example. > > And I want to separate z.a.example, but not the others, and there are > often changes to the list.  Without having to mark every one, how can I > (as a.example), mark above the cut that z.a.example is separate? Cool. Subset of branches. > a.example. > b.a.example. > c.a.example. > d.a.example. > ... > z.a.example. \ ._perim TXT begin would clearly work. If there were a need to instead have a.example make the declaration, I don't see an obvious answer. My first thought is for the Scheme to have a sub-notation, to indicate that the presence of the Perimeter is not for all branches, such as by having it list the children links it applies to. But that's not feeling terribly satisfactory. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 4 09:01:53 2019 Return-Path: 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 27D2C120607 for ; Thu, 4 Apr 2019 09:01:48 -0700 (PDT) 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=6Lri8Dfj; dkim=pass (1536-bit key) header.d=taugh.com header.b=WF/+xj9e 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 ujW8sJp4jIQk for ; Thu, 4 Apr 2019 09:01:38 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 A528E1205CD for ; Thu, 4 Apr 2019 09:00:49 -0700 (PDT) Received: (qmail 82908 invoked from network); 4 Apr 2019 16:00:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=143da.5ca62a30.k1904; bh=FGGDGUlY9/RnHKZuP3QGpKdd5JsanougEU8y81nl1gY=; b=6Lri8Dfj/Ye3HDl1nsEwniMCBuVfEA91YkITl54PNqPeZVSwWB40hG5YP8quks2b1j6sDGb6fkDJT5LjBOO3KNeNpBbCtwFTj9WM+Q3njAJ/23t32687YG2U03QCptFYR+xYtxIYWvTZ62oxbOB7ZiSuygO1YEX3EdqKMRNjO9UMADNQYQayP7IFuLh61tH6TBZZyyW3hEfPGjonkEfkfgRWNdR7EGJzJ8hODDDM04hkfEq3rHNGDiGepG31Vobm DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=143da.5ca62a30.k1904; bh=FGGDGUlY9/RnHKZuP3QGpKdd5JsanougEU8y81nl1gY=; b=WF/+xj9eLe/2lGEeDqBAtl1fQ0aduwHSwWNUDTwTo5DJ7cItwRrxtJHrdO/q6zfmEoQK9cUgUMOJ8Gac21Tw611qDQq5lsA81If3U+E4MTLiEDflosRlg2Ig6T2tsj07Yh1T1VVEf5aIaP5LAg6+qPZ8cQ/ZHSsWdNeFptcSsju+OqE9S35Qoc6VHtGMW5riK3nuh9FCY1caA465ckDasXq9sLxJPbC346jeGmcr8eJs0QWnylj59c/ODB6i54AL Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 04 Apr 2019 16:00:48 -0000 Received: by ary.qy (Postfix, from userid 501) id B5A292011692FD; Thu, 4 Apr 2019 12:00:47 -0400 (EDT) Date: 4 Apr 2019 12:00:47 -0400 Message-Id: <20190404160047.B5A292011692FD@ary.qy> From: "John Levine" To: dbound@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <09cdb203-f926-70cd-3f7b-b06cdc48a11b@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dbound] department of poor memory, was 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 16:01:49 -0000 In article <09cdb203-f926-70cd-3f7b-b06cdc48a11b@dcrocker.net> you write: >On 4/4/2019 6:43 AM, John R. Levine wrote: >> If you want to compare apples to apples, you might want to adjust the >> draft to compare your prefixed TXT records to my prefixed TXT records. > >What specific wording changes to the draft are you suggesting? Honestly, now that I look at it again, it's clear that none of the proposed hacks to avoid tree walks will work, and anything that needs tree walks is dead on arrival, so there's not much point. If you want to keep at it, as far as I can tell, the main differences between my 2016 proposal and this one is that I use code numbers to identify different kinds of boundaries and you use strings, easy enough to change either way, and yours requires walking up the tree one level at a time which can be a lot of lookups if people send hostile requests while mine does one lookup per defined boundary. You might check and see if I missed anything. R's, John From nobody Thu Apr 4 09:58:06 2019 Return-Path: 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 33DCD120121 for ; Thu, 4 Apr 2019 09:58:04 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 Gbp8C9XsV5Y6 for ; Thu, 4 Apr 2019 09:58:01 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89DD120118 for ; Thu, 4 Apr 2019 09:58:00 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id v22so2723254lje.9 for ; Thu, 04 Apr 2019 09:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XOKBfXOuc7qrxRjH9C8VzPre2zf5PrF/C16vwZIGYrI=; b=JoF0wzqtT0swsZUuzZBt7Xh/y1I5sSJMvYk0WILv+wAGmkwCGNHUp4TFxK3ou1hokQ qMRn6Bof4owCBP4SQaNv/5V5gt1GXrTvEufPkvsDvWfKG/VLBnn3f4ot782Cd5+Eqv67 Y+fodk/dk1KdC2liQ+8WkzVfzfgBitBQ1PZk8NbEq2IqQ9eBRmXrCF00M7jXopGuN05U AH+Z+2bsV9QnZtoOlMK1Y4EjqHOjdH5IYFzj1aBuTyfIGTWBI5tYbQPnLP/VdJhTm8s0 wjKxKnputvsgT0TELTd4hmpQEsS2to2pPVtqc0yj3xq0SDI4zSbfMR8m9WoO3pPhQhV/ 7O+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XOKBfXOuc7qrxRjH9C8VzPre2zf5PrF/C16vwZIGYrI=; b=afM/mK2dseQrUAZEY2BPGdxadM6gGFT6Hv0fSn6RXCNTQIFkWXogCn3qrD1uQ0BAs9 ON0qD2sho/YvPF2do1VNED+5T/fpIaCc5UFMfWz/SSKPO3ojRG2KrQfzfJ3QTehQ7EyJ iC3mJ4swKNP415Y3gqJ4CCs2pOU7W/y7gp2JT5d78g0XlBeqezAx07AjFUCiSxRSwfs8 cVRaOY/3aKfV+WD9yP8P0JoC2RbmkmgWt03wsjRyJg1XiNWmdo926wVLHFpZZJjWUwf7 pJf3XTor4Nx80UDH255W+qIc3ZcVR/54D4IMKnYFGw1/Polh/UFn1VipZkPA/3hZ+4iU dbpA== X-Gm-Message-State: APjAAAXuCscyTYf1UoaUQ4YUt7OEgIxWeVmmMmSqbliNTTF59c3Nok8U RrnyV+O0askFWQYZL4nclDYOPdZ9tf1Z2CEqP3CdeA== X-Google-Smtp-Source: APXvYqznlslYktXojM0D4ZKEK73Bwt7HkKIBJ3TijG2orGnmZamqSbas9yjxWU5XkfUJVAPN5WkPxZIdGr+bIbACirE= X-Received: by 2002:a2e:81da:: with SMTP id s26mr4393493ljg.86.1554397078585; Thu, 04 Apr 2019 09:57:58 -0700 (PDT) MIME-Version: 1.0 References: <03202426-5fa7-de6a-688d-491bde7402a8@dcrocker.net> <17bd278f-17b4-7b77-f209-253a290cfde7@dcrocker.net> In-Reply-To: <17bd278f-17b4-7b77-f209-253a290cfde7@dcrocker.net> From: Bob Harold Date: Thu, 4 Apr 2019 12:57:47 -0400 Message-ID: To: Dave Crocker Cc: dbound@ietf.org Content-Type: multipart/alternative; boundary="000000000000b5976c0585b745fd" Archived-At: Subject: Re: [dbound] [DNSOP] Over on the dbound list: draft-dcrocker-dns-perimeter-00 X-BeenThere: dbound@ietf.org 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: Thu, 04 Apr 2019 16:58:04 -0000 --000000000000b5976c0585b745fd Content-Type: text/plain; charset="UTF-8" On Thu, Apr 4, 2019 at 10:54 AM Dave Crocker wrote: > Bob, > > On 4/4/2019 7:17 AM, Bob Harold wrote: > > I have two questions: > > > > If I want to separate these levels: > > example. > > a.example. > > b.a.example. > > > > Then a.example is both a 'begin' and 'end' node. Do I put in two > > records, one for 'begin' and one for 'end'? > > First, note that Perimeters are actually /between/ node names. So the > above would be: > > > example. > {perimeter} > > a.example. > {perimeter} > > b.a.example. > > Some choices for marking these will depend upon the specific Schema that > is defined. So, for example, I could imagine a Schema that demands an > 'end' above a 'begin' and I could imagine a Scheme that merely requires > either one to be in place, or requires a specific one. > So for a simple hierarchy there might a schema specification might > merely mandate that each perimeter down a hierarchy be marked by a new > 'begin': > > > {perimeter} > > > example. > \ > ._perim TXT begin > > {perimeter} > > > a.example. > \ > ._perim TXT begin > > > {perimeter} > > > b.a.example. > \ > ._perim TXT begin > > > Each _perim record, in the above sequence, for example., is declaring > that there is a Perimeter above the associated DNS node name. > > but yes, the requirement might be for more verbosity: > > > {perimeter} > > > example. > \ > ._perim TXT begin > ._perim TXT end > > {perimeter} > > > a.example. > \ > ._perim TXT end > ._perim TXT begin > > > {perimeter} > > > b.a.example. > \ > ._perim TXT end > ._perim TXT begin > > And my having to write this response makes me suspect there's some > benefit in adding an end-begin shorthand to the specification, to reduce > the verbosity and permit a single record to declares Perimeters both > above and below the node. It's purpose would be for Perimeter hierarchy > have a one-name level, such as your example (and I suspect would be a > common use.) > > Agreed. > > > Secondly, if I have: > > a.example. > > b.a.example. > > c.a.example. > > d.a.example. > > ... > > z.a.example. > > > > And I want to separate z.a.example, but not the others, and there are > > often changes to the list. Without having to mark every one, how can I > > (as a.example), mark above the cut that z.a.example is separate? > > Cool. Subset of branches. > > > a.example. > > b.a.example. > > c.a.example. > > d.a.example. > > ... > > z.a.example. > \ > ._perim TXT begin > > would clearly work. > > If there were a need to instead have a.example make the declaration, I > don't see an obvious answer. > This is my concern. > My first thought is for the Scheme to have a sub-notation, to indicate > that the presence of the Perimeter is not for all branches, such as by > having it list the children links it applies to. But that's not feeling > terribly satisfactory. > Not great, but probably required. Could the RFC include a note about this possible issue? > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > --000000000000b5976c0585b745fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Apr 4, 2019 at 10:54 AM Dave Croc= ker <dhc@dcrocker.net> wrote:=
Bob,

On 4/4/2019 7:17 AM, Bob Harold wrote:
> I have two questions:
>
> If I want to separate these levels:
> example.
> a.example.
> b.a.example.
>
> Then a.example is both a 'begin' and 'end' node.=C2=A0= Do I put in two
> records,=C2=A0 one for 'begin' and one for 'end'?

First, note that Perimeters are actually /between/ node names.=C2=A0 So the=
above would be:

=C2=A0> example.
=C2=A0 =C2=A0{perimeter}
=C2=A0> a.example.
=C2=A0 =C2=A0{perimeter}
=C2=A0> b.a.example.

Some choices for marking these will depend upon the specific Schema that is defined.=C2=A0 So, for example, I could imagine a Schema that demands an=
'end' above a 'begin' and I could imagine a Scheme that mer= ely requires
either one to be in place, or requires a specific one.
=C2= =A0
So for a simple hierarchy there might a schema specification might
merely mandate that each perimeter down a hierarchy be marked by a new
'begin':


=C2=A0 =C2=A0{perimeter}

=C2=A0> example.
=C2=A0 =C2=A0\
=C2=A0 =C2=A0 ._perim TXT begin <schema>

=C2=A0 =C2=A0{perimeter}

=C2=A0> a.example.
=C2=A0 =C2=A0\
=C2=A0 =C2=A0 ._perim TXT begin <schema>


=C2=A0 =C2=A0{perimeter}

=C2=A0> b.a.example.
=C2=A0 =C2=A0\
=C2=A0 =C2=A0 ._perim TXT begin <schema>


Each _perim record, in the above sequence, for example., is declaring
that there is a Perimeter above the associated DNS node name.

but yes, the requirement might be for more verbosity:


=C2=A0 =C2=A0{perimeter}

=C2=A0> example.
=C2=A0 =C2=A0\
=C2=A0 =C2=A0 ._perim TXT begin <schema>
=C2=A0 =C2=A0 ._perim TXT end <schema>

=C2=A0 =C2=A0{perimeter}

=C2=A0> a.example.
=C2=A0 =C2=A0\
=C2=A0 =C2=A0 ._perim TXT end <schema>
=C2=A0 =C2=A0 ._perim TXT begin <schema>


=C2=A0 =C2=A0{perimeter}

=C2=A0> b.a.example.
=C2=A0 =C2=A0\
=C2=A0 =C2=A0 ._perim TXT end <schema>
=C2=A0 =C2=A0 ._perim TXT begin <schema>

And my having to write this response makes me suspect there's some
benefit in adding an end-begin shorthand to the specification, to reduce the verbosity and permit a single record to declares Perimeters both
above and below the node.=C2=A0 It's purpose would be for Perimeter hie= rarchy
have a one-name level, such as your example (and I suspect would be a
common use.)

Agreed.
=C2=A0

> Secondly, if I have:
> a.example.
> b.a.example.
> c.a.example.
> d.a.example.
> ...
> z.a.example.
>
> And I want to separate z.a.example, but not the others, and there are =
> often changes to the list.=C2=A0 Without having to mark every one, how= can I
> (as a.example), mark above the cut that z.a.example is separate?

Cool.=C2=A0 Subset of branches.

=C2=A0> a.example.
=C2=A0> b.a.example.
=C2=A0> c.a.example.
=C2=A0> d.a.example.
=C2=A0> ...
=C2=A0> z.a.example.
=C2=A0 =C2=A0\
=C2=A0 =C2=A0 ._perim TXT begin <schema>

would clearly work.

If there were a need to instead have a.example make the declaration, I
don't see an obvious answer.

This i= s my concern.
=C2=A0
My first thought is for the Scheme to have a sub-notation, to indicate
that the presence of the Perimeter is not for all branches, such as by
having it list the children links it applies to.=C2=A0 But that's not f= eeling
terribly satisfactory.

Not great, but p= robably required.=C2=A0 Could the RFC include a note about this possible is= sue?
=C2=A0
bbiw.net

--000000000000b5976c0585b745fd-- From nobody Thu Apr 4 10:29:17 2019 Return-Path: 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 A3CC21200E3 for ; Thu, 4 Apr 2019 10:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=dcrocker.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 ase91Ah98N4A for ; Thu, 4 Apr 2019 10:29:13 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 8ABFC12027D for ; Thu, 4 Apr 2019 10:29:02 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x34HUjEk014294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Apr 2019 10:30:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554399046; bh=oP/ztI2FUZ9ygmQIJ/gIYQizeGGxvcgDsW7FRiqic1Q=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=mRd2eMoxg+5osKiFooJNGDxRLkT3v0agLdk4E9Cnk9XsPQM5PDID2JVbUOvw/cx3d opC4WhfJ0smfsrtmWr6kfv89kZt9tTyrCiWrPaXFWEAi6HX/b7UsLPFXS1DXr+kE7j jt172XH7gL7rmlDNsWbuBrLpOCVN6cbD6PLmkJ3w= To: Bob Harold Cc: dbound@ietf.org References: <03202426-5fa7-de6a-688d-491bde7402a8@dcrocker.net> <17bd278f-17b4-7b77-f209-253a290cfde7@dcrocker.net> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <3578e46a-4144-3b82-692c-7b358ad2d4fb@dcrocker.net> Date: Thu, 4 Apr 2019 10:28:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dbound] [DNSOP] Over on the dbound list: draft-dcrocker-dns-perimeter-00 X-BeenThere: dbound@ietf.org 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: Thu, 04 Apr 2019 17:29:16 -0000 On 4/4/2019 9:57 AM, Bob Harold wrote: > And my having to write this response makes me suspect there's some > benefit in adding an end-begin shorthand to the specification, to > reduce > the verbosity and permit a single record to declares Perimeters both > above and below the node.  It's purpose would be for Perimeter > hierarchy > have a one-name level, such as your example (and I suspect would be a > common use.) > > Agreed. OK. Since adding constructs makes a spec and its implementation more complicated,(*) I'll ask the group whether the simplicity of having just 'begin' and 'end' for marking Perimeters -- at the expense of the verbosity of extra records -- is preferred or whether adding a third choice, as a contraction, such as "endbegin", is preferred so there would be only one record. (For completeness: The 'part' construct doesn't define a Perimeter, so it doesn't come into this issue.) > Cool.  Subset of branches. > >  > a.example. >  > b.a.example. >  > c.a.example. >  > d.a.example. >  > ... >  > z.a.example. >    \ >     ._perim TXT begin > > would clearly work. > > If there were a need to instead have a.example make the declaration, I > don't see an obvious answer. > > > This is my concern. > > My first thought is for the Scheme to have a sub-notation, to indicate > that the presence of the Perimeter is not for all branches, such as by > having it list the children links it applies to.  But that's not > feeling > terribly satisfactory. > > > Not great, but probably required.  Could the RFC include a note about > this possible issue? Sure. But I'll also ask for suggestions to see whether we can have Perimeter handle this sufficiently to satisfy folk. I'm taking the open question as: How should DNS Perimeter Overlay provide for a parent node to specify that a subordinate Perimeter applies only to a subset of its subordinate links? It might help to move this from the abstract to the concrete if we develop a few real-world examples we'd like to cover. I don't have any to suggest but hope others do. d/ (*) I tend to think of additions as having disproportionate effects, best treated as exponential. So adding even one item to a small list of features is worth worrying about. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 4 13:49:24 2019 Return-Path: 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 BF2471205DA for ; Thu, 4 Apr 2019 13:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jothan-com.20150623.gappssmtp.com 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 s62K2U8nRGRL for ; Thu, 4 Apr 2019 13:49:15 -0700 (PDT) Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D16912021C for ; Thu, 4 Apr 2019 13:49:15 -0700 (PDT) Received: by mail-vs1-xe44.google.com with SMTP id g187so2206553vsc.8 for ; Thu, 04 Apr 2019 13:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jothan-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jlBU6/2zfoONaup+EXOFVE/aFvlX9HhnwR17sUpDbus=; b=G9NJelHS0juFQ8By+CaJKFxF8PJoDr68I7j4UPb+6xBD5XQ/LU0zACh5scpk+jwOaJ 5zmVXyqfYA8MhCvTZds7PqjGPC5cYPK5W2QVKj732WyRHumkQ0bXbdj/iwUBzDWPH0hR 6gSpySO3HxLi3v2+0AiADL90Li+TLXvy2vA7vAdcV3aVm+NYjfhUjnhD33lo5/xSB1Dz d61SNhQkR9Wl+p/ommtF8+/ZF20YnS7nsIYh5umKe7ojK5lp48Eyr4JhKRV0BKXuNbaN JvZ5eSa+ZKaZE4DowGNGvLjmZnoRlR+FjvEPGXK/yEKSC9TM2lc/JTO+evQH3xHCSIwp C0vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jlBU6/2zfoONaup+EXOFVE/aFvlX9HhnwR17sUpDbus=; b=tKrYrdIdqHhfXoHLfCVOlphT+BZaoCoDi0elvQ1k4XGE68JdS6VuYAor/i3yFN4mVf bx4smE4xkNx1vLlr3f28WtD0SkuOay5s20v/qpZQC6k0E+mhjR41CSA+GvjSQwTy6Uv9 YSx3pklltaTN4zF/VQmN9zD4bqMxDllgxuiCRnquFEHwPnzPTLG/kQdCGe2kM78qvRog ujiyxi6ErJTAiSuHmB++EaJ2pnSpvyTlAq1sF0+nVBRFZINCHfkolMCVIEpeFLOEQGRW 5or+M5HaeljSMj01pVDGSTUuCqM8CFUI+wNt97ZQinEwvY4v/ofeX1cDU5FpC18ahOUh PG7g== X-Gm-Message-State: APjAAAXKjHLOHFFd66gN2gmw0iraFpoknARVHVF6WR16V++/M98bRDfP TkdkrqsL5Jj2EYH31rqxFrNCgpl2xQRTu1Y5CSP2O2jE X-Google-Smtp-Source: APXvYqy1hdDlrjj0XeibQ5R1AK0frnywTPdr0JBOtA+yaoF8EVid85/2QAZUFNXgvrWmzcnqcgar/ezSab89LmEcVK4= X-Received: by 2002:a67:eb41:: with SMTP id x1mr5784403vso.84.1554410954466; Thu, 04 Apr 2019 13:49:14 -0700 (PDT) MIME-Version: 1.0 References: <09cdb203-f926-70cd-3f7b-b06cdc48a11b@dcrocker.net> <20190404160047.B5A292011692FD@ary.qy> In-Reply-To: <20190404160047.B5A292011692FD@ary.qy> From: Jothan Frakes Date: Thu, 4 Apr 2019 13:49:01 -0700 Message-ID: To: John Levine Cc: dbound@ietf.org, Dave Crocker Content-Type: multipart/alternative; boundary="000000000000c6bee30585ba80ba" Archived-At: Subject: Re: [dbound] department of poor memory, was 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 20:49:22 -0000 --000000000000c6bee30585ba80ba Content-Type: text/plain; charset="UTF-8" Setting aside tree walks for holistic solutions, I see per zone utillity in a structured format that could be implemented by a zone operator... Us PSL volunteers often require a custom txt record as a validation of authenticity/authority of requestor on patches that get submitted. Not saying it swaps right in to place, but (just theorizing here) one could enhance the integrity of sections being from an authoritative administeator AND validate the patch by matching requests against these entries within a zone as part of the process to tighten up a match. On Thu, Apr 4, 2019, 09:01 John Levine wrote: > In article <09cdb203-f926-70cd-3f7b-b06cdc48a11b@dcrocker.net> you write: > >On 4/4/2019 6:43 AM, John R. Levine wrote: > >> If you want to compare apples to apples, you might want to adjust the > >> draft to compare your prefixed TXT records to my prefixed TXT records. > > > >What specific wording changes to the draft are you suggesting? > > Honestly, now that I look at it again, it's clear that none of the > proposed hacks to avoid tree walks will work, and anything that needs > tree walks is dead on arrival, so there's not much point. > > If you want to keep at it, as far as I can tell, the main differences > between my 2016 proposal and this one is that I use code numbers to > identify different kinds of boundaries and you use strings, easy > enough to change either way, and yours requires walking up the tree > one level at a time which can be a lot of lookups if people send > hostile requests while mine does one lookup per defined boundary. > > You might check and see if I missed anything. > > R's, > John > > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > --000000000000c6bee30585ba80ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Setting aside tree walks for holistic solutions, I see pe= r zone utillity in a structured format that could be implemented by a zone = operator...=C2=A0

Us PSL volun= teers often require a custom txt record as a validation of authenticity/aut= hority of requestor on patches that get submitted.
<= br>
Not saying it swaps right in to place, but (just= theorizing here) one could enhance the integrity of sections being from an= authoritative administeator AND validate the patch by matching requests ag= ainst these entries within a zone as part of the process to tighten up a ma= tch.


On Thu, Apr 4, 2019, 09:01 Joh= n Levine <johnl@taugh.com> wro= te:
In article <09cdb203-f926-70cd-3f7b-b06cdc48a11b@dcrocker.net> y= ou write:
>On 4/4/2019 6:43 AM, John R. Levine wrote:
>> If you want to compare apples to apples, you might want to adjust = the
>> draft to compare your prefixed TXT records to my prefixed TXT reco= rds.
>
>What specific wording changes to the draft are you suggesting?

Honestly, now that I look at it again, it's clear that none of the
proposed hacks to avoid tree walks will work, and anything that needs
tree walks is dead on arrival, so there's not much point.

If you want to keep at it, as far as I can tell, the main differences
between my 2016 proposal and this one is that I use code numbers to
identify different kinds of boundaries and you use strings, easy
enough to change either way, and yours requires walking up the tree
one level at a time which can be a lot of lookups if people send
hostile requests while mine does one lookup per defined boundary.

You might check and see if I missed anything.

R's,
John

_______________________________________________
dbound mailing list
dbo= und@ietf.org
https://www.ietf.org/mailman/listinfo/dbound<= /a>
--000000000000c6bee30585ba80ba-- From nobody Sat Apr 6 05:36:53 2019 Return-Path: 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 ECE1212001A for ; Sat, 6 Apr 2019 05:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.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 fJKFWLQEyQYT for ; Sat, 6 Apr 2019 05:36:49 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 6C0BB120049 for ; Sat, 6 Apr 2019 05:36:49 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x36CcX5J008602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 6 Apr 2019 05:38:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554554314; bh=/u4Zd8WkNQJwhjDBOkS0VasvgUEfumJEziXQT4pIDjE=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=d8CxB5zIQU+lTYckLpTzqwJgsr4bQX4JSH72MU+p5CMzi4UTKY4MuvFaVxu0eu4g6 cIUy71XZyNArKq3e7l/56CBHWLqMppwuUt2Yi7xdDqPKQoeJokLtqPzM9tgs6RX96u 3TNv0ocXEHyf2Qt1uZZoDKNZ5gODb9UtIUGH7DZE= To: dbound@ietf.org References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sat, 6 Apr 2019 05:36:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dbound] NXDomain (was: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 12:36:51 -0000 > if you ask for _perim.a.b.c.tld, and there is only _perim.c.tld, > the DNS response will be an NXDOMAIN and I don't think that DNS clients > expect to find additional records in an NXDOMAIN response. So indeed, this was an interesting point. However from what I can tell, including Additional information in an NXDomain response is entirely legal, albeit certainly unusual. My understanding is that it's likely careful use of a resolver library can retrieve the Additional information. Some calls won't get it; others probably will. The guidance for making this work is that it's seeking to emulate DNS wildcard behavior, through cooperative behavior by both the resolver and the authoritative server. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Apr 6 08:09:24 2019 Return-Path: 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 F20BE12000E for ; Sat, 6 Apr 2019 08:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=lDRgdtYG; dkim=pass (1536-bit key) header.d=taugh.com header.b=fgoDCbp8 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 CXhTkkrjC6BJ for ; Sat, 6 Apr 2019 08:09:21 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 B3102120103 for ; Sat, 6 Apr 2019 08:09:20 -0700 (PDT) Received: (qmail 87524 invoked from network); 6 Apr 2019 15:09:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=155e2.5ca8c11f.k1904; bh=R4tK7jsn8IIHFjpJeAc3r7ok89uh613rAxEG+pwkbmM=; b=lDRgdtYG6qfVV+cnkBknnsYmm9Pk/fSBDx4vSFc/nxiXPbcH2Cv2ubTx0hrbmCIi6QFfUhw/2FLMGZ18qISRDfr7Fde9gynuKYPdfcwfnnJZoNcDUme7UigfO3BG+1BaLtNIR6ew+r/R8RjY0Zm8kj56+DDaGxtEt7gzLaCDJ0VsUXu2szOvFVr2DgJLFacs6h4banlIUpo7bgc5BAe7B5gGOVnjJN/quIvIAEp2NRJJmt7douo5q5C7gR8oWqkK DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=155e2.5ca8c11f.k1904; bh=R4tK7jsn8IIHFjpJeAc3r7ok89uh613rAxEG+pwkbmM=; b=fgoDCbp8h5MnB6CXAIMvQRMgkplNLQYT5hNVQZJBVS3g/CmF43NutQ/sYyJBRGSwAnKV6VC4fMK9HKDQKuovYbQ3SL0yRA3no6Le5xedLpUMgzKK+7Kt7r+pe96i/+q556Kvt+KuzEboUOFFZxY0TsAqeRZoBdlRsVe35dojyq0HplhmZ5Th9LIOCai6IwNDMxEDzs0AUZIf5U6QRlxoD4YwtsyUqjGZ0LGsDglQOM9h0e99rK2NX/WdAh7Z5LKy Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 06 Apr 2019 15:09:18 -0000 Received: by ary.qy (Postfix, from userid 501) id 9B9BC2011A23A4; Sat, 6 Apr 2019 11:09:17 -0400 (EDT) Date: 6 Apr 2019 11:09:17 -0400 Message-Id: <20190406150918.9B9BC2011A23A4@ary.qy> From: "John Levine" To: dbound@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dbound] NXDomain (was: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 15:09:23 -0000 In article you write: >However from what I can tell, including Additional information in an >NXDomain response is entirely legal, albeit certainly unusual. No argument there. >My understanding is that it's likely careful use of a resolver library >can retrieve the Additional information. Some calls won't get it; >others probably will. As I may have said one or two times before, this hack will require changes to DNS servers to return additional information that they don't return now, changes to DNS caches to store and pass through additional information that they don't store or pass through now, and changes to DNS client libraries to retrieve the additional information that they don't retrieve now. I will cheerfully bet any amount of money that none of these changes ever happen. >The guidance for making this work is that it's seeking to emulate DNS >wildcard behavior, through cooperative behavior by both the resolver and >the authoritative server. Don't forget the caches which also will need to be changed. Once again, please compare this proposal to my 2016 proposal that uses normal DNS wildcards and works right now with no changes to any DNS server, cache, or client. Using TXT records, a fair amount of DNS crudware can probably provision it, too. I'm not saying it's perfect, but it's at least plausible. R's, John From nobody Sat Apr 6 14:15:04 2019 Return-Path: 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 5045C12006B for ; Sat, 6 Apr 2019 14:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.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 w6ltMso5Kb3v for ; Sat, 6 Apr 2019 14:15:01 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 775911200A0 for ; Sat, 6 Apr 2019 14:15:01 -0700 (PDT) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x36LGiAA013613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 6 Apr 2019 14:16:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1554585405; bh=qu8h/bPv6fYl9sLEGrABd1TE+Pv1vtXi0AeXRcCJpJs=; h=Subject:To:References:From:Reply-To:Date:In-Reply-To:From; b=In3Ha2eZkizjo8jRntGsFtAKBMMqFAb8qdBZF39uvFt+/Mk1de0JN1kApABcoZyrY m6/Insdmk4erfKC/w0BnDPNDjxNm5WL4frZNbb+BecZOrIC2e0Itd3RgBDBqhsNbe3 COmTMHg1DEZHTGGDQMoV9VmqgCC6O1bIdG3CjOGc= To: John Levine , dbound@ietf.org References: <20190406150918.9B9BC2011A23A4@ary.qy> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: Date: Sat, 6 Apr 2019 14:14:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190406150918.9B9BC2011A23A4@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dbound] NXDomain (was: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 21:15:03 -0000 On 4/6/2019 8:09 AM, John Levine wrote: > In article you write: >> My understanding is that it's likely careful use of a resolver library >> can retrieve the Additional information. Some calls won't get it; >> others probably will. > > As I may have said one or two times before, this hack will require > changes to DNS servers to return additional information that they > don't return now, Since that statement is in the current draft, I'm not clear what insight is intended by your multiple repetitions of it here. > changes to DNS caches to store and pass through > additional information that they don't store or pass through now, and Oh? You are saying that caches do not cache an entire response. I did not find references that support that. Please document. > changes to DNS client libraries to retrieve the additional information > that they don't retrieve now. I will cheerfully bet any amount of > money that none of these changes ever happen. That does not match my understanding. My understanding from a knowledgeable source is: "APIs such as those in libresolv that deal in raw packets do tend to make the entire packet available. Others such as `getaddrinfo` do not." Since you appear to be claiming otherwise, please explain. Worse, I even found an RFC with multiple examples of Additional information in an NXDomain response: Negative Caching of DNS Queries (DNS NCACHE) https://tools.ietf.org/html/rfc2308 > Once again, please compare this proposal to my 2016 proposal that uses If you wish to do the work of a careful audit of the differences and similarities, and pursue a pointed review of the similarities and differences, perhaps that will facilitate conversation. It would certainly improve the tone. d/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Apr 6 15:14:44 2019 Return-Path: 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 CF44D120075 for ; Sat, 6 Apr 2019 15:14:42 -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 (1536-bit key) header.d=iecc.com header.b=KJlsNlfw; dkim=pass (1536-bit key) header.d=taugh.com header.b=snuwNubg 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 O47KkUyOHGwp for ; Sat, 6 Apr 2019 15:14:40 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 9AFA9120003 for ; Sat, 6 Apr 2019 15:14:40 -0700 (PDT) Received: (qmail 79510 invoked from network); 6 Apr 2019 22:14:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=13692.5ca924cf.k1904; bh=kLoro4c/R5/Dx18W539FttKEeZbonm/WeZEsays/DhU=; b=KJlsNlfwMDTMAT3M2us0WAABJQ1sFeipB//HnlkpCRbK/qD9zNjvvgCsQkXaGUKE1FyKUuInbmEn3j2n8JGooR6WNt0P+0FWWh/1oAurNlqYvK0Lzt0w17BHUZsPK1Ka9TV1NvX2KTVfVYoXMb0ZXHkwFym/FPeOoNofewMI1XoZu1qF+QM/fuZoss9bMFxE4CgcIc8+trGfW2Fma5Z6ni165ZOIiUJKey0PbEdkRapEOWjlzCrhR+FydOM5qlHS DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=13692.5ca924cf.k1904; bh=kLoro4c/R5/Dx18W539FttKEeZbonm/WeZEsays/DhU=; b=snuwNubgR7PbQF5Yev3aFu5Uy9y7k4u8v6kB/5bo4BxVpBtu+dJP6C9BIiKbLAytSMY05+z5Pz4UnskrfqfhEDSLzxLyPQX/OEVcq3do+1qaZJm9JHagM9qq1hi0SaCamNyfWKuphS7qsSwCCYzwvtNU7M52vTYgXaqxFjP1IaA+sl50LvYKr9Xvx7EacCgFvDGF/J91bea2Hzung/uMJLKNDNrgu0LmimkXJDTRaTSrSq1nezfSKMevwgdunmjo Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 06 Apr 2019 22:14:38 -0000 Date: 6 Apr 2019 18:14:38 -0400 Message-ID: From: "John R Levine" To: dbound@ietf.org User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [dbound] New Version Notification for draft-levine-dbound-dns-02.txt (fwd) X-BeenThere: dbound@ietf.org 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: Sat, 06 Apr 2019 22:14:43 -0000 Since I keep saying how wonderful my wildcard dbound proposal was, I figure I should resuscitate it. Here it is with TXT records rather than a new rrtype and a few other minor tweaks. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ---------- Forwarded message ---------- Date: Sat, 6 Apr 2019 18:10:32 From: internet-drafts@ietf.org To: John Levine Subject: [taugh.com-standards] New Version Notification for draft-levine-dbound-dns-02.txt A new version of I-D, draft-levine-dbound-dns-02.txt has been successfully submitted by John Levine and posted to the IETF repository. Name: draft-levine-dbound-dns Revision: 02 Title: Publishing Organization Boundaries in the DNS Document date: 2019-04-06 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-levine-dbound-dns-02.txt Status: https://datatracker.ietf.org/doc/draft-levine-dbound-dns/ Htmlized: https://tools.ietf.org/html/draft-levine-dbound-dns-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-levine-dbound-dns Diff: https://www.ietf.org/rfcdiff?url2=draft-levine-dbound-dns-02 Abstract: The organization that manages a subtree in the DNS is often different from the one that manages the tree above it. We describe an architecture to publish in the DNS the boundaries between organizations that can be adapted to various policy models and can be queried with a small number of DNS lookups. From nobody Sat Apr 6 17:21:13 2019 Return-Path: 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 8390C120077 for ; Sat, 6 Apr 2019 17:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GPsIh6jrjfD1 for ; Sat, 6 Apr 2019 17:21:09 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B2312006A for ; Sat, 6 Apr 2019 17:21:09 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id v84so7767746oif.4 for ; Sat, 06 Apr 2019 17:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iUPLJ0FFJN/4BIsU2KwqQMe7fv1ImKLbl+QEgpF86e4=; b=PbodU0cNq1sJNbt58MwJtBwgLQ9yEWupfjE94+dJbyKjwOCIcvN6V3f3hJXEAT+/7M UYt0TVO466Zm8R6jYtfX9kewlr1kd5QIhF4VgMaYH5kvAYWRk3tPsI36zRp9tGTm+NiU /aowVXU2E4UO9wV4CabeobXpcnRJsJ1deMbB7R4B4XiJ4T8JI/Xaa2MRmMRITa+S2WcE 4+1/+OOlzTpEQU6KM8pFa2OAMUsTJLw9sQsgmah1l2tLj6441KbNrpPWRthUcOVvEk59 RKbCnVBuaZA4KYSNe6SRsoRf/wcHWsAByHKrzdvaatMU+PI/Se5LCvhwbT/RjwHGHktX DrXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iUPLJ0FFJN/4BIsU2KwqQMe7fv1ImKLbl+QEgpF86e4=; b=lg0HSV4cv99WNbpMDGCB2DfWQp5gsHIM0u61U0J+9W64ReFefPx66PzmIrXXEe6lAc 4rSrZLouqULSYEO1enzdiHp6FqvpSc79lpo/0NV/xZref8JfAFQNgvx0FEbawUcWSEjx LZGsJ2mRDTIxGDGZt7kebU5qyfre09zjEkoTHRRR3z909Wxi37ibgIkmAG7jtvT9qUKn KZFzRgRd6+CEUqh/ZqGDD+lfWdjbVFoZSHnt6TqK3oANPjWEeCB7pXCP9Xymgaoh60km ZRxiq9iEaK1hYjqAYg0x848zGmGMHvzFh9azrXGn8iUiOw+KQZomxYrYEEElOc/xxvV7 tFUA== X-Gm-Message-State: APjAAAUaHlxG5Nn9lC9g9+1lr4iTB32yA2P7BiSRz3/6dHFt0o58G9sp ggErQZRBc2TILBYYCVZiJoPbk06TPXA37KasKTPD/Q== X-Google-Smtp-Source: APXvYqxrOjA4XS5nMZIXtAYRXTaPiZwZkYa1eHu7qK0RBn8v8Z12nSF+kjtLxlgB1d0B3a9MKDjlXP3plfqp+kzPn5M= X-Received: by 2002:aca:4c88:: with SMTP id z130mr11851466oia.170.1554596468328; Sat, 06 Apr 2019 17:21:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Sat, 6 Apr 2019 20:21:00 -0400 Message-ID: To: John R Levine Cc: dbound@ietf.org Content-Type: multipart/alternative; boundary="000000000000438d4d0585e5b242" Archived-At: Subject: Re: [dbound] New Version Notification for draft-levine-dbound-dns-02.txt (fwd) X-BeenThere: dbound@ietf.org 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: Sun, 07 Apr 2019 00:21:11 -0000 --000000000000438d4d0585e5b242 Content-Type: text/plain; charset="UTF-8" Thanks John I remember thinking this idea is even simpler than the PSD-like proposal in dmarc right now. On Sat, Apr 6, 2019 at 6:14 PM John R Levine wrote: > Since I keep saying how wonderful my wildcard dbound proposal was, I > figure I should resuscitate it. Here it is with TXT records rather than a > new rrtype and a few other minor tweaks. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > ---------- Forwarded message ---------- > Date: Sat, 6 Apr 2019 18:10:32 > From: internet-drafts@ietf.org > To: John Levine > Subject: [taugh.com-standards] New Version Notification for > draft-levine-dbound-dns-02.txt > > > A new version of I-D, draft-levine-dbound-dns-02.txt > has been successfully submitted by John Levine and posted to the > IETF repository. > > Name: draft-levine-dbound-dns > Revision: 02 > Title: Publishing Organization Boundaries in the DNS > Document date: 2019-04-06 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/internet-drafts/draft-levine-dbound-dns-02.txt > Status: https://datatracker.ietf.org/doc/draft-levine-dbound-dns/ > Htmlized: https://tools.ietf.org/html/draft-levine-dbound-dns-02 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-levine-dbound-dns > Diff: > https://www.ietf.org/rfcdiff?url2=draft-levine-dbound-dns-02 > > Abstract: > The organization that manages a subtree in the DNS is often different > from the one that manages the tree above it. We describe an > architecture to publish in the DNS the boundaries between > organizations that can be adapted to various policy models and can be > queried with a small number of DNS lookups. > > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > --000000000000438d4d0585e5b242 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks John

I remember thinking this id= ea is even simpler than the PSD-like proposal in dmarc right now.=C2=A0

On Sat, Apr 6, 2019 at 6:14 PM John R Levine <johnl@taugh.com> wrote:
Since I= keep saying how wonderful my wildcard dbound proposal was, I
figure I should resuscitate it.=C2=A0 Here it is with TXT records rather th= an a
new rrtype and a few other minor tweaks.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---------- Forwarded message ----------
Date: Sat, 6 Apr 2019 18:10:32
From: interne= t-drafts@ietf.org
To: John Levine <standards@taugh.com>
Subject: [taugh.com-standards] New Version Notification for
=C2=A0 =C2=A0 =C2=A0draft-levine-dbound-dns-02.txt


A new version of I-D, draft-levine-dbound-dns-02.txt
has been successfully submitted by John Levine and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-levine-dbound-dns
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Publishing Organization Boundaries= in the DNS
Document date:=C2=A0 2019-04-06
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-levine-dbound-dns-0= 2.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-levine-dbound-dns/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-levine-dbound-dns-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/html/draft-levine-dbound-dns
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-levine-dbound-dns-02<= br>
Abstract:
=C2=A0 =C2=A0 The organization that manages a subtree in the DNS is often d= ifferent
=C2=A0 =C2=A0 from the one that manages the tree above it.=C2=A0 We describ= e an
=C2=A0 =C2=A0 architecture to publish in the DNS the boundaries between
=C2=A0 =C2=A0 organizations that can be adapted to various policy models an= d can be
=C2=A0 =C2=A0 queried with a small number of DNS lookups.

_______________________________________________
dbound mailing list
dbound@ietf.org https://www.ietf.org/mailman/listinfo/dbound
--000000000000438d4d0585e5b242-- From nobody Sat Apr 6 17:29:57 2019 Return-Path: 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 EF515120094 for ; Sat, 6 Apr 2019 17:29:54 -0700 (PDT) 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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=uv+LKdmn; dkim=pass (2048-bit key) header.d=kitterman.com header.b=FPm5FyjL 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 EoBHqa_g35AE for ; Sat, 6 Apr 2019 17:29:52 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE12B12006A for ; Sat, 6 Apr 2019 17:29:52 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id B7AF0F8027B for ; Sat, 6 Apr 2019 20:29:50 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1554596990; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=wsf385thCyfNmJiaPNRhlKFYw+UFIuaTITAtqpcgmZg=; b=uv+LKdmnBOCs1AeSMtSyPGRe2MMk4livIp26KxO7ZXiqsjFBdugf5Wgv Pl44zHjUiVZI03UKMNQK/GJlx4UFBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1554596990; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=wsf385thCyfNmJiaPNRhlKFYw+UFIuaTITAtqpcgmZg=; b=FPm5FyjLRXA7MTUsFgKQWt7vwpkDXy5h6yaYS9VINxeRWdzaTYsLWEn3 iTpOg6BPfyErObdQb7NjThy79prN/gYzL/sIcQsVrs5Avw0SVirMbgybAg xUQm1V7PaL5nOpOAB7CK1Jwc0TcS2R3ygQcAQTdBCcinJeImxq9jTAvygS HwBUwV7RwGQcY8jJLOzFtj/oSHVPFKJXAJh6kGWmAXymx05+6+wsl15r5j u3tbOWsSWdqCGSwJEX8fWNa/Bc+qBxzh02PuYybEo0GZIfFIWnvnmmGJdg TH9HEkg9WjvmTAcH6gWNvNhfMKXHXu/eOmFQJa+bz6WEyWhDCmitqw== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 8B8D9F80053 for ; Sat, 6 Apr 2019 20:29:50 -0400 (EDT) From: Scott Kitterman To: dbound@ietf.org Date: Sat, 06 Apr 2019 20:29:49 -0400 Message-ID: <2192430.1ppicJjaX3@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dbound] New Version Notification for draft-levine-dbound-dns-02.txt (fwd) X-BeenThere: dbound@ietf.org 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: Sun, 07 Apr 2019 00:29:55 -0000 I think they are orthogonal. This is about how you find the public/private boundary. PSD DMARC is about when to look past it. Scott K On Saturday, April 06, 2019 08:21:00 PM Tim Wicinski wrote: > Thanks John > > I remember thinking this idea is even simpler than the PSD-like proposal in > dmarc right now. > > On Sat, Apr 6, 2019 at 6:14 PM John R Levine wrote: > > Since I keep saying how wonderful my wildcard dbound proposal was, I > > figure I should resuscitate it. Here it is with TXT records rather than a > > new rrtype and a few other minor tweaks. > > > > Regards, > > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > > Please consider the environment before reading this e-mail. https://jl.ly > > > > ---------- Forwarded message ---------- > > Date: Sat, 6 Apr 2019 18:10:32 > > From: internet-drafts@ietf.org > > To: John Levine > > Subject: [taugh.com-standards] New Version Notification for > > > > draft-levine-dbound-dns-02.txt > > > > A new version of I-D, draft-levine-dbound-dns-02.txt > > has been successfully submitted by John Levine and posted to the > > IETF repository. > > > > Name: draft-levine-dbound-dns > > Revision: 02 > > Title: Publishing Organization Boundaries in the DNS > > Document date: 2019-04-06 > > Group: Individual Submission > > Pages: 10 > > URL: > > https://www.ietf.org/internet-drafts/draft-levine-dbound-dns-02.txt > > Status: https://datatracker.ietf.org/doc/draft-levine-dbound-dns/ > > Htmlized: https://tools.ietf.org/html/draft-levine-dbound-dns-02 > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-levine-dbound-dns > > Diff: > > https://www.ietf.org/rfcdiff?url2=draft-levine-dbound-dns-02 > > > > Abstract: > > The organization that manages a subtree in the DNS is often different > > from the one that manages the tree above it. We describe an > > architecture to publish in the DNS the boundaries between > > organizations that can be adapted to various policy models and can be > > queried with a small number of DNS lookups. > > > > _______________________________________________ > > dbound mailing list > > dbound@ietf.org > > https://www.ietf.org/mailman/listinfo/dbound From nobody Sat Apr 27 12:20:09 2019 Return-Path: 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 32291120019 for ; Sat, 27 Apr 2019 12:20:02 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=0hDeRn8T; dkim=pass (1536-bit key) header.d=taugh.com header.b=OXGnGrGZ 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 IrqGmrrmCsaA for ; Sat, 27 Apr 2019 12:19:59 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 5116B120089 for ; Sat, 27 Apr 2019 12:19:59 -0700 (PDT) Received: (qmail 74923 invoked from network); 27 Apr 2019 19:19:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=124a6.5cc4ab5d.k1904; i=johnl-iecc.com@submit.iecc.com; bh=ENRuAzKxtAvMKPCcIck4XUIG+jyG5a8sFI2vIJNU1so=; b=0hDeRn8TA+ig6Zht2efT3dkfYtjtDOUNOxdBZmampSCqjPWs00QOQd5CSKzKeqId2ofSfthR2P8hSo2hpVQZI3rZq1d2Y9AL5J3ltj0hdm5yaE7+2yLEXy5/EDNcBI/0vx5P+egh3BjQumUk/QA//VGGnGtTZD5QyxioYb09FwN+Wwdfsvg/4RkEejjA2GXwORZaeFsiNYv5kCYUP74ds9scNMsL1M2q1ZIqw3QXQh8R1sssOQM65brNDSdh8uRp DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=124a6.5cc4ab5d.k1904; olt=johnl-iecc.com@submit.iecc.com; bh=ENRuAzKxtAvMKPCcIck4XUIG+jyG5a8sFI2vIJNU1so=; b=OXGnGrGZ5Sf/kMIiMkagVUgbauL2fj6XmKtWjtfsiu7J7hz6huJXgAw1zWbjeCzUz+NFI0WSPw+oiVer4a9zfKAhST1pUHmEVfKn7UMF9DtQ9JnQXW8m5M6pKJ4Rh4cZlP/jEQL+Vj8CEJHAFG+/pssOmRBk2YALOM1rb5A+xy0Tpm/woCkn12T0ic0OvpmiJiFlPzJyCE/Y+1sO4fSmARE7ipXno7zs7+C7P+R6DrRAqbm6sz6X1JFv6UJqnicK Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 27 Apr 2019 19:19:57 -0000 Date: 27 Apr 2019 15:19:57 -0400 Message-ID: From: "John R Levine" To: dbound@ietf.org, dmarc@ietf.org In-Reply-To: References: User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [dbound] New Version of draft-levine-dbound-dns-03 with code X-BeenThere: dbound@ietf.org 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: Sat, 27 Apr 2019 19:20:02 -0000 You may recall that we've been discussing ways to publish DNS authority boundaries, like the Mozilla PSL but in the DNS itself, not a text file. I've been claiming that with careful use of wildcards one make the number of lookups depend on the number of boundaries, not the number of labels in the name being checked, so it's reliably reasonably fast. I figured I should put my bits where my mouth is so I wrote a script to translate the Mozilla PSL into DNS rules. It turned out to be harder than I thought because the PSL has wildcard rules with exceptions, e.g.: *.ck !www.ck That turned out to be straightforward to handle with a tweak to the spec I just made in the -03 version. The code to make the DNS records, and another script to take a domain name and look it up in those records are here: https://github.com/jrlevine/bound I think the lookup code is OK but there may be some glitches in the PSL translator for some of the more arcane combination of wildcard and non-wildcard boundaries. Take a look if interested. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly PS to Scott: I think it would be pretty easy to add a tag for PSD TLDs.