From envite@rolamasao.org Wed May 1 10:00:07 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C0921F9A85 for ; Wed, 1 May 2013 10:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.137 X-Spam-Level: * X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_STATIC=1.172, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE9aV+VJvDdq for ; Wed, 1 May 2013 10:00:03 -0700 (PDT) Received: from rolamasao.org (68.167.216.87.static.jazztel.es [87.216.167.68]) by ietfa.amsl.com (Postfix) with ESMTP id DC8D321F9A81 for ; Wed, 1 May 2013 09:59:50 -0700 (PDT) Received: from tochox.localnet (localhost [IPv6:::1]) by rolamasao.org (Postfix_t) with ESMTPSA id B1A9E11EA7 for ; Wed, 1 May 2013 17:59:33 +0100 (WEST) From: Noel David Torres =?iso-8859-1?q?Ta=F1o?= To: dnsext@ietf.org Date: Wed, 1 May 2013 17:59:28 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) References: <201304250029.57132.envite@rolamasao.org> In-Reply-To: <201304250029.57132.envite@rolamasao.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2756876.Ml1mW7GjTN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201305011759.29280.envite@rolamasao.org> Subject: Re: [dnsext] Draft for OID X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 17:00:07 -0000 --nextPart2756876.Ml1mW7GjTN Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all Draft for DNS-like OID system has been submitted: https://datatracker.ietf.org/doc/draft-torres-dnsext-oid/ No comments? I can really not trust I've written such a perfect document th= at=20 nobody objects to it. Noel Torres er Envite =2D------------------------ A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? --nextPart2756876.Ml1mW7GjTN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlGBSfEACgkQcLQA8+7Hw3Kf8gCfafh2uTmzcyEQo96/TJdA9yCV YQMAnixZg6bPkZo/aVRpiz5OlMEazVCY =y1yq -----END PGP SIGNATURE----- --nextPart2756876.Ml1mW7GjTN-- From paf@frobbit.se Wed May 1 10:17:09 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A8421F9897 for ; Wed, 1 May 2013 10:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEfTON5SlZyf for ; Wed, 1 May 2013 10:17:08 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 4E97121F9885 for ; Wed, 1 May 2013 10:17:08 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) by mail.frobbit.se (Postfix) with ESMTPSA id DC7C420245; Wed, 1 May 2013 19:17:06 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_B1AD8273-D1BF-4D31-9954-7CCADF888D98"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <201305011759.29280.envite@rolamasao.org> Date: Wed, 1 May 2013 19:17:06 +0200 Message-Id: <6251E1FB-9BA6-4F34-9711-43D6EBE316C9@frobbit.se> References: <201304250029.57132.envite@rolamasao.org> <201305011759.29280.envite@rolamasao.org> To: =?iso-8859-1?Q?Noel_David_Torres_Ta=F1o?= X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] Draft for OID X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 17:17:09 -0000 --Apple-Mail=_B1AD8273-D1BF-4D31-9954-7CCADF888D98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 1 maj 2013, at 18:59, Noel David Torres Ta=F1o = wrote: > Hi all >=20 > Draft for DNS-like OID system has been submitted: >=20 > https://datatracker.ietf.org/doc/draft-torres-dnsext-oid/ >=20 > No comments? I can really not trust I've written such a perfect = document that=20 > nobody objects to it. Well, I pointed at the existing registry = http://www.alvestrand.no/objectid/top.html earlier, but did not see any = comments from for example you :-) Have you been in contact with Harald? Patrik > Noel Torres > er Envite > ------------------------- > A: Because it breaks the logical flow of discussion. > Q: Why is top posting bad? > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --Apple-Mail=_B1AD8273-D1BF-4D31-9954-7CCADF888D98 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iD8DBQFRgU4SrMabGguI180RAuYgAJ9sd0KX1ISMtYkqI213rfInULczCgCcDgC4 7pTKdJgb9hT0DBnfkUeGqwY= =J07g -----END PGP SIGNATURE----- --Apple-Mail=_B1AD8273-D1BF-4D31-9954-7CCADF888D98-- From jim@rfc1035.com Wed May 1 11:32:41 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A430821F998B for ; Wed, 1 May 2013 11:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdPKcM-ICjli for ; Wed, 1 May 2013 11:32:37 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 9C20121F9970 for ; Wed, 1 May 2013 11:32:36 -0700 (PDT) Received: from [IPv6:::1] (shaun.rfc1035.com [93.186.33.42]) by shaun.rfc1035.com (Postfix) with ESMTP id 14CA3CBC41F; Wed, 1 May 2013 19:32:30 +0100 (BST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: <201305011759.29280.envite@rolamasao.org> Date: Wed, 1 May 2013 19:32:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <116AB7C6-10BE-43C7-AC76-86498A3FAEDA@rfc1035.com> References: <201304250029.57132.envite@rolamasao.org> <201305011759.29280.envite@rolamasao.org> To: =?iso-8859-1?Q?Noel_David_Torres_Ta=F1o?= X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] Draft for OID X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 18:32:41 -0000 On 1 May 2013, at 17:59, Noel David Torres Ta=F1o = wrote: > No comments? I can really not trust I've written such a perfect = document that=20 > nobody objects to it. I don't object to the document. I just don't see what problem it solves = or why/how it's needed. I think it needs a great deal of work, perhaps = far, far more than you appreciate. Sorry. The principle of putting OIDs into the DNS is sound. Any hierarchical = naming or numbering scheme is an obvious fit with the DNS. But beyond that your draft lacks vast amounts of important detail. For = example, what's the justification for using a new class? Who is going to = provide and operate the DNS infrastructure for that: name servers, = registry, etc? Which entities are responsible for managing this new name = space? What roles do they have and how do they interact with each other? = Have you asked them -- ISO, ITU-T, National Standards Institutes, = vendors, current users of OIDs, etc -- and what did they say? [cf The = handshakes between all the actors in the management of e164.arpa.] Who = manages the registries which map names to numbers for (parts of) the OID = labels? How does an ISO-flavour OID -- which is delimited by spaces IIUC = -- get mapped into a domain name? The purpose and meaning of the = proposed RRtypes are unclear too. Who defines these types and manages = the registry for them? Why does your draft propose/need a new root? Why = not put all OIDs under oid.arpa (say) and just stick with the IN class, = like pretty much everything else on the Internet? What does this EQUIV = RRtype do that CNAME or DNAME can't? What are resolvers expected to do = and not do when they encounter this EQUIV record? Are IN class RRtypes = valid or not in this new name space? How is delegation done and how do = resolvers traverse your new name space? Your draft has a couple of = sentences on an NS RRtype but nothing on how these name servers are = located or how their IP addresses (presumably) are presented in this OID = class. These are all rhetorical questions BTW. There's no need to answer them = here and now but they really have to be addressed somehow in a future = version of your document or set of documents. There's the seed of a nice idea here but it needs an awful lot of hard = work and attention to detail.= From envite@rolamasao.org Wed May 1 12:24:39 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7220F21F9AFC for ; Wed, 1 May 2013 12:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.137 X-Spam-Level: * X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_STATIC=1.172, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlVw-WkEvbAW for ; Wed, 1 May 2013 12:24:35 -0700 (PDT) Received: from rolamasao.org (68.167.216.87.static.jazztel.es [87.216.167.68]) by ietfa.amsl.com (Postfix) with ESMTP id 486D021F9885 for ; Wed, 1 May 2013 12:24:32 -0700 (PDT) Received: from tochox.localnet (localhost [IPv6:::1]) by rolamasao.org (Postfix_t) with ESMTPSA id BA5DA11EA7 for ; Wed, 1 May 2013 20:24:30 +0100 (WEST) From: Noel David Torres =?iso-8859-1?q?Ta=F1o?= To: dnsext@ietf.org Date: Wed, 1 May 2013 20:24:21 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) References: <201304250029.57132.envite@rolamasao.org> <201305011759.29280.envite@rolamasao.org> <6251E1FB-9BA6-4F34-9711-43D6EBE316C9@frobbit.se> In-Reply-To: <6251E1FB-9BA6-4F34-9711-43D6EBE316C9@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5347060.0vWh3ddEth"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201305012024.23730.envite@rolamasao.org> Subject: Re: [dnsext] Draft for OID X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 19:24:39 -0000 --nextPart5347060.0vWh3ddEth Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mi=E9rcoles, 1 de mayo de 2013 18:17:06 Patrik F=E4ltstr=F6m wrote: > On 1 maj 2013, at 18:59, Noel David Torres Ta=F1o = =20 wrote: > > Hi all > >=20 > > Draft for DNS-like OID system has been submitted: > >=20 > > https://datatracker.ietf.org/doc/draft-torres-dnsext-oid/ > >=20 > > No comments? I can really not trust I've written such a perfect document > > that nobody objects to it. >=20 > Well, I pointed at the existing registry > http://www.alvestrand.no/objectid/top.html earlier, but did not see any > comments from for example you :-) >=20 > Have you been in contact with Harald? >=20 > Patrik No, I knew of that page and also of http://oid-info.com but they are web- based, thus not easily parseable, and not complete. I'm seeking for a machi= ne- parseable, as-complete-as-each-owner-wants-to-publicite solution. Thanks for the comment Noel er Envite =2D------------------------ A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? --nextPart5347060.0vWh3ddEth Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlGBa+cACgkQcLQA8+7Hw3IqcwCeJmX/HZ08BpWyvWKhqRZ1NiBl k+sAn0yyufynWZfClnUPDWApEoh6Pf4i =0Yso -----END PGP SIGNATURE----- --nextPart5347060.0vWh3ddEth-- From paul.hoffman@vpnc.org Wed May 1 12:32:39 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AC621F99BD for ; Wed, 1 May 2013 12:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbnAsedpCw9p for ; Wed, 1 May 2013 12:32:38 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA9C21F9907 for ; Wed, 1 May 2013 12:32:37 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r41JWYZ5010799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 May 2013 12:32:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <201305011759.29280.envite@rolamasao.org> Date: Wed, 1 May 2013 12:32:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6593BCE4-ECF6-450B-9364-62B662EF7BA6@vpnc.org> References: <201304250029.57132.envite@rolamasao.org> <201305011759.29280.envite@rolamasao.org> To: =?iso-8859-1?Q?Noel_David_Torres_Ta=F1o?= X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] Draft for OID X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 19:32:39 -0000 On May 1, 2013, at 9:59 AM, Noel David Torres Ta=F1o = wrote: > No comments? I can really not trust I've written such a perfect = document that=20 > nobody objects to it. I can only speak for myself about why I didn't comment. You never = answered the earlier question about why this is needed. A much, much = lighter-weight solution is to simply set up something in the current IN = class under a name like "all-oids.org". Why expect the world to make a = heavy-weight change to the DNS protocol for some use case that you don't = even state? --Paul Hoffman= From warren@kumari.net Thu May 2 09:15:50 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F3121F8F4D for ; Thu, 2 May 2013 09:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.832 X-Spam-Level: X-Spam-Status: No, score=-101.832 tagged_above=-999 required=5 tests=[AWL=0.768, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epPaQ2PkO7Rd for ; Thu, 2 May 2013 09:15:45 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D9221F8F32 for ; Thu, 2 May 2013 09:15:41 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.117]) by vimes.kumari.net (Postfix) with ESMTPSA id 162291B40047; Thu, 2 May 2013 12:15:41 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <6593BCE4-ECF6-450B-9364-62B662EF7BA6@vpnc.org> Date: Thu, 2 May 2013 12:15:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0253DBD8-E157-4F22-AEC0-578C4F5A366D@kumari.net> References: <201304250029.57132.envite@rolamasao.org> <201305011759.29280.envite@rolamasao.org> <6593BCE4-ECF6-450B-9364-62B662EF7BA6@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] Draft for OID X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 16:15:50 -0000 On May 1, 2013, at 3:32 PM, Paul Hoffman wrote: > On May 1, 2013, at 9:59 AM, Noel David Torres Ta=F1o = wrote: >=20 >> No comments? I can really not trust I've written such a perfect = document that=20 >> nobody objects to it. >=20 > I can only speak for myself about why I didn't comment. You never = answered the earlier question about why this is needed. A much, much = lighter-weight solution is to simply set up something in the current IN = class under a name like "all-oids.org". Or, as another option, set up something in the current IN class under a = name like "all-oids.org", using that to demonstrate how / what problem = it solves and then going through all the effort of getting consensus, = polishing the edges, etc. Or, just charge folk to register their OIDs in = all-oids.org :-P I don't think folk are against the idea, but there needs to be more = justification than: because it's cool and easier to parse... > Why expect the world to make a heavy-weight change to the DNS protocol = for some use case that you don't even state? +1. Demonstrate the utility (or, more clearly state the problem) and = folk will probably follow along. W >=20 > --Paul Hoffman > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 -- "Build a man a fire, and he'll be warm for a day. Set a man on fire, and = he'll be warm for the rest of his life." -- Terry Pratchett From hallam@gmail.com Fri May 3 04:40:42 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D25A21F93B1 for ; Fri, 3 May 2013 04:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bz+8y3ZUbeh for ; Fri, 3 May 2013 04:40:42 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A234A21F8433 for ; Fri, 3 May 2013 04:40:41 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id s10so1260164wey.3 for ; Fri, 03 May 2013 04:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=I2JfSJ8utvfS8fSnNNoNV3ZdkyQW1PCh8s0Ab2/CvvI=; b=MhnAHY2jv8TGpdttsy2MR+QriXYZxQldrOVhxr30+Y27MiPNTIk6u7/G8XHlAYVieM 37/SgOlvjW3qNhp2gjOwpWYNkSU13aAmVii/gRhMYYrW++a6wQgNx7LRQQ/rjZXpxK7l fuvArjHLljGmxw/63OE7u/CvznAPYnA/3FeNqzoaA7Cwx0DaFxEvqTHG2Jmr/E6VKNZ7 ooYkTH+a+2D+//JioNtFhD03dEHhNdwI9V8wc73CxH8sfIMaZRkCCAli5Z0cdkV/y+TQ 1AH4stWw4gRKuEBhy2dRqOrYEw4rSPpg2vaBTLwd+TpPIvKmow8j2PfI1vBW7ln/jDWf hB0w== MIME-Version: 1.0 X-Received: by 10.180.95.106 with SMTP id dj10mr12080920wib.1.1367581240783; Fri, 03 May 2013 04:40:40 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Fri, 3 May 2013 04:40:40 -0700 (PDT) In-Reply-To: <7B2DEDE4-1038-4A24-8A7C-213223A64CF9@frobbit.se> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> <72539563-0FA7-4C5E-901B-A5AFCE9CE038@virtualized.org> <7B2DEDE4-1038-4A24-8A7C-213223A64CF9@frobbit.se> Date: Fri, 3 May 2013 07:40:40 -0400 Message-ID: From: Phillip Hallam-Baker To: "dnsext@ietf.org Group" Content-Type: multipart/alternative; boundary=f46d04428d920efabd04dbced2c4 Subject: Re: [dnsext] Obsoleting SPF RRTYPE X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 11:40:42 -0000 --f46d04428d920efabd04dbced2c4 Content-Type: text/plain; charset=ISO-8859-1 Responding to multiple arguments in the thread. 1) The majority of participants in the SPF group never intended to transition to the SPF record. It was only ever proposed to get the spec past IETF last call over objections from DNSEXT. I can't see anything has changed since. The DNSEXT participants did not exactly help their cause by telling everyone that the Microsoft DNS server supported unknown record types long after Microsoft had denied that it did and showed the source code to prove that the server could not save or read unknown record types. 2) The issues involved in SPF, DKIM and DANE are different. DANE has a dependency on DNSSEC and thus a requirement for new RR type support, DKIM and SPF do not. DKIM did not require wildcard records (for signing mail at least) and so use of prefix records was practical. SPF required wildcard support because of its function and required that it did not have a DNSSEC dependency. 3) +1 to Paul Hoffman on the not answering the question point. DNSSEC would have deployed ten years ago with the ATLAS rollout had this WG accepted one simple change to the specification for the sake of deployment. Not that the fault is entirely in the WG, the chair and the AD bear most of the blame as did the IESG for allowing an AD in one area to chair a WG in another. 4) SPF existed and had a significant deployed base before the WG was started. The most that the WG could have done was to have persuaded some users of SPF to use the new record instead of TXT. Ending use of the TXT record was never an achievable goal and that is the only outcome that would have had any value. But anyway, what is done is done. If people think that there is a value to TXT record like things and that the new RR mechanism works then why not address the problem of SPF polluting the TXT namespace (which I never liked) by creating a new TXT record or so? --f46d04428d920efabd04dbced2c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Responding to multiple arguments in the thread.

1) The majority of participants in the SPF group = never intended to transition to the SPF record. It was only ever proposed t= o get the spec past IETF last call over objections from DNSEXT. I can't= see anything has changed since.

The DNSEXT participants did not exactly hel= p their cause by telling everyone that the Microsoft DNS server supported u= nknown record types long after Microsoft had denied that it did and showed = the source code to prove that the server could not save or read unknown rec= ord types.

2) The issues involved in SPF, DKIM and DAN= E are different. DANE has a dependency on DNSSEC and thus a requirement for= new RR type support, DKIM and SPF do not. DKIM did not require wildcard re= cords (for signing mail at least) and so use of prefix records was practica= l. SPF required wildcard support because of its function and required that = it did not have a DNSSEC dependency.

3) +1 to Paul Hoffman on the not answering = the question point. DNSSEC would have deployed ten years ago with the ATLAS= rollout had this WG accepted one simple change to the specification for th= e sake of deployment. Not that the fault is entirely in the WG, the chair a= nd the AD bear most of the blame as did the IESG for allowing an AD in one = area to chair a WG in another.

4) SPF existed and had a significant deploy= ed base before the WG was started. The most that the WG could have done was= to have persuaded some users of SPF to use the new record instead of TXT. = Ending use of the TXT record was never an achievable goal and that is the o= nly outcome that would have had any value.


But anyway, what is do= ne is done.=A0

If people think that th= ere is a value to TXT record like things and that the new RR mechanism work= s then why not address the problem of SPF polluting the TXT namespace (whic= h I never liked) by creating a new TXT record or so?
--f46d04428d920efabd04dbced2c4-- From hallam@gmail.com Fri May 3 04:42:23 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42A821F93FB for ; Fri, 3 May 2013 04:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXz90dPdrRMa for ; Fri, 3 May 2013 04:42:23 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id DB56A21F93B1 for ; Fri, 3 May 2013 04:42:22 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id l13so512886wie.6 for ; Fri, 03 May 2013 04:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=55RqM1uk8P74m2+4Gkdc8MobrgBnx7b2x0Iknse9Vtc=; b=K/HnKyUApE7N/qhyJ/Eo4wWM34mjKaYOFmVBs2UgfiVuozbStTh9sQ1DSEe1cheU3w X9eenSxTCd+AzGWdec/PFUkTqyFFgEI4svvr9PJNScPC72ZNXXYXeSRf/QQI0UmLv9Xk j07bnB0LufO28hXOmXDdNMPtGpyleuRtIAg0z9epG842jhW4YewjnTwyVT81vJ4iJXiX M1xBvSDpa2Qu/fNk/USpfRhtJQJL3wEvRXbTPvhpnBPvzXX1IpEY1f9PZuutV3F2Y6er hXslxcIVap+8qjekRLw22bIaQ04CfoUXZLBhwAjA8pzajimGHHbsmRtJpY53C0sl82pG 5hCw== MIME-Version: 1.0 X-Received: by 10.180.95.106 with SMTP id dj10mr12088516wib.1.1367581340623; Fri, 03 May 2013 04:42:20 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Fri, 3 May 2013 04:42:20 -0700 (PDT) In-Reply-To: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> Date: Fri, 3 May 2013 07:42:20 -0400 Message-ID: From: Phillip Hallam-Baker To: Jim Reid Content-Type: multipart/alternative; boundary=f46d04428d92026ade04dbced82f Cc: Edward Lewis , "dnsext@ietf.org" Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 11:42:24 -0000 --f46d04428d92026ade04dbced82f Content-Type: text/plain; charset=ISO-8859-1 It is not just stupid to further overload TXT, it is impossible. The SPF group knew when they were doing the draft that they were essentially making any other use of the TXT record infeasible in the future. Or at least I pointed that out. On Mon, Apr 29, 2013 at 11:19 AM, Jim Reid wrote: > On 29 Apr 2013, at 15:49, Edward Lewis wrote: > > > The only concern is that pushing more data into TXT records is that, if > more than one application does this and involves the same name, we are > increasing the number of large RRsets pushed around. > > Nope. ALL the applications looking up TXT records will have to wade > through a pile of them to find and make sense of the one(s) that are of > specific interest. Good luck if > 1 of these TXT records have similar RDATA > but are meant for use by different things. Though perhaps that's just a > concern for dnsop or developers rather than this WG. > > Frankly, it's beyond stupid to overload TXT records now a unique RRtype > code is simple to get (ha!) or some prefix convention could be applied: > like adding _spf (say) to the QNAME so a big bunch of TXT records don't all > have to sit at the same node in the tree. > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --f46d04428d92026ade04dbced82f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It is not just stupid to further overload TXT, it is impos= sible.

The SPF group knew when they were doing the= draft that they were essentially making any other use of the TXT record in= feasible in the future. Or at least I pointed that out.


On Mon,= Apr 29, 2013 at 11:19 AM, Jim Reid <jim@rfc1035.com> wrote:
On 29 Apr 2013, at 15:49, Edward Lewis <ed.lewis@neustar.biz> wrote:

> The only concern is that pushing more data into TXT records is that, i= f more than one application does this and involves the same name, we are in= creasing the number of large RRsets pushed around.

Nope. ALL the applications looking up TXT records will have to wade through= a pile of them to find and make sense of the one(s) that are of specific i= nterest. Good luck if > 1 of these TXT records have similar RDATA but ar= e meant for use by different things. Though perhaps that's just a conce= rn for dnsop or developers rather than this WG.

Frankly, it's beyond stupid to overload TXT records now a unique RRtype= code is simple to get (ha!) or some prefix convention could be applied: li= ke adding _spf (say) to the QNAME so a big bunch of TXT records don't a= ll have to sit at the same node in the tree.

_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext



--
Website: http://hallambaker.com/
--f46d04428d92026ade04dbced82f-- From envite@rolamasao.org Fri May 3 06:09:18 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989DF21F8EC2 for ; Fri, 3 May 2013 06:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.437 X-Spam-Level: * X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_STATIC=1.172, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+m2e9Gx747B for ; Fri, 3 May 2013 06:09:14 -0700 (PDT) Received: from rolamasao.org (68.167.216.87.static.jazztel.es [87.216.167.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7DE21F87D0 for ; Fri, 3 May 2013 06:09:13 -0700 (PDT) Received: from tochox.localnet (localhost [IPv6:::1]) by rolamasao.org (Postfix_t) with ESMTPSA id ED98111EDA for ; Fri, 3 May 2013 14:09:11 +0100 (WEST) From: Noel David Torres =?iso-8859-1?q?Ta=F1o?= To: dnsext@ietf.org Date: Fri, 3 May 2013 14:09:05 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) References: <201304250029.57132.envite@rolamasao.org> <201305011759.29280.envite@rolamasao.org> <116AB7C6-10BE-43C7-AC76-86498A3FAEDA@rfc1035.com> In-Reply-To: <116AB7C6-10BE-43C7-AC76-86498A3FAEDA@rfc1035.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1697750.1POzeJua8T"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201305031409.06978.envite@rolamasao.org> Subject: Re: [dnsext] Draft for OID X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:09:18 -0000 --nextPart1697750.1POzeJua8T Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > On 1 May 2013, at 17:59, Noel David Torres Ta=F1o = =20 wrote: > > No comments? I can really not trust I've written such a perfect document > > that nobody objects to it. >=20 > I don't object to the document. I just don't see what problem it solves or > why/how it's needed. I think it needs a great deal of work, perhaps far, > far more than you appreciate. Sorry. I know it is very far beyond being a candidate to RFC, but I thought that t= he=20 best way to get interesting comments on its deficiences whould be this WG. = I=20 thought I may be plain wrong, but I'll never know unless trying. >=20 > The principle of putting OIDs into the DNS is sound. Any hierarchical > naming or numbering scheme is an obvious fit with the DNS. Thanks >=20 > But beyond that your draft lacks vast amounts of important detail. For > example, what's the justification for using a new class? Who is going to My intention i creating a new Class is in that the current IN Class maps a= =20 tree into a linear space, and do an ugly hack in the back mapping (PTR reco= rds=20 and the in-addr.arpa pseudo-TLD), while this OID mapping would be for mappi= ng=20 a real tree-like structure in a unique way into another tree-like structure= ,=20 back and forth. No ugly hack :D > provide and operate the DNS infrastructure for that: name servers, > registry, etc? Which entities are responsible for managing this new name Each RA for a OID would be responsible for its own nameserver, pretty much= =20 like in the IN class. There is no central registry for OID as there are onl= y=20 three TLDs, each one acting as a RA and delegating under its own arc. A sta= rt=20 point may be IANA running its own nameserver for 1.3.6.1 . > space? What roles do they have and how do they interact with each other? Responsibility for managing is actually assigned as responsibility for=20 managing OID themselves. This is not a new namespace, only a new machine-re= ady=20 way of accessing it. > Have you asked them -- ISO, ITU-T, National Standards Institutes, vendors, > current users of OIDs, etc -- and what did they say? [cf The handshakes > between all the actors in the management of e164.arpa.] Who manages the No, I have not asked them. I would not like going to them woithout a workin= g=20 implementation and a semi-usable specification at least. > registries which map names to numbers for (parts of) the OID labels? How Each RA manages under its own arc. > does an ISO-flavour OID -- which is delimited by spaces IIUC -- get mapped > into a domain name? The purpose and meaning of the proposed RRtypes are This is only a presentation way. Dot notation is another one. This means,=20 {joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3)=20 nistAlgorithm(4) hashAlgs(2)}, which is the OID for SHA2, can be directly=20 mapped without any register to joint-iso-itu- t.country.us.organization.gov.csor.nistAlgorithm.hashAlgs or to=20 2.16.840.1.101.3.4.2 but if you have the latter, you'll have a hard time=20 finding out what is it referring to. > unclear too. Who defines these types and manages the registry for them? IETF (that is, we) should define them, and IANA manage the register, like f= or=20 IN class. > Why does your draft propose/need a new root? Why not put all OIDs under > oid.arpa (say) and just stick with the IN class, like pretty much > everything else on the Internet? What does this EQUIV RRtype do that CNAME I thougt it is better to have a new root matching that of the OID tree than= =20 faking one under the already cluttered IN tree. > or DNAME can't? What are resolvers expected to do and not do when they In my view, EQUIV is mainly the same as CNAME is for IN, but CNAME means "T= he=20 canonical name of the resource your are looking for is X, go search there" = and=20 is not easy to view it in the reverse mapping, while EQUIV for OID means "T= he=20 resource you are looking for is equivalent, both in alphanumerical and in=20 numerical form, to X, go search there". For the machine it is the same (go= =20 search X), but the meaning is not. > encounter this EQUIV record? Are IN class RRtypes valid or not in this new Resolvers are expected to cache if they are caching resolvers, and go searc= h=20 X. > name space? How is delegation done and how do resolvers traverse your new They are not. > name space? Your draft has a couple of sentences on an NS RRtype but Resolvers should be seeded with the root nameservers like in IN class. Ther= e=20 are 13 for IN class which every resolver is well aware of, and there should= be=20 a similar setup for OID class (maybe same servers, maybe not, maybe some of= =20 them volunteer and others do not). Beyond that, like in IN class the root=20 servers only manage TLDs which are then delegated and managed individually = by=20 each country central Registrar, in OID the three (and there are only three)= =20 TLDs would be managed (if they want) by ISO and ITU-T. But, even if they do= =20 not want to, this setup can be used inside an organization like a library o= r=20 an emergencies body which has its own OID assigned and manages it=20 independently. For example, World Meteorological Organization may use 2.49.= 0=20 even if ISO and ITU-T does not provide any DNS resource for 2.49, just=20 providing that WMO computers use a nameserver that is aware on its own abou= t=20 2.49.0 (BTW, 2.49.0 is the OID used for weather alerts and weather alerting= =20 agencies). > nothing on how these name servers are located or how their IP addresses > (presumably) are presented in this OID class. The idea is that nameservers are managed like for the IN class but they may= be=20 separated machines. The NS register indicates which nameservers are availab= le=20 for an OID arc. Like in current practice, inside the organizations these=20 nameservers do not need to be appointed by any higher level, but just be aw= are=20 of local names/oids. >=20 > These are all rhetorical questions BTW. There's no need to answer them he= re > and now but they really have to be addressed somehow in a future version > of your document or set of documents. Not rethorical, they help me think twice as well! >=20 > There's the seed of a nice idea here but it needs an awful lot of hard wo= rk > and attention to detail. I volunteer for the hard work (didn't I?) but I need your expertise for the= =20 attention to detail. Thanks Noel er Envite =2D------------------------ A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? --nextPart1697750.1POzeJua8T Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlGDtvIACgkQcLQA8+7Hw3I0NwCeODbcVKVZI5M/2zXdyYpTcYTl TfUAmwab5A8qOfDJARaa0uQJ8FAEs3I2 =YJxk -----END PGP SIGNATURE----- --nextPart1697750.1POzeJua8T-- From nweaver@icsi.berkeley.edu Fri May 3 06:18:26 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9629E21F962B for ; Fri, 3 May 2013 06:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wABnQI3UlM8Q for ; Fri, 3 May 2013 06:18:20 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id A4D3121F9634 for ; Fri, 3 May 2013 06:18:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 543E92C4007; Fri, 3 May 2013 06:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tWav21GmjDds; Fri, 3 May 2013 06:18:20 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 022732C4002; Fri, 3 May 2013 06:18:20 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Nicholas Weaver In-Reply-To: Date: Fri, 3 May 2013 06:18:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1503) Cc: Edward Lewis , "dnsext@ietf.org" Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:18:26 -0000 On May 3, 2013, at 4:42 AM, Phillip Hallam-Baker = wrote: > It is not just stupid to further overload TXT, it is impossible. >=20 > The SPF group knew when they were doing the draft that they were = essentially making any other use of the TXT record infeasible in the = future. Or at least I pointed that out. No its not, its trivial to further overload the text record. All you = have to do is make sure YOUR strings don't start with the same magic = string, and/or are located in a different convention in the DNS = hierarchy, as SPF records. And given the silly resistance amongst some in this group to tolerate = allocating new RR types (look at the debate over the entirely sensible = EUI48 and EUI64 RTYPEs), and the annoyance of getting authority software = to allow one to provision new RTYPEs in an easily readable form [1], it = makes perfect sense for developers who want to shove something into DNS = to skip the whole IETF crap, create a convention, and shove things = either in A-records (like the RBLs have done) or TXT records. [1] Yes, you can specify it as: > The special token \# (a backslash immediately followed by a hash > sign), which identifies the RDATA as having the generic encoding > defined herein rather than a traditional type-specific encoding. >=20 > An unsigned decimal integer specifying the RDATA length in = octets. >=20 > Zero or more words of hexadecimal data encoding the actual RDATA > field, each containing an even number of hexadecimal digits. But lets face it, thats a PITA compared to going "MYTYPE: this is my = record" as one string in a TXT record. From envite@rolamasao.org Fri May 3 06:24:17 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D74121F89C3 for ; Fri, 3 May 2013 06:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.237 X-Spam-Level: * X-Spam-Status: No, score=1.237 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_STATIC=1.172, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL5VACu+YAm0 for ; Fri, 3 May 2013 06:24:12 -0700 (PDT) Received: from rolamasao.org (68.167.216.87.static.jazztel.es [87.216.167.68]) by ietfa.amsl.com (Postfix) with ESMTP id D0FE521F8681 for ; Fri, 3 May 2013 06:24:11 -0700 (PDT) Received: from tochox.localnet (localhost [IPv6:::1]) by rolamasao.org (Postfix_t) with ESMTPSA id DAE6B11EDA for ; Fri, 3 May 2013 14:24:10 +0100 (WEST) From: Noel David Torres =?iso-8859-1?q?Ta=F1o?= To: dnsext@ietf.org Date: Fri, 3 May 2013 14:24:06 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) References: <201304250029.57132.envite@rolamasao.org> <201305011759.29280.envite@rolamasao.org> <6593BCE4-ECF6-450B-9364-62B662EF7BA6@vpnc.org> In-Reply-To: <6593BCE4-ECF6-450B-9364-62B662EF7BA6@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2207427.RvDCxVsfut"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201305031424.07067.envite@rolamasao.org> Subject: Re: [dnsext] Draft for OID X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:24:18 -0000 --nextPart2207427.RvDCxVsfut Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mi=E9rcoles, 1 de mayo de 2013 20:32:34 Paul Hoffman wrote: > On May 1, 2013, at 9:59 AM, Noel David Torres Ta=F1o =20 wrote: > > No comments? I can really not trust I've written such a perfect document > > that nobody objects to it. >=20 > I can only speak for myself about why I didn't comment. You never answered > the earlier question about why this is needed. A much, much lighter-weight > solution is to simply set up something in the current IN class under a > name like "all-oids.org". Why expect the world to make a heavy-weight > change to the DNS protocol for some use case that you don't even state? >=20 > --Paul Hoffman In fact, the world at large does not need to change nothing. Only machines= =20 which (in some way) need to deal with OIDs in this way would need a resolve= r=20 or nameserver OID-aware. =46or the question about why is needed, well, why Internet itself is needed= ?=20 This is just a convenience that may help. About why a new class, I have jus= t=20 answered that in my answer to Jim Reid. Regards Noel er Envite =2D------------------------ A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? --nextPart2207427.RvDCxVsfut Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlGDuncACgkQcLQA8+7Hw3LCoACdHGe8tH45a3Y1FNvSBnfdtaM8 KgIAnjxB20znRhpSgTkYO7vQ9+pAaQ3w =wzlP -----END PGP SIGNATURE----- --nextPart2207427.RvDCxVsfut-- From marka@isc.org Fri May 3 06:54:45 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDFA21F8766 for ; Fri, 3 May 2013 06:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFZsB5ACc1UQ for ; Fri, 3 May 2013 06:54:45 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 238A921F890F for ; Fri, 3 May 2013 06:54:38 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B647CC9423; Fri, 3 May 2013 13:54:29 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367589277; bh=QPRJaB15tUHibocjapbS7nkcj6xQYpyhhluoeQDkdjs=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=p8TKoGCiNpr5fGYLmDpZKbXqYdYt5mxKXlgokOEVuLgeQkGvVP0x1tUPUDSbnkPqD 9BULfPtynUWEsY3YylVhls8WeNWD+y1PJIZkn+wwCCKZwhWJP4endI47pBDi+2k+mI /x8NQnEZWHi4l3VC+NImhPv9++K9rd09+aFarQt4= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Fri, 3 May 2013 13:54:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:69de:6e05:3984:4407]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2C82F216C40; Fri, 3 May 2013 13:54:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5C8E733E2780; Fri, 3 May 2013 23:53:09 +1000 (EST) To: Nicholas Weaver From: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> In-reply-to: Your message of "Fri, 03 May 2013 06:18:19 -0700." Date: Fri, 03 May 2013 23:53:08 +1000 Message-Id: <20130503135309.5C8E733E2780@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Edward Lewis , "dnsext@ietf.org" Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:54:46 -0000 In message , Nicholas Weaver writes: > > On May 3, 2013, at 4:42 AM, Phillip Hallam-Baker wrote: > > > It is not just stupid to further overload TXT, it is impossible. > > > > The SPF group knew when they were doing the draft that they were essentially making any other use of the > > TXT record infeasible in the future. Or at least I pointed that out. > > No its not, its trivial to further overload the text record. All you have to do is make sure YOUR strings > don't start with the same magic string, and/or are located in a different convention in the DNS hierarchy, > as SPF records. As well as whatever anyone else is doing with TXT records. > And given the silly resistance amongst some in this group to tolerate allocating new RR types (look at the > debate over the entirely sensible EUI48 and EUI64 RTYPEs), and the annoyance of getting authority software > to allow one to provision new RTYPEs in an easily readable form [1], Yet there was code shipped that supported EUI48 and EUI64 before the first word of complaint was raised. > it makes perfect sense for developers > who want to shove something into DNS to skip the whole IETF crap, create a convention, and shove things eit > her in A-records (like the RBLs have done) or TXT records. > > [1] Yes, you can specify it as: > > > The special token \# (a backslash immediately followed by a hash > > sign), which identifies the RDATA as having the generic encoding > > defined herein rather than a traditional type-specific encoding. > > > > An unsigned decimal integer specifying the RDATA length in octets. > > > > Zero or more words of hexadecimal data encoding the actual RDATA > > field, each containing an even number of hexadecimal digits. > > But lets face it, thats a PITA compared to going "MYTYPE: this is my record" as one string in a TXT record. Or you could write a tool that uses the existing resolver libraries to dynamically load the records. You don't have to wait for nameserver developer to update nameservers or registrars to update web forms to use new types. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From hallam@gmail.com Fri May 3 06:58:09 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E8E21F8766 for ; Fri, 3 May 2013 06:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2EjYhXX4pHS for ; Fri, 3 May 2013 06:58:08 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3E64B21F965E for ; Fri, 3 May 2013 06:57:59 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so1576265wgg.8 for ; Fri, 03 May 2013 06:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:cc:content-type; bh=Itf56pyWW8S1PKADPXg+1rMkRlPLoWqrVnaRC3NFNGI=; b=SE1NrYM4nlZCHdzpijQlw0KR2sEnd7NzDVN+GZI/BqkEAx4rpC7+/mKI+UXJiAOHcC +qtTesNq9Anf/w1s9lFh2eFqm3LAOhAtR9corXRZ2nDuIAdaziEaFbh55PW/DC0ao4Rr FFjgEbhxWuSvkvlaJn6irVP08Diim4+ksCoP5iO5yaYsP/4LlKKlfbirTKAUQ3iTvdtS i0ZhnCoAUkJASXsFR/KRYAMDrl4C5FxlJsnthXq7fVqrZMD+1Q9+bukPU4d2gJPuTy85 LrK2J8fg+pjXUWheFlkscsYo3/JZGohfs0kY13ht8p1LGf2WXr7Lc8YvZP9EOF/V2rk8 1f7w== MIME-Version: 1.0 X-Received: by 10.194.62.174 with SMTP id z14mr14116661wjr.20.1367589473284; Fri, 03 May 2013 06:57:53 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Fri, 3 May 2013 06:57:53 -0700 (PDT) In-Reply-To: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> Date: Fri, 3 May 2013 09:57:53 -0400 Message-ID: From: Phillip Hallam-Baker Cc: "dnsext@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86d6d8c1007304dbd0bcd8 Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:58:10 -0000 --047d7b86d6d8c1007304dbd0bcd8 Content-Type: text/plain; charset=ISO-8859-1 DNS has an effective hard limit on the total size of all the records in a RR set of 500 bytes. It is theoretically possible to go over that limit but bad things start to happen and TCP fallback does not work any more reliably than new RR types do. SPF was already a deployed standard before the WG started. The IETF wrote the specification after it was too late to change. Now what could make the whole process a lot easier would be to allocate a band of DNS RR codes for records that would all have TXT syntax. That would allow BIND etc. to make one change to support the new syntax. Alternatively we could extend the handling of unknown RR syntax so that there was a string presentation option. For example, imagine that all RRs from 1024 to 2048 are defined to be TXT syntax. Anyone wanting any other syntax has to use a different RR code. So a record would be: example.com TXT1024 "Some stuff here" example.com TXT1025 "A different project" There would still be a need for prefixing but in general a DNS record should be always prefixed or never prefixed. On Fri, May 3, 2013 at 9:18 AM, Nicholas Weaver wrote: > > On May 3, 2013, at 4:42 AM, Phillip Hallam-Baker wrote: > > > It is not just stupid to further overload TXT, it is impossible. > > > > The SPF group knew when they were doing the draft that they were > essentially making any other use of the TXT record infeasible in the > future. Or at least I pointed that out. > > No its not, its trivial to further overload the text record. All you have > to do is make sure YOUR strings don't start with the same magic string, > and/or are located in a different convention in the DNS hierarchy, as SPF > records. > > And given the silly resistance amongst some in this group to tolerate > allocating new RR types (look at the debate over the entirely sensible > EUI48 and EUI64 RTYPEs), and the annoyance of getting authority software to > allow one to provision new RTYPEs in an easily readable form [1], it makes > perfect sense for developers who want to shove something into DNS to skip > the whole IETF crap, create a convention, and shove things either in > A-records (like the RBLs have done) or TXT records. > > > > [1] Yes, you can specify it as: > > > The special token \# (a backslash immediately followed by a hash > > sign), which identifies the RDATA as having the generic encoding > > defined herein rather than a traditional type-specific encoding. > > > > An unsigned decimal integer specifying the RDATA length in octets. > > > > Zero or more words of hexadecimal data encoding the actual RDATA > > field, each containing an even number of hexadecimal digits. > > But lets face it, thats a PITA compared to going "MYTYPE: this is my > record" as one string in a TXT record. > > -- Website: http://hallambaker.com/ --047d7b86d6d8c1007304dbd0bcd8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
DNS has an effective hard limit on the total size of all t= he records in a RR set of 500 bytes. It is theoretically possible to go ove= r that limit but bad things start to happen and TCP fallback does not work = any more reliably than new RR types do.

SPF was already a deployed standard before the WG star= ted. The IETF wrote the specification after it was too late to change.


Now what could make t= he whole process a lot easier would be to allocate a band of DNS RR codes f= or records that would all have TXT syntax. That would allow BIND etc. to ma= ke one change to support the new syntax. Alternatively we could extend the = handling of unknown RR syntax so that there was a string presentation optio= n.

For example, imagine that all RRs from 1024= to 2048 are defined to be TXT syntax. Anyone wanting any other syntax has = to use a different RR code. So a record would be:

example.com TXT1024 "Som= e stuff here"
example.c= om TXT1025 "A different project"

There would still be a need for prefixing but in general a DNS record shoul= d be always prefixed or never prefixed.



On Fri, May 3, 2= 013 at 9:18 AM, Nicholas Weaver <nweaver@icsi.berkeley.edu>= wrote:

On May 3, 2013, at 4:42 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:

> It is not just stupid to further overload TXT, it is impossible.
>
> The SPF group knew when they were doing the draft that they were essen= tially making any other use of the TXT record infeasible in the future. Or = at least I pointed that out.

No its not, its trivial to further overload the text record. =A0All y= ou have to do is make sure YOUR strings don't start with the same magic= string, and/or are located in a different convention in the DNS hierarchy,= as SPF records.

And given the silly resistance amongst some in this group to tolerate alloc= ating new RR types (look at the debate over the entirely sensible EUI48 and= EUI64 RTYPEs), and the annoyance of getting authority software to allow on= e to provision new RTYPEs in an easily readable form [1], it makes perfect = sense for developers who want to shove something into DNS to skip the whole= IETF crap, create a convention, and shove things either in A-records (like= the RBLs have done) or TXT records.



[1] Yes, you can specify it as:

> =A0 =A0 =A0 The special token \# (a backslash immediately followed by = a hash
> =A0 =A0 =A0 sign), which identifies the RDATA as having the generic en= coding
> =A0 =A0 =A0 defined herein rather than a traditional type-specific enc= oding.
>
> =A0 =A0 =A0 An unsigned decimal integer specifying the RDATA length in= octets.
>
> =A0 =A0 =A0 Zero or more words of hexadecimal data encoding the actual= RDATA
> =A0 =A0 =A0 field, each containing an even number of hexadecimal digit= s.

But lets face it, thats a PITA compared to going "MYTYPE: this is my r= ecord" as one string in a TXT record.




--
Website: http://hallambaker.com/
--047d7b86d6d8c1007304dbd0bcd8-- From Ted.Lemon@nominum.com Fri May 3 07:03:41 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC62021F9625 for ; Fri, 3 May 2013 07:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30L66nNf4+6q for ; Fri, 3 May 2013 07:03:32 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 0815821F962D for ; Fri, 3 May 2013 07:03:31 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUYPDs+JL7IavZa3OXN0tUrs3tJY8fQdK@postini.com; Fri, 03 May 2013 07:03:32 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6F6E81B80F4 for ; Fri, 3 May 2013 07:03:31 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 66994190061; Fri, 3 May 2013 07:03:31 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 3 May 2013 07:03:26 -0700 From: Ted Lemon To: Phillip Hallam-Baker Thread-Topic: [dnsext] loads of TXT records for fun and profit Thread-Index: AQHOROzyhfjGSq7i9UmyqVzThMYc8Jjz0ggAgAAa0oCAAAsOgIAAAYuA Date: Fri, 3 May 2013 14:03:26 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B63077516EA82mbx01winnominum_" MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 14:03:41 -0000 --_000_8D23D4052ABE7A4490E77B1A012B63077516EA82mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On May 3, 2013, at 9:57 AM, Phillip Hallam-Baker > wrote: Now what could make the whole process a lot easier would be to allocate a b= and of DNS RR codes for records that would all have TXT syntax. That would = allow BIND etc. to make one change to support the new syntax. Alternatively= we could extend the handling of unknown RR syntax so that there was a stri= ng presentation option. I see some benefit in that if in fact TXT is the right format for storing t= he things that would get stored in these records. However, the point has = been made with respect to SPF that it would have been better had it not bee= n just a text record. I don't know whether this argument is correct or no= t, but if it is correct, making it easy to put in TXT records and hard to p= ut in anything else is probably going to make things worse, not better. --_000_8D23D4052ABE7A4490E77B1A012B63077516EA82mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2D0DF0A402C4BB4E8DFE3BEFB4AD21A3@nominum.com> Content-Transfer-Encoding: quoted-printable
On May 3, 2013, at 9:57 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
Now what could make the whole process a lot easier would be to allocate a band= of DNS RR codes for records that would all have TXT syntax. That would all= ow BIND etc. to make one change to support the new syntax. Alternatively we= could extend the handling of unknown RR syntax so that there was a string presentation option.

I see some benefit in that if in fact TXT is the right format for stor= ing the things that would get stored in these records.   However, the = point has been made with respect to SPF that it would have been better had = it not been just a text record.   I don't know whether this argument is correct or not, but if it is correct, making= it easy to put in TXT records and hard to put in anything else is probably= going to make things worse, not better.

--_000_8D23D4052ABE7A4490E77B1A012B63077516EA82mbx01winnominum_-- From hallam@gmail.com Fri May 3 07:22:52 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2854121F87E0 for ; Fri, 3 May 2013 07:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlQq47MgSW9H for ; Fri, 3 May 2013 07:22:51 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E0AB721F919D for ; Fri, 3 May 2013 07:22:50 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id t11so1317761wey.23 for ; Fri, 03 May 2013 07:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DMnJ2WDk6M7eS5IokmcjWpCbX59vw16/ZZBUTB+DYC4=; b=iJVo6XjKZNIGWIXV7Rrykf7p1nVy5kF8tehkn2H5QxsThaepvkGVI7fwHa1EPsW4Xs i0cipnuLY4ufwgcCeMgRgbypW04FTn7IsFo2ELkbIE+xJwMxD1z6LVf0uqQONC23K91s tOjGqOJtdU8ut/g+dmokUlci8cg2wA3SikgG/qZk7c0Im6JfRJt13+qs1nzpc68nsmDE 2sAPcYHqMUMxWwyqWM72aSpZt7hGognzETooTmW69S/GrqvPMHE4QRhbYlbEiuj17gTt 8QnnGhfdY1g5Flh8z6XgpkkJ1ofiS6UzCGySqXd2YAZypjrx8OFlUUr+UF7THkdSB9h1 njig== MIME-Version: 1.0 X-Received: by 10.194.62.174 with SMTP id z14mr14271189wjr.20.1367590970018; Fri, 03 May 2013 07:22:50 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Fri, 3 May 2013 07:22:49 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> Date: Fri, 3 May 2013 10:22:49 -0400 Message-ID: From: Phillip Hallam-Baker To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b86d6d8f751ad04dbd115ce Cc: "dnsext@ietf.org" Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 14:22:52 -0000 --047d7b86d6d8f751ad04dbd115ce Content-Type: text/plain; charset=ISO-8859-1 The syntax of the record is an editor war. There are arguments to be made in favor of a compact representation but the IETF has traditionally favored verbose text headers over compact representations for anything above the application layer. If the WG wants to influence design choices then they have to provide an infrastructure that supports the requirements that the applications area people assert. Instead the interaction with this group has been that apps area people say that they need X and this group tells them that they are wrong. And that is not a productive way to go forward. What it really comes down to is what the DNS server maintainers are willing to support. Adding new RR types to my code is easy as I generate all the code for parsing/emitting the RR data. The same is not true for BIND and the other servers. But for most applications, packing/unpacking binary DNS records really does not help at all unless there is 1024-2048 bits worth of opaque binary data involved. Which means that the only records for which binary format really makes a difference tend to be records that involve PKI in some way. On Fri, May 3, 2013 at 10:03 AM, Ted Lemon wrote: > On May 3, 2013, at 9:57 AM, Phillip Hallam-Baker > wrote: > > Now what could make the whole process a lot easier would be to allocate a > band of DNS RR codes for records that would all have TXT syntax. That would > allow BIND etc. to make one change to support the new syntax. Alternatively > we could extend the handling of unknown RR syntax so that there was a > string presentation option. > > > I see some benefit in that if in fact TXT is the right format for storing > the things that would get stored in these records. However, the point has > been made with respect to SPF that it would have been better had it not > been just a text record. I don't know whether this argument is correct or > not, but if it is correct, making it easy to put in TXT records and hard to > put in anything else is probably going to make things worse, not better. > > -- Website: http://hallambaker.com/ --047d7b86d6d8f751ad04dbd115ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The syntax of the record is an editor war.

<= div style>There are arguments to be made in favor of a compact representati= on but the IETF has traditionally favored verbose text headers over compact= representations for anything above the application layer.

If the WG wants to influence design choices= then they have to provide an infrastructure that supports the requirements= that the applications area people assert. Instead the interaction with thi= s group has been that apps area people say that they need X and this group = tells them that they are wrong. And that is not a productive way to go forw= ard.

What it really comes down to is what the DN= S server maintainers are willing to support. Adding new RR types to my code= is easy as I generate all the code for parsing/emitting the RR data. The s= ame is not true for BIND and the other servers.


But for most applicati= ons, packing/unpacking binary DNS records really does not help at all unles= s there is 1024-2048 bits worth of opaque binary data involved. Which means= that the only records for which binary format really makes a difference te= nd to be records that involve PKI in some way.



On Fri, May 3, 2013 at 10:03 AM, Ted Lemon = <Ted.Lemon@no= minum.com> wrote:
On May 3, 2013, at 9:57 AM, Phillip Hallam-Baker <hallam@gmail.com>=A0wrote:
Now what could make the whole process a lot easier would be to allocate a band= of DNS RR codes for records that would all have TXT syntax. That would all= ow BIND etc. to make one change to support the new syntax. Alternatively we= could extend the handling of unknown RR syntax so that there was a string presentation option.

I see some benefit in that if in fact TXT is the right format for stor= ing the things that would get stored in these records. =A0 However, the poi= nt has been made with respect to SPF that it would have been better had it = not been just a text record. =A0 I don't know whether this argument is correct or not, but if it is correct, making= it easy to put in TXT records and hard to put in anything else is probably= going to make things worse, not better.




--
Website: http://hallambaker.com/
--047d7b86d6d8f751ad04dbd115ce-- From hallam@gmail.com Fri May 3 07:44:28 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5AE21F8766 for ; Fri, 3 May 2013 07:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb7YWj-rinsS for ; Fri, 3 May 2013 07:44:27 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6CD21F86E4 for ; Fri, 3 May 2013 07:44:27 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id j13so1638657wgh.4 for ; Fri, 03 May 2013 07:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=4vcJ40CkZSC+GkS9ryUTUCHp4pHiMBlpHx2mYsL8ako=; b=jcRJMsF9HdlnXWZ+PXKq4OTWrf6R4bXYwjo8zWhp2s0pslsdysNyQHmeWH9fCXPnmn AouXTiLIL5Wot+lDQXZQ8djdARVTewKiYi+5X07kqJEgTKNV4ys7/iG05J67D2H+T7qk qMdg6blh819XFqQ4RShbrLur5J8Utk0cyCFNKtHfTFleSwo9v7t20q5C3M0IwaHlO9ue he2u858lzCoNjd4IKHbcQUc6oBAkUDZHKqkdSDVsXvVEjDUJVJB9qXxGDoPEPpeXCi+i LBQcPU0Xw/90EVO+6Voe8PMYBP4CvHwlsgpMtjQfagDxtVZJQQ2YeTfPr8NI7ZTo2NLZ mW7A== MIME-Version: 1.0 X-Received: by 10.180.188.198 with SMTP id gc6mr13712340wic.14.1367592263942; Fri, 03 May 2013 07:44:23 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Fri, 3 May 2013 07:44:23 -0700 (PDT) Date: Fri, 3 May 2013 10:44:23 -0400 Message-ID: From: Phillip Hallam-Baker To: "dnsext@ietf.org" Content-Type: multipart/alternative; boundary=001a11c389a4170a1304dbd163ad Subject: [dnsext] Code generator for DNS RR parsing/emitting X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 14:44:28 -0000 --001a11c389a4170a1304dbd163ad Content-Type: text/plain; charset=ISO-8859-1 Folk may be interested in the following Open Source project: https://sourceforge.net/projects/omnidiscovery/ The code is not 100% complete but it does support many of the most commonly used DNS RRs right now. The synthesizer generates code to parse/emit DNS RRs from an abstract description file. Here are the first three entries: RR A 1 "Host address" "RFC1035" IPv4 Address RR NS 2 "Authoritative name server" "RFC1035" Domain NSDNAME RR MD 3 "Mail destination" "RFC1035" Domain MADNAME Obsolete [100+ other RR definitions omitted] This abstract description is then used to produce an API to allow applications to handle the RRs in any language someone cares to write a back end for. The synthesizer is implemented in Goedel which is an open source synthesizer for writing synthesizers. At present the only output language supported is C#. The reason I am doing C# is that there isn't a good library for DNS API support out there right now and that is the language I prefer to work in. Generating C, Objective C or Java would be fairly straightforward. I don't plan to support anything beyond posibly doing C. The code has been tested on Windows, OSX and Linux (under Mono). It works the same on all platforms to the extent that it works. Writing support for DNS RR types is pretty much a template filling operation. If someone wanted to they could use Goedel to fill in the templates that BIND has in its code. As you will see above, the obsolete MD RR has a description but it is marked as obsolete. This allows the code generator to be used to generate a 'fat' API for use implementing a tool like digg and a thin API that only supports the exact calls required for some embedded device. The synth could even be used to generate a HTML or Windows Forms interface for managing DNS RRs. Working this way does not actually save a lot of time on a project like this but it does improve accuracy a great deal and thus reduces maintenance. Using the synth effectively reduces the number of code paths at issue. So if you can get the code to work at all and pass a modest number of test cases it is very likely correct. Adding extra RR types takes 5 mins. -- Website: http://hallambaker.com/ --001a11c389a4170a1304dbd163ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Folk may be interested in the following Open So= urce project:

https://sourceforge.net/projects/omnidiscovery/
=
The code is not 100% complete but it does support many of = the most commonly used DNS RRs right now.


The synthesizer generates code to parse/emit DNS R= Rs from an abstract description file. Here are the first three entries: 

RR	A			1		"Host address"	"RFC1035"
	IPv4			Address
=09
RR	NS			2		"Authoritative name server" "RFC1035"
	Domain			NSDNAME
	=09
RR	MD			3		"Mail destination" "RFC1035"
	Domain			MADNAME
	Obsolete
[100+ other RR definitions omitted]
This abstract des= cription is then used to produce an API to allow applications to handle the= RRs in any language someone cares to write a back end for. The synthesizer= is implemented in Goedel which is an open source synthesizer for writing s= ynthesizers.

At present the only output language support= ed is C#. The reason I am doing C# is that there isn't a good library f= or DNS API support out there right now and that is the language I prefer to= work in. Generating C, Objective C or Java would be fairly straightforward= . I don't plan to support anything beyond posibly doing C.

The code has been tested on Windows, OSX an= d Linux (under Mono). It works the same on all platforms to the extent that= it works.


Writin= g support for DNS RR types is pretty much a template filling operation. If = someone wanted to they could use Goedel to fill in the templates that BIND = has in its code.

As you will see above, the obsolete MD RR h= as a description but it is marked as obsolete. This allows the code generat= or to be used to generate a 'fat' API for use implementing a tool l= ike digg and a thin API that only supports the exact calls required for som= e embedded device.

The synth could even be used to generate a = HTML or Windows Forms interface for managing DNS RRs.


Working this way does not actually save = a lot of time on a project like this but it does improve accuracy a great d= eal and thus reduces maintenance. Using the synth effectively reduces the n= umber of code paths at issue. So if you can get the code to work at all and= pass a modest number of test cases it is very likely correct.

Adding extra RR types takes 5 mins.

--
Website: http://hal= lambaker.com/
--001a11c389a4170a1304dbd163ad-- From hallam@gmail.com Fri May 3 08:50:13 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBDC21F97C1 for ; Fri, 3 May 2013 08:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a02fxo36tFFf for ; Fri, 3 May 2013 08:50:11 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4AE21F8763 for ; Fri, 3 May 2013 08:06:07 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id z2so1384921wey.5 for ; Fri, 03 May 2013 08:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wKV4OUN1DxRJvajtVStXaG4HYoe7u9T/Qljt2PyYQAk=; b=uiZ82gge+5YuoPlDwLVpEdAfR9CM18KoPVibogjAabmvFwDB+YSJufvHugVoJAMra9 NUVbeK2h6tjruezRpa4GlGgIXcewu60yn8DOaC3IhhJGo3unQvhNTInL9nabKK9lKZNy FV9knZfRBFuegftIXARxEN6c50eKOBuhoNgyqWyZfcP0rvy5g+cgk2/al4jfiGT733ni toW/4xGtElHYtiY1CnKG7dLNS9VaguIXkYTHCajs/xhT9Y+uauKymsL/TC0g/UobDS2W yWMFpw5rW3dQl2YI+WdWhge5tKgz4gxKoCupQan6wSIiBlwPyA65SBcgo1hokggvFwtW tGAg== MIME-Version: 1.0 X-Received: by 10.194.62.174 with SMTP id z14mr14521196wjr.20.1367593560965; Fri, 03 May 2013 08:06:00 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Fri, 3 May 2013 08:06:00 -0700 (PDT) In-Reply-To: <6593BCE4-ECF6-450B-9364-62B662EF7BA6@vpnc.org> References: <201304250029.57132.envite@rolamasao.org> <201305011759.29280.envite@rolamasao.org> <6593BCE4-ECF6-450B-9364-62B662EF7BA6@vpnc.org> Date: Fri, 3 May 2013 11:06:00 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b86d6d8660a9f04dbd1b06a Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Draft for OID X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 15:50:14 -0000 --047d7b86d6d8660a9f04dbd1b06a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If it was going to be done at all. oids.arpa ?? Yes, I can see the reasons why not. And they are unfortunately the reasons that the idea is probably unsound. I think this proposal suffers from the authoritative registry bug. It is not possible to establish an authoritative registry for an existing namespace after the fact. Not unless there is a reason to believe that the community that uses the identifier will move to the new one. Experience with SRV shows that even that is difficult. IETF has even less claim to OIDs. Or at least the IETF should have less claim to OIDS. What the IETF could do is to tell IANA to set up and manage a registry that would map to a part of the DNS space which would in turn contain links to some source of authority (via DNS space) describing the purpose. So for example, I have an OID space for Default Deny Security Inc off the IETF arc. There might be some sort of DNS record like 1.2.3.4.5.oid.arpa OIDPTR defaultdenysecurity.com It would probably be more useful to have a URI that could point to a text document with some description. But what would be the use of such a scheme? OIDs are a useful idea but I can't think of any case where having a machine readable description of an OID would have a lot of value. there are some cases where having a link to a human readable description could be of use. It would be useful if the OID for a crypto algorithm linked to the specification, maybe. Probably the bast use would be to describe PKIX certificate policy OIDs. Normally this would be a pointless task since Harald's database is adequate. But what might change matters is the politics surrounding IETF and ITU-T. I didn't think we were there yet when we talked about this in Orlando, but I think that relationship is on the brink of collapse. I am reading ITU-T proposals relating to X.509 coming from the people's republic of Iran. Whatever the content of the proposal, the ITU-T model of nation state participation is simply not sustainable. I think they are going to push and push until the only answer the IETF can give is to sever all links and all dependencies on ITU-T standards. On Wed, May 1, 2013 at 3:32 PM, Paul Hoffman wrote: > On May 1, 2013, at 9:59 AM, Noel David Torres Ta=F1o > wrote: > > > No comments? I can really not trust I've written such a perfect documen= t > that > > nobody objects to it. > > I can only speak for myself about why I didn't comment. You never answere= d > the earlier question about why this is needed. A much, much lighter-weigh= t > solution is to simply set up something in the current IN class under a na= me > like "all-oids.org". Why expect the world to make a heavy-weight change > to the DNS protocol for some use case that you don't even state? > > --Paul Hoffman > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --=20 Website: http://hallambaker.com/ --047d7b86d6d8660a9f04dbd1b06a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If it was going to be done at all. oids.arpa ??

Yes, I can see the reasons why not. And they are unfortunate= ly the reasons that the idea is probably unsound.

I think this proposal suffers from the authoritative registry bug. It is no= t possible to establish an authoritative registry for an existing namespace= after the fact. Not unless there is a reason to believe that the community= that uses the identifier will move to the new one. Experience with SRV sho= ws that even that is difficult. IETF has even less claim to OIDs.


Or at least the IETF s= hould have less claim to OIDS. What the IETF could do is to tell IANA to se= t up and manage a registry that would map to a part of the DNS space which = would in turn contain links to some source of authority (via DNS space) des= cribing the purpose.

So for example, I have an OID space for Def= ault Deny Security Inc off the IETF arc. There might be some sort of DNS re= cord like

1.2.3.4.5.oid.arpa OIDPTR defaultdenysecurity.com

It would probably be more useful to have a = URI that could point to a text document with some description.


But what would be the use of = such a scheme? OIDs are a useful idea but I can't think of any case whe= re having a machine readable description of an OID would have a lot of valu= e.

there are some cases where having a link to= a human readable description could be of use. It would be useful if the OI= D for a crypto algorithm linked to the specification, maybe. Probably the b= ast use would be to describe PKIX certificate policy OIDs.


Normally this would be= a pointless task since Harald's database is adequate. But what might c= hange matters is the politics surrounding IETF and ITU-T. I didn't thin= k we were there yet when we talked about this in Orlando, but I think that = relationship is on the brink of collapse.

I am reading ITU-T proposals relating to X.= 509 coming from the people's republic of Iran. Whatever the content of = the proposal, the ITU-T model of nation state participation is simply not s= ustainable. I think they are going to push and push until the only answer t= he IETF can give is to sever all links and all dependencies on ITU-T standa= rds.



<= br>


On Wed, May 1, 2013 at 3:32 PM, Paul Hoffman <paul.hoffman@vpnc.org<= /a>> wrote:
On May 1, 2013, at 9:59 AM= , Noel David Torres Ta=F1o <envi= te@rolamasao.org> wrote:

> No comments? I can really not trust I've written such a perfect do= cument that
> nobody objects to it.

I can only speak for myself about why I didn't comment. You never= answered the earlier question about why this is needed. A much, much light= er-weight solution is to simply set up something in the current IN class un= der a name like "all= -oids.org". Why expect the world to make a heavy-weight change to = the DNS protocol for some use case that you don't even state?

--Paul Hoffman
_____________________= __________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext



--
= Website: http://hallambaker.com/
--047d7b86d6d8660a9f04dbd1b06a-- From paul.hoffman@vpnc.org Fri May 3 08:55:37 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F66221F84D6 for ; Fri, 3 May 2013 08:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1+XVFuKQkbG for ; Fri, 3 May 2013 08:55:34 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 91D6521F84B2 for ; Fri, 3 May 2013 08:09:52 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r43F9mmt094892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 3 May 2013 08:09:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Fri, 3 May 2013 08:09:49 -0700 Content-Transfer-Encoding: 7bit Message-Id: <03A31140-F56B-4B09-AC9F-139FA8F52B44@vpnc.org> References: <201304250029.57132.envite@rolamasao.org> <201305011759.29280.envite@rolamasao.org> <6593BCE4-ECF6-450B-9364-62B662EF7BA6@vpnc.org> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1503) Subject: Re: [dnsext] Draft for OID X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 15:55:37 -0000 On May 3, 2013, at 8:06 AM, Phillip Hallam-Baker wrote: > I think this proposal suffers from the authoritative registry bug. +1 --Paul Hoffman From jabley@hopcount.ca Fri May 3 09:42:50 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7BC21F86D8 for ; Fri, 3 May 2013 09:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjD2wRdwu0L5 for ; Fri, 3 May 2013 09:42:49 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3359321F88F3 for ; Fri, 3 May 2013 08:46:48 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id um15so963378pbc.9 for ; Fri, 03 May 2013 08:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=ta57WNujojFFYfNPfPXNeagIr9ZAyXs9Op9Gk5GGPVA=; b=NGKnPGrBJdoBAkHBRQYSkkgYzcV71c7NRaxFzclIHe7EdxKK1EBS5EkBnP8pQnKVbi eUmrd8qeeyP0O8DitaUJHpf3n4E7MhCk5E1GHnY63E1TWGySUULnDj6Qvt6wpxUy8lAf Bx96224bJs5YmtEgh+av/MCcnnG0gYdfuRTDs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ta57WNujojFFYfNPfPXNeagIr9ZAyXs9Op9Gk5GGPVA=; b=jnFdsAgUMKxJQaOwCfR+T1MZQIcn2JKJFkC2cNs08idoEs65Ko9gr5oujLyhQL5Rur IvsxYxaQCBQGLv25zBnnQzUiRP848J+2pHMYg54idvXN/99qCk9JIBTLDNC6+hZvYFel MiLJi1TJjR1Gtm310Hr/eJ6Y/VLRYJ4rQZALzh03fmjFNwUL9Lx75HHwHJUjReIlvtbp luy2s4j1CgcS6PjzvvyBYTYEbUWdGBn/h/ArusPHmOOrxrTzx/HT3A8RGJkrN16QOv5P vfNPa4a0q3ihbIZLTneBSRHWpVDsMtXX/iT/jfk9EPWigpmX3Pv8zWstvQU3yQQv7XWp k9Kg== X-Received: by 10.66.120.164 with SMTP id ld4mr15233534pab.187.1367595986078; Fri, 03 May 2013 08:46:26 -0700 (PDT) Received: from dh19.r1.hopcount.ca (dh19.r1.hopcount.ca. [199.212.90.19]) by mx.google.com with ESMTPSA id vv6sm13316378pab.6.2013.05.03.08.46.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 May 2013 08:46:25 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: Date: Fri, 3 May 2013 11:46:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnLfLRvNV5hhFvBlS7+4HRELXiYTA46qD5ABYxEDiJzB4dMZKnc1CnEmycg7kCN4CVpCjiT Cc: "dnsext@ietf.org" Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 16:42:50 -0000 On 2013-05-03, at 09:57, Phillip Hallam-Baker wrote: > DNS has an effective hard limit on the total size of all the records = in a RR set of 500 bytes. >=20 > It is theoretically possible to go over that limit but bad things = start to happen and TCP fallback does not work any more reliably than = new RR types do. I don't think we necessarily see widespread problems with large = responses. I realise that large responses are a reasonable concern, and there is = much scope for actual measurement to better characterise the landscape = with facts and science, but I don't think it's sensible to work from the = basis that the non-EDNS0-capable UDP-only DNS client sets an effective = hard limit. This is a very general comment with no science behind it, of course, so = it doesn't really say anything beyond "here be dragons, or maybe not, = who knows". > Now what could make the whole process a lot easier would be to = allocate a band of DNS RR codes for records that would all have TXT = syntax. That would allow BIND etc. to make one change to support the new = syntax. Alternatively we could extend the handling of unknown RR syntax = so that there was a string presentation option. Recent experience suggests it's possible to apply for a new RRType and = have code-points assigned in less than a week. It also seems possible (with only the effort involved in opening a = couple of trouble tickets to make the feature request) to get the = code-points implemented in multiple major authoritative servers in less = than three weeks. Most deployed DNS authority servers (I have no numbers, but given the = purported market share of BIND9 I'll say "most") follow RFC3597 and = hence are able to understand (for example) krill.hopcount.ca. 86400 IN TYPE108 \# 6 7c d1 c3 e8 10 2f even if they can't understand krill.hopcount.ca. 86400 IN EUI48 7c-d1-c3-e8-10-2f The fact that EUI48 has a conveniently-hexadecimal RDATA payload makes = this an over-simple example, but it's not that hard to convert RRs with = textual data into the same format for provisioning purposes if your = nameserver doesn't understand the new RRType's presentation format ("not = hard" used here to mean "possible in less than 20 lines of awk"). Given all of this, I don't really understand the benefits of = pre-assigning TXT-like RRTypes for future use. The barrier to entry = (today!) does not seem high, and having RRTypes defined with meaningful = canonical representations and stable references for use seems = beneficial. Joe= From drc@virtualized.org Fri May 3 10:12:33 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D8A21F9AEB for ; Fri, 3 May 2013 10:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4te8od8JqASe for ; Fri, 3 May 2013 10:12:23 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 50CEC21F8E6B for ; Fri, 3 May 2013 08:59:06 -0700 (PDT) Received: from [10.100.1.35] (35-64.lax.icann.org [192.0.35.64]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id AFD0317184; Fri, 3 May 2013 15:58:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: Date: Fri, 3 May 2013 08:59:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> To: Nicholas Weaver X-Mailer: Apple Mail (2.1503) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:12:33 -0000 Nicholas, On May 3, 2013, at 6:18 AM, Nicholas Weaver = wrote: >> The SPF group knew when they were doing the draft that they were = essentially making any other use of the TXT record infeasible in the = future. Or at least I pointed that out. > No its not, its trivial to further overload the text record. =20 Not really. The ABNF of SPF does not take into account the order of RRs = within an RRset is not guaranteed. The "v=3Dspf1" version discriminator = does not prefix each "term", it only prefixes a "record" and SPF terms = can be split over multiple TXT records. > And given the silly resistance amongst some in this group to tolerate = allocating new RR types (look at the debate over the entirely sensible = EUI48 and EUI64 RTYPEs), The EUI48 and EUI64 RR types were allocated. The 'silly resistance' = came later. > and the annoyance of getting authority software to allow one to = provision new RTYPEs in an easily readable form [1], Yep, that's a challenge, and hence the underscore label convention. =20 > it makes perfect sense for developers who want to shove something into = DNS to skip the whole IETF crap, create a convention, and shove things = either in A-records (like the RBLs have done) or TXT records. Yes, and the SPF community has greatly complicated (or removed) that = capability for domains used in "MAIL FROM/HELO". Regards, -drc From hallam@gmail.com Fri May 3 10:26:21 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8C121F9729 for ; Fri, 3 May 2013 10:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.2 X-Spam-Level: X-Spam-Status: No, score=0.2 tagged_above=-999 required=5 tests=[AWL=0.200, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8nVkOFr2kWj for ; Fri, 3 May 2013 10:26:20 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 774F521F991F for ; Fri, 3 May 2013 09:17:10 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id u7so1482973wey.16 for ; Fri, 03 May 2013 09:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=z+ADQPaTPUq4B8ik5t4V6vZkKrV40TH7/3aB5mQtyDA=; b=OE99YHlnY1D/zbW+J5kAVE3QCHhdDOngrUugZEklcXaQZoQOFVYQkJ1N0/ZZJrizV3 gpfkmzFwR+eQeGsy4djr2mwx0b9h+eiKFsfzX9KGIJQDzvdD95aaZbe2X2u71cPMoQfM augCrT+dmWlsd+tnwiZV+o+/dV4qTv+0RHIA3k8upZfzJ1bPtiVKCVGRH8lL+KIaqJKS cMIjGfeXLiDOA600hFhGLtbVRIt6YUxwRhIEg7daNPglf4ta87F8xquvOcfUY20LUq25 7WJeo3CxA/BzirmObm9C5YRTHmzpFwp3BbBd9rylyYPvMbKoXpsrNUb+6gU95X6Za48N 1qyg== MIME-Version: 1.0 X-Received: by 10.180.86.230 with SMTP id s6mr14328240wiz.6.1367597829383; Fri, 03 May 2013 09:17:09 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Fri, 3 May 2013 09:17:09 -0700 (PDT) In-Reply-To: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> Date: Fri, 3 May 2013 12:17:09 -0400 Message-ID: From: Phillip Hallam-Baker To: Joe Abley Content-Type: multipart/alternative; boundary=f46d04428624d0ecbc04dbd2ae37 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:26:22 -0000 --f46d04428624d0ecbc04dbd2ae37 Content-Type: text/plain; charset=ISO-8859-1 My point on TXT records and the 500 byte limit is that when you make a query for an unprefixed TXT record you are going to get ALL the records for all hacks that are overloading TXT with additional semantics. So the approach is not scalable which I think you agree with. Getting a RR assignment isn't the pain point. The only reason for getting an assignment is to make it more likely we will get decent support in BIND etc. I know all about the unknown RR coding. But that is second best support. What I am proposing is that we cut off a chunk of RR space that allows it to be used in a useful fashion without waiting for new deployments of BIND etc. Having to update BIND is second best in any case. The fewer updates and the fewer code paths to be verified, the better. Adding a new RR type to BIND only takes me a few hours. But writing the regression tests and the support infrastructure would be a lot more work and that is what it would be necessary to consider the code to be 'production'. On Fri, May 3, 2013 at 11:46 AM, Joe Abley wrote: > > On 2013-05-03, at 09:57, Phillip Hallam-Baker wrote: > > > DNS has an effective hard limit on the total size of all the records in > a RR set of 500 bytes. > > > > It is theoretically possible to go over that limit but bad things start > to happen and TCP fallback does not work any more reliably than new RR > types do. > > I don't think we necessarily see widespread problems with large responses. > > I realise that large responses are a reasonable concern, and there is much > scope for actual measurement to better characterise the landscape with > facts and science, but I don't think it's sensible to work from the basis > that the non-EDNS0-capable UDP-only DNS client sets an effective hard limit. > > This is a very general comment with no science behind it, of course, so it > doesn't really say anything beyond "here be dragons, or maybe not, who > knows". > > > Now what could make the whole process a lot easier would be to allocate > a band of DNS RR codes for records that would all have TXT syntax. That > would allow BIND etc. to make one change to support the new syntax. > Alternatively we could extend the handling of unknown RR syntax so that > there was a string presentation option. > > Recent experience suggests it's possible to apply for a new RRType and > have code-points assigned in less than a week. > > It also seems possible (with only the effort involved in opening a couple > of trouble tickets to make the feature request) to get the code-points > implemented in multiple major authoritative servers in less than three > weeks. > > Most deployed DNS authority servers (I have no numbers, but given the > purported market share of BIND9 I'll say "most") follow RFC3597 and hence > are able to understand (for example) > > krill.hopcount.ca. 86400 IN TYPE108 \# 6 7c d1 c3 e8 10 2f > > even if they can't understand > > krill.hopcount.ca. 86400 IN EUI48 7c-d1-c3-e8-10-2f > > The fact that EUI48 has a conveniently-hexadecimal RDATA payload makes > this an over-simple example, but it's not that hard to convert RRs with > textual data into the same format for provisioning purposes if your > nameserver doesn't understand the new RRType's presentation format ("not > hard" used here to mean "possible in less than 20 lines of awk"). > > Given all of this, I don't really understand the benefits of pre-assigning > TXT-like RRTypes for future use. The barrier to entry (today!) does not > seem high, and having RRTypes defined with meaningful canonical > representations and stable references for use seems beneficial. > > > Joe -- Website: http://hallambaker.com/ --f46d04428624d0ecbc04dbd2ae37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My point on TXT records and the 500 byte limit = is that when you make a query for an unprefixed TXT record you are going to= get ALL the records for all hacks that are overloading TXT with additional= semantics. So the approach is not scalable which I think you agree with.= =A0


Getting a RR assignment isn't the pain po= int. The only reason for getting an assignment is to make it more likely we= will get decent support in BIND etc.

I know all a= bout the unknown RR coding. But that is second best support. What I am prop= osing is that we cut off a chunk of RR space that allows it to be used in a= useful fashion without waiting for new deployments of BIND etc.=A0

Having to update BIND is second best in any= case. The fewer updates and the fewer code paths to be verified, the bette= r. Adding a new RR type to BIND only takes me a few hours. But writing the = regression tests and the support infrastructure would be a lot more work an= d that is what it would be necessary to consider the code to be 'produc= tion'.





On Fri, May 3, 2013 at = 11:46 AM, Joe Abley <jabley@hopcount.ca> wrote:

On 2013-05-03, at 09:57, Phillip Hallam-Baker <hallam@gmail.com> wrote:

> DNS has an effective hard limit on the total size of all the records i= n a RR set of 500 bytes.
>
> It is theoretically possible to go over that limit but bad things star= t to happen and TCP fallback does not work any more reliably than new RR ty= pes do.

I don't think we necessarily see widespread problems with large r= esponses.

I realise that large responses are a reasonable concern, and there is much = scope for actual measurement to better characterise the landscape with fact= s and science, but I don't think it's sensible to work from the bas= is that the non-EDNS0-capable UDP-only DNS client sets an effective hard li= mit.

This is a very general comment with no science behind it, of course, so it = doesn't really say anything beyond "here be dragons, or maybe not,= who knows".

> Now what could make the whole process a lot easier would be to allocat= e a band of DNS RR codes for records that would all have TXT syntax. That w= ould allow BIND etc. to make one change to support the new syntax. Alternat= ively we could extend the handling of unknown RR syntax so that there was a= string presentation option.

Recent experience suggests it's possible to apply for a new RRTyp= e and have code-points assigned in less than a week.

It also seems possible (with only the effort involved in opening a couple o= f trouble tickets to make the feature request) to get the code-points imple= mented in multiple major authoritative servers in less than three weeks.
Most deployed DNS authority servers (I have no numbers, but given the purpo= rted market share of BIND9 I'll say "most") follow RFC3597 an= d hence are able to understand (for example)

=A0 krill.hopcount.c= a. 86400 IN TYPE108 \# 6 7c d1 c3 e8 10 2f

even if they can't understand

=A0 krill.hopcount.c= a. 86400 IN EUI48 7c-d1-c3-e8-10-2f

The fact that EUI48 has a conveniently-hexadecimal RDATA payload makes this= an over-simple example, but it's not that hard to convert RRs with tex= tual data into the same format for provisioning purposes if your nameserver= doesn't understand the new RRType's presentation format ("not= hard" used here to mean "possible in less than 20 lines of awk&q= uot;).

Given all of this, I don't really understand the benefits of pre-assign= ing TXT-like RRTypes for future use. The barrier to entry (today!) does not= seem high, and having RRTypes defined with meaningful canonical representa= tions and stable references for use seems beneficial.


Joe



--=
Website: http://hallambaker.com/
--f46d04428624d0ecbc04dbd2ae37-- From johnl@iecc.com Fri May 3 10:37:21 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D228121F86AE for ; Fri, 3 May 2013 10:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.6 X-Spam-Level: X-Spam-Status: No, score=-108.6 tagged_above=-999 required=5 tests=[HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qs6+9BhzILnP for ; Fri, 3 May 2013 10:37:17 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BD5ED21F8BDE for ; Fri, 3 May 2013 10:19:14 -0700 (PDT) Received: (qmail 20512 invoked from network); 3 May 2013 17:19:07 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 May 2013 17:19:07 -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=5183f18b.xn--3zv.k1305; i=johnl@user.iecc.com; bh=AZ0cNOx9jrOgtm2bDHabDRDvtaRQ93aHLICOj8gt/fU=; b=RROdjn/YGIUv+wRSM6sGbe5GLHpMwXrlSLG+xbUz1xm7RZLLDAHH6kBrdCaP/V9tJGd5MBV6P2YTlkWrwZVc3Vjx2+JybjUA83yapcBdMpebno94lq3PxH8a4pkwSgD2pRtiKdFLLqxDnLfLWwELtxbA8+dLuHrWcOJjibk1bpQ= 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=5183f18b.xn--3zv.k1305; olt=johnl@user.iecc.com; bh=AZ0cNOx9jrOgtm2bDHabDRDvtaRQ93aHLICOj8gt/fU=; b=SOg+2Yy7P0WCKvS8NzhYNg53RpOXmI4zOI+sObRezIKTEyzdVkG9b76QHGPldbFWt+nhTQfZDir8txsf4u6ju4NLvbWnghrTujRnFaa+DSEGB2v7byPFgHC+0rqmcb3GlZ44WrYVkLmpUKgaLPs9n11m9FEczLNTgoGy1O51avk= Date: 3 May 2013 17:18:43 -0000 Message-ID: <20130503171843.39672.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: Ted.Lemon@nominum.com Subject: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:37:22 -0000 > However, the point has been made with respect to SPF >that it would have been better had it not been just a text record. Uh, no. SPF (the protocol) is overcomplex, with much of the complexity ending up in the DNS records. Decoding SPF records uses a fairly complex parser; storing a tokenized version wouldn't help and would probably be bulkier. A decade ago there were a bunch of designated sender schemes kicking around of which SPF was by far the most complicated and kludgy, but it's the one that survived? Why? Partly it's because the proponents of SPF were much better at PR than the rest of us, but mostly it's because they correctly recognized that publishing the sender policies in the DNS was the most difficult step, so SPF made it really easy to do, even at the cost of making the rest of SPF much messier. You go to the SPF web wizard, check a few boxes to decribe your sending setup, and it gives you a TXT record you can paste into your DNS and you're done. If stuff changes, e.g., the address of a mail host, or the set of hosts your ISP uses, it's not your problem, your own SPF record doesn't have to change. SPF requires that mail recipients interpret a complex and fragile description language to come up with a set of IP addresses for each incoming message. The other approaches had the sender publish the addresses directly, rather than a rule for finding them. But that meant that senders had to do the equivalent work before publishing the IPs, and had to update their DNS when the set changed. That was and is too hard for the small senders who are the bulk of sending domains if not the bulk of mail, so SPF won. (Don't argue, I'm describing the actual history.) SPF requires a ridiculous amount of work by recipients. The source for libspf2 is about 17,000 lines of code, and interpreting SPF records requires more DNS queries than any other DNS application I know. But all this is to work around the chokepoint of publishing DNS records, since everything else, looking them up, and calling libraries from mail servers, is vastly easier. Phill is right that 4408 added the type 99 record at the last minute since it was otherwise blocked by the DNS theorists. Nobody I know ever thought there was a realistic chance of existing SPF users switching. There is a protocol bug in 4408 due to the last minute insertion of type 99. Apparently none of the type 99 enthusiasts cared enough to review the changed spec and notice the bug, but of course in the long run it didn't matter. I agree that it's certainly somewhat easier to get an RRTYPE than it was a decade ago, so long as you understand that you just ignore all the nitpickery, but reasonable people still avoid doing so because using a prefixed TXT or other existing type is so much easier. It's not just because they're all stupid. R's, John From nweaver@icsi.berkeley.edu Fri May 3 10:40:04 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FA221F8F43 for ; Fri, 3 May 2013 10:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlR6yw8ccM8a for ; Fri, 3 May 2013 10:39:58 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9965D21F9743 for ; Fri, 3 May 2013 10:29:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 84AD82C4008; Fri, 3 May 2013 10:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ITCExgadQp+w; Fri, 3 May 2013 10:29:15 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 3F7402C4007; Fri, 3 May 2013 10:29:15 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Nicholas Weaver In-Reply-To: Date: Fri, 3 May 2013 10:29:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <136D764A-2018-4B42-A6A0-A2EC828B9A61@icsi.berkeley.edu> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1503) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:40:04 -0000 On May 3, 2013, at 9:17 AM, Phillip Hallam-Baker = wrote: > My point on TXT records and the 500 byte limit is that when you make a = query for an unprefixed TXT record you are going to get ALL the records = for all hacks that are overloading TXT with additional semantics. So the = approach is not scalable which I think you agree with.=20 >=20 >=20 > Getting a RR assignment isn't the pain point. The only reason for = getting an assignment is to make it more likely we will get decent = support in BIND etc. >=20 > I know all about the unknown RR coding. But that is second best = support. What I am proposing is that we cut off a chunk of RR space that = allows it to be used in a useful fashion without waiting for new = deployments of BIND etc.=20 >=20 > Having to update BIND is second best in any case. The fewer updates = and the fewer code paths to be verified, the better. Adding a new RR = type to BIND only takes me a few hours. But writing the regression tests = and the support infrastructure would be a lot more work and that is what = it would be necessary to consider the code to be 'production'. Why not instead just add a SECOND "unknown RTYPE encoding": a series of = strings thats encoded like it is a TXT record. From drc@virtualized.org Fri May 3 10:45:17 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33D121F845E for ; Fri, 3 May 2013 10:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI6kwAmtRCul for ; Fri, 3 May 2013 10:45:11 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5D90921F96E6 for ; Fri, 3 May 2013 10:42:57 -0700 (PDT) Received: from [10.100.1.35] (35-64.lax.icann.org [192.0.35.64]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id D683517184; Fri, 3 May 2013 17:42:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: <136D764A-2018-4B42-A6A0-A2EC828B9A61@icsi.berkeley.edu> Date: Fri, 3 May 2013 10:42:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4297F3DB-9E03-4B2B-86AB-3F0FE5E5713F@virtualized.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> <136D764A-2018-4B42-A6A0-A2EC828B9A61@icsi.berkeley.edu> To: Nicholas Weaver X-Mailer: Apple Mail (2.1503) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:45:17 -0000 On May 3, 2013, at 10:29 AM, Nicholas Weaver = wrote: > Why not instead just add a SECOND "unknown RTYPE encoding": a series = of strings thats encoded like it is a TXT record. And we can use typecode 99! :) Regards, -drc From envite@rolamasao.org Fri May 3 10:48:41 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001E021F93FC for ; Fri, 3 May 2013 10:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.337 X-Spam-Level: **** X-Spam-Status: No, score=4.337 tagged_above=-999 required=5 tests=[FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_STATIC=1.172, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LxcPpepQhIf for ; Fri, 3 May 2013 10:48:37 -0700 (PDT) Received: from rolamasao.org (68.167.216.87.static.jazztel.es [87.216.167.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3C06621F8506 for ; Fri, 3 May 2013 10:48:35 -0700 (PDT) Received: from tochox.localnet (localhost [IPv6:::1]) by rolamasao.org (Postfix_t) with ESMTPSA id 1A87711EDA for ; Fri, 3 May 2013 18:48:34 +0100 (WEST) From: Noel David Torres =?iso-8859-1?q?Ta=F1o?= To: dnsext@ietf.org Date: Fri, 3 May 2013 18:48:26 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) References: <201304250029.57132.envite@rolamasao.org> <6593BCE4-ECF6-450B-9364-62B662EF7BA6@vpnc.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1888944.XUnqDk5z6y"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201305031848.28163.envite@rolamasao.org> Subject: Re: [dnsext] Draft for OID X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:48:41 -0000 --nextPart1888944.XUnqDk5z6y Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > If it was going to be done at all. oids.arpa ?? >=20 > Yes, I can see the reasons why not. And they are unfortunately the reasons > that the idea is probably unsound. >=20 > I think this proposal suffers from the authoritative registry bug. It is > not possible to establish an authoritative registry for an existing > namespace after the fact. Not unless there is a reason to believe that the > community that uses the identifier will move to the new one. Experience > with SRV shows that even that is difficult. IETF has even less claim to > OIDs. >=20 Maybe the proposal has been misunderstood. It DOES NOT (note capitals) try = to=20 establish a new authoritative registry. It only creates a parseable method = of=20 storage. Nothing in the draft implies that you need to have your DNS appoin= ted=20 by the upper OID arc if you're using OID-DNS privately, you only need that = if=20 you are publishing, but in that case the authority delegation has already=20 taken place. >=20 > Or at least the IETF should have less claim to OIDS. What the IETF could = do > is to tell IANA to set up and manage a registry that would map to a part = of > the DNS space which would in turn contain links to some source of authori= ty > (via DNS space) describing the purpose. IANA already has a registry of OIDs on the PEN, but that does not allow=20 anybody to have an easy way of knowing what's under 1.3.6.1.4.1.41434.3.1 i= f I=20 use that (even if you know by reading the list that 1.3.6.1.4.1.41434 is=20 assigned to Rolamasao.org) >=20 > So for example, I have an OID space for Default Deny Security Inc off the > IETF arc. There might be some sort of DNS record like >=20 > 1.2.3.4.5.oid.arpa OIDPTR defaultdenysecurity.com >=20 > It would probably be more useful to have a URI that could point to a text > document with some description. >=20 Yes, the Draft can be amended adding an URI RR instead of the current DNS R= R.=20 What a good idea. I'll use it in next version. >=20 > But what would be the use of such a scheme? OIDs are a useful idea but I > can't think of any case where having a machine readable description of an > OID would have a lot of value. If you are presenting a LDAP structure (lots of OIDs assigned by different= =20 people), if you are identifiying people's medical records (2.16.840.1.11388= 3),=20 if you are looking at people's identity cards (2.16.724.1.2.2.4.2.1) and mo= re=20 others. >=20 > there are some cases where having a link to a human readable description > could be of use. It would be useful if the OID for a crypto algorithm > linked to the specification, maybe. Probably the bast use would be to > describe PKIX certificate policy OIDs. >=20 Yes >=20 > Normally this would be a pointless task since Harald's database is > adequate. But what might change matters is the politics surrounding IETF > and ITU-T. I didn't think we were there yet when we talked about this in > Orlando, but I think that relationship is on the brink of collapse. Why is it adequate? If I maintain an OID arc under a PEN number, why must I= =20 register into Harald's instead of publishing on my own and let people check= on=20 my authoritative server? >=20 > I am reading ITU-T proposals relating to X.509 coming from the people's > republic of Iran. Whatever the content of the proposal, the ITU-T model of > nation state participation is simply not sustainable. I think they are > going to push and push until the only answer the IETF can give is to sever > all links and all dependencies on ITU-T standards. I will not mess in politics (yet). But this depends 0% on ITU-T, this is a = new=20 method of representing, transmitting and storing OIDs, not a new authority = on=20 them Thanks for the comments! I always learn by reading Noel er Envite =2D------------------------ A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? --nextPart1888944.XUnqDk5z6y Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlGD+GwACgkQcLQA8+7Hw3LimACdEKdZSz2rBZKdMbbQNVMo35Lr utMAoIxyGVBTZHHEgeTHMvzcA8uwZ42n =5GMz -----END PGP SIGNATURE----- --nextPart1888944.XUnqDk5z6y-- From doug.mtview@gmail.com Fri May 3 12:05:05 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C2C21F96B4; Fri, 3 May 2013 12:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MCrOj4ZGL7g; Fri, 3 May 2013 12:05:04 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE5E21F84A6; Fri, 3 May 2013 12:04:57 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id uo1so1043754pbc.34 for ; Fri, 03 May 2013 12:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:subject:date:message-id:cc:to :mime-version:x-mailer; bh=KDXmzyOdJ/a0Xghkhq7dxRaU+nn9HIrESFqLLKxxb+4=; b=aAsFEhtWcU9+Z6MQ7US16+Suw//fqZz2mP000HcyqXEOtuNDzIcMEWICVpw1MMhS0q Anp1a/sqh8agXFHAIjqz/hNUE4fOVO3KrDE850SSAyjZuXqLevd+w73ydPSO/ekgACUU Z6th/lq+FawNycgfTb+pwMu58z/N79KfpWW64DzBKjWtTaIx2ZE49ToJUfCKl991cjhy ltXgWR/ovMxAvXn4KZRsv3YP01Ka/+++IWJGwfbTVH9zXAXQXKzb6lAO9MFuQ7bqrO0M e4Cwf7ZIEwNjqun7HcCjX/DXcKjtgd5V0g0x4WHjGnrA03Bc1xVBNeT/JWFuPV3Cajek jw4Q== X-Received: by 10.66.166.107 with SMTP id zf11mr16195044pab.166.1367607896894; Fri, 03 May 2013 12:04:56 -0700 (PDT) Received: from ?IPv6:2601:9:3180:3e:6977:cc82:b053:faf8? ([2601:9:3180:3e:6977:cc82:b053:faf8]) by mx.google.com with ESMTPSA id ih1sm12634971pbb.44.2013.05.03.12.04.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 May 2013 12:04:55 -0700 (PDT) From: Douglas Otis Content-Type: multipart/alternative; boundary="Apple-Mail=_438BAF92-9972-44B6-8856-17D48DA59C61" Date: Fri, 3 May 2013 12:04:53 -0700 Message-Id: <363177C4-6D23-48C1-9609-226A9B55EAAD@gmail.com> To: " IETF" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: "dnsext@ietf.org" Subject: [dnsext] Effects on DNS can be severe X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 19:05:05 -0000 --Apple-Mail=_438BAF92-9972-44B6-8856-17D48DA59C61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear ietf and dnsext, I apologies for posting this ahead of the wg last call. Over many years at attempting to change the course of the SPF process, = this effort appears to have been futile. It seems many even feel the present spfbis document represents current = practices. It does not, from the perspective of macros. I have written an I-D that I fully expect SPF proponents will denounce = and so I have left that wg alone. =20 Here is a draft written in hopes of placing these concerns into a = broader scope-- http://tools.ietf.org/html/draft-otis-ipv6-email-authent-00 Two references in this draft did not carry over in the same manner as = in the tcl script? =20 Until remedied, here are the links missing in this i-d: [I-D.otis-spf-dos-exploit] http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01 [v6-BGP-Rpts] http://bgp.potaroo.net/v6/as6447/ SPF can pose serious threats, that when confronted, few solutions are = available. I have been able to convince some of the larger providers of = this concern, who in returned offered assurances the macro extensions in = their SPF libraries are removed and in doing so have not seen any = problems. This is a serious effort at addressing a security concern, please read = this draft from that perspective. Regards, Douglas Otis --Apple-Mail=_438BAF92-9972-44B6-8856-17D48DA59C61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = ietf and dnsext,

I apologies for posting this = ahead of the wg last call.

Over many years at = attempting to change the course of the SPF process, this effort appears = to have been futile.
It seems many even feel the present = spfbis document represents current practices.  It does not, from = the perspective of macros.
I have written an I-D that I fully = expect SPF proponents will denounce and so I have left that wg alone. =  

Here is a draft written in hopes of = placing these concerns into a broader scope--

<= /div>
Two references in this draft  did not carry over in the = same manner as in the tcl script?  
Until remedied, here = are the links missing in this i-d:


<= div>[v6-BGP-Rpts]

SPF can pose serious threats, that when = confronted, few solutions are available.  I have been able to = convince some of the larger providers of this concern, who in returned = offered assurances the macro extensions in their SPF libraries are = removed and in doing so have not seen any = problems.

This is a serious effort at = addressing a security concern, please read this draft from that = perspective.

Regards,
Douglas = Otis

= --Apple-Mail=_438BAF92-9972-44B6-8856-17D48DA59C61-- From drc@virtualized.org Fri May 3 14:01:18 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D9721F90C1 for ; Fri, 3 May 2013 14:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8GQrVlwET0o for ; Fri, 3 May 2013 14:01:12 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 39ED521F90DF for ; Fri, 3 May 2013 14:01:12 -0700 (PDT) Received: from [10.100.1.35] (35-64.lax.icann.org [192.0.35.64]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 8EA6017184; Fri, 3 May 2013 21:01:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: <20130503203921.GA22566@redoubt.spodhuis.org> Date: Fri, 3 May 2013 14:01:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> <20130503203921.GA22566@redoubt.spodhuis.org> To: Phil Pennock X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 21:01:18 -0000 Phil, On May 3, 2013, at 1:39 PM, Phil Pennock = wrote: > That is not my understanding as a reader of RFC4408 and as someone who > worked with the coder (and documented the results) for the handling of > TXT records in a widespread MTA to be as flexible as possible and to > support SPF-style lookups. Last sentence of RFC 4408, section 3.1.3: " SPF or TXT records containing multiple strings are useful in constructing records that would exceed the 255-byte maximum length of a string within a single TXT or SPF RR record." Sure sounds to me like 4408 anticipates multiple TXT RRs. Regards, -drc From dougb@dougbarton.us Fri May 3 14:10:12 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AFA21F90EA for ; Fri, 3 May 2013 14:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCPx0YzS2Ec8 for ; Fri, 3 May 2013 14:10:12 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFAC21F9133 for ; Fri, 3 May 2013 14:10:12 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b] (unknown [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b]) by dougbarton.us (Postfix) with ESMTPSA id ACF6222B62 for ; Fri, 3 May 2013 21:10:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1367615411; bh=Tj5fQJgtkiVuww4POi24iITi/DUppdJtjK5FR9CYgEk=; h=Date:From:To:Subject:References:In-Reply-To; b=pQv946u+mKtIXIVb4oyxOztqu5zGSQjeeNqjWMfzZ4ZJhQv8R8/tmleP4+Zd3fA4A 9aOGDzAnXQLwsQVDxYETf834jnFbCRtfAw2DcefavBxaGBVYOfe6bjh4CqVlxAjkRa l2Cy0PQHPQ+3LpAxeEeZYlLq8Suf1L/3NIZWuwGI= Message-ID: <518427B3.5070209@dougbarton.us> Date: Fri, 03 May 2013 14:10:11 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> <20130503203921.GA22566@redoubt.spodhuis.org> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 21:10:12 -0000 On 05/03/2013 02:01 PM, David Conrad wrote: > Phil, > > On May 3, 2013, at 1:39 PM, Phil Pennock wrote: >> That is not my understanding as a reader of RFC4408 and as someone who >> worked with the coder (and documented the results) for the handling of >> TXT records in a widespread MTA to be as flexible as possible and to >> support SPF-style lookups. > > Last sentence of RFC 4408, section 3.1.3: > > " SPF or TXT records containing multiple strings are useful in > constructing records that would exceed the 255-byte maximum length of > a string within a single TXT or SPF RR record." > > Sure sounds to me like 4408 anticipates multiple TXT RRs. Yeah, this is not theoretical. They show up in practice for organizations with larger mail infrastructures. IIRC the source for libspf2 has some info on this as well. Doug From superuser@gmail.com Fri May 3 14:57:24 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5649921F92CF for ; Fri, 3 May 2013 14:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjouEk-LFXP4 for ; Fri, 3 May 2013 14:57:23 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id B8FBA21F9164 for ; Fri, 3 May 2013 14:57:21 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so1966355wgh.17 for ; Fri, 03 May 2013 14:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aRG9ey1/VVCMGDZYbxt/2rf+IgM22tZ0RayhV07OhhM=; b=bL+kUuAHgOEqIOMnuc8P3Dq3TPLUd9L/8z1XZIf+zdRAc8z9a8mmWL45UGy3olXFdH uvKxp8C4YWECZxhCEjQ01H2PrbGzbTxyn3uCjJFcR97GhrInKcegvHKPvo3HzPotC2OD WzMryMr03raDCrHdLuXhKwiT3eE8n4PMuTqkY2WJh6+bXuYEvQ3yBaZ6fWH/G1gl6e21 hW6KE6ooX401BdgsWXn4r319XLBvijnJtm4gLLvAB76oT6cKcjvIPn3IujVmfVn8t9Ue S9G+Gc7HkmtSfHlYqlxd/qQKhmUq3ckgvuR+cw2MyzfRDt2ie+Z6thepEFAHEq/FItjW TCnw== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr16315846wjb.17.1367618240927; Fri, 03 May 2013 14:57:20 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Fri, 3 May 2013 14:57:20 -0700 (PDT) In-Reply-To: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> <20130503203921.GA22566@redoubt.spodhuis.org> Date: Fri, 3 May 2013 14:57:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: David Conrad Content-Type: multipart/alternative; boundary=047d7b5d8cff705d2304dbd76f11 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 21:57:24 -0000 --047d7b5d8cff705d2304dbd76f11 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 3, 2013 at 2:01 PM, David Conrad wrote: > Last sentence of RFC 4408, section 3.1.3: > > " SPF or TXT records containing multiple strings are useful in > constructing records that would exceed the 255-byte maximum length of > a string within a single TXT or SPF RR record." > > Sure sounds to me like 4408 anticipates multiple TXT RRs. > No, that section is all about having a single TXT RR whose complete content doesn't fit in 255 characters. It illustrates how to achieve this within a single RR in zone file format. --047d7b5d8cff705d2304dbd76f11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 3, 2013 at 2:01 PM, David Conrad <drc@virtu= alized.org> wrote:
Last sentence of RFC 4408, section 3.1.3:
" =A0SPF or TXT records containing multiple strings are useful in
=A0 =A0constructing records that would exceed the 255-byte maximum length o= f
=A0 =A0a string within a single TXT or SPF RR record."

Sure sounds to me like 4408 anticipates multiple TXT RRs.

No, that= section is all about having a single TXT RR whose complete content doesn&#= 39;t fit in 255 characters.=A0 It illustrates how to achieve this within a = single RR in zone file format.
--047d7b5d8cff705d2304dbd76f11-- From dougb@dougbarton.us Fri May 3 15:30:48 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422A221F8F1F for ; Fri, 3 May 2013 15:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT-AV13bwxlE for ; Fri, 3 May 2013 15:30:44 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id F41E821F8E98 for ; Fri, 3 May 2013 15:30:43 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b] (unknown [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b]) by dougbarton.us (Postfix) with ESMTPSA id A602A22B62; Fri, 3 May 2013 22:30:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1367620243; bh=rles3p96ykBV7nYfyMHl79x9F2XvPswxxBxMQR9D6f4=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=NjN+/sUwR4UdFvAV8UCD2Y6M7YTHKCzOv3cGZyz1qpg9Ox15RfPM9UV+rU6l0kQqi Zh8y/lvuPS0/fw2F+6/C7//BR7N2FbADWfBlrOPVn3p/K+ubHB4ZoT84Xqyj68KcKC nRMQW7iJNwpsnjl8h16kEkaMmk5Bl4wn2T2bDL+4= Message-ID: <51843A93.3010109@dougbarton.us> Date: Fri, 03 May 2013 15:30:43 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> <20130503203921.GA22566@redoubt.spodhuis.org> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 22:30:48 -0000 On 05/03/2013 02:57 PM, Murray S. Kucherawy wrote: > On Fri, May 3, 2013 at 2:01 PM, David Conrad > wrote: > > Last sentence of RFC 4408, section 3.1.3: > > " SPF or TXT records containing multiple strings are useful in > constructing records that would exceed the 255-byte maximum > length of > a string within a single TXT or SPF RR record." > > Sure sounds to me like 4408 anticipates multiple TXT RRs. > > > No, that section is all about having a single TXT RR whose complete > content doesn't fit in 255 characters. It illustrates how to achieve > this within a single RR in zone file format. ... which doesn't prevent people from splitting them across multiple records. Doug From namedroppers+phil@spodhuis.org Fri May 3 16:31:12 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EC121F8EB1 for ; Fri, 3 May 2013 16:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.729 X-Spam-Level: ** X-Spam-Status: No, score=2.729 tagged_above=-999 required=5 tests=[AWL=5.329, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUDZbTDnY31I for ; Fri, 3 May 2013 16:31:12 -0700 (PDT) Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) by ietfa.amsl.com (Postfix) with ESMTP id D964B21F8681 for ; Fri, 3 May 2013 16:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201210; h=Date:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From; bh=bqIjgw2gVrUap9nWB8lvmojQAdOk9j1J24RCiOKb2f0=; b=fM4EEz/0FxokOX9Cf4XRg88uTPud5qtXmArSZ8/sG7y0iZLRXBNMFVyXjlD+AIm3gqGBUb8KEzuz4+chZWUL4uDHdMPfHmB+l8wsjXtpDi/0uraZynqfRrEQqCj098FGmQBSfUqqPsN0CLTNWbw8niXnmgxO1J2NJuqnMu3wd90=; Received: from [::1] (port=56429 helo=localhost) (helo=localhost) by smtp.spodhuis.org with esmtp id 1UYPPu-0006OC-4A; Fri, 03 May 2013 23:31:11 +0000 From: Phil Pennock To: David Conrad Message-ID: <20130503203921.GA22566.take2@redoubt.spodhuis.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Date: Fri, 03 May 2013 23:29:55 +0000 Cc: dnsext@ietf.org Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 23:31:12 -0000 If folks can read this message, then it appears that my posting problems are caused by the IETF mail-system silently discarding mail with a BATV/PRVS sender. Reposting with that disabled. On 2013-05-03 at 08:59 -0700, David Conrad wrote: > Not really. The ABNF of SPF does not take into account the order of > RRs within an RRset is not guaranteed. The "v=spf1" version > discriminator does not prefix each "term", it only prefixes a "record" > and SPF terms can be split over multiple TXT records. That is not my understanding as a reader of RFC4408 and as someone who worked with the coder (and documented the results) for the handling of TXT records in a widespread MTA to be as flexible as possible and to support SPF-style lookups. (Exim, ${dnsdb...} stuff, used in some minimal setups when libspf2 is not used.) SPF can be split over multiple strings within a single TXT record but can not be split over multiple RR of type TXT. RFC 4408: ----------------------------8< cut here >8------------------------------ 3. SPF Records An SPF record is a DNS Resource Record (RR) that declares which hosts are, and are not, authorized to use a domain name for the "HELO" and "MAIL FROM" identities. Loosely, the record partitions all hosts into permitted and not-permitted sets (though some hosts might fall into neither category). [...] 3.1.2. Multiple DNS Records A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record. See Section 4.5 for the selection rules. 3.1.3. Multiple Strings in a Single DNS record [...] 4.5. Selecting Records Records begin with a version section: record = version terms *SP version = "v=spf1" Starting with the set of records that were returned by the lookup, record selection proceeds in two steps: 1. Records that do not begin with a version section of exactly "v=spf1" are discarded. Note that the version section is terminated either by an SP character or the end of the record. A record with a version section of "v=spf10" does not match and must be discarded. 2. If any records of type SPF are in the set, then all records of type TXT are discarded. After the above steps, there should be exactly one record remaining and evaluation can proceed. If there are two or more records remaining, then check_host() exits immediately with the result of "PermError". If no matching records are returned, an SPF client MUST assume that the domain makes no SPF declarations. SPF processing MUST stop and return "None". ----------------------------8< cut here >8------------------------------ From namedroppers+phil@spodhuis.org Fri May 3 16:33:03 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7C021F8D27 for ; Fri, 3 May 2013 16:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.253 X-Spam-Level: * X-Spam-Status: No, score=1.253 tagged_above=-999 required=5 tests=[AWL=3.253, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaONxFpa7Qb5 for ; Fri, 3 May 2013 16:33:03 -0700 (PDT) Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF6121F8C33 for ; Fri, 3 May 2013 16:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201210; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=HWia+E5ChBxUbi87oreRze6svqjylqfy+dYscuVa7tI=; b=I+axxvT3jieZFthHZxoc8yESx5n+t9ks/QbVh71S/8pcCPeKuKZP20+WEjb5X2XnvPxfwuplBZlO8x/1uDdPDRIPZiEdHdfpJ4UvPT+hQ+9jx8O1yGPZAvPDWcfI/7HusKzO7D7Qt6plGIJ6fDY6bvS0Sr/9Y+oKBsm1xLyoymM=; Received: from [::1] (port=53093 helo=localhost) (helo=localhost) by smtp.spodhuis.org with esmtp id 1UYPSn-0006Of-6Q; Fri, 03 May 2013 23:33:02 +0000 Date: Fri, 3 May 2013 18:00:31 -0400 From: Phil Pennock To: David Conrad Message-ID: <20130503220031.GA23507.take2@redoubt.spodhuis.org> References: <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> <20130503203921.GA22566@redoubt.spodhuis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: dnsext@ietf.org Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 23:33:04 -0000 On 2013-05-03 at 14:01 -0700, David Conrad wrote: > Phil, > > On May 3, 2013, at 1:39 PM, Phil Pennock wrote: > > That is not my understanding as a reader of RFC4408 and as someone who > > worked with the coder (and documented the results) for the handling of > > TXT records in a widespread MTA to be as flexible as possible and to > > support SPF-style lookups. > > Last sentence of RFC 4408, section 3.1.3: > > " SPF or TXT records containing multiple strings are useful in > constructing records that would exceed the 255-byte maximum length of > a string within a single TXT or SPF RR record." > > Sure sounds to me like 4408 anticipates multiple TXT RRs. One TXT RR contains one or more strings, each of maximum length 255. To rip an example I wrote for Exim docs: foo.example. IN TXT "a" "b" "c" foo.example. IN TXT "d" "e" "f" ${lookup dnsdb{>/ txt=foo.example}} -> "a/d" ${lookup dnsdb{>/; txt=foo.example}} -> "def/abc" ${lookup dnsdb{>/,+ txt=foo.example}} -> "a+b+c/d+e+f" That's two RRs, each with three strings. You can also look up spftest$N.test.globnix.net for N in 1..6 for more examples. N 2, 3 and 6 are most relevant. (Both SPF=99 and TXT records are present.) spftest6 is fun, in that it breaks into multiple strings in the middle of "v=spf1", which is absolutely allowed by the SPF specification. -Phil From johnl@iecc.com Fri May 3 18:48:55 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A8921F8F69 for ; Fri, 3 May 2013 18:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnUbkWgdwSeK for ; Fri, 3 May 2013 18:48:51 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD9421F8F44 for ; Fri, 3 May 2013 18:48:50 -0700 (PDT) Received: (qmail 40976 invoked from network); 4 May 2013 01:48:47 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 4 May 2013 01:48:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=518468ff.xn--9vv.k1305; i=johnl@user.iecc.com; bh=GBYcMjWZ55X4mhHzKm+/Ytzb3vlaiF6R/JQsojlU5fs=; b=kBMCIIynYlChV9pYvzRKsxbhZWt3RuRel4oh6NDzNP1f469c68D8AcrNrFOPHuCgB4UGKd2OUf68NAKwQWOQhGHQef7p9VizxP6Zct8Z7p1omMsDvZ8vUqVFJ8c67oY32ccpj1HG+3E63hNc7bBQLbE+mLwBRmKt/CXFA32ipdg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=518468ff.xn--9vv.k1305; olt=johnl@user.iecc.com; bh=GBYcMjWZ55X4mhHzKm+/Ytzb3vlaiF6R/JQsojlU5fs=; b=p/9GneuHv/4esECMtslEgeoHOgFn0xg2BQ83eEKTLAZyjfPvZtTfmndcf83Tyo4gPGF0N4F9s9AzQz7crFggdVOey/2LJWsZ/5A3s/6bx4KnuM7c+tr9QYkHYSeMcYawMrjzX0zCeBVw3ia/EhynZKbv+4ZWcUrlzw76nGoRwf8= Date: 4 May 2013 01:48:25 -0000 Message-ID: <20130504014825.42875.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <51843A93.3010109@dougbarton.us> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 01:48:55 -0000 >> No, that section is all about having a single TXT RR whose complete >> content doesn't fit in 255 characters. It illustrates how to achieve >> this within a single RR in zone file format. > >... which doesn't prevent people from splitting them across multiple >records. Section 3.1.2 of RFC 4408 forbids an SPF checker from looking at multiple records at the same name. Section 3.2 of the current draft has the same language. SPF has to forbid multiple records at the same name, since their semantics are obviously impossible to define. A single TXT record can, of course, contain any number of strings and can be arbitrarily long. See RFC 1035 sec 3.3.14. Is there some reason it's preferable to guess rather than reading the spec? R's, John From dmiller@tiggee.com Fri May 3 20:57:04 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B0A21F88D8 for ; Fri, 3 May 2013 20:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4OdVuQHeJTc for ; Fri, 3 May 2013 20:57:00 -0700 (PDT) Received: from smtp1.tiggee.com (smtp1.tiggee.com [208.94.147.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6C28D21F8551 for ; Fri, 3 May 2013 20:57:00 -0700 (PDT) Message-ID: <5184870C.5020904@tiggee.com> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tiggee.com; s=dkprod2001; t=1367639819; bh=Zpvt3D/ul5V3rF6x5GaFgw1laPgVClIPl+H9 5qY6or0=; h=DomainKey-Signature:Date:From:User-Agent:MIME-Version: To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=Uszi0GS7Y8PalmuCZF0Z1TEINS8v9p1j9N6W6 aimuJc4N7VTUhcJ9IEx9JWCdOQ5rlm3cNXSZ8PV+Oxp0tvn0IZiVZ692P86QE6nA86E 0ayQqT3QRuVnenxXjnIelsi0tdyT/CjAEIn0sbjdPPeprRPVn/QWPq0yS427Ry1z3ms = DomainKey-Signature: a=rsa-sha1; s=dkprod2001; d=tiggee.com; c=simple; q=dns; h=date:from:user-agent:mime-version:to:subject:references: in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=SVX31yow5iW6nErfMUtL4w/JbIESM04BnUzoDNiW9Jq2wcojjQWA89WIc4iEq7uqf w5/QxivejmiDX39RYgs+VZU7zQ22ku6lwa+Ka4Cwyq+Gu6IebhTfdzlrnIQD4rnHzo6 e0obA/4jaMrlqLF4d6xNLh/I4tfy6X0FhbY0Co8= Date: Fri, 03 May 2013 23:57:00 -0400 From: David Miller User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130504014825.42875.qmail@joyce.lan> In-Reply-To: <20130504014825.42875.qmail@joyce.lan> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 03:57:04 -0000 On 5/3/2013 9:48 PM, John Levine wrote: >>> No, that section is all about having a single TXT RR whose complete >>> content doesn't fit in 255 characters. It illustrates how to achieve >>> this within a single RR in zone file format. >> >> ... which doesn't prevent people from splitting them across multiple >> records. > > Section 3.1.2 of RFC 4408 forbids an SPF checker from looking at > multiple records at the same name. Section 3.2 of the current draft > has the same language. SPF has to forbid multiple records at the same > name, since their semantics are obviously impossible to define. > > A single TXT record can, of course, contain any number of strings and > can be arbitrarily long. See RFC 1035 sec 3.3.14. TXT records don't have a specified maximum length, but they cannot be arbitrarily long. They have to fit into an RR. RDLENGTH, which specifies the length of the RDATA field, is an unsigned 16 bit integer (max 65535). See RFC 1035 sec 3.2.1. 64k is very long, but not arbitrarily long. > > Is there some reason it's preferable to guess rather than reading the > spec? > > R's, > John -DMM From johnl@iecc.com Fri May 3 21:30:28 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D892721F8FD5 for ; Fri, 3 May 2013 21:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.766 X-Spam-Level: X-Spam-Status: No, score=-110.766 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt2v5lyYKpmX for ; Fri, 3 May 2013 21:30:24 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7324021F8FD3 for ; Fri, 3 May 2013 21:30:24 -0700 (PDT) Received: (qmail 71398 invoked from network); 4 May 2013 04:30:22 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 4 May 2013 04:30:22 -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=51848ede.xn--i8sz2z.k1305; i=johnl@user.iecc.com; bh=i8aoCDc+4PWp9NrLBX8bAtFFOJrTomsN18tZTpqWmGY=; b=pvtaePcheR5QJDqRyCHVg/WlTH9X+lpJC0B546yAK7U/16QbiJJEEMmUtJKuICTs+Xk533Qy3KYd5YUMnmpC2Y23EDKYhQAhDfQt3prg9VzyDNI5rhJcCcc754xbeNZa0tgTDQffxu2ivJqugrWN/X7GYueOlUMQI1hncrous3A= 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=51848ede.xn--i8sz2z.k1305; olt=johnl@user.iecc.com; bh=i8aoCDc+4PWp9NrLBX8bAtFFOJrTomsN18tZTpqWmGY=; b=T+4nWSzfF6JVfOA165DBUTH0D1V/nOPmr6eoMZuf4T+d4qNf+ttKoYGbNDlMB8sX8OZZM7aiGBBfxJQYckVni5FjQXRKfIOHAOhMnKXZR+NiWFK8xt20PM0ag0VQQurid6qyMe5QdrHBtPQG8FokhCo/owPWA9w77WnAzkBa0oQ= Date: 4 May 2013 04:30:00 -0000 Message-ID: <20130504043000.99930.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <5184870C.5020904@tiggee.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 04:30:29 -0000 >> A single TXT record can, of course, contain any number of strings and >> can be arbitrarily long. See RFC 1035 sec 3.3.14. > >TXT records don't have a specified maximum length, but they cannot be >arbitrarily long. They have to fit into an RR. RDLENGTH, which >specifies the length of the RDATA field, is an unsigned 16 bit integer >(max 65535). See RFC 1035 sec 3.2.1. > >64k is very long, but not arbitrarily long. Well, yes, you're right, the RR's total length is a 16 bit value. I'd be pretty horrified if that were ever an issue for SPF. R's, John From bmanning@karoshi.com Sat May 4 06:33:22 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D0921F958D for ; Sat, 4 May 2013 06:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Baq9m8hpa+M7 for ; Sat, 4 May 2013 06:33:17 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id B883D21F94FD for ; Sat, 4 May 2013 06:33:17 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id r44DXEFo027832; Sat, 4 May 2013 13:33:14 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r44DXCov027831; Sat, 4 May 2013 13:33:12 GMT Date: Sat, 4 May 2013 13:33:12 +0000 From: bmanning@vacation.karoshi.com To: John Levine Message-ID: <20130504133312.GA27772@vacation.karoshi.com.> References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130503171843.39672.qmail@joyce.lan> User-Agent: Mutt/1.4.1i Cc: dnsext@ietf.org, Ted.Lemon@nominum.com Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 13:33:22 -0000 On Fri, May 03, 2013 at 05:18:43PM -0000, John Levine wrote: > > ... and interpreting SPF > records requires more DNS queries than any other DNS application I > know. > > R's, > John So what you are saying is that SPF is a carefully crafted DNS DDoS attack because it was too hard to do the work inside your own protocol? What ever happened to "Be Conservitive in What you Send..." /bill From johnl@taugh.com Sat May 4 08:16:46 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800DB21F853A for ; Sat, 4 May 2013 08:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhhkwyesYw28 for ; Sat, 4 May 2013 08:16:43 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4193321F8765 for ; Sat, 4 May 2013 08:16:39 -0700 (PDT) Received: (qmail 90925 invoked from network); 4 May 2013 15:16:38 -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:cleverness; s=16329.51852656.k1305; bh=JnMJvaPccUsoWvr2WFvEVQwyxHRIPH/KTcEUh2G0jTs=; b=SF5gfcth7lF7De6e5sndRYE1b6dPvX3tDkKv1adayc9Lc+lP8vxW2hXqxhU+m/KyHzQLTT/NtknpVMjVtBlBCWH262iWC3nVv2GaY9C1srmTTHyNNsPU1RMmC/8Koah3UAPBcy8+gCau6egDSxgyhr9rvCMF3hEbwcEqy/Z9NH8= 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:cleverness; s=16329.51852656.k1305; bh=JnMJvaPccUsoWvr2WFvEVQwyxHRIPH/KTcEUh2G0jTs=; b=TEEzqmy4o5qNjlXFBsJ0RFoWVY/GddRGA6sIy0xqiVPnRfipBYxUVsBJCqRQJMVdxIA1LWm+Jv5d7+aP3yP+dDToqbOtVBbxSaIgODGbi75/KULy+Er21wIeQiiFbJ8VQt/dfOKrMKhi/+ogpVVY25NBM2rJFp+6t9YFG3mcvfM= Received: (ofmipd 127.0.0.1); 4 May 2013 15:16:16 -0000 Date: 4 May 2013 11:16:38 -0400 Message-ID: From: "John R Levine" To: bmanning@vacation.karoshi.com In-Reply-To: <20130504133312.GA27772@vacation.karoshi.com.> References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-69262283-1367680598=:8602" Cc: dnsext@ietf.org, Ted.Lemon@nominum.com Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 15:16:46 -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. --3825401791-69262283-1367680598=:8602 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> ... and interpreting SPF records requires more DNS queries than any >> other DNS application I know. > So what you are saying is that SPF is a carefully crafted DNS > DDoS attack because it was too hard to do the work inside your > own protocol? Yup, just like CNAME. In the decade that SPF has been around, the putative DDoS has never been observed in the wild, ever, despite Doug Otis warning us about it every 15 minutes since 4408 was a draft, and a few experiments I did with stunt DNS servers that returned giant trees of SPF records very slowly. It turns out everyone does loop breaking, just like for CNAME. It's a sloppy design from a decade ago that succeeded because it made an end run around the DNS provisioning problems of "better" alternatives. > What ever happened to "Be Conservative in What you Send..." It lost out to Stuff That Actually Exists Works Better than Stuff That Doesn't. A decade ago, SPF was far from my favorite authentication design, but now it exists, it's more widely used than most standards track protocols, and it would be silly to pretend otherwise. Hence the spfbis charter to standardize existing practice. R's, John --3825401791-69262283-1367680598=:8602 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTA0MTUxNjM4WjAjBgkqhkiG 9w0BCQQxFgQUSCdqkbbf4sfVc+zx3VfaxxwxYeQweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAYuwUGXe5I71V 5RbkRU0JQcUYfUL+krBAJCdHGMzx6yiAPWrsxseiqMsUWIo8plaKKcvnGxqT W+EjgPBiOZdLmdMT6FKLixxMteo5qmJDch358WtxfU0kaUZ0DkGnbOmtx7ok rDvHd05+JrD3cM2uNeWKKRjsWDE/jIxtTs3p9YiW5Bg1oVdiTSn2BcogKZvX LEOQvSxOaj8AtgOtgWKAzyr7CDDXrPsLPCy7ymyA1UHmqVB9+JwqJUOZ9vLn jHnaAp1fZe0a/CVCAgvKjCIm5zTu8wcJbd+IJpa0LX+h03RQ0Ejt0b6VY6uQ b5JDRuPNyyMTumJVobEh/gKqCsomjQ== --3825401791-69262283-1367680598=:8602-- From doug.mtview@gmail.com Sat May 4 18:01:11 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29D721F96B9 for ; Sat, 4 May 2013 18:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du34gHCLl3CR for ; Sat, 4 May 2013 18:01:05 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id D375221F96B8 for ; Sat, 4 May 2013 18:01:05 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id x10so1457444pdj.21 for ; Sat, 04 May 2013 18:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=nRN2vPei0FUyW103DvtEJxQzciu6mPPS+MgWXrUNpuU=; b=mLp9obr/ndsPeu9WCQTJCDbDYczEdQbG027WFOEAo+O/elgXJjmId61fD14I5Iks/C uemnMiQm7JNeBQPZzRCZpuPJPGgaZJfMygChvxbvML72i3ZhEd+6LKKh8T4zUjT0XiTc 3BQcWE0eayd18gdlXnNhiMZAmGFGoj8Kz4GCOgV/MTxzcf6EekR3x6yHict1RGjAtbt6 5XSUE+YAAVEQdLT+bdEPJH2Vf1nuMWw0ih5OeiKArUx5TMefm5e+gkPlNldB+uBO0Seu +s732id5AHlzGTVo9SX6W/ExymKaDB8wNt5HNfOJWAvH+RXfmKReZL0b9xqF9qYaisi9 pmsw== X-Received: by 10.66.149.5 with SMTP id tw5mr20919027pab.87.1367715665641; Sat, 04 May 2013 18:01:05 -0700 (PDT) Received: from [192.168.1.194] (c-24-4-157-244.hsd1.ca.comcast.net. [24.4.157.244]) by mx.google.com with ESMTPSA id 10sm17547498pbr.45.2013.05.04.18.01.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 May 2013 18:01:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: Date: Sat, 4 May 2013 18:01:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> To: John R Levine X-Mailer: Apple Mail (2.1503) Cc: bmanning@vacation.karoshi.com, dnsext@ietf.org, Ted.Lemon@nominum.com Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 01:01:11 -0000 On May 4, 2013, at 8:16 AM, John R Levine wrote: >>> ... and interpreting SPF records requires more DNS queries than any = other DNS application I know. >=20 >> So what you are saying is that SPF is a carefully crafted DNS >> DDoS attack because it was too hard to do the work inside your >> own protocol? >=20 > Yup, just like CNAME. >=20 > In the decade that SPF has been around, the putative DDoS has never = been observed in the wild, ever, despite Doug Otis warning us about it = every 15 minutes since 4408 was a draft, and a few experiments I did = with stunt DNS servers that returned giant trees of SPF records very = slowly. It turns out everyone does loop breaking, just like for CNAME. = It's a sloppy design from a decade ago that succeeded because it made an = end run around the DNS provisioning problems of "better" alternatives. >=20 >> What ever happened to "Be Conservative in What you Send..." >=20 > It lost out to Stuff That Actually Exists Works Better than Stuff That = Doesn't. >=20 > A decade ago, SPF was far from my favorite authentication design, but = now it exists, it's more widely used than most standards track = protocols, and it would be silly to pretend otherwise. Hence the spfbis = charter to standardize existing practice. Dear John and Bill, I have heard this canard several times as if it offers some level of = assurance. How does one know whether SPF sourced any particular DDoS = related query? These represent reverse PTR, TXT, A, AAAA record types = at any location. It is also wrong to suggest SPF specification represents existing = practice. Not all providers implemented SPF macro components. The = decision to depreciate SPF (99) RRs happened at roughly the same level = of local-part macro expansion use. Use of local-part macros requires = other mechanisms to prevent unlimited spoofing when SPF pass becomes = independent of the sending client. The impact that such clever = mechanisms may have is unknown if they ever become popular.=20 Thank you Bill for clearly expressing this opinion. Regards, Douglas Otis =20 From bmanning@karoshi.com Sat May 4 18:22:21 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A741C21F9699 for ; Sat, 4 May 2013 18:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3jT5eubiEln for ; Sat, 4 May 2013 18:22:16 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD5C21F905C for ; Sat, 4 May 2013 18:22:16 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id r451MGFo030543; Sun, 5 May 2013 01:22:16 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r451MGAt030542; Sun, 5 May 2013 01:22:16 GMT Date: Sun, 5 May 2013 01:22:16 +0000 From: bmanning@vacation.karoshi.com To: John R Levine Message-ID: <20130505012216.GA29079@vacation.karoshi.com.> References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dnsext@ietf.org, Ted.Lemon@nominum.com Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 01:22:21 -0000 On Sat, May 04, 2013 at 11:16:38AM -0400, John R Levine wrote: > >>... and interpreting SPF records requires more DNS queries than any > >>other DNS application I know. > > > So what you are saying is that SPF is a carefully crafted DNS > > DDoS attack because it was too hard to do the work inside your > > own protocol? > > Yup, just like CNAME. > excuse me, how do you reconcile your first statement; "more DNS queries than -any- other DNS application I know" with "just like CNAME" CNAME semantics and behaviour are well known and studied. You get -ONE- redirect. Other DNS tricks have been DNS-abusive and have been abandon (BITSTRING) or redesigned (KEY/SIG). > In the decade that SPF has been around, the putative DDoS has never been > observed in the wild, ever, despite Doug Otis warning us about it every 15 > minutes since 4408 was a draft, and a few experiments I did with stunt DNS > servers that returned giant trees of SPF records very slowly. It turns > out everyone does loop breaking, just like for CNAME. It's a sloppy > design from a decade ago that succeeded because it made an end run around > the DNS provisioning problems of "better" alternatives. care to publish the experiment and its results? I'd like to replicate it. > > What ever happened to "Be Conservative in What you Send..." > > It lost out to Stuff That Actually Exists Works Better than Stuff That > Doesn't. actually, not so much - there is certainly a whole lot of parasitic behaviour in this decades work - there appears to be evidence that the SPF RR type exists and works. > A decade ago, SPF was far from my favorite authentication design, but now > it exists, it's more widely used than most standards track protocols, and > it would be silly to pretend otherwise. Hence the spfbis charter to > standardize existing practice. Now that I have a hard time believing... "more widely used that most standards track protocols" is a mightly big brush. Perhaps you want to focus on SMTP authentication - then I would have an easier time believing you. > R's, > John From doug.mtview@gmail.com Sat May 4 18:30:45 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF7E21F9699 for ; Sat, 4 May 2013 18:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FU2I9tK24Em1 for ; Sat, 4 May 2013 18:30:40 -0700 (PDT) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by ietfa.amsl.com (Postfix) with ESMTP id F237221F8F1F for ; Sat, 4 May 2013 18:30:39 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w11so1485856pde.37 for ; Sat, 04 May 2013 18:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=Hh7J6nEg2pN5yrAzQ0M7T48q/Zt0YKBKTJ8O/bD0v64=; b=Yz42K80ak++llvkaAKWGDsJr0JtTghy+h1Lmu2TDV0CGdTesxhPlZZqG4DjQTPw8O1 ltUMH/KUC2B4yZSnKoVkKHjFwu+q//+SRU0BvbNnK1GXHHEyOiMl/qopKaEucMh//CdG nKvXe/lNZEJmQ/dRpoaf7JJGmb01gpNF9su2KHNfwdaStouu5DRnQBzY5EkiNROEY7z/ MTcfH4IczU7KznmFIuQHFUPGjGyVJWQqZlaMQbMcFMBdyQXQ6GBBBnvdROUdguHPlbtQ BLjUEpVk7g8fsEmfRr9dhTWNpJbhBJ0Zb1BrrC5lTv+9tF/YyyLq0+Bj3cxUnDLFPqe1 TbWw== X-Received: by 10.68.27.9 with SMTP id p9mr19674071pbg.139.1367717439781; Sat, 04 May 2013 18:30:39 -0700 (PDT) Received: from [192.168.1.194] (c-24-4-157-244.hsd1.ca.comcast.net. [24.4.157.244]) by mx.google.com with ESMTPSA id fx2sm19210046pac.4.2013.05.04.18.30.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 May 2013 18:30:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: <5185b451.85f8420a.05ec.0c69SMTPIN_ADDED_BROKEN@mx.google.com> Date: Sat, 4 May 2013 18:30:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <5185b451.85f8420a.05ec.0c69SMTPIN_ADDED_BROKEN@mx.google.com> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1503) Cc: dnsext@ietf.org, Ted.Lemon@nominum.com Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 01:30:45 -0000 On May 4, 2013, at 6:22 PM, bmanning@vacation.karoshi.com wrote: > On Sat, May 04, 2013 at 11:16:38AM -0400, John R Levine wrote: >>>> ... and interpreting SPF records requires more DNS queries than any=20= >>>> other DNS application I know. >>=20 >>> So what you are saying is that SPF is a carefully crafted DNS >>> DDoS attack because it was too hard to do the work inside your >>> own protocol? >>=20 >> Yup, just like CNAME. >>=20 >=20 > excuse me, how do you reconcile your first statement; "more DNS = queries > than -any- other DNS application I know" with "just like CNAME" >=20 > CNAME semantics and behaviour are well known and studied. You = get -ONE- > redirect. Other DNS tricks have been DNS-abusive and have been = abandon > (BITSTRING) or redesigned (KEY/SIG). >=20 >> In the decade that SPF has been around, the putative DDoS has never = been=20 >> observed in the wild, ever, despite Doug Otis warning us about it = every 15=20 >> minutes since 4408 was a draft, and a few experiments I did with = stunt DNS=20 >> servers that returned giant trees of SPF records very slowly. It = turns=20 >> out everyone does loop breaking, just like for CNAME. It's a sloppy=20= >> design from a decade ago that succeeded because it made an end run = around=20 >> the DNS provisioning problems of "better" alternatives. >=20 > care to publish the experiment and its results? > I'd like to replicate it. >=20 >>> What ever happened to "Be Conservative in What you Send..." >>=20 >> It lost out to Stuff That Actually Exists Works Better than Stuff = That=20 >> Doesn't. >=20 >=20 > actually, not so much - there is certainly a whole lot of = parasitic=20 > behaviour in this decades work - there appears to be evidence = that=20 > the SPF RR type exists and works. >=20 >> A decade ago, SPF was far from my favorite authentication design, but = now=20 >> it exists, it's more widely used than most standards track protocols, = and=20 >> it would be silly to pretend otherwise. Hence the spfbis charter to=20= >> standardize existing practice. >=20 > Now that I have a hard time believing... "more widely used that = most > standards track protocols" is a mightly big brush. Perhaps you = want > to focus on SMTP authentication - then I would have an easier = time=20 > believing you. >=20 >> R's, >> John Dear Bill and John, May I also add, SPF verification of the Mail =46rom parameter provides = authorization for Non-Delivery Notifications. It does not provide any = form of Authentication. Regards, Douglas Otis= From bmanning@karoshi.com Sun May 5 01:53:56 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E8221F8A11 for ; Sun, 5 May 2013 01:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKwEtnMnLV96 for ; Sun, 5 May 2013 01:53:52 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3AD21F8A0C for ; Sun, 5 May 2013 01:53:50 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id r458rnFo006166; Sun, 5 May 2013 08:53:50 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r458rmRb006165; Sun, 5 May 2013 08:53:48 GMT Date: Sun, 5 May 2013 08:53:48 +0000 From: bmanning@vacation.karoshi.com To: John R Levine Message-ID: <20130505085348.GA6061@vacation.karoshi.com.> References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <20130505012216.GA29079@vacation.karoshi.com.> <20130505032549.GA30757@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dnsext@ietf.org Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 08:53:56 -0000 On Sun, May 05, 2013 at 12:51:52AM -0400, John R Levine wrote: > Re CNAME and SPF looping, whatever you call them, the loop breaking issues > are the same. This really isn't a complicated idea. SPF is slightly > uglier since a single SPF record can have multiple includes, but the > solution, a fixed limit on the iterations, is the same. one vs. many ... and the number of includes in SPF is bounded at the upper limit of...? > > Please enumerate "all of the large systems" that use SPF. etc, etc > > Sorry, it's not my job to do your homework. You can get a pretty good > idea of whether a system uses SPF by seeing it if publishes SPF records > (the TXT records mail systems actually use, not the type 99 they don't.) > I expect you can do that better than I can. I'll be pretty surprised if > you find a large system that doesn't other than Yahoo, who doesn't for > internal political reasons, but we know they check SPF since they do > queries for the records when you send them mail. Not my job to prove your unfounded assertions. > > John, your lack of crispness and accuracy suggest that you are > > conflating > > any number of concepts. While the number of messages surrounding > > this > > topic is large, I am confident that your estimates are off by several > > orders of magnitude. > > If you're saying that the author of RFC 6686 is lying about the data he > presents, including 400,000 domains that publish TXT SPF records and the > few thousand that publish type 99, I'll pass the message along. I'm saying that your claim of millions of messages is flawed. No as to the claims for RFC 6686, I'll be happy to take those numbers at face value. (but, yeah, pass my concerns along) 402,000 domains using SPF is barely statistically relevent, considering there are over 350 million domains in existance. just over 1%. > > If the SPF WG had actually read the DNS RFCs, they > > would have known about the formal advice regarding overloading TXT. > > Why did the WG reject this RFC? > > As you would know if you had read the recent traffic in dnsxet and spfbis, > or looked at the spfbis charter, the WG is updating RFC 4408 and > documenting existing practice. Nobody claims that it was a swell idea to > use unprefixed TXT records a decade ago, but unless you can provide us > with a time machine, there's nothing to be done about it now. apparently no one in the spfbis wg bothered to read http://tools.ietf.org/html/rfc5507 and there is no time limit to the choice of a good idea v. a bad idea. a bad idea can and should be questioned at any time - there is no "its too late" arguemnt that should hold, particularly when there is roughly 1% penetration of the service against the number of existing domains. > Despite what the fantasists in dnsext imagine, there is no chance > whatsoever of getting those hundreds of thousands of existing mail systems > to change the way they publish and check SPF data, particularly a change > that has less than no operational benefit. (Don't argue unless you know > more people who run large mail systems than I do, and I meet pretty much > all of them at MAAWG meetings.) The only recent changes I can think of > are that Yahoo used to check both TXT and type 99 and now only checks TXT, > and Micsosoft mail properties including Hotmail gave up on Sender ID and > just check SPF. my what a pessemistic/fatalistic attitude you have there. and again with your unsupported assertions. > > To be clear - at this point I'd really like to see you document any > > formal study of the impact of SPF on the DNS. From any credible > > source. > > Anything. > > The closest thing to a study is what's described in RFC 6686, and it > wasn't looking for effects on the DNS other than to observe in passing the > *fact* that in 2012, when it was published, a lot of DNS servers didn't > respond to type 99 requests at all (no NODATA, no NXDOMAIN, no nothing), > despite that being obviously, painfully wrong. Again, if you don't > believe it, I'll be happy to let the author know you think he's lying. > > Beyond that there is none. No study, no effect. Feel free to prove > otherwise. "No effect"??? You've just completely flipped from your original assertion back on May 3rd, "interpreting SPF records requires more DNS queries than any other DNS application I know." Which is it? I don't need to prove your assertions, I want some proof that your assertions about the impact on the DNS are based on actual facts. /bill > > R's, > John From marka@isc.org Sun May 5 04:06:41 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FAB21F84AF for ; Sun, 5 May 2013 04:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJjGpJsiYm1I for ; Sun, 5 May 2013 04:06:41 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 500FD21F849C for ; Sun, 5 May 2013 04:06:41 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 94510C9428; Sun, 5 May 2013 11:06:38 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367752000; bh=Ddm4p8dlbeO7NLzWtlPNNSKy/eMdkpLLUT4TUsTYKhw=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=hHY/aS07klXg1Y+93bjI0odc73XZx8mHmbcXxLArDaLDJzZ+dKkYXW1QGdNMtGVWb o7nsI3nKut9iOgKzaK2UNnGPBR10Y3QHxcxgP4ZCPRqIHL/mRji7Lmfr+HnzHRVOdo 8nXUiU61dwGXmevTot5JgogFZVofqv1GbjzYuNjo= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Sun, 5 May 2013 11:06:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:fd87:187:5ff3:9a87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3D1FB216C40; Sun, 5 May 2013 11:06:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0D83433E9BFC; Sun, 5 May 2013 21:06:35 +1000 (EST) To: bmanning@vacation.karoshi.com From: Mark Andrews References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <20130505012216.GA29079@vacation.karoshi.com.> <20130505032549.GA30757@vacation.karoshi.com.> <20130505085348.GA6061@vacation.karoshi.com.> In-reply-to: Your message of "Sun, 05 May 2013 08:53:48 +0000." <20130505085348.GA6061@vacation.karoshi.com.> Date: Sun, 05 May 2013 21:06:34 +1000 Message-Id: <20130505110635.0D83433E9BFC@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 11:06:42 -0000 I looked a 25579 unique domains that have sent me email over the last 20 odd years. 737 (2.88%) failed to resolve when queried with SPF of those 737, 178 subequently succeeded with A TXT query 853 (spf query) + 102 (txt query) of those return a non empty answer section (138 + 4 cnames). As far as I can see success difference between SPF and TXT is at the noise level. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From superuser@gmail.com Sun May 5 17:34:02 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E106E21F977E for ; Sun, 5 May 2013 17:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li2uNo9Rddge for ; Sun, 5 May 2013 17:34:02 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D6E0E21F977D for ; Sun, 5 May 2013 17:34:01 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id s10so2639587wey.3 for ; Sun, 05 May 2013 17:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EGFfI+rCCiKoZvXoJPkluVXTtHNLIuktmNte7YPLTdk=; b=UY7IKNchCVuS1LFygYzw9ZDLGXiAxeyUvfpghITneJBBLZzDvQxLhmBznS4ieiaXMe OKC3eTIlNO0cP5NqF6jbO/aVuQfaTnCPko2gQHFW6CoBirpJ8i5S3zFrz9jzOTL92lDI cOgSO7W2k3iuHuZXfw6Hur2r3X2VrCc5d2Gvy7yNuxaTt9CXamJqeTVjW/23MRkmLaQH W5+Tlv8kxbSCjqAbHQnvrOti1j9sBxAPa8MpRddVuKk11i96KxCTT01gDSSCwtIKct2x hlMqGox3NxWw1siC1aIZjMCA/vbgr1bqDTF4MqBWjT1+gh2u3odExR1phdD2LStriJ3b ieIg== MIME-Version: 1.0 X-Received: by 10.195.12.228 with SMTP id et4mr17917033wjd.59.1367800441011; Sun, 05 May 2013 17:34:01 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Sun, 5 May 2013 17:34:00 -0700 (PDT) In-Reply-To: <51861e2f.62a3420a.11ed.ffffc5c1SMTPIN_ADDED_BROKEN@mx.google.com> References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <20130505012216.GA29079@vacation.karoshi.com.> <20130505032549.GA30757@vacation.karoshi.com.> <51861e2f.62a3420a.11ed.ffffc5c1SMTPIN_ADDED_BROKEN@mx.google.com> Date: Sun, 5 May 2013 17:34:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: bmanning@vacation.karoshi.com Content-Type: multipart/alternative; boundary=047d7bb04ad86914cc04dc01db9d Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 00:34:03 -0000 --047d7bb04ad86914cc04dc01db9d Content-Type: text/plain; charset=ISO-8859-1 On Sun, May 5, 2013 at 1:53 AM, wrote: > > If you're saying that the author of RFC 6686 is lying about the data he > > presents, including 400,000 domains that publish TXT SPF records and the > > few thousand that publish type 99, I'll pass the message along. > > I'm saying that your claim of millions of messages is flawed. > No as to the claims for RFC 6686, I'll be happy to take those > numbers > at face value. (but, yeah, pass my concerns along) > 402,000 domains using SPF is barely statistically relevent, > considering > there are over 350 million domains in existance. just over 1%. > Isn't "domains that appear to be sending mail" a more useful universe from which to sample than "registered domains"? apparently no one in the spfbis wg bothered to read > http://tools.ietf.org/html/rfc5507 > and there is no time limit to the choice of a good idea v. a bad > idea. > a bad idea can and should be questioned at any time - there is no > "its too late" arguemnt that should hold, particularly when there > is > roughly 1% penetration of the service against the number of > existing domains. > I'm an existence proof that your claim is false. I've read RFC5507 and I'm familiar with its contents. I've already said that, were we writing this anew, I think we'd likely be taking a different path here, one that would make the members of dnsext much happier. But since the former is false, and there's a substantial deployed base much of which is unlikely to change its behaviour for various reasons, we have to look at this a different way. > > > Despite what the fantasists in dnsext imagine, there is no chance > > whatsoever of getting those hundreds of thousands of existing mail > systems > > to change the way they publish and check SPF data, particularly a change > > that has less than no operational benefit. (Don't argue unless you know > > more people who run large mail systems than I do, and I meet pretty much > > all of them at MAAWG meetings.) The only recent changes I can think of > > are that Yahoo used to check both TXT and type 99 and now only checks > TXT, > > and Micsosoft mail properties including Hotmail gave up on Sender ID and > > just check SPF. > > my what a pessemistic/fatalistic attitude you have there. > and again with your unsupported assertions. > His pessimism is founded in reality. I have similar contact with the same people, and I reach the same conclusion. -MSK --047d7bb04ad86914cc04dc01db9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, May 5, 2013 at 1:53 AM, <bmanning@va= cation.karoshi.com> wrote:
> If you're saying that the author of= RFC 6686 is lying about the data he
> presents, including 400,000 domains that publish TXT SPF records and t= he
> few thousand that publish type 99, I'll pass the message along.
=A0 =A0 =A0 =A0 I'm saying that your claim of millions of messages is f= lawed.
=A0 =A0 =A0 =A0 No as to the claims for RFC 6686, I'll be happy to take= those numbers
=A0 =A0 =A0 =A0 at face value. (but, yeah, pass my concerns along)
=A0 =A0 =A0 =A0 402,000 domains using SPF is barely statistically relevent,= considering
=A0 =A0 =A0 =A0 there are over 350 million domains in existance. =A0just ov= er 1%.

Isn't "domains that app= ear to be sending mail" a more useful universe from which to sample th= an "registered domains"?

=A0 =A0 =A0 =A0 apparently no one in the spfbis wg bothered to read http://tools.ietf= .org/html/rfc5507
=A0 =A0 =A0 =A0 and there is no time limit to the choice of a good idea v. = a bad idea.
=A0 =A0 =A0 =A0 a bad idea can and should be questioned at any time - there= is no
=A0 =A0 =A0 =A0 "its too late" arguemnt that should hold, particu= larly when there is
=A0 =A0 =A0 =A0 roughly 1% penetration of the service against the number of= existing domains.

I'm an existence= proof that your claim is false.=A0 I've read RFC5507 and I'm famil= iar with its contents.=A0 I've already said that, were we writing this = anew, I think we'd likely be taking a different path here, one that wou= ld make the members of dnsext much happier.=A0 But since the former is fals= e, and there's a substantial deployed base much of which is unlikely to= change its behaviour for various reasons, we have to look at this a differ= ent way.
=A0

> Despite what the fantasists in dnsext imagine, there is no chance
> whatsoever of getting those hundreds of thousands of existing mail sys= tems
> to change the way they publish and check SPF data, particularly a chan= ge
> that has less than no operational benefit. =A0(Don't argue unless = you know
> more people who run large mail systems than I do, and I meet pretty mu= ch
> all of them at MAAWG meetings.) =A0The only recent changes I can think= of
> are that Yahoo used to check both TXT and type 99 and now only checks = TXT,
> and Micsosoft mail properties including Hotmail gave up on Sender ID a= nd
> just check SPF.

=A0 =A0 =A0 =A0 my what a pessemistic/fatalistic attitude you have there. =A0 =A0 =A0 =A0 and again with your unsupported assertions.

His pessimism is founded in reality.=A0 I have similar= contact with the same people, and I reach the same conclusion.
=A0
<= /div>-MSK
--047d7bb04ad86914cc04dc01db9d-- From superuser@gmail.com Sun May 5 17:36:15 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BD821F977D for ; Sun, 5 May 2013 17:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrpKkOYZDt-T for ; Sun, 5 May 2013 17:36:14 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCD821F9777 for ; Sun, 5 May 2013 17:36:14 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hm14so2059232wib.11 for ; Sun, 05 May 2013 17:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3tYbFMha4iV5iJv/lJrK62aV0tAseZEAxMiZqWsxmfI=; b=gFQng15GYNBXd1hkuHeERy/dMNiJNI4joYUiaBWT1vD+eiF4JT5eYzDsw8KHt3GIPP camCzMmYld4S2uuRmiH3L1NBZUXvVS8Sn8cJWZHExJ9ewnQCd25U5knjSlEcBsGz9mj8 +QOBg4ZjwxPhvvcEkpnWi3tk60wW1TwlNvx/vBbF/YCSQb/0634PBE5q0lhvHQ8Bxtc/ WRH6+MP4FZYmcy6ZpU3e9l4Hn115yZfysrLHR22oD5swqnDoCFDqSUgp4nbt7/VViHXA oivfWewSd8n328A2SRGtq5tNEerVoEJ5SRHPKi3mU2QTvIj2xTgaleXjPj0PqhE1+nul JhwQ== MIME-Version: 1.0 X-Received: by 10.180.72.227 with SMTP id g3mr11467564wiv.1.1367800573368; Sun, 05 May 2013 17:36:13 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Sun, 5 May 2013 17:36:13 -0700 (PDT) In-Reply-To: <20130505110635.0D83433E9BFC@drugs.dv.isc.org> References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <20130505012216.GA29079@vacation.karoshi.com.> <20130505032549.GA30757@vacation.karoshi.com.> <20130505085348.GA6061@vacation.karoshi.com.> <20130505110635.0D83433E9BFC@drugs.dv.isc.org> Date: Sun, 5 May 2013 17:36:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mark Andrews Content-Type: multipart/alternative; boundary=f46d043c81924ca1ca04dc01e3aa Cc: bmanning@vacation.karoshi.com, "dnsext@ietf.org Group" Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 00:36:15 -0000 --f46d043c81924ca1ca04dc01e3aa Content-Type: text/plain; charset=ISO-8859-1 On Sun, May 5, 2013 at 4:06 AM, Mark Andrews wrote: > I looked a 25579 unique domains that have sent me email > over the last 20 odd years. > That's a far more constrained sample size than the RFC6686 surveys used, and I have some vague thoughts about likely bias of mail going to isc.org. -MSK --f46d043c81924ca1ca04dc01e3aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --f46d043c81924ca1ca04dc01e3aa-- From marka@isc.org Sun May 5 18:12:49 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FE121F973A for ; Sun, 5 May 2013 18:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tcr+X3LnhI96 for ; Sun, 5 May 2013 18:12:48 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7011421F96E6 for ; Sun, 5 May 2013 18:12:48 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id D02CDC9465; Mon, 6 May 2013 01:12:40 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367802766; bh=CXOXoUVF/YxRiQfU6UbcwiTLwEBY855wrj9gyrTlUko=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=VTl1XqfP99aimP2t5oZz8k29FZS4C5oUyy5VjMzkIzmeUQb0kzh4Ghq7ykyl7GMn4 3VpOSfL5PqvnhMG3MWqOU2lb4UzFv03loModTUp4kkGo4wrsNBa876PhST1KS/LO5T v1e9XtFBxOR2WtPTGErWaz508wf2kA/kSPxLK6vM= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Mon, 6 May 2013 01:12:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6F8F9216C40; Mon, 6 May 2013 01:12:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id A1AD633EB06B; Mon, 6 May 2013 11:12:36 +1000 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <20130505012216.GA29079@vacation.karoshi.com.> <20130505032549.GA30757@vacation.karoshi.com.> <20130505085348.GA6061@vacation.karoshi.com.> <20130505110635.0D83433E9BFC@drugs.dv.isc.org> In-reply-to: Your message of "Sun, 05 May 2013 17:36:13 -0700." Date: Mon, 06 May 2013 11:12:36 +1000 Message-Id: <20130506011236.A1AD633EB06B@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: bmanning@vacation.karoshi.com, "dnsext@ietf.org Group" Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 01:12:49 -0000 In message , "Murray S. Kucherawy" writes: > > On Sun, May 5, 2013 at 4:06 AM, Mark Andrews wrote: > > > I looked a 25579 unique domains that have sent me email > > over the last 20 odd years. > > That's a far more constrained sample size than the RFC6686 surveys used, > and I have some vague thoughts about likely bias of mail going to isc.org. That list of domains includes personal as well as business correspondence, spam sources, mail from various mailing lists. And RFC6686 is biased as it use the Alexa top X which is known to use more load balancers which are often not RFC 103[45] compliant name servers. They don't do negative answers properly. Fixing one set of nameservers in the Alexa top X can drastically change the numbers as many domains Alexa top X are served by identical sets of name servers. The vast majority of name servers (from sites sending email or not) respond to both TXT and SPF queries. Of those that don't most are broken for both TXT and SPF (and AAAA and NS and SOA). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From superuser@gmail.com Mon May 6 01:31:18 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549FA21F8F0D for ; Mon, 6 May 2013 01:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uBRfQVKSolJ for ; Mon, 6 May 2013 01:31:17 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC5521F8F0C for ; Mon, 6 May 2013 01:31:17 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hm14so2277403wib.17 for ; Mon, 06 May 2013 01:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ghxvygl9w0u30i4Pw81l7Qm4CUYo4IoffShYN/dCHxI=; b=XjnzVUk2IZLpQ8k4f/27qF/cJJb7OCArWRMfM3TWaYfYPxg6JVF5FkeR+uI1G0YKhH ewMgZJZAcnVX7D+LTsvWV1mMy3goVUjM/w6sHh4Awok/mmzA3E/M1UX5/3znYaxkQUdC /dRetC7t0SeelB4r8QL8PxIM38RaFVh9wGIZOn4duPN7TvvQDPnhDGuYAYfydCsDZcLI 9B6TE/Tgbx25b7pdIvpV+se4m+Xp/gAwpl6wCc9xCe2Q3mAGTh6t1w7LinrOqUAkX5Lx IIRgEndhFlKo3DJK8kW4Mz/IVfgxKOMPD/NqgjH/SWViNfj90UQDpJgRiNONHYdR65UK iO3w== MIME-Version: 1.0 X-Received: by 10.194.59.208 with SMTP id b16mr23957950wjr.15.1367829076823; Mon, 06 May 2013 01:31:16 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 6 May 2013 01:31:16 -0700 (PDT) In-Reply-To: <20130506011236.A1AD633EB06B@drugs.dv.isc.org> References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <20130505012216.GA29079@vacation.karoshi.com.> <20130505032549.GA30757@vacation.karoshi.com.> <20130505085348.GA6061@vacation.karoshi.com.> <20130505110635.0D83433E9BFC@drugs.dv.isc.org> <20130506011236.A1AD633EB06B@drugs.dv.isc.org> Date: Mon, 6 May 2013 01:31:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mark Andrews Content-Type: multipart/alternative; boundary=047d7b86de323cd4af04dc088666 Cc: bmanning@vacation.karoshi.com, "dnsext@ietf.org Group" Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 08:31:18 -0000 --047d7b86de323cd4af04dc088666 Content-Type: text/plain; charset=ISO-8859-1 On Sun, May 5, 2013 at 6:12 PM, Mark Andrews wrote: > And RFC6686 is biased as it use the Alexa top X which is known to > use more load balancers which are often not RFC 103[45] compliant > name servers. They don't do negative answers properly. Fixing one > set of nameservers in the Alexa top X can drastically change the > numbers as many domains Alexa top X are served by identical sets > of name servers. > 1) I think you're supporting RFC6686's conclusions there. 2) There was more than just the Alexa survey in RFC6686. -MSK --047d7b86de323cd4af04dc088666 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --047d7b86de323cd4af04dc088666-- From dougb@dougbarton.us Mon May 6 01:38:10 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A07521F8F6C for ; Mon, 6 May 2013 01:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJPfN6G742-G for ; Mon, 6 May 2013 01:38:06 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 0389921F8793 for ; Mon, 6 May 2013 01:38:06 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:bd97:326e:ce:1bc7] (unknown [IPv6:2001:470:d:5e7:bd97:326e:ce:1bc7]) by dougbarton.us (Postfix) with ESMTPSA id 79A6C22B3F for ; Mon, 6 May 2013 08:38:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1367829485; bh=TnhDxZ9lCG4f40u2T21jeicn4AeZuFaAhRFOOpekyNc=; h=Date:From:To:Subject:References:In-Reply-To; b=meLUXJeFMTxDmEUo6UA53nvJmM2NjyrpNM8OeucNWi3T6Cc3WHbr9N7dpn8FJyzbr ra0Jlj4ZLYRzQCDh1RNcm9VO7uPp2dDp9lElOWTz0SCeZNu0qrqifl0ahOFJELwIUM OgKvuU2h2lm43AcLZFFHr2P1eGrzmN7grs4Dvsb4= Message-ID: <51876BED.9020600@dougbarton.us> Date: Mon, 06 May 2013 01:38:05 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <20130505012216.GA29079@vacation.karoshi.com.> <20130505032549.GA30757@vacation.karoshi.com.> <20130505085348.GA6061@vacation.karoshi.com.> <20130505110635.0D83433E9BFC@drugs.dv.isc.org> <20130506011236.A1AD633EB06B@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 08:38:10 -0000 On 05/06/2013 01:31 AM, Murray S. Kucherawy wrote: > On Sun, May 5, 2013 at 6:12 PM, Mark Andrews > wrote: > > And RFC6686 is biased as it use the Alexa top X which is known to > use more load balancers which are often not RFC 103[45] compliant > name servers. They don't do negative answers properly. Fixing one > set of nameservers in the Alexa top X can drastically change the > numbers as many domains Alexa top X are served by identical sets > of name servers. > > > 1) I think you're supporting RFC6686's conclusions there. 6686 asked the wrong questions, and then used the data to come to the wrong conclusions. It's totally irrelevant to the question, "How should SPF be done properly going forward?" Doug From bmanning@karoshi.com Mon May 6 05:58:50 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D3621F8F87 for ; Mon, 6 May 2013 05:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSZxIOjQ-kTJ for ; Mon, 6 May 2013 05:58:36 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3862D21F8F24 for ; Mon, 6 May 2013 05:58:36 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id r46CwTFo013465; Mon, 6 May 2013 12:58:29 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r46CwS8f013463; Mon, 6 May 2013 12:58:28 GMT Date: Mon, 6 May 2013 12:58:23 +0000 From: bmanning@vacation.karoshi.com To: "Murray S. Kucherawy" Message-ID: <20130506125823.GA13430@vacation.karoshi.com.> References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <20130505012216.GA29079@vacation.karoshi.com.> <20130505032549.GA30757@vacation.karoshi.com.> <51861e2f.62a3420a.11ed.ffffc5c1SMTPIN_ADDED_BROKEN@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, "dnsext@ietf.org Group" Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 12:58:50 -0000 On Sun, May 05, 2013 at 05:34:00PM -0700, Murray S. Kucherawy wrote: > On Sun, May 5, 2013 at 1:53 AM, wrote: > > > > If you're saying that the author of RFC 6686 is lying about the data he > > > presents, including 400,000 domains that publish TXT SPF records and the > > > few thousand that publish type 99, I'll pass the message along. > > > > I'm saying that your claim of millions of messages is flawed. > > No as to the claims for RFC 6686, I'll be happy to take those > > numbers > > at face value. (but, yeah, pass my concerns along) > > 402,000 domains using SPF is barely statistically relevent, > > considering > > there are over 350 million domains in existance. just over 1%. > > > > Isn't "domains that appear to be sending mail" a more useful universe from > which to sample than "registered domains"? Probably - but I was following Johns usage. > > apparently no one in the spfbis wg bothered to read > > http://tools.ietf.org/html/rfc5507 > > and there is no time limit to the choice of a good idea v. a bad > > idea. > > a bad idea can and should be questioned at any time - there is no > > "its too late" arguemnt that should hold, particularly when there > > is > > roughly 1% penetration of the service against the number of > > existing domains. > > > > I'm an existence proof that your claim is false. I've read RFC5507 and I'm > familiar with its contents. I've already said that, were we writing this > anew, I think we'd likely be taking a different path here, one that would > make the members of dnsext much happier. But since the former is false, > and there's a substantial deployed base much of which is unlikely to change > its behaviour for various reasons, we have to look at this a different way. there is this wonderful thing called "O'Dells Law" which, paraphrased is: "The installed based doesn't matter". However, there is nothing preventing the SPF community from using TXT to store thier particularly unique stuff. But there can be zero whining when other folks use TXT for their own purposes and confuse the heck out of SPF processors which get (for thier purposes) malformed SPF data... > > > Despite what the fantasists in dnsext imagine, there is no chance > > > whatsoever of getting those hundreds of thousands of existing mail > > systems > > > to change the way they publish and check SPF data, particularly a change > > > that has less than no operational benefit. (Don't argue unless you know > > > more people who run large mail systems than I do, and I meet pretty much > > > all of them at MAAWG meetings.) The only recent changes I can think of > > > are that Yahoo used to check both TXT and type 99 and now only checks > > TXT, > > > and Micsosoft mail properties including Hotmail gave up on Sender ID and > > > just check SPF. > > > > my what a pessemistic/fatalistic attitude you have there. > > and again with your unsupported assertions. > > His pessimism is founded in reality. I have similar contact with the same > people, and I reach the same conclusion. Sounds very much like the folks who hijacked net 1.0.0.0/8 for their wireless/NAT space. (Or pretty much anyone who has "borrowed" IP space because it was too hard to get/justify the space properly.) They have no incentive to change their installed base... except for interoperability problems. /bill > > -MSK From superuser@gmail.com Mon May 6 07:04:25 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C7621F9154 for ; Mon, 6 May 2013 07:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr2DSXcEJ-Kn for ; Mon, 6 May 2013 07:04:24 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A09A221F9223 for ; Mon, 6 May 2013 07:04:17 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id c11so3586035wgh.22 for ; Mon, 06 May 2013 07:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HCZ4YYVy6jZrIizPEBaZcJqkU4LYyzaKk1PGQtLwREE=; b=FYut/5NpPg2bCu/qabWlQCN0Q8N6r5/SrPKIpPaKTU+Fl1NRuTSRLBkJbeHpRb+Pmc PyyeQNEuPXGbC4Q9196QJ+DmrJTE9UAxPLzV0Z6mjAtC2RiSYQBuGRjbi82aKlfBh4+9 EROAV0jBKAEbtMIux4jXKTsLzYCeH9FWN5gF/Hi0Im47QzVKQXy5mzfnfTgsT2hBpr5X 1yEEoYNs590FUznS08n11GSpVt48kSO9FhnoYqd9nRFFJomfTU/OdiUuMZ68xDAcqwwG 2/tkYRDiEwSY852vriSqUilNCZuFWbYVgine86C1N3ciSl6Lmi7Pepv3LaYZQsg1Sm/x dyVw== MIME-Version: 1.0 X-Received: by 10.195.12.228 with SMTP id et4mr20875834wjd.59.1367849056809; Mon, 06 May 2013 07:04:16 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 6 May 2013 07:04:16 -0700 (PDT) In-Reply-To: <5187a8f9.852acd0a.12c2.7d46SMTPIN_ADDED_BROKEN@mx.google.com> References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <20130505012216.GA29079@vacation.karoshi.com.> <20130505032549.GA30757@vacation.karoshi.com.> <51861e2f.62a3420a.11ed.ffffc5c1SMTPIN_ADDED_BROKEN@mx.google.com> <5187a8f9.852acd0a.12c2.7d46SMTPIN_ADDED_BROKEN@mx.google.com> Date: Mon, 6 May 2013 07:04:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: bmanning@vacation.karoshi.com Content-Type: multipart/alternative; boundary=047d7bb04ad8233d1a04dc0d2dca Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 14:04:25 -0000 --047d7bb04ad8233d1a04dc0d2dca Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 6, 2013 at 5:58 AM, wrote: > there is this wonderful thing called "O'Dells Law" which, > paraphrased > is: "The installed based doesn't matter". However, there is > nothing > preventing the SPF community from using TXT to store thier > particularly > unique stuff. But there can be zero whining when other folks use > TXT for > their own purposes and confuse the heck out of SPF processors > which get > (for thier purposes) malformed SPF data... > Numerous such cases exist (I gave ut.edu as an example) and nobody is doing any of the aforementioned whining. Establishing a loop across a set of strings looking for the one that starts "v=spf1" is hardly rocket science. If that's the primary concern, I think we're good to go from here. -MSK --047d7bb04ad8233d1a04dc0d2dca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 6, 2013 at 5:58 AM, <bmanning@va= cation.karoshi.com> wrote:
=A0 =A0 =A0 =A0 there is this wonderful thin= g called "O'Dells Law" which, paraphrased
=A0 =A0 =A0 =A0 is: =A0"The installed based doesn't matter". = =A0 However, there is nothing
=A0 =A0 =A0 =A0 preventing the SPF community from using TXT to store thier = particularly
=A0 =A0 =A0 =A0 unique stuff. =A0But there can be zero whining when other f= olks use TXT for
=A0 =A0 =A0 =A0 their own purposes and confuse the heck out of SPF processo= rs which get
=A0 =A0 =A0 =A0 (for thier purposes) malformed SPF data...

Numerous such cases exist (I gave ut.edu as an example) and nobody is doing any of the afore= mentioned whining.=A0 Establishing a loop across a set of strings looking f= or the one that starts "v=3Dspf1" is hardly rocket science.=A0 If= that's the primary concern, I think we're good to go from here.
-MSK
--047d7bb04ad8233d1a04dc0d2dca-- From marka@isc.org Tue May 7 07:45:24 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5900E21F8E75 for ; Tue, 7 May 2013 07:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irz8uGXsltrI for ; Tue, 7 May 2013 07:45:23 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5562F21F8616 for ; Tue, 7 May 2013 07:45:23 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id E2CA75F98E6; Tue, 7 May 2013 14:45:11 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367937922; bh=F9gu9wpceXId3tnX8ksTjRF4t05VdC7C4XgeaCwfVJA=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=qpr+k0ChbpLZj4JnzHUUgExLipNyO88ah6YDq4Lhc0JPcM/ogeXosU+pGQbV11/59 dUXsCf7WQ06TqFseoo77lrbBni8GmBDpHEjwVr0xuZvu2YmVkPoNw2fvID/kj+UCWz pgvP+tKzxn+yXIW51Me0j2BsJBDCLyQnQwnACxHI= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:5c2a:7407:e708:cbb]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 46003216C43; Tue, 7 May 2013 14:45:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id BEB2D33F8406; Wed, 8 May 2013 00:44:16 +1000 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <20130505012216.GA29079@vacation.karoshi.com.> <20130505032549.GA30757@vacation.karoshi.com.> <20130505085348.GA6061@vacation.karoshi.com.> <20130505110635.0D83433E9BFC@drugs.dv.isc.org> <20130506011236.A1AD633EB06B@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 06 May 2013 01:31:16 -0700." Date: Wed, 08 May 2013 00:44:16 +1000 Message-Id: <20130507144416.BEB2D33F8406@drugs.dv.isc.org> Cc: bmanning@vacation.karoshi.com, "dnsext@ietf.org Group" Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 14:45:24 -0000 In message , "Murray S. Kucherawy" writes: > --047d7b86de323cd4af04dc088666 > Content-Type: text/plain; charset=ISO-8859-1 > > On Sun, May 5, 2013 at 6:12 PM, Mark Andrews wrote: > > > And RFC6686 is biased as it use the Alexa top X which is known to > > use more load balancers which are often not RFC 103[45] compliant > > name servers. They don't do negative answers properly. Fixing one > > set of nameservers in the Alexa top X can drastically change the > > numbers as many domains Alexa top X are served by identical sets > > of name servers. > > > > 1) I think you're supporting RFC6686's conclusions there. > > 2) There was more than just the Alexa survey in RFC6686. > > -MSK As far as I can see there is nothing in it with respect to failure rates and spf sites using type SPF are approaching 8% which is a significant increase (2x) since the RFC6686 surveys. TXT: 22157 NOERROR, 2777 NXDOMAIN, 645 SERVFAIL, 9289 v=spf1 SPF: 22068 NOERROR, 2774 NXDOMAIN, 737 SERVFAIL, 730 v=spf1 CASE1 CASE2 CASE3 8614 txt only 33.7% 92.2% 96.8% 96.6% 95.2% 55 spf only 0.2% 0.6% 675 txt + spf 2.6% 7.2% have spf 7.8% 3.2% 3.4% 4.8% Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From hallam@gmail.com Tue May 7 15:14:50 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F5821F918C for ; Tue, 7 May 2013 15:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUpTSG4RqDSI for ; Tue, 7 May 2013 15:14:49 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E978E21F881C for ; Tue, 7 May 2013 15:14:48 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id q57so1055444wes.23 for ; Tue, 07 May 2013 15:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9cTEBhzpf8GJ+P1xdIxsGGhJyUdY5vlizQnT0WrYirY=; b=BmEAx1+LgpoEH8DRnL/U8DtkQO68BlaeGKKamQZcYy60WfqrQbbF3xeraGCZcaRrUz +IbrZbB8WsIaVv8RAqkNIsBrOcrQE/4VTQNIGXsfp6eU5kupQLUa1oFjf+vUMUuEiedZ Kj1GvONhu7UTj+rQzXhhJCAydQFlS9AFRLAyXjd7H/k5Z4U0wMdjuVqI+B7ofarht84p bCLRG5xoMLLpapZ/MJd12epgn/J+V5oIeguA8n2IKbucbd1PgJhv/iU4Iz96wriZkdSs JOAz2HxhPd7ZtGJWWwsgHTM5eawI9mtw1wB1WfSMK4LFwNE2ei4ebk+Ak75KeYj/xn5/ Kq7Q== MIME-Version: 1.0 X-Received: by 10.194.61.45 with SMTP id m13mr6339161wjr.20.1367964886711; Tue, 07 May 2013 15:14:46 -0700 (PDT) Received: by 10.194.121.161 with HTTP; Tue, 7 May 2013 15:14:46 -0700 (PDT) In-Reply-To: <5187a917.62a3420a.7013.5f98SMTPIN_ADDED_BROKEN@mx.google.com> References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <20130505012216.GA29079@vacation.karoshi.com.> <20130505032549.GA30757@vacation.karoshi.com.> <51861e2f.62a3420a.11ed.ffffc5c1SMTPIN_ADDED_BROKEN@mx.google.com> <5187a917.62a3420a.7013.5f98SMTPIN_ADDED_BROKEN@mx.google.com> Date: Wed, 8 May 2013 00:14:46 +0200 Message-ID: From: Phillip Hallam-Baker To: "bmanning@vacation.karoshi.com" Content-Type: multipart/alternative; boundary=047d7ba976a423458404dc2825e1 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 22:14:50 -0000 --047d7ba976a423458404dc2825e1 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 6, 2013 at 2:58 PM, wrote: > > > I'm an existence proof that your claim is false. I've read RFC5507 and > I'm > > familiar with its contents. I've already said that, were we writing this > > anew, I think we'd likely be taking a different path here, one that would > > make the members of dnsext much happier. But since the former is false, > > and there's a substantial deployed base much of which is unlikely to > change > > its behaviour for various reasons, we have to look at this a different > way. > > > there is this wonderful thing called "O'Dells Law" which, > paraphrased > is: "The installed based doesn't matter". However, there is > nothing > preventing the SPF community from using TXT to store thier > particularly > unique stuff. But there can be zero whining when other folks use > TXT for > their own purposes and confuse the heck out of SPF processors > which get > (for thier purposes) malformed SPF data... > > O'Dells Law only applies AFTER you have reached critical mass and growth is automatic. If you are in a situation where the installed base meets the requirements just fine then the new proposal doesn't matter and will actually shrink over time as a percentage of the installed base as people continue to use the legacy system. If the numer of domains with feature X is growing at a significantly faster rate than the Internet then it will become ~100% in due course. If the numer of domains with feature X is growing at a significantly slower rate than the Internet then it will become ~0% in due course. About one year after an RFC has been published there is sometimes a sudden shock of realization that maybe deployment did matter after all. Catching an existing system is very hard. Apart from POP vs IMAP and WWW vs Gopher, I can't remember any examples offhand. -- Website: http://hallambaker.com/ --047d7ba976a423458404dc2825e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, May 6, 2013 at 2:58 PM, <bmanning@vacation.ka= roshi.com> wrote:

> I'm an existence proof that your claim is false. =A0I've read = RFC5507 and I'm
> familiar with its contents. =A0I've already said that, were we wri= ting this
> anew, I think we'd likely be taking a different path here, one tha= t would
> make the members of dnsext much happier. =A0But since the former is fa= lse,
> and there's a substantial deployed base much of which is unlikely = to change
> its behaviour for various reasons, we have to look at this a different= way.


=A0 =A0 =A0 =A0 there is this wonderful thing called "O'Dell= s Law" which, paraphrased
=A0 =A0 =A0 =A0 is: =A0"The installed based doesn't matter". = =A0 However, there is nothing
=A0 =A0 =A0 =A0 preventing the SPF community from using TXT to store thier = particularly
=A0 =A0 =A0 =A0 unique stuff. =A0But there can be zero whining when other f= olks use TXT for
=A0 =A0 =A0 =A0 their own purposes and confuse the heck out of SPF processo= rs which get
=A0 =A0 =A0 =A0 (for thier purposes) malformed SPF data...


O'De= lls Law only applies AFTER you have reached critical mass and growth is aut= omatic.

If you are in a situation wher= e the installed base meets the requirements just fine then the new proposal= doesn't matter and will actually shrink over time as a percentage of t= he installed base as people continue to use the legacy system.

If the numer of domains with feature X is g= rowing at a significantly faster rate than the Internet then it will become= ~100% in due course.

If the numer of = domains with feature X is growing at a significantly slower rate than the I= nternet then it will become ~0% in due course.


About one year after an RFC = has been published there is sometimes a sudden shock of realization that ma= ybe deployment did matter after all. Catching an existing system is very ha= rd. Apart from POP vs IMAP and WWW vs Gopher, I can't remember any exam= ples offhand.

--
Website: http://h= allambaker.com/
--047d7ba976a423458404dc2825e1-- From marka@isc.org Tue May 7 16:14:15 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E39D21F8EFE for ; Tue, 7 May 2013 16:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgHCVoyvDdpX for ; Tue, 7 May 2013 16:14:15 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 0864D21F8E75 for ; Tue, 7 May 2013 16:14:14 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id EEF81C9450; Tue, 7 May 2013 23:14:03 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367968453; bh=rweJudG4O3AdbCOxXdTnPEpIC2ZvO+uSfi9mILkB670=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=atpCdQDDsVibouCAoXyP3RK4/TGn14dCEuEp9I1p5s1bfrNJWrYYZi/RiLaiMwv3Y LuNyBfFTAOhkH57OYGU6J5TjKU5j30mr3Px+VxQQH42kJd9KPDNAhjbH8rWNEu4j4F giisbXGJTbBEgIKraI83LvS7ndpt7Yntr3EXpdSw= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Tue, 7 May 2013 23:14:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:5c2a:7407:e708:cbb]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id AAE4C216C40; Tue, 7 May 2013 23:14:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id EDF9633FB488; Wed, 8 May 2013 09:13:55 +1000 (EST) To: Phillip Hallam-Baker From: Mark Andrews References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <20130505012216.GA29079@vacation.karoshi.com.> <20130505032549.GA30757@vacation.karoshi.com.> <51861e2f.62a3420a.11ed.ffffc5c1SMTPIN_ADDED_BROKEN@mx.google.com> <5187a917.62a3420a.7013.5f98SMTPIN_ADDED_BROKEN@mx.google.com> In-reply-to: Your message of "Wed, 08 May 2013 00:14:46 +0200." Date: Wed, 08 May 2013 09:13:55 +1000 Message-Id: <20130507231355.EDF9633FB488@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "bmanning@vacation.karoshi.com" , "dnsext@ietf.org Group" Subject: Re: [dnsext] SPF, a cautionary tale X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 23:14:15 -0000 In message , Phillip Hallam-Baker writes: > > On Mon, May 6, 2013 at 2:58 PM, wrote: > > > > > > I'm an existence proof that your claim is false. I've read RFC5507 and > > I'm > > > familiar with its contents. I've already said that, were we writing this > > > anew, I think we'd likely be taking a different path here, one that would > > > make the members of dnsext much happier. But since the former is false, > > > and there's a substantial deployed base much of which is unlikely to > > change > > > its behaviour for various reasons, we have to look at this a different > > way. > > > > > > there is this wonderful thing called "O'Dells Law" which, > > paraphrased > > is: "The installed based doesn't matter". However, there is > > nothing > > preventing the SPF community from using TXT to store thier > > particularly > > unique stuff. But there can be zero whining when other folks use > > TXT for > > their own purposes and confuse the heck out of SPF processors > > which get > > (for thier purposes) malformed SPF data... > > > > > O'Dells Law only applies AFTER you have reached critical mass and growth is > automatic. > > If you are in a situation where the installed base meets the requirements > just fine then the new proposal doesn't matter and will actually shrink > over time as a percentage of the installed base as people continue to use > the legacy system. > > If the numer of domains with feature X is growing at a significantly faster > rate than the Internet then it will become ~100% in due course. > > If the numer of domains with feature X is growing at a significantly slower > rate than the Internet then it will become ~0% in due course. > > > About one year after an RFC has been published there is sometimes a sudden > shock of realization that maybe deployment did matter after all. Catching > an existing system is very hard. Apart from POP vs IMAP and WWW vs Gopher, > I can't remember any examples offhand. > > -- > Website: http://hallambaker.com/ Both SPF queries and SPF records are growing w.r.t. TXT records and queries so the arguement is moot. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ted.Lemon@nominum.com Sat May 11 08:25:44 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC4D21F90FD for ; Sat, 11 May 2013 08:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzsBecfBR9DM for ; Sat, 11 May 2013 08:25:38 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8909921F90BB for ; Sat, 11 May 2013 08:25:38 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUY5i8bOY1Je4HLLyFFP3a8CzL3kY3UUv@postini.com; Sat, 11 May 2013 08:25:38 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4E15C1B8053 for ; Sat, 11 May 2013 08:25:37 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4394819005D; Sat, 11 May 2013 08:25:37 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sat, 11 May 2013 08:25:30 -0700 From: Ted Lemon To: "dnsext@ietf.org Group" Thread-Topic: Updates to draft-ietf-dnsext-dnssec-algo-signal draft as a result of IESG review Thread-Index: AQHOTlvEBXdp6nQNbEuty8FlVsj2Dg== Date: Sat, 11 May 2013 15:25:28 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077517C4EF@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <302C5A93F939B142B9B4E22C2D9260F6@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete Resnick Subject: [dnsext] Updates to draft-ietf-dnsext-dnssec-algo-signal draft as a result of IESG review X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 15:25:44 -0000 During IESG review some subtle issues were raised with the DNSSEC algorithm= signaling draft that resulted in an RFC editor note being added to the doc= ument. I'm writing this note to apprise the working group of the changes = that were made. My expectation is that the working group will not see any= of these changes as substantially changing the document in a way that woul= d influence the outcome of the last call, but they are not merely editorial= , so it seemed appropriate to give the working group a shot at them. The complete editor's note is here: http://datatracker.ietf.org/doc/draft-i= etf-dnsext-dnssec-algo-signal/writeup/ The particular change to which I want to draw your attention relate to the = question of what it means for a resolver to be a validating resolver. The= document as submitted by the working group allowed for the possibility tha= t a validating resolver might not set the DO bit; this then led to an ambig= uity in section 5 about the processing of the three new options. The text as submitted by the working group said that the server doesn't pro= cess the options if the DO bit isn't set. The question was raised: what i= f a validating resolver doesn't set the DO bit for a particular query? Do= n't we still care, in principle, what algorithms it supports? The clarifying change is the change to section 3.1.1: a validating stub res= olver is now defined for the purposes of the document as one that sets the = DO bit. The actual piece of software running on the host may sometimes se= t the DO bit and sometimes not, but we only _treat_ it as a validating reso= lver if it does. If this sounds like an interesting point to you, please check out the edito= r's note and see how it affects the draft. If we don't hear any substanti= ve objection by midweek, I will release the document for publication with t= he editor's note as is. There are a number of editorial changes in the edi= tor's note as well; the changes that pertain to this question are specifica= lly those that address 3.1.1 and 3.2.1. From fw@deneb.enyo.de Sat May 11 13:36:36 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D54221F859D for ; Sat, 11 May 2013 13:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL7pQ9ibQQnI for ; Sat, 11 May 2013 13:36:31 -0700 (PDT) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2367B21F8518 for ; Sat, 11 May 2013 13:36:30 -0700 (PDT) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1UbGWq-00020z-Q0; Sat, 11 May 2013 22:36:28 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1UbGX4-0006yD-2x; Sat, 11 May 2013 22:36:42 +0200 From: Florian Weimer To: David Miller References: <20130504014825.42875.qmail@joyce.lan> <5184870C.5020904@tiggee.com> Date: Sat, 11 May 2013 22:36:41 +0200 In-Reply-To: <5184870C.5020904@tiggee.com> (David Miller's message of "Fri, 03 May 2013 23:57:00 -0400") Message-ID: <87li7ljlt2.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dnsext@ietf.org Subject: Re: [dnsext] loads of TXT records for fun and profit X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 20:36:36 -0000 * David Miller: > TXT records don't have a specified maximum length, but they cannot be > arbitrarily long. They have to fit into an RR. RDLENGTH, which > specifies the length of the RDATA field, is an unsigned 16 bit integer > (max 65535). See RFC 1035 sec 3.2.1. > > 64k is very long, but not arbitrarily long. It's also the overall packet length limit, so an entire RRset cannot be larger. From iesg-secretary@ietf.org Fri May 17 14:10:52 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C5C21F96C3; Fri, 17 May 2013 14:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6bxof8xC14V; Fri, 17 May 2013 14:10:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9495221F96D3; Fri, 17 May 2013 14:10:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130517211048.11271.22071.idtracker@ietfa.amsl.com> Date: Fri, 17 May 2013 14:10:48 -0700 Cc: dnsext chair , dnsext mailing list , RFC Editor Subject: [dnsext] Protocol Action: 'Signaling Cryptographic Algorithm Understanding in DNSSEC' to Proposed Standard (draft-ietf-dnsext-dnssec-algo-signal-10.txt) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 21:10:52 -0000 The IESG has approved the following document: - 'Signaling Cryptographic Algorithm Understanding in DNSSEC' (draft-ietf-dnsext-dnssec-algo-signal-10.txt) as Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/ Technical Summary The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. Working Group Summary The DNSEXT WG members reviewed and commented on previous revisions of the document. All substantive comments were reviewed and the document updated accordingly. Most reviewers feel that the proposed extensions would be harmless to the protocol and would be useful for measuring cryptographic algorithm implementation uptake in clients. A minority of the reviewers questioned the need for such signalling. No reviewers flagged the existence of the proposed EDNS0 extension create interoperability or deployment problems. Document Quality The document does not change any protocol or change client or server processing in any significant way, but proposes a new option to EDNS(0) to aid authoritative DNS zone administrators to measure cryptograpic algorithm code in clients. Personnel Patrik Fältström is the Document Shepherd, and Ted Lemon is the Responsible Area Director. RFC Editor Note Please make the following changes, to which the authors have agreed: Section 1 Introduction OLD: Each digital signature RR (RRSIG) contains an algorithm code number. NEW: Each digital signature (RRSIG) RR contains an algorithm code number that corresponds to a DNSSEC public key (DNSKEY RR). OLD: Likewise, Delegation Signer (DS) RRs and NSEC3 RRs use a hashed value as part of their RDATA NEW: Likewise, Delegation Signer (DS) RRs and Hashed Authenticated Denial of Existence (NSEC3) RRs use a hashed value as part of their RDATA OLD: These proposed EDNS options serve to measure the acceptance and use of new digital signing algorithms. NEW: These proposed EDNS0 options serve to measure the acceptance and use of new digital signing algorithms. Section 2 Signaling DNSSEC Algorithm Understood (DAU), DS Hash Understood (DHU) and NSEC3 Hash Understood (N3U) Using EDNS OLD: These options are contained in the RDATA of the OPT meta-RR. This document defines three new EDNS options for a client to signal which digital signature and/or hash algorithms the client supports. NEW: These options are contained in the resource record data (RDATA) of the OPT meta-RR. This document defines three new EDNS0 options for a client to signal which digital signature and/or hash algorithms the client supports. Section 3.1.1 OLD: A validating stub resolver already (usually) sets the DO bit [RFC4035] to indicate that it wishes to receive additional DNSSEC RRs (i.e. RRSIG RRs) in the response. Such validating resolvers SHOULD include the DAU, DHU and/or the N3U option(s) in the OPT RR when sending a query. NEW: A validating stub resolver sets the DO bit [RFC4035] to indicate that it wishes to receive additional DNSSEC RRs (i.e. RRSIG RRs) in the response. Such validating resolvers SHOULD include the DAU, DHU and/or the N3U option(s) in the OPT RR when sending a query. Section 3.2.1 OLD: If the client did include the DO and CD bits, but did not include the DAU, DHU and/or N3U option(s) in the query, NEW: If the client did include the DO and Checking Disabled (CD) bits, but did not include the DAU, DHU and/or N3U option(s) in the query, In Section 4: OLD Intermediate proxies [RFC5625] that understand DNS are RECOMMENDED to NEW: Intermediate proxies [RFC5625-442] that understand DNS are RECOMMENDED to Section 5 OLD: If the options are present but the DNSSEC-OK (OK) bit is not set, NEW: If the options are present but the DNSSEC-OK (DO) bit is not set, In Section 9: OLD: [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009. NEW: [RFC5625-442] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625 section 4.4.2, August 2009.