From jay@nzrs.net.nz Mon Aug 12 19:48:29 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 253FE11E8107 for ; Mon, 12 Aug 2013 19:48:29 -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 subbCkI5wosy for ; Mon, 12 Aug 2013 19:48:25 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id CC01C11E8108 for ; Mon, 12 Aug 2013 19:48:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 094284B5320 for ; Tue, 13 Aug 2013 14:48:20 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id on9eVQj3Nyvb for ; Tue, 13 Aug 2013 14:48:13 +1200 (NZST) Received: from [192.168.1.230] (121-74-100-115.telstraclear.net [121.74.100.115]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id F244F4B531A for ; Tue, 13 Aug 2013 14:48:12 +1200 (NZST) From: Jay Daley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> Date: Tue, 13 Aug 2013 14:48:12 +1200 To: DNSEXT Working Group Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 02:48:29 -0000 Not sure where else to take this but I thought you might be interested = in it, though possibly more in a "we don't need this you heretic" type = of way. Feedback most welcome, honest. Jay A new version of I-D, draft-daley-servezones-00.txt has been successfully submitted by Jay Daley and posted to the IETF repository. Filename: draft-daley-servezones Revision: 00 Title: DNS SERVEZONES message Creation date: 2013-08-13 Group: Individual Submission Number of pages: 6 URL: = http://www.ietf.org/internet-drafts/draft-daley-servezones-00.txt Status: http://datatracker.ietf.org/doc/draft-daley-servezones Htmlized: http://tools.ietf.org/html/draft-daley-servezones-00 Abstract: This memo describes an addition to the DNS protocol that support the remote provisioning of zones on authoritative servers. This addition is complementary to the existing mechanisms for provisioning zone data using the DNS protocol. --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From miek@miek.nl Mon Aug 12 20:31:51 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 06E3211E811F for ; Mon, 12 Aug 2013 20:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[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 s0aRjjeDQ0O0 for ; Mon, 12 Aug 2013 20:31:46 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3505311E8108 for ; Mon, 12 Aug 2013 20:31:45 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl13so8345863pab.34 for ; Mon, 12 Aug 2013 20:31:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=5IzSTTIsbdxmdOxknsi0JbC6Fe50btm9mFcK88eeqjg=; b=nwtOOToPUSPAMiWgBqBYYIxIfg+aaJMB4ssQ8tA6vW0SPSWKxBjYpfWme0XI9uazxo SWnP+wL3hqTkKvS67AXWjOAKACF6l5nXNICFPPCXHsvDxRcBGX8wYBuuL29fp8A9p9QZ ivIvXscF8caRLQYQgduKkWP7rZfrJBHg/jRmCdtEgHYqAfROgLG7V7X6/jXtuHCaJWNV +a/0Ex9wvOGLQ9rLo54NSDcIzo+vyGfB1CNA/A8SW36s2OMXBFU2AOiVekAIHiQuw+yF KyV2cJNTtzpVb5gWVJR6+3p/4pugm2WSPVi3WvtUaVs1E7jREPBDnTqpVBpCrkfDaVaC uwew== X-Gm-Message-State: ALoCoQnAWAlrsnq27vT5hfxSxaoeJwV73XHAt4oJtkAKImgM0BOHCY+3are0kYzKY2WzyiSvM5ke X-Received: by 10.66.25.102 with SMTP id b6mr2219432pag.129.1376364705738; Mon, 12 Aug 2013 20:31:45 -0700 (PDT) Received: from miek.nl (c-98-248-32-3.hsd1.ca.comcast.net. [98.248.32.3]) by mx.google.com with ESMTPSA id ht5sm40762032pbb.29.2013.08.12.20.31.44 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 12 Aug 2013 20:31:45 -0700 (PDT) Date: Mon, 12 Aug 2013 20:31:43 -0700 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20130813033143.GA24608@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 03:31:51 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [ Quoting in "[dnsext] A new DNS message - SERVEZ..." ] > Not sure where else to take this but I thought you might be interested in it, though possibly more in a "we don't need this you heretic" type of way. Feedback most welcome, honest. somewhat like pdns's supermasters? http://doc.powerdns.com/html/slave.html#supermaster grtz Miek --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlIJqJ8ACgkQJYuFzziA0PaQ+wCg1fpQHDAGaO0ygduFV9YpC1k9 JpoAn3wz+l7vIMJq9lv8qPKyF8V37VYr =SigG -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From jay@nzrs.net.nz Mon Aug 12 20:41:14 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 3DE3D11E8110 for ; Mon, 12 Aug 2013 20:41:14 -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 gTa4B+WzV1q6 for ; Mon, 12 Aug 2013 20:41:10 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id D6F7F21F9E43 for ; Mon, 12 Aug 2013 20:41:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 440F74B535A; Tue, 13 Aug 2013 15:41:08 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZK1Abzmm4uy; Tue, 13 Aug 2013 15:41:01 +1200 (NZST) Received: from [192.168.1.230] (121-74-100-115.telstraclear.net [121.74.100.115]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id BD16B4B572B; Tue, 13 Aug 2013 15:41:00 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <20130813033143.GA24608@miek.nl> Date: Tue, 13 Aug 2013 15:40:59 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813033143.GA24608@miek.nl> To: Miek Gieben X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 03:41:14 -0000 On 13/08/2013, at 3:31 PM, Miek Gieben wrote: > somewhat like pdns's supermasters? >=20 > http://doc.powerdns.com/html/slave.html#supermaster Ah yes I'd forgotten about that. Not quite the same as supermasters is = only for provisioning slaves whereas servezones can provision both = masters and slaves. Also, if I remember rightly, supermasters can only = add zones and not remove them whereas servezones can do both. Check out the draft - you'll be surprised at how short and neat it is. thanks Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From miek@miek.nl Mon Aug 12 20:58: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 41D7621E809E for ; Mon, 12 Aug 2013 20:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[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 thDU0zcPpFbB for ; Mon, 12 Aug 2013 20:58:19 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6C31E11E8129 for ; Mon, 12 Aug 2013 20:58:19 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj1so7820888pad.28 for ; Mon, 12 Aug 2013 20:58:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=GOTl1sSxGdOSLtLGlkKHELpADE1vUt9TURsXq2gZmiQ=; b=b0cSHtVjAmg4QOQkR4ZCGe0mEC6DFePT0ojjch51ptFHgLP/MkVsTkfGoia2AMYbA1 lXjtAYsd7GqNIQ9UknV9U0t0lUphQGSniHtyF6HXeBqmKg+tS5c4AUw4/ZeFE5fdkP+1 1VCvjhO52gimJ7iT7BEJzrM063RzOFYduQdlsO1UEvTVLrewzeOEwmPwt95UYpo4ZlWt ck7zBS1KzS+cZPcEryaRwDcEUU+27yY1d9+JxKeMwJp3UPQZhMbBqGsNO0MvyTTCA2UO DlGQa8/ouTNzhpq4VzxlAtbw00AdJ0myGjoimk6XBRW5JnM/msqDZS+86Y+/p4BOhzyV rSFA== X-Gm-Message-State: ALoCoQn60ZHbK4PFeuSZ64Au5mYG/33FwUW7IDh0qIvn8xkAl4JC3v3EZXC6xE/zhJfRPMMz/F2i X-Received: by 10.67.11.103 with SMTP id eh7mr2353027pad.153.1376366299066; Mon, 12 Aug 2013 20:58:19 -0700 (PDT) Received: from miek.nl (c-98-248-32-3.hsd1.ca.comcast.net. [98.248.32.3]) by mx.google.com with ESMTPSA id ar5sm40865672pbc.40.2013.08.12.20.58.17 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 12 Aug 2013 20:58:18 -0700 (PDT) Date: Mon, 12 Aug 2013 20:58:16 -0700 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20130813035816.GA25312@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813033143.GA24608@miek.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 03:58:24 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "Re: [dnsext] A new DNS message - SE..." ] > > http://doc.powerdns.com/html/slave.html#supermaster >=20 > Ah yes I'd forgotten about that. Not quite the same as supermasters is o= nly for provisioning slaves whereas servezones can provision both masters a= nd slaves. Also, if I remember rightly, supermasters can only add zones an= d not remove them whereas servezones can do both. True, but with a simple hack that could be added too (a SOA with all 0's). > Check out the draft - you'll be surprised at how short and neat it is. Yes, I did. What I'm saying is that something like this already exists and it didn't need to protocol change/addition, there is some elegance in that. IMO you should at least mention it [supermasters] and make a case for your = proposal? - Grtz, --- Miek Gieben --zhXaljGHf11kAtnf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlIJrtgACgkQJYuFzziA0PZmxgCg9TaDPr5AIhAM+MFp5lF6jXNp bsUAoJCKeXoHWSui3OAO4MjXjsrAD+Ul =0Mkv -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From marka@isc.org Mon Aug 12 21:06:19 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 AAD9111E8122 for ; Mon, 12 Aug 2013 21:06:19 -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 WAPGX-JkKZxd for ; Mon, 12 Aug 2013 21:06:14 -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 DF59C11E8118 for ; Mon, 12 Aug 2013 21:06:14 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id C0562C941E; Tue, 13 Aug 2013 04:06:00 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376366773; bh=FweP6ADdduWHYraJ7cBoumjqpIzifOxjxyf8tXzHQTg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=FAw4C41Ftx+l1hXtXnx0SGC1ltWk2+OySsXOjy9utGk6fJN3ofYptYWQWu1lUDWAY OB74WjCYmZCA9Nuf13FNINYE75j1chPkA5/B36lLZ/UhlC+UVnJiu6lIP3See6H5Gy QTZuQxQMIBQaccPnbsH1dVxcKr92Wwk2SPdEird0= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 13 Aug 2013 04:06:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3E7B816032F; Tue, 13 Aug 2013 04:10:41 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id og3zeJ6a7bMQ; Tue, 13 Aug 2013 04:10:40 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CB8ED160436; Tue, 13 Aug 2013 04:10:40 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 9ADF1160435; Tue, 13 Aug 2013 04:10:40 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id E525D3849522; Tue, 13 Aug 2013 14:05:57 +1000 (EST) To: Jay Daley From: Mark Andrews References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> In-reply-to: Your message of "Tue, 13 Aug 2013 14:48:12 +1200." <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> Date: Tue, 13 Aug 2013 14:05:57 +1000 Message-Id: <20130813040557.E525D3849522@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 04:06:19 -0000 This appears to burn a opcode for no good reason. UPDATE w/ a EDNS option say "NEWZONE" could replace the master side of this w/o burning a opcode. NOTIFY w/ type NS could replace the slave side of this w/o burning a opcode. The FQDN restrictions. Do they apply to rdata or not? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jay@nzrs.net.nz Mon Aug 12 21:34: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 DCD4F21F99F3 for ; Mon, 12 Aug 2013 21:34:10 -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 dg8TKRbsLJ7S for ; Mon, 12 Aug 2013 21:34:07 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id C776621E80AC for ; Mon, 12 Aug 2013 21:34:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 4289A4B5921; Tue, 13 Aug 2013 16:34:02 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTVv4K8GMPS9; Tue, 13 Aug 2013 16:33:55 +1200 (NZST) Received: from [192.168.1.230] (121-74-100-115.telstraclear.net [121.74.100.115]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 1A6FA4B57E9; Tue, 13 Aug 2013 16:33:55 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <20130813035816.GA25312@miek.nl> Date: Tue, 13 Aug 2013 16:33:53 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <1701A5CE-3008-477D-9FAB-6DF41FC95929@nzrs.net.nz> References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813033143.GA24608@miek.nl> <20130813035816.GA25312@miek.nl> To: Miek Gieben X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 04:34:11 -0000 On 13/08/2013, at 3:58 PM, Miek Gieben wrote: > [ Quoting in "Re: [dnsext] A new DNS message - = SE..." ] >>> http://doc.powerdns.com/html/slave.html#supermaster >>=20 >> Ah yes I'd forgotten about that. Not quite the same as supermasters = is only for provisioning slaves whereas servezones can provision both = masters and slaves. Also, if I remember rightly, supermasters can only = add zones and not remove them whereas servezones can do both. >=20 > True, but with a simple hack that could be added too (a SOA with all > 0's). It's not as simple as that: Is that hack for provisioning a master or for removing a zone? And how = would you provision the initial data of a master before it started = serving? >> Check out the draft - you'll be surprised at how short and neat it = is. >=20 > Yes, I did. What I'm saying is that something like this already exists > and it didn't need to protocol change/addition, there is some elegance > in that. >=20 > IMO you should at least mention it [supermasters] and make a case for = your proposal? I like the general idea that certain masters have more authority, = elegant as you say, but I wouldn't describe servezones as inelegant by = comparison since it is simple and straightforward. However there is = much more to supermasters that needs to be done before I need to mention = it. =20 To be clear if someone did work that idea up into a full proposal that = does what servezones does then I would be pleased. Jay >=20 > - Grtz, >=20 > --- > Miek Gieben > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From jay@nzrs.net.nz Mon Aug 12 21:44: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 92DAE11E812A for ; Mon, 12 Aug 2013 21:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.866, 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 SbBL7ZrNEjz6 for ; Mon, 12 Aug 2013 21:44:31 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 532DB21F99ED for ; Mon, 12 Aug 2013 21:44:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id D0DED4B57E9; Tue, 13 Aug 2013 16:44:24 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq9hh2bQHN4f; Tue, 13 Aug 2013 16:44:17 +1200 (NZST) Received: from [192.168.1.230] (121-74-100-115.telstraclear.net [121.74.100.115]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id A9ED24B25BA; Tue, 13 Aug 2013 16:44:17 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <20130813040557.E525D3849522@drugs.dv.isc.org> Date: Tue, 13 Aug 2013 16:44:16 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1508) Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 04:44:36 -0000 On 13/08/2013, at 4:05 PM, Mark Andrews wrote: > This appears to burn a opcode for no good reason. We're not exactly burning them when the last one was added 16 years ago = in 1997 and one was reclaimed 11 years ago in 2002. > UPDATE w/ a EDNS option say "NEWZONE" could replace the master side > of this w/o burning a opcode. So can only one zone be specified or are the RRs in the UPDATE now taken = as zones? And how does it delete zones - with the same overloading of = TYPE or CLASS? And what about the pre-requisites, are they ignored or = must they exist before the zone can be deleted? > NOTIFY w/ type NS could replace the slave side of this w/o burning > a opcode. Again all this does is generate a list of questions. I'm not averse to an alternative that hacks the existing protocol but = it's not trivial. >=20 > The FQDN restrictions. Do they apply to rdata or not? No. Jay >=20 > Mark > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From marka@isc.org Mon Aug 12 22:42:35 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 B3EC111E8136 for ; Mon, 12 Aug 2013 22:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.975, 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 pgF-NlqGYWtl for ; Mon, 12 Aug 2013 22:42:31 -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 83D3211E8135 for ; Mon, 12 Aug 2013 22:42:31 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 49984C94BF; Tue, 13 Aug 2013 05:42:16 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376372550; bh=wZUbFWbq098sEWAaG4dkOPT6NdKlYqcs4E2Ap0MRRCk=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=nQr1w+gTJBQiJ76Zfw7LYaaUnq2Po/Cmj1TsrcQeRyvzMewnZRzVMnRwGAE4xSMoo oMtZNnlOil5YB/SDRa19oVo3HF3ebuaBmUpVldEtdlvxTWrX4cnPiDhyPnEj5wRdUH Lh3FYKJuqiojeDe0M712yfrsx+a8pLyAKrs9FrB8= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 13 Aug 2013 05:42:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 114D8160436; Tue, 13 Aug 2013 05:46:57 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SGn1170OKjqW; Tue, 13 Aug 2013 05:46:56 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 127E7160435; Tue, 13 Aug 2013 05:46:56 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id D86F016032F; Tue, 13 Aug 2013 05:46:55 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id EB582384A540; Tue, 13 Aug 2013 15:42:11 +1000 (EST) To: Jay Daley From: Mark Andrews References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 13 Aug 2013 16:44:16 +1200." Date: Tue, 13 Aug 2013 15:42:11 +1000 Message-Id: <20130813054211.EB582384A540@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 05:42:35 -0000 In message , Jay Daley writes: > On 13/08/2013, at 4:05 PM, Mark Andrews wrote: > > > This appears to burn a opcode for no good reason. > > We're not exactly burning them when the last one was added 16 years ago = > in 1997 and one was reclaimed 11 years ago in 2002. It's only a 4 bit space. > > UPDATE w/ a EDNS option say "NEWZONE" could replace the master side > > of this w/o burning a opcode. > > So can only one zone be specified or are the RRs in the UPDATE now taken > as zones? And how does it delete zones - with the same overloading of > TYPE or CLASS? I can think of a couple of ways to do this using notify/update/edns. > And what about the pre-requisites, are they ignored or > must they exist before the zone can be deleted? You apply them as normal to a empty zone if it doesn't already exist otherwise you apply them to the zone. > > NOTIFY w/ type NS could replace the slave side of this w/o burning > > a opcode. > > Again all this does is generate a list of questions. > > > I'm not averse to an alternative that hacks the existing protocol but > it's not trivial. Actually it is pretty trivial if all you want to do is tell a server to start/stop serving a zone. The hard part is all the metadata that is associated with serving a zone and making that generic enough to be useful in a multi-vendor way. > > The FQDN restrictions. Do they apply to rdata or not? > > No. > > Jay > > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > -- > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 > linkedin: www.linkedin.com/in/jaydaley -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jay@nzrs.net.nz Mon Aug 12 23:02:27 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 9CB0F21F9F08 for ; Mon, 12 Aug 2013 23:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 Ej+EVUQaKqog for ; Mon, 12 Aug 2013 23:02:23 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFA821F9F2D for ; Mon, 12 Aug 2013 23:02:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 9577A4B5973; Tue, 13 Aug 2013 18:02:21 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSlMrY-aoJ0y; Tue, 13 Aug 2013 18:02:14 +1200 (NZST) Received: from [192.168.1.230] (121-74-100-115.telstraclear.net [121.74.100.115]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 6BC804B59F4; Tue, 13 Aug 2013 18:02:14 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <20130813054211.EB582384A540@drugs.dv.isc.org> Date: Tue, 13 Aug 2013 18:02:13 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <98EF80FB-9B3A-49B3-9F28-4A160D8377CA@nzrs.net.nz> References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> <20130813054211.EB582384A540@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1508) Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 06:02:27 -0000 On 13/08/2013, at 5:42 PM, Mark Andrews wrote: > In message , Jay = Daley writes: >> On 13/08/2013, at 4:05 PM, Mark Andrews wrote: >>=20 >>> This appears to burn a opcode for no good reason. >>=20 >> We're not exactly burning them when the last one was added 16 years = ago =3D >> in 1997 and one was reclaimed 11 years ago in 2002. >=20 > It's only a 4 bit space. One every 16 years gives us 192 years until we exhaust even 4 bits. > ... > Actually it is pretty trivial if all you want to do is tell a server > to start/stop serving a zone. The hard part is all the metadata that > is associated with serving a zone and making that generic enough to > be useful in a multi-vendor way. If it's trivial then it would be great if you could write it up and we = can compare. I'm not stuck on servezones if there is a better = alternative. Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From regnauld@x0.dk Mon Aug 12 23:18:00 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 A070421E80B9 for ; Mon, 12 Aug 2013 23:18:00 -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 EtpOCCliX3Au for ; Mon, 12 Aug 2013 23:17:54 -0700 (PDT) Received: from moof.catpipe.net (moof.catpipe.net [194.28.252.64]) by ietfa.amsl.com (Postfix) with ESMTP id BF86A21E80BB for ; Mon, 12 Aug 2013 23:17:53 -0700 (PDT) Received: from localhost (moof.catpipe.net [194.28.252.64]) by localhost.catpipe.net (Postfix) with ESMTP id 3464A4CE9CC; Tue, 13 Aug 2013 08:17:52 +0200 (CEST) Received: from moof.catpipe.net ([194.28.252.64]) by localhost (moof.catpipe.net [194.28.252.64]) (amavisd-new, port 10024) with ESMTP id zjYTxfua8GVh; Tue, 13 Aug 2013 08:17:51 +0200 (CEST) Received: from macbook.bluepipe.net (unknown [14.141.62.10]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTPA id B5AFD4CE9CB; Tue, 13 Aug 2013 08:17:51 +0200 (CEST) Received: by macbook.bluepipe.net (Postfix, from userid 1001) id E4CBBF57E3B; Tue, 13 Aug 2013 11:47:50 +0530 (IST) Date: Tue, 13 Aug 2013 11:47:50 +0530 From: Phil Regnauld To: Mark Andrews Message-ID: <20130813061750.GI68461@macbook.bluepipe.net> References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> <20130813054211.EB582384A540@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130813054211.EB582384A540@drugs.dv.isc.org> X-Operating-System: Darwin 12.4.0 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 06:18:00 -0000 Mark Andrews (marka) writes: > > Actually it is pretty trivial if all you want to do is tell a server > to start/stop serving a zone. The hard part is all the metadata that > is associated with serving a zone and making that generic enough to > be useful in a multi-vendor way. There were a couple of efforts to address this I believe, including NSCP. Cheers, Phil From jim@rfc1035.com Tue Aug 13 01:11: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 5D0D711E80ED for ; Tue, 13 Aug 2013 01:11:46 -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 iEcVE8gDATP3 for ; Tue, 13 Aug 2013 01:11:41 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) by ietfa.amsl.com (Postfix) with ESMTP id C88F211E80E4 for ; Tue, 13 Aug 2013 01:11:38 -0700 (PDT) Received: from [IPv6:::1] (shaun.rfc1035.com [93.186.33.42]) by shaun.rfc1035.com (Postfix) with ESMTP id EFEF2CBC41F; Tue, 13 Aug 2013 09:11:35 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jim Reid In-Reply-To: <20130813040557.E525D3849522@drugs.dv.isc.org> Date: Tue, 13 Aug 2013 09:11:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1508) Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 08:11:53 -0000 On 13 Aug 2013, at 05:05, Mark Andrews wrote: > This appears to burn a opcode for no good reason. There are plenty to spare, so burn away. That said, it would be prudent to define just one opcode covering server = "management" in general -- ie start/stop doing something -- and maybe = another for provisioning. There be rat-holes... > UPDATE w/ a EDNS option say "NEWZONE" could replace the master side > of this w/o burning a opcode. >=20 > NOTIFY w/ type NS could replace the slave side of this w/o burning > a opcode. Both of these are very bad ideas because they change the behaviour and = semantics of an already widely deployed part of the DNS protocol. From marka@isc.org Tue Aug 13 01:32: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 4B2BE21E80E9 for ; Tue, 13 Aug 2013 01:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 R54YQ9srw9HH for ; Tue, 13 Aug 2013 01:31:58 -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 7F79721E80E8 for ; Tue, 13 Aug 2013 01:31:58 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id D812DC94BC; Tue, 13 Aug 2013 08:31:44 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376382718; bh=XCJ25GCRgebS3IcNCSvKxTwunAiqeMHqLE2YXDeNLao=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=eWtQtDQUZZmB6Nh1sVXwFPINKwmujYUSFJbv1XHIh/8uL/LTvttv/5JJpQ+clDbq8 q0jVurApmQoJpJXGCSClSgGGd+tnmaO71WiXh1bSKJC6OBXqXsbP9yT0VchOiFGbmD EtRnOp+T9Y2lCOwtdnfZ1GG/QUw/ieqJbYYk2+DI= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 13 Aug 2013 08:31:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2A6B91601C2; Tue, 13 Aug 2013 08:36:26 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id dmL526bUjIoS; Tue, 13 Aug 2013 08:36:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8D174160437; Tue, 13 Aug 2013 08:36:25 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 576931601E7; Tue, 13 Aug 2013 08:36:25 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id A46D5384D363; Tue, 13 Aug 2013 18:31:40 +1000 (EST) To: Jim Reid From: Mark Andrews References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 13 Aug 2013 09:11:35 +0100." Date: Tue, 13 Aug 2013 18:31:40 +1000 Message-Id: <20130813083140.A46D5384D363@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 08:32:03 -0000 In message , Jim Reid writes: > On 13 Aug 2013, at 05:05, Mark Andrews wrote: > > > This appears to burn a opcode for no good reason. > > There are plenty to spare, so burn away. > > That said, it would be prudent to define just one opcode covering server = > "management" in general -- ie start/stop doing something -- and maybe = > another for provisioning. There be rat-holes... > > > UPDATE w/ a EDNS option say "NEWZONE" could replace the master side > > of this w/o burning a opcode. > >=20 > > NOTIFY w/ type NS could replace the slave side of this w/o burning > > a opcode. > > Both of these are very bad ideas because they change the behaviour and = > semantics of an already widely deployed part of the DNS protocol. How does it break the sematics of UPDATE? server 1.2.3.4 newzone example.net update add example.net 3600 SOA ... update add example.net 3600 NS ... update add example.net 3600 NS ... update add example.net 3600 A ... send The only difference is you don't get NOTAUTH as a rcode if you tell the server to create the zone. It would be about 10 minutes work to add this to named. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jay@nzrs.net.nz Tue Aug 13 01:47:08 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 3DD3921E80F0 for ; Tue, 13 Aug 2013 01:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, 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 DfyWzmdsNXkd for ; Tue, 13 Aug 2013 01:47:03 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id BF7EB21E80F2 for ; Tue, 13 Aug 2013 01:47:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id E4DC94B4199; Tue, 13 Aug 2013 20:47:00 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgSRkhXXixlw; Tue, 13 Aug 2013 20:46:54 +1200 (NZST) Received: from [192.168.1.230] (121-74-100-115.telstraclear.net [121.74.100.115]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id A97934B415B; Tue, 13 Aug 2013 20:46:53 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: Date: Tue, 13 Aug 2013 20:46:52 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <04CA3CF3-79F7-4529-9C9E-60504BC96F4C@nzrs.net.nz> References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> To: Jim Reid , Mark Andrews X-Mailer: Apple Mail (2.1508) Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 08:47:08 -0000 Answering a couple of points: On 13/08/2013, at 8:11 PM, Jim Reid wrote: > That said, it would be prudent to define just one opcode covering = server "management" in general -- ie start/stop doing something -- and = maybe another for provisioning. There be rat-holes... I would prefer that DNS server management was a different protocol. = Phil mentioned NSCP, which is an excellent candidate. Provisioning is = an oddity because it didn't exist in DNS originally but was added with = UPDATE and having done that I can see the value in finishing the job by = adding the provisioning of zones but I can't currently see any value in = going further than that. On 13/08/2013, at 8:31 PM, Mark Andrews wrote: >> Both of these are very bad ideas because they change the behaviour = and =3D >> semantics of an already widely deployed part of the DNS protocol. >=20 > How does it break the sematics of UPDATE? Presumably because people are not looking for the new EDNS code in their = existing code and its existence changes the way the data is interpreted, = so the behaviour of existing code could vary. > server 1.2.3.4 > newzone example.net > update add example.net 3600 SOA ... > update add example.net 3600 NS ... > update add example.net 3600 NS ... > update add example.net 3600 A ... > send How do you delete a zone? =20 Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From jim@rfc1035.com Tue Aug 13 02:11:08 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 2BFFA21E80F1 for ; Tue, 13 Aug 2013 02:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] 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 MK7HdE0l37w0 for ; Tue, 13 Aug 2013 02:11:03 -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 EF8A221F99F3 for ; Tue, 13 Aug 2013 02:11:02 -0700 (PDT) Received: from [IPv6:::1] (shaun.rfc1035.com [93.186.33.42]) by shaun.rfc1035.com (Postfix) with ESMTP id B7CC8CBC41F; Tue, 13 Aug 2013 10:10:42 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jim Reid In-Reply-To: <20130813083140.A46D5384D363@drugs.dv.isc.org> Date: Tue, 13 Aug 2013 10:10:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> <20130813083140.A46D5384D363@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1508) Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 09:11:08 -0000 On 13 Aug 2013, at 09:31, Mark Andrews wrote: > How does it break the sematics of UPDATE? Jay's already explained that. > server 1.2.3.4 > newzone example.net > update add example.net 3600 SOA ... > update add example.net 3600 NS ... > update add example.net 3600 NS ... > update add example.net 3600 A ... > send >=20 > The only difference is you don't get NOTAUTH as a rcode if you tell = the > server to create the zone. Taking the above strawman example, how would the server at 1.2.3.4 = signal to the client that although it speaks UPDATE, it doesn't do this = new-fangled "newzone" featurette? For instance because the server = doesn't understand this weird UPDATE message or has no code to support = that or because it won't/can't allow new zones to be added on the fly, = say for policy reasons or file system permissions? Also, consider backwards compatibility. The installed base won't know to = interpret your UPDATE message with extra newzone EDNS secret sauce. = They'd just see a regular UPDATE with some EDNS goop that makes no sense = to them. Would they (a) reject the request outright (FORMERR? NOTIMP?); = (b) try to process the "vanilla" part of that UPDATE message and ignore = the EDNS stuff? Maybe you'd need to burn an error code or two here... :-) The above are rehotorical questions BTW: there's no need to answer them. From Jelte.Jansen@sidn.nl Tue Aug 13 02:23:31 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 3EB0921E80E1 for ; Tue, 13 Aug 2013 02:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119] 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 ZnMJBMpSgxWS for ; Tue, 13 Aug 2013 02:23:26 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 1047921E8097 for ; Tue, 13 Aug 2013 02:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=+4LMXSOVGigPtZtS7uaZAo56DJQubNYuS5zsxUGqKxA=; b=DolI0XWtkzZcsk8trYOVg9bw9owb5QpRXdsKEYXxFu24rfcTHaXLWwWcuP1JVDVSxHDNoAgHRRPDup3rmsie8K+zMGQ8TJxYwQeKWGW1rZUll7RkzuLzGGPIBznyGvMMxXiZfHHedpSxIB5p+Kr9O203lLOy6NOLkhhAG7juHcM= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r7D9NP8Q009506-r7D9NP8S009506 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Tue, 13 Aug 2013 11:23:25 +0200 Received: from [94.198.152.217] (94.198.152.217) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 13 Aug 2013 11:23:24 +0200 Message-ID: <5209FB0C.8050502@sidn.nl> Date: Tue, 13 Aug 2013 11:23:24 +0200 From: Jelte Jansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: DNSEXT Working Group References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> <04CA3CF3-79F7-4529-9C9E-60504BC96F4C@nzrs.net.nz> In-Reply-To: <04CA3CF3-79F7-4529-9C9E-60504BC96F4C@nzrs.net.nz> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.217] Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 09:23:31 -0000 On 08/13/2013 10:46 AM, Jay Daley wrote: > Answering a couple of points: > > On 13/08/2013, at 8:11 PM, Jim Reid wrote: > >> That said, it would be prudent to define just one opcode covering server "management" in general -- ie start/stop doing something -- and maybe another for provisioning. There be rat-holes... > > I would prefer that DNS server management was a different protocol. Phil mentioned NSCP, which is an excellent candidate. Provisioning is an oddity because it didn't exist in DNS originally but was added with UPDATE and having done that I can see the value in finishing the job by adding the provisioning of zones but I can't currently see any value in going further than that. > > FYI, in terms of efforts, there's also the approach taken in Yadifa: https://ripe66.ripe.net/presentations/207-YADIFA-RIEP66-DynamicProvisioning-pres.pdf IIRC, there were also some other proposals in the style of the old metazones idea back then (and i recall one floating around based on a class instead of an opcode). AFAIK, NSCP hasn't had any action since it got kicked back to dnsop, lots of people want it, noone wants to work on it, and perhaps it is also overshooting the goals people have. BTW, The nscp mailing list wasn't used in the end, but it never did get cleaned up. So if there is gonna be a bigger effort than 'just' adding and removing zones, perhaps we can try again. PS I ran out of initialisms to start my sentences with. Jelte From marka@isc.org Tue Aug 13 03:35: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 806CF21E8115 for ; Tue, 13 Aug 2013 03:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, 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 LbmcSQBgKOMM for ; Tue, 13 Aug 2013 03:35:43 -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 30C6921E8107 for ; Tue, 13 Aug 2013 03:35:29 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id BAD3EC941E; Tue, 13 Aug 2013 10:35:15 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376390128; bh=hrNznpjtidgL4X6Z5IimAQhaBkzs0CnVtsceOGUhgCM=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=eaknA5wGIpmXKIRg60O0e3a8HNXzg2L/tVaA8Ty4Jhnt3V9+pLU0tb0ECmArIcWTQ miwDMmql7v9TefKLOOc2zemPFG3ntQdmdzsapZ1g3x7jqU29G9wBg1t8k8VOZrcQOi Q5MdkFFXykXL9PXK5kZrbQFE/nrjEP47uTLVDN6A= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 13 Aug 2013 10:35:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 664851601E7; Tue, 13 Aug 2013 10:39:57 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4nCuh6dGQmpJ; Tue, 13 Aug 2013 10:39:56 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C4618160438; Tue, 13 Aug 2013 10:39:56 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 773CE160437; Tue, 13 Aug 2013 10:39:56 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id C5506384DE03; Tue, 13 Aug 2013 20:35:10 +1000 (EST) To: Jim Reid From: Mark Andrews References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> <20130813083140.A46D5384D363@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 13 Aug 2013 10:10:42 +0100." Date: Tue, 13 Aug 2013 20:35:10 +1000 Message-Id: <20130813103510.C5506384DE03@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 10:35:48 -0000 In message , Jim Reid writes: > On 13 Aug 2013, at 09:31, Mark Andrews wrote: > > > How does it break the sematics of UPDATE? > > Jay's already explained that. > > > server 1.2.3.4 > > newzone example.net > > update add example.net 3600 SOA ... > > update add example.net 3600 NS ... > > update add example.net 3600 NS ... > > update add example.net 3600 A ... > > send > > > > The only difference is you don't get NOTAUTH as a rcode if you tell the > > server to create the zone. > > Taking the above strawman example, how would the server at 1.2.3.4 signal > to the client that although it speaks UPDATE, it doesn't do this > new-fangled "newzone" featurette? It would return NOTAUTH if it didn't understand the EDNS option and didn't have the zone. It had the zone it would "add" the records which in most cases would be a no-op. If you add "prereq nxdomain " to the above none of the adds would take with a existing zone. > For instance because the server doesn't understand this weird UPDATE > message or has no code to support that or because it won't/can't allow > new zones to be added on the fly, say for policy reasons or file system > permissions? If you don't allow adding new zones you return REFUSED. Filesystem problems are no different to not being able to create a journal, you get SERVFAIL. > Also, consider backwards compatibility. The installed base won't know to > interpret your UPDATE message with extra newzone EDNS secret sauce. > They'd just see a regular UPDATE with some EDNS goop that makes no sense > to them. Would they (a) reject the request outright (FORMERR? NOTIMP?); > (b) try to process the "vanilla" part of that UPDATE message and ignore > the EDNS stuff? > > Maybe you'd need to burn an error code or two here... :-) > > The above are rehotorical questions BTW: there's no need to answer them. Well the questions are addressable. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From regnauld@x0.dk Tue Aug 13 03:49: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 A36EE21E8107 for ; Tue, 13 Aug 2013 03:49:50 -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 5enp7raINYMY for ; Tue, 13 Aug 2013 03:49:44 -0700 (PDT) Received: from moof.catpipe.net (moof.catpipe.net [194.28.252.64]) by ietfa.amsl.com (Postfix) with ESMTP id B888321E80E1 for ; Tue, 13 Aug 2013 03:49:44 -0700 (PDT) Received: from localhost (moof.catpipe.net [194.28.252.64]) by localhost.catpipe.net (Postfix) with ESMTP id 469914CEA1A; Tue, 13 Aug 2013 12:49:42 +0200 (CEST) Received: from moof.catpipe.net ([194.28.252.64]) by localhost (moof.catpipe.net [194.28.252.64]) (amavisd-new, port 10024) with ESMTP id iz8Z1rPB2h95; Tue, 13 Aug 2013 12:49:42 +0200 (CEST) Received: from macbook.bluepipe.net (unknown [14.141.62.10]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTPA id BCEEF4CE9B4; Tue, 13 Aug 2013 12:49:41 +0200 (CEST) Received: by macbook.bluepipe.net (Postfix, from userid 1001) id E0A7DF61121; Tue, 13 Aug 2013 16:19:38 +0530 (IST) Date: Tue, 13 Aug 2013 16:19:38 +0530 From: Phil Regnauld To: Jelte Jansen Message-ID: <20130813104938.GS68461@macbook.bluepipe.net> References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> <04CA3CF3-79F7-4529-9C9E-60504BC96F4C@nzrs.net.nz> <5209FB0C.8050502@sidn.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5209FB0C.8050502@sidn.nl> X-Operating-System: Darwin 12.4.0 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 10:49:50 -0000 Jelte Jansen (jelte.jansen) writes: > AFAIK, NSCP hasn't had any action since it got kicked back to dnsop, > lots of people want it, noone wants to work on it, and perhaps it is > also overshooting the goals people have. > > BTW, The nscp mailing list wasn't used in the end, but it never did get > cleaned up. So if there is gonna be a bigger effort than 'just' adding > and removing zones, perhaps we can try again. > > PS I ran out of initialisms to start my sentences with. ROFL. Maybe it's time I looked at NSCP and draft-regnauld-ns-communication (2006!) with new glasses :) TTFN, Phil From jabley@hopcount.ca Tue Aug 13 05:38:19 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 6410821E8127 for ; Tue, 13 Aug 2013 05:38:19 -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 OeYNGcmi80wZ for ; Tue, 13 Aug 2013 05:38:18 -0700 (PDT) Received: from mail-gh0-x22f.google.com (mail-gh0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9A721E8122 for ; Tue, 13 Aug 2013 05:38:18 -0700 (PDT) Received: by mail-gh0-f175.google.com with SMTP id z19so2336309ghb.34 for ; Tue, 13 Aug 2013 05:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZihLc700l8EluEc2p0odhxjog/Aa8JF9/pOndnTKRoI=; b=jOcoQCoC/dkkXPYf1ywDFY2Yv2l971uy2Y2dMyKKr9sQYgXRSurw4JoxEWhDYwKxxS +qbsSZTNHytN1VMan+UpR4fCAg02zhPTu0A8mgeOGo3JIRY6s47fvti3db4vODgnriqG P4TBHHBSLW9FCy1Vl2V/cKRhMtp9wIydssVbc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ZihLc700l8EluEc2p0odhxjog/Aa8JF9/pOndnTKRoI=; b=VkFZTCvxzROJzGxTk+kK6HoPli0YUBEHgjI8fINHJOzWvSC7SDnspRx+5VeaLWZByM 3eBiguKnhEgyW4U8g56lUaA3GU59Qx+ZszrCDj9YA9tl6VMaFb0MHjETEPfdWetjic/e plNvOQcaqaDBRf1u0ToFXPjN3ARc3iHBwvddfqba3ebpK98sIfRX6WeCVjlzLbUn9M7B u3jIvx3B80gBL2E9pmtx1f+IU3fszIVya/sfvrMR5h2zgiuT9N7Cfj69e3y9vVA69DM5 A+4pPhNKnbjUZyCovgP4yJ2HIWFdachWGvtnM/QRbjA2Yh9jc6bzC/5VB55oUkGy++OB f/xg== X-Gm-Message-State: ALoCoQkXXGOMlJ5HpAdgOPds98fDvAngsKORVCXCLFaNRx8ONyY3LKc2dPsAvwd19cWx88kRsZnX X-Received: by 10.236.176.130 with SMTP id b2mr3314624yhm.48.1376397496935; Tue, 13 Aug 2013 05:38:16 -0700 (PDT) Received: from [10.10.0.132] ([186.1.202.38]) by mx.google.com with ESMTPSA id n28sm13602243yhm.4.2013.08.13.05.38.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Aug 2013 05:38:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Joe Abley In-Reply-To: <5209FB0C.8050502@sidn.nl> Date: Tue, 13 Aug 2013 08:38:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <36FF164D-8176-405B-B226-653B16138C9C@hopcount.ca> References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> <04CA3CF3-79F7-4529-9C9E-60504BC96F4C@nzrs.net.nz> <5209FB0C.8050502@sidn.nl> To: Jelte Jansen X-Mailer: Apple Mail (2.1508) Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 12:38:19 -0000 On 2013-08-13, at 05:23, Jelte Jansen wrote: > AFAIK, NSCP hasn't had any action since it got kicked back to dnsop, > lots of people want it, noone wants to work on it, and perhaps it is > also overshooting the goals people have. There's an implementation that works with multiple nameservers, right? I don't remember how polished it was, but I remember it being good = enough for Sara to be able to do live demos from the stage at RIPE = meetings. Even considering Sara's nerves of steel, that suggests it = works well enough :-) https://dev.sinodun.com/wiki/display/DNSCCM/DNSCCM+Home Joe= From jay@nzrs.net.nz Tue Aug 13 14:15:06 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 A602D21F9ECA for ; Tue, 13 Aug 2013 14:15:06 -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 MMRIYMgEhpig for ; Tue, 13 Aug 2013 14:15:02 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 026A921F9CF8 for ; Tue, 13 Aug 2013 14:14:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 645994B52F6; Wed, 14 Aug 2013 09:14:24 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Evdo0rivAM1Q; Wed, 14 Aug 2013 09:14:17 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 67FAB4B589F; Wed, 14 Aug 2013 09:14:17 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <5209FB0C.8050502@sidn.nl> Date: Wed, 14 Aug 2013 09:01:49 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <96C49427-2761-4204-945B-418B0C67A86A@nzrs.net.nz> References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> <04CA3CF3-79F7-4529-9C9E-60504BC96F4C@nzrs.net.nz> <5209FB0C.8050502@sidn.nl> To: Jelte Jansen X-Mailer: Apple Mail (2.1508) Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 13 Aug 2013 21:15:06 -0000 On 13/08/2013, at 9:23 PM, Jelte Jansen wrote: > FYI, in terms of efforts, there's also the approach taken in Yadifa: > = https://ripe66.ripe.net/presentations/207-YADIFA-RIEP66-DynamicProvisionin= g-pres.pdf Wow. So this uses DNS UPDATE syntax with a new CLASS to identify itself = and a whole set of TYPES have been redefined to be interpreted as = provisioning/control instructions. As a general comment, while the YADIFA implementation is clever I for = one don't agree that it is appropriate to add so much = provisioning/control into DNS. Adding/removing zones is an obvious, = glaring gap but everything else belongs in an out-of-band protocol like = NSCP. =20 I say that because we know that DNS server/service providers are = continually innovating their feature set. That's how they differentiate = themselves now that DNS servers are commodities. If all of the = provisioning/control is baked into the DNS protocol then it gets very = messy when people wish to add proprietary features. An out-of band = protocol with support for extensions, similar to EPP, provides a much = better way to support this innovation. =20 > IIRC, there were also some other proposals in the style of the old > metazones idea back then (and i recall one floating around based on a > class instead of an opcode). >=20 > AFAIK, NSCP hasn't had any action since it got kicked back to dnsop, > lots of people want it, noone wants to work on it, and perhaps it is > also overshooting the goals people have. AFAICT NSCP was just ahead of its time and the depth of features that it = has now matches pretty well the depth of features that people are = implementing, for example as in YADIFA above. If anything that just = proves how good an idea NSCP was *cough* and what benefits we would all = now be accruing had it been agreed as an RFC some years ago. Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From jay@nzrs.net.nz Tue Aug 13 14:22: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 AF75321E8180 for ; Tue, 13 Aug 2013 14:22: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=[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 mpb9udof39-k for ; Tue, 13 Aug 2013 14:22:44 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id BD81821E816A for ; Tue, 13 Aug 2013 14:22:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 7C9FC4B52FC for ; Wed, 14 Aug 2013 09:22:40 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpDJeac8z8jL for ; Wed, 14 Aug 2013 09:22:33 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 90E794B25D0 for ; Wed, 14 Aug 2013 09:22:33 +1200 (NZST) From: Jay Daley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <53243CBE-5097-4399-8506-AA853EDF31F6@nzrs.net.nz> Date: Wed, 14 Aug 2013 09:22:34 +1200 To: DNSEXT Working Group Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dnsext] Another piece to the provisioning puzzle - dnsxml 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, 13 Aug 2013 21:22:50 -0000 Apologies to those of you who have already seen this on dnsop. A new version of I-D, draft-daley-dnsxml-00.txt has been successfully submitted by Jay Daley and posted to the IETF repository. Filename: draft-daley-dnsxml Revision: 00 Title: dnsxml - A standard XML representation of DNS data Creation date: 2013-07-31 Group: Individual Submission Number of pages: 54 URL: = http://www.ietf.org/internet-drafts/draft-daley-dnsxml-00.txt Status: http://datatracker.ietf.org/doc/draft-daley-dnsxml Htmlized: http://tools.ietf.org/html/draft-daley-dnsxml-00 Abstract: This memo describes a syntax for encoding DNS Resource Records in XML, and a schema to define that syntax written in XML Schema. It can be used to represent all DNS RDATA. This can be used by diverse applications as a common format. DNS Resource Records are represented as XML elements with the name of the element taken from the mnemonic used to represent the DNS Resource Record in presentation format. The RDATA is represented as XML attributes or content of the element. The attribute names are taken from the RDATA field names specified in the normative RFC. --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From johani@johani.org Wed Aug 14 03: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 2BB4F11E811E for ; Wed, 14 Aug 2013 03:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 nncavanjKbVY for ; Wed, 14 Aug 2013 03:26:15 -0700 (PDT) Received: from mail.johani.org (mail.johani.org [77.72.230.65]) by ietfa.amsl.com (Postfix) with ESMTP id 254B011E8110 for ; Wed, 14 Aug 2013 03:26:15 -0700 (PDT) Received: from ardbeg.netnod.se (ardbeg.netnod.se [77.72.226.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: johani) by mail.johani.org (Postfix) with ESMTPSA id A8DC2143C4; Wed, 14 Aug 2013 10:26:13 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Johan_Ihr=E9n?= In-Reply-To: <5209FB0C.8050502@sidn.nl> Date: Wed, 14 Aug 2013 12:26:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> <04CA3CF3-79F7-4529-9C9E-60504BC96F4C@nzrs.net.nz> <5209FB0C.8050502@sidn.nl> To: Jelte Jansen X-Mailer: Apple Mail (2.1085) Cc: DNSEXT Working Group Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 14 Aug 2013 10:26:21 -0000 On Aug 13, 2013, at 11:23 , Jelte Jansen wrote: > On 08/13/2013 10:46 AM, Jay Daley wrote: >> I would prefer that DNS server management was a different protocol. Amen to that. I think we're way past the point where we need to discuss = whether this is wanted or not (it is), but most of the implementations = go for the in-band alternative of overloading the DNS protocol with this = type of provisioning information, i.e. traditional mixing of control = plane and data plane. While the DNS protocol does have a bit of bad history in that space (all = the SOA parameters specifying slave server refresh and retry behaviour = for instance) I think it would be... ummm... unfortunate... to continue = down that path just because it is the easiest.=20 I'd much rather have a new protocol, be it NSCP or something else. >> Phil mentioned NSCP, which is an excellent candidate. Provisioning = is an oddity because it didn't exist in DNS originally but was added = with UPDATE and having done that I can see the value in finishing the = job by adding the provisioning of zones but I can't currently see any = value in going further than that. >=20 > IIRC, there were also some other proposals in the style of the old > metazones idea back then (and i recall one floating around based on a > class instead of an opcode). Shuddder. > AFAIK, NSCP hasn't had any action since it got kicked back to dnsop, > lots of people want it, noone wants to work on it, and perhaps it is > also overshooting the goals people have. Could be. I've thought a bit about that over the years, and that's = probably the best explanation. Regards, Johan From jad@sinodun.com Fri Aug 16 05:48:54 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 BDBE611E81A1 for ; Fri, 16 Aug 2013 05:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 ylSiWAhLSfVr for ; Fri, 16 Aug 2013 05:48:32 -0700 (PDT) Received: from cpanelsmarthost2.zen.co.uk (cpanelsmarthost2.zen.co.uk [82.71.204.226]) by ietfa.amsl.com (Postfix) with ESMTP id E6B0C11E8131 for ; Fri, 16 Aug 2013 05:48:31 -0700 (PDT) Received: from [88.98.24.67] (helo=shcp01.hosting.zen.net.uk) by cpanelsmarthost2.zen.co.uk with esmtp (Exim 4.72) (envelope-from ) id 1VAJSA-0002D5-3L for dnsext@ietf.org; Fri, 16 Aug 2013 12:48:30 +0000 Received: from 82-68-198-190.dsl.in-addr.zen.co.uk ([82.68.198.190]:31963 helo=[192.168.1.39]) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VAJS4-0007ub-Oh for dnsext@ietf.org; Fri, 16 Aug 2013 13:48:24 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: John Dickinson In-Reply-To: <36FF164D-8176-405B-B226-653B16138C9C@hopcount.ca> Date: Fri, 16 Aug 2013 12:48:30 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7FE39722-2FBF-4D12-8CE1-5A6FE0EEF05D@sinodun.com> References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813040557.E525D3849522@drugs.dv.isc.org> <04CA3CF3-79F7-4529-9C9E-60504BC96F4C@nzrs.net.nz> <5209FB0C.8050502@sidn.nl> <36FF164D-8176-405B-B226-653B16138C9C@hopcount.ca> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sinodun.com X-Get-Message-Sender-Via: shcp01.hosting.zen.net.uk: authenticated_id: jad+sinodun.com/only user confirmed/virtual account not confirmed X-Mailman-Approved-At: Fri, 16 Aug 2013 07:23:49 -0700 Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 16 Aug 2013 12:48:54 -0000 On 13 Aug 2013, at 12:38, Joe Abley wrote: >=20 > On 2013-08-13, at 05:23, Jelte Jansen wrote: >=20 >> AFAIK, NSCP hasn't had any action since it got kicked back to dnsop, >> lots of people want it, noone wants to work on it, and perhaps it is >> also overshooting the goals people have. >=20 > There's an implementation that works with multiple nameservers, right? >=20 > I don't remember how polished it was, but I remember it being good = enough for Sara to be able to do live demos from the stage at RIPE = meetings. Even considering Sara's nerves of steel, that suggests it = works well enough :-) >=20 > https://dev.sinodun.com/wiki/display/DNSCCM/DNSCCM+Home Yes - we produced an implementation of NSCP a while back which supports = BIND 9 and NSD 3 but is now stuck at beta because a) the funding ran out = (billable work got in the way) and b) we didn't ever get anyone = interested in testing it in anger. We have version 3 of the draft (based = on the working implementation) that is 95% done, just stalled at final = review as these things tend to do...... Technically the issues we faced with the implementation were: - We chose to use NETCONF/ Yang which had some limitations. At the time = there was only one Open Source implementation of NETCONF (Yuma) which = was missing a couple of key features. - NETCONF assumes that devices have an API available to dynamically = update single elements of the configuration. This didn't play so nicely = with nameservers that need to reload the entire config to pick up any = change... - the NETCONF/ Yang model assumes that there is a nice clear base = control protocol which every device (nameserver) implements. Then = everything else is treated as an optional extension. When you try to = implement this for nameservers (even just the the two we implemented) = your base model turns out to be tiny since each nameserver does even the = most basic things in different enough ways to make a common model = tricky.=20 I believe there was some work done by BIND10, KNOT and others to try to = align their remote control protocols but I don't know the details. We would be interested in revisiting, updating the code and ID if there = is any interest on the dnsop list. regards John --- jad@sinodun.com http://sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From drc@virtualized.org Mon Aug 19 15:08:06 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 1400711E82F9 for ; Mon, 19 Aug 2013 15:08:06 -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 DQ9wgZin1gli for ; Mon, 19 Aug 2013 15:08:00 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id DF74711E830D for ; Mon, 19 Aug 2013 15:07:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id E21138712A for ; Mon, 19 Aug 2013 18:07:39 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 01829-01 for ; Mon, 19 Aug 2013 18:07:39 -0400 (EDT) Received: from terminus.lan (menlopark.keplers.com [74.93.6.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id 6726287128 for ; Mon, 19 Aug 2013 18:07:39 -0400 (EDT) From: David Conrad Content-Type: multipart/signed; boundary="Apple-Mail=_6FCDA7D5-CD3B-43A5-8145-75BEBE943637"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Date: Mon, 19 Aug 2013 15:07:37 -0700 To: "dnsext@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dnsext] Deprecating SPF 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, 19 Aug 2013 22:08:06 -0000 --Apple-Mail=_6FCDA7D5-CD3B-43A5-8145-75BEBE943637 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For those not on IETF-Announce/IETF lists: Quoting The IESG (iesg-secretary@ietf.org): > The IESG has received a request from the SPF Update WG (spfbis) to > consider the following document: > - 'Sender Policy Framework (SPF) for Authorizing Use of Domains in = Email, Version 1' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. If you have an opinion (which I believe some on this list do), might be = worth providing it... Regards, -drc --Apple-Mail=_6FCDA7D5-CD3B-43A5-8145-75BEBE943637 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSEpcqAAoJEIzZ2DQOJFbK1Z8IALHRP2kyQT2Hv/wEKAt6np8K RAx94508cLfr44GDxTrcJVNJy5okvQM+qKJzt4qxiVXumx0NyZ86AIOJVslWFVsO ciMhvU+LLKkKJ2d2YO72+Tu4JJhnVbVWogJxrv2/SZHrII1ZEgkRdyvF5C96R4f1 rtVQs9DwnEmqKpX/GsJga/6M42cL47rGi1x/Rhs+DgwARDh+IygssO3s4H1jzH69 lw1tqgjO1XoT2VdjHNmOIIxwEVkjuyzmTnfWKH+sCfYML5jeqZMUVoHLx4NHdeKO /WZed0ELT4d/DuUb/XMQsuv2N464KHJECRPDP6PVoE+FU42VnADEWMxHRcrjW1w= =9wcz -----END PGP SIGNATURE----- --Apple-Mail=_6FCDA7D5-CD3B-43A5-8145-75BEBE943637-- From ajs@anvilwalrusden.com Mon Aug 19 15:20:51 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 E5EDB11E8175 for ; Mon, 19 Aug 2013 15:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 xX5H-OsznMKg for ; Mon, 19 Aug 2013 15:20:46 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF0A11E8172 for ; Mon, 19 Aug 2013 15:20:45 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 74FDA8A031 for ; Mon, 19 Aug 2013 22:20:42 +0000 (UTC) Date: Mon, 19 Aug 2013 18:20:38 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130819222037.GA55876@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Deprecating SPF 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, 19 Aug 2013 22:20:52 -0000 On Mon, Aug 19, 2013 at 03:07:37PM -0700, David Conrad wrote: > If you have an opinion (which I believe some on this list do), might be worth providing it... > If, however, you have an opinion about the deprecation of RTYPE 99 use, I'd appreciate it if you'd at least read the archives about how the decision was made (no brickbats for David, who clearly did that reading). I seem to recall trying to get some interest in that discussion back when it was happening, and nobody came. Showing up now with an opinion but not having read the arguments might not get a friendly reception from Pete Resnick, the responsible AD. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From paf@frobbit.se Mon Aug 19 23:01:08 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 10E0911E8101 for ; Mon, 19 Aug 2013 23:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 mSEBIhPp8dm4 for ; Mon, 19 Aug 2013 23:01:07 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 8411911E80D2 for ; Mon, 19 Aug 2013 23:01:07 -0700 (PDT) Received: from [IPv6:2a01:3f0:1::85d3:8d58:735a:e251] (unknown [IPv6:2a01:3f0:1:0:85d3:8d58:735a:e251]) by mail.frobbit.se (Postfix) with ESMTPSA id 8741E21F96; Tue, 20 Aug 2013 08:00:57 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20130819222037.GA55876@mx1.yitter.info> Date: Tue, 20 Aug 2013 08:00:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> References: <20130819222037.GA55876@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) Cc: Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 06:01:08 -0000 On 20 aug 2013, at 00:20, Andrew Sullivan = wrote: > I seem to recall trying to get some interest in that > discussion back when it was happening, and nobody came. The problem is that people like me feel we have already stated our view, = strongly, several times, and we give up. People that support deprecation of RR 99 has just repeated their view = that anything but TXT is useless and that as both TXT and 99 is in use, = we can simply deprecate use of RR 99. If that argument IS something IETF (including IAB) is listening to. Then = who am I to say that that is an extremely bad architectural choice. I.e. the question is a fundamental architectural question on the DNS. = Should we use different or same RR Types. If we should use TXT and overload that RR, and IAB accepts that (even if = IAB has written a document on Choices with DNS (which I was a co-author = of), well, then lets do that fully, for everything. I should btw also solve the problem with A+AAAA queries. If we deprecate 99, we should also deprecate both A and AAAA and reuse = TXT instead. That would make deployment of IPv6 easier. :-) Yes, I think the discussion is that silly, and because of that I have = given up this discussion. :-( That said, I strongly support your comment Andrew that IF people want to = go back and continue the argument, one should re-read the archives. Or = else Pete (cc:ed -- for disclosure reasons, not because I ask for a = reaction) will not be happy ;-) Patrik P.S. Even their use of the TXT is silly, as they have first of all an = RDATA field with separators. Then they say that one should either only = use the first of the fields, or if there is more than one, concatenate = them. After that they have an algorithm on how to extract separate = fields out of that one field (where they already removed the field = separators). The silliness does not stop...it just goes on and on and = on. From alex@alex.org.uk Mon Aug 19 23:55: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 5FA3411E81CC for ; Mon, 19 Aug 2013 23:55:45 -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 UnQA65kvsgJ6 for ; Mon, 19 Aug 2013 23:55:44 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id 2C09011E8180 for ; Mon, 19 Aug 2013 23:55:43 -0700 (PDT) Received: by mail.avalus.com (Postfix) with ESMTPSA id E45E6C561A2; Tue, 20 Aug 2013 07:55:29 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Alex Bligh In-Reply-To: <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> Date: Tue, 20 Aug 2013 07:55:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5918AE00-4722-4001-805C-496386A807B4@alex.org.uk> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1085) Cc: Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 06:55:45 -0000 On 20 Aug 2013, at 07:00, Patrik F=E4ltstr=F6m wrote: > The problem is that people like me feel we have already stated our = view, strongly, several times, and we give up. >=20 > People that support deprecation of RR 99 has just repeated their view = that anything but TXT is useless and that as both TXT and 99 is in use, = we can simply deprecate use of RR 99. >=20 > If that argument IS something IETF (including IAB) is listening to. = Then who am I to say that that is an extremely bad architectural choice. +1. The same argument could be used to recommend deprecating IPv6 in = favour of IPv4. --=20 Alex Bligh From tale@dd.org Tue Aug 20 07:01:31 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 E0F2C21F9BB4 for ; Tue, 20 Aug 2013 07:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 wdnC6jKyAkdo for ; Tue, 20 Aug 2013 07:01:27 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3273E11E80E4 for ; Tue, 20 Aug 2013 07:01:22 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 9908B3F441; Tue, 20 Aug 2013 10:00:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <21011.30360.404427.255303@gro.dd.org> Date: Tue, 20 Aug 2013 10:00:56 -0400 From: Dave Lawrence To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> Cc: Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 14:01:32 -0000 Patrik F=E4ltstr=F6m writes: > The problem is that people like me feel we have already stated our > view, strongly, several times, and we give up.=20 Indeed. And because it was evident that no headway was being made by either side, some of us (me, at least) just sat out. I read through all of the arguments as they were happening. I appreciate the tension between easy pragmatism and clean design and thought that, amidst the usual snarking, good points were made on both sides. Personally, I support continued migration from TXT to SPF, but openly acknowledge that was the bias I had when the issue first arose, and the debate didn't change my mind either. I didn't contribute then because I didn't think there were any useful additional points to be made. I'm wondering now why I'm even writing this message, because it too doesn't contribute much useful to the discussion. Maybe on some level it is useful to hear ongoing frustration that the process of the Internet Engineering Task Force does not produce good engineering. On the other hand I have little doubt that some people reading this think the preceding sentence is just sour grapes from ending up on the losing side of the debate and they think the engineering is just fine. Net result: some of us give up before we even start. From bmanning@karoshi.com Tue Aug 20 07: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 17A3A11E8222 for ; Tue, 20 Aug 2013 07:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 0YeHnHL85hQc for ; Tue, 20 Aug 2013 07:06:22 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id A0AB711E8221 for ; Tue, 20 Aug 2013 07:06:02 -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 r7KE3mdr008202; Tue, 20 Aug 2013 14:03:49 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r7KE3mop008201; Tue, 20 Aug 2013 14:03:48 GMT Date: Tue, 20 Aug 2013 14:03:48 +0000 From: bmanning@vacation.karoshi.com To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20130820140348.GA8062@vacation.karoshi.com.> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> User-Agent: Mutt/1.4.1i Cc: Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 14:06:41 -0000 On Tue, Aug 20, 2013 at 08:00:56AM +0200, Patrik Fdltstrvm wrote: > > If we deprecate 99, we should also deprecate both A and AAAA and reuse TXT instead. That would make deployment of IPv6 easier. :-) > interestingly, we find here in the DNS, the problem of multiplexing. historically, such use in the DNS triggers "additional section processing" which has been considered a very poor choice for decades. outside the DNS, we have IP address multiplexing and port multiplexing, as ways to extend the lifetime of the IPv4 space, (NAT, CGN, ad nausea)... so its clear that parts of the community -really- want to do things the hard way, simply because the first steps look -so- easy. Admiral Ackbar said it best. That out of the way, apparently the IAB has no problems documenting use/practice. So there are two varients, 16 and 99. Fine. If I were to recommend any further action, it would be to insist that all SPF ID's/RFC's carry some boilerplate text along the lines of: "Type 16 (TXT) stores arbitrary text in a DNS record. Since the early 1990s, this record often carries protocol specific data, such as specified by RFC 1464, opportunistic encryption, Sender Policy Framework, DKIM, DMARC, DNS-SD, etc. Applications which use type 16 instead of their own RR type MUST NOT presume that only thier data structures are present. They SHOULD use application specific RR types when available." /bill From eckert@cisco.com Tue Aug 20 07:10: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 64C4311E8115 for ; Tue, 20 Aug 2013 07:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.304 X-Spam-Level: X-Spam-Status: No, score=-9.304 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] 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 IiZPOPjN0hkE for ; Tue, 20 Aug 2013 07:10:32 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0B01A11E80D9 for ; Tue, 20 Aug 2013 07:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2882; q=dns/txt; s=iport; t=1377007832; x=1378217432; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=wa7yba8U/k3UFqYtlRFYdsdjqUbaWR0A1HF0caxMQpo=; b=QmFmvC2w+2pWv36PZycP4RX5ZpiZiP9VJZtKl6iQyDc6+ZQKvZoiC7a+ HbPLLE5fBbpXauBWsA58xh6FsV1hkRArDjS5P0JO0unyvxr+qpEio2kIM 8OZyr/F5KdnpWom2b23pQM5PKJPadh1FddYWuAm0LY0Q2O4vMkpWh0/P5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAFx4E1KrRDoH/2dsb2JhbABagwU1Rb9lgSEWdIIkAQEBBAEBATc0CxALEgYJJQ8FEyIVEhSHew2sbwSQVQeEFAOJLY43AZFWgzwc X-IronPort-AV: E=Sophos;i="4.89,920,1367971200"; d="scan'208";a="86327541" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 20 Aug 2013 14:10:31 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7KEAUd8025500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 14:10:30 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r7KEATsS025616; Tue, 20 Aug 2013 07:10:29 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r7KEATYH025615; Tue, 20 Aug 2013 07:10:29 -0700 Date: Tue, 20 Aug 2013 07:10:29 -0700 From: Toerless Eckert To: Patrik@cisco.com, F@cisco.com Message-ID: <20130820141029.GQ32655@cisco.com> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> User-Agent: Mutt/1.4.2.2i X-Auto-Response-Suppress: DR, OOF, AutoReply Cc: Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 14:10:36 -0000 Probably stupid question: I assume that a key reason for some part of the community preferring TXT records is that they allow to quickly adopt them because it is possible to configure them on any existing DNS server. Are there any examples of DNS servers that allow to define new RR types and some value encoding - without having to wait for a software upgrade of the DNS server software. Likewise, are the DNS client APIs where the apps can leverage new RR types unknown at the time the client SDK was written. Cheers Toerless On Tue, Aug 20, 2013 at 08:00:56AM +0200, Patrik F?ltstr?m wrote: > On 20 aug 2013, at 00:20, Andrew Sullivan wrote: > > > I seem to recall trying to get some interest in that > > discussion back when it was happening, and nobody came. > > The problem is that people like me feel we have already stated our view, strongly, several times, and we give up. > > People that support deprecation of RR 99 has just repeated their view that anything but TXT is useless and that as both TXT and 99 is in use, we can simply deprecate use of RR 99. > > If that argument IS something IETF (including IAB) is listening to. Then who am I to say that that is an extremely bad architectural choice. > > I.e. the question is a fundamental architectural question on the DNS. Should we use different or same RR Types. > > If we should use TXT and overload that RR, and IAB accepts that (even if IAB has written a document on Choices with DNS (which I was a co-author of), well, then lets do that fully, for everything. > > I should btw also solve the problem with A+AAAA queries. > > If we deprecate 99, we should also deprecate both A and AAAA and reuse TXT instead. That would make deployment of IPv6 easier. :-) > > Yes, I think the discussion is that silly, and because of that I have given up this discussion. :-( > > That said, I strongly support your comment Andrew that IF people want to go back and continue the argument, one should re-read the archives. Or else Pete (cc:ed -- for disclosure reasons, not because I ask for a reaction) will not be happy ;-) > > Patrik > > P.S. Even their use of the TXT is silly, as they have first of all an RDATA field with separators. Then they say that one should either only use the first of the fields, or if there is more than one, concatenate them. After that they have an algorithm on how to extract separate fields out of that one field (where they already removed the field separators). The silliness does not stop...it just goes on and on and on. > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From bmanning@karoshi.com Tue Aug 20 07:19:30 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 E157011E8100 for ; Tue, 20 Aug 2013 07:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 fGMAM67TAWvD for ; Tue, 20 Aug 2013 07:19:26 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7113C11E8104 for ; Tue, 20 Aug 2013 07:19:26 -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 r7KEJOdr008301; Tue, 20 Aug 2013 14:19:24 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r7KEJOL1008300; Tue, 20 Aug 2013 14:19:24 GMT Date: Tue, 20 Aug 2013 14:19:24 +0000 From: bmanning@vacation.karoshi.com To: Toerless Eckert Message-ID: <20130820141924.GB8062@vacation.karoshi.com.> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820141029.GQ32655@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130820141029.GQ32655@cisco.com> User-Agent: Mutt/1.4.1i Cc: Pete Resnick , "dnsext@ietf.org Group" , F@cisco.com, Patrik@cisco.com Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 14:19:31 -0000 Steve Hotz and I designed and built a DNS server platform that supported loadable DNS attributes including RR types. I don't know of any production systems that support that however. /bill On Tue, Aug 20, 2013 at 07:10:29AM -0700, Toerless Eckert wrote: > Probably stupid question: > > I assume that a key reason for some part of the community preferring TXT > records is that they allow to quickly adopt them because it is possible to > configure them on any existing DNS server. Are there any examples of DNS > servers that allow to define new RR types and some value encoding - without > having to wait for a software upgrade of the DNS server software. Likewise, > are the DNS client APIs where the apps can leverage new RR types unknown at > the time the client SDK was written. > > Cheers > Toerless > > On Tue, Aug 20, 2013 at 08:00:56AM +0200, Patrik F?ltstr?m wrote: > > On 20 aug 2013, at 00:20, Andrew Sullivan wrote: > > > > > I seem to recall trying to get some interest in that > > > discussion back when it was happening, and nobody came. > > > > The problem is that people like me feel we have already stated our view, strongly, several times, and we give up. > > > > People that support deprecation of RR 99 has just repeated their view that anything but TXT is useless and that as both TXT and 99 is in use, we can simply deprecate use of RR 99. > > > > If that argument IS something IETF (including IAB) is listening to. Then who am I to say that that is an extremely bad architectural choice. > > > > I.e. the question is a fundamental architectural question on the DNS. Should we use different or same RR Types. > > > > If we should use TXT and overload that RR, and IAB accepts that (even if IAB has written a document on Choices with DNS (which I was a co-author of), well, then lets do that fully, for everything. > > > > I should btw also solve the problem with A+AAAA queries. > > > > If we deprecate 99, we should also deprecate both A and AAAA and reuse TXT instead. That would make deployment of IPv6 easier. :-) > > > > Yes, I think the discussion is that silly, and because of that I have given up this discussion. :-( > > > > That said, I strongly support your comment Andrew that IF people want to go back and continue the argument, one should re-read the archives. Or else Pete (cc:ed -- for disclosure reasons, not because I ask for a reaction) will not be happy ;-) > > > > Patrik > > > > P.S. Even their use of the TXT is silly, as they have first of all an RDATA field with separators. Then they say that one should either only use the first of the fields, or if there is more than one, concatenate them. After that they have an algorithm on how to extract separate fields out of that one field (where they already removed the field separators). The silliness does not stop...it just goes on and on and on. > > > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From jfesler@gigo.com Tue Aug 20 07:22: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 A7E4F11E822E for ; Tue, 20 Aug 2013 07:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 zz7mnvJ1RHsU for ; Tue, 20 Aug 2013 07:22:41 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by ietfa.amsl.com (Postfix) with ESMTP id E2DAF11E8115 for ; Tue, 20 Aug 2013 07:22:40 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so459500wes.39 for ; Tue, 20 Aug 2013 07:22:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rmAEGjjaEyNXB1OzcRAjumydwkMDfSMBIbZUINOKX8U=; b=JqYrkUAaXakJg6e2dbTG6WQmxFC0m33OSaEXULd4QgE58SZt2lNFkp9/AIyFqQDAVD 69cgwdyKGzbhlG9kWnbYKypMbwSLD5icKTE0S8ctAArh2UW+TItVb70f5Jy9HPoXas62 XDKW4ul+WVDmO0/wsPHvuhf84Z7hDqGSigVuzwrTAOYkF91eK6rFQyNGwPxCF0EvM6gm Qf3fIpKjnWrVUDRlQ3FroWM59cgsjjX82mZmg6iHvtT7JlS6gMIQdbIfoBwfaWydzhhF o46EJubruUXK/+CZ61HILEKzcQVmmxpXXfzfb46mF1rP7yHYO02Bf/TrCxq6gLnjXw63 4XyA== X-Gm-Message-State: ALoCoQmYNcwxl6ThcJ6Y717Q1UAQVqM24ORJfPIyOTdBb/NcofeURigT0OVTDS7KVirRMno+Ioze MIME-Version: 1.0 X-Received: by 10.180.189.37 with SMTP id gf5mr1527756wic.31.1377008559935; Tue, 20 Aug 2013 07:22:39 -0700 (PDT) Received: by 10.216.248.131 with HTTP; Tue, 20 Aug 2013 07:22:39 -0700 (PDT) In-Reply-To: <20130820141029.GQ32655@cisco.com> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820141029.GQ32655@cisco.com> Date: Tue, 20 Aug 2013 07:22:39 -0700 Message-ID: From: Jason Fesler To: Toerless Eckert Content-Type: multipart/alternative; boundary=001a11c23c7e1168ac04e461caf7 Cc: Pete Resnick , "dnsext@ietf.org Group" , "F@cisco.com" , "Patrik@cisco.com" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 14:22:45 -0000 --001a11c23c7e1168ac04e461caf7 Content-Type: text/plain; charset=ISO-8859-1 On Tuesday, August 20, 2013, Toerless Eckert wrote: > Probably stupid question: > > Are there any examples of DNS > servers that allow to define new RR types and some value encoding - without > having to wait for a software upgrade of the DNS server software. djbdns has a mechanism for this. "Handy" for AAAA records... -- Jason Fesler, email/jabber resume: http://jfesler.com "Give a man 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." --001a11c23c7e1168ac04e461caf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tuesday, August 20, 2013, Toerless Eckert wrote:
Probably stupid question:

Are there any examples of DNS
servers that allow to define new RR types and some value encoding - without=
having to wait for a software upgrade of the DNS server software.

djbdns has a mechanism for this. =A0"Handy"= ; for AAAA records...=A0


--
=
=A0Jason Fesler, email/jabber <jfesler@gigo.com> resume: http://jfesler.com
=A0"Give a man fi= re, and he'll be warm for a day;
=A0set a man on fire, and he'll be warm for the rest of his life.&= quot;


--001a11c23c7e1168ac04e461caf7-- From ajs@anvilwalrusden.com Tue Aug 20 07:42:19 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 F0C9311E8104 for ; Tue, 20 Aug 2013 07:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 F4gipme3YJp5 for ; Tue, 20 Aug 2013 07:42:13 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2920711E8100 for ; Tue, 20 Aug 2013 07:42:13 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 9190E8A031 for ; Tue, 20 Aug 2013 14:42:12 +0000 (UTC) Date: Tue, 20 Aug 2013 10:42:11 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130820144211.GD20618@mx1.yitter.info> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 14:42:19 -0000 On Tue, Aug 20, 2013 at 08:00:56AM +0200, Patrik Fältström wrote: > > People that support deprecation of RR 99 has just repeated their > view that anything but TXT is useless and that as both TXT and 99 is > in use, we can simply deprecate use of RR 99. I think that is a gross caricature of what the proponents of deprecation have argued. It's easy to knock down a straw person. The argument is instead that the overwhelming majority of actual deployed uses are either using TXT or are using both TXT and SPF. Virtually nobody is using SPF only. Therefore, regardless of what 4408bis said, it would have to continue to support TXT. If it were altered to require SPF lookup first, then it would, at day 1, immediately impose almost totally useless query load for every SPF attempt. If it were altered to require TXT lookup first, then there would be no reason at all ever to move to the SPF type. Moreover, either strategy would require additional complexity (the fallback rules) for SPF validators, and it would require additional specification of what a server was supposed to do in the case where the TXT record and the SPF record didn't agree; this would make the specification more complex, too. For all those reasons, it seemed to the WG that the dual-RRTYPE strategy that was used for SPF was a mistake, and that it should be removed. This is not a precedent or a general engineering point (unless you mean the more general point that the IETF and IAB ought to work hard and convincing people not to use unscoped TXT records for application data (i.e. without an underscore label) even during prototyping. But the IAB has already published that advice). > If we deprecate 99, we should also deprecate both A and AAAA and reuse TXT instead. That would make deployment of IPv6 easier. :-) > This doesn't follow, because it's merely a contingent fact that SPF was originally developed using the TXT record at the target name. People no longer do that, unless they're named "Google", it seems. > P.S. Even their use of the TXT is silly, as they have first of all > an RDATA field with separators. Then they say that one should either > only use the first of the fields, or if there is more than one, > concatenate them. After that they have an algorithm on how to > extract separate fields out of that one field (where they already > removed the field separators). The silliness does not stop...it just > goes on and on and on. Sure. But the plain fact is that this protocol, with all its stupidity and weaknesses, is widely deployed on the Internet. Indeed, there's a case to be made that it is at least as successful as DNSSEC and more successful than IPv6. For that reason, it seems churlish not to standardize it. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From jaap@NLnetLabs.nl Tue Aug 20 07:43:34 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 7028111E8227 for ; Tue, 20 Aug 2013 07:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.465, 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 dasZjeBZBK7R for ; Tue, 20 Aug 2013 07:43:34 -0700 (PDT) Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4ccb]) by ietfa.amsl.com (Postfix) with ESMTP id B3F5711E822D for ; Tue, 20 Aug 2013 07:43:32 -0700 (PDT) Received: from bela.nlnetlabs.nl (localhost [IPv6:::1]) by bela.nlnetlabs.nl (8.14.7/8.14.7) with ESMTP id r7KEfqAe070703; Tue, 20 Aug 2013 16:41:53 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) Authentication-Results: bela.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl Message-Id: <201308201441.r7KEfqAe070703@bela.nlnetlabs.nl> To: Dave Lawrence From: Jaap Akkerhuis In-reply-to: <21011.30360.404427.255303@gro.dd.org> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <21011.30360.404427.255303@gro.dd.org> Comments: In-reply-to Dave Lawrence message dated "Tue, 20 Aug 2013 10:00:56 -0400." Date: Tue, 20 Aug 2013 16:41:52 +0200 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (bela.nlnetlabs.nl [IPv6:::1]); Tue, 20 Aug 2013 16:41:54 +0200 (CEST) Cc: Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 14:43:34 -0000 Patrik F�ltstr�m writes: > The problem is that people like me feel we have already stated our > view, strongly, several times, and we give up. Indeed. And because it was evident that no headway was being made by either side, some of us (me, at least) just sat out. I read through all of the arguments as they were happening. I appreciate the tension between easy pragmatism and clean design and thought that, amidst the usual snarking, good points were made on both sides. Personally, I support continued migration from TXT to SPF, but openly acknowledge that was the bias I had when the issue first arose, and the debate didn't change my mind either. I didn't contribute then because I didn't think there were any useful additional points to be made. I'm wondering now why I'm even writing this message, because it too doesn't contribute much useful to the discussion. Maybe on some level it is useful to hear ongoing frustration that the process of the Internet Engineering Task Force does not produce good engineering. On the other hand I have little doubt that some people reading this think the preceding sentence is just sour grapes from ending up on the losing side of the debate and they think the engineering is just fine. Net result: some of us give up before we even start. Yes. I'm one of those. jaap From jabley@hopcount.ca Tue Aug 20 07:50: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 CEC9521F8427 for ; Tue, 20 Aug 2013 07:50:42 -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 XcBrm+Cwinne for ; Tue, 20 Aug 2013 07:50:42 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3903C11E8227 for ; Tue, 20 Aug 2013 07:50:40 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so476164pdi.33 for ; Tue, 20 Aug 2013 07:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rBc8CLB8xGftfPh7VfdnCk/r+z7W/+7pm1++3BA+WJs=; b=CMxE31ZpHl4Xv6d7rnGE9VbmWw+DjA/jm8fTSeng3g4cv79VkJ2f5xM0zlxyQNImAu 0hu1i6hVzM1th24Zr/3pa+Hvtenriw3OdYIvTf0xDsD9DdASxLH8uEt8aPz+uCboKFZ+ SMwYVJGvAYISHj6c7e1jc/W1OWQr+h0CeNIJE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=rBc8CLB8xGftfPh7VfdnCk/r+z7W/+7pm1++3BA+WJs=; b=MGSaZA5muzobj2KULyigFubvvRM+sqU00kKZD6gUZ5ijtU2DVBDHrWLE3Pz2oXRSgF hRVaICY6ekdSbAP/UV5bvENrco8dzOo5XxbuQwhea1IVRaTe9ji4dJq0+C8Uw7Kh7Sm/ KA/HaXDlvHyM3zjBLPUnyeHQwSU7PeXrJ0j2zMbISnGtdQX7D60WUL9gOMRg/qsidP8A mKLB9EPF4GamEU3IA9EvlV6b0su+/2yZywy+2b7r7f7N0a70eCi+7mbe8Fm6EbZXd3Mt 9jQYR6sZlBEQWm8PY/HYslZ6ALburAoAifmLYDVHF+A2jfLwB8OHjS5Ib0nhMSZICwTL NnaQ== X-Gm-Message-State: ALoCoQn1TXJkRq5WghdEiSYzSpZxutdSs1NSNzQ4Hy2y5TEqYNp2UYxZhNA38xmQInZANGmBKPiq X-Received: by 10.66.221.8 with SMTP id qa8mr2612407pac.188.1377010234238; Tue, 20 Aug 2013 07:50:34 -0700 (PDT) Received: from [199.212.90.39] (198-84-196-106.cpe.teksavvy.com. [198.84.196.106]) by mx.google.com with ESMTPSA id dg3sm2605155pbc.24.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Aug 2013 07:50:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Joe Abley In-Reply-To: <20130820141029.GQ32655@cisco.com> Date: Tue, 20 Aug 2013 10:50:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820141029.GQ32655@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1508) Cc: Pete Resnick , "dnsext@ietf.org Group" , F@cisco.com, Patrik@cisco.com Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 14:50:50 -0000 On 2013-08-20, at 10:10, Toerless Eckert wrote: > Are there any examples of DNS > servers that allow to define new RR types and some value encoding - = without=20 > having to wait for a software upgrade of the DNS server software. Yes, including BIND9 which is probably the most widely-deployed DNS = server software. But my vague recollection is that this is not supported by Microsoft's = DNS server implementation on Windows, and since many Windows environment = are tied to that implementation because of requirements to use Active = Directory, and since many people have mail systems running on Windows, = TXT was a pragmatic path forward. RFC 3597 may be worth a look if you are interested. Joe From jra@baylink.com Tue Aug 20 07:54:31 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 096D811E8227 for ; Tue, 20 Aug 2013 07:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 RIm-kZPQNl0C for ; Tue, 20 Aug 2013 07:54:26 -0700 (PDT) Received: from benjamin.baylink.com (rrcs-24-129-180-187.se.biz.rr.com [24.129.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 2316411E80E3 for ; Tue, 20 Aug 2013 07:54:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by benjamin.baylink.com (Postfix) with ESMTP id BB8B61F00399 for ; Tue, 20 Aug 2013 10:54:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at benjamin.baylink.com Received: from benjamin.baylink.com ([127.0.0.1]) by localhost (benjamin.baylink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 977uNznHMM3E for ; Tue, 20 Aug 2013 10:54:13 -0400 (EDT) Received: from benjamin.baylink.com (benjamin.baylink.com [192.168.253.10]) by benjamin.baylink.com (Postfix) with ESMTP id C54D41F00589 for ; Tue, 20 Aug 2013 10:54:13 -0400 (EDT) Date: Tue, 20 Aug 2013 10:54:13 -0400 (EDT) From: Jay Ashworth To: dnsext Message-ID: <22092316.4326.1377010453764.JavaMail.root@benjamin.baylink.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [71.251.93.138] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - SAF3 (Win)/6.0.9_GA_2686) Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 14:54:31 -0000 ----- Original Message ----- > From: "Joe Abley" > On 2013-08-20, at 10:10, Toerless Eckert wrote: > > > Are there any examples of DNS > > servers that allow to define new RR types and some value encoding - > > without > > having to wait for a software upgrade of the DNS server software. > > Yes, including BIND9 which is probably the most widely-deployed DNS > server software. > > But my vague recollection is that this is not supported by Microsoft's > DNS server implementation on Windows, and since many Windows > environment are tied to that implementation because of requirements to > use Active Directory, and since many people have mail systems running > on Windows, TXT was a pragmatic path forward. Probably worth noting, too, that *LOTS* of people interact with DNS through webhost control panels; those, too, would have to accept as valid a new record type: if it's not on the pull-down menu, you can't add it. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From marka@isc.org Tue Aug 20 08:01: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 BA31611E8252 for ; Tue, 20 Aug 2013 08:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.445, 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 LZQhffObTGri for ; Tue, 20 Aug 2013 08:00:59 -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 A706A11E823E for ; Tue, 20 Aug 2013 08:00:59 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 6A646C9423; Tue, 20 Aug 2013 15:00:46 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377010859; bh=/8ignwNdc+dq9zDnf4c/7PZBWmiTHuN8eo2N2rVaa6k=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=ZZWdtF0GpVwsuzZ5oPF0V7owJfI9FPru4luFySBbTTWohHI8jBLFxAuge+zSz1L8O hfCMn71oTeBgzfkeMuqOV4asTPrS/+AnM0ZH3Ou1xs4FYmH6vvOi4iXYGnSnQs7v4Y Z5tkzYdnXTFVl43jXD7XFGIWuZ8kVX3FO3b040l0= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 20 Aug 2013 15:00:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 981461602B4; Tue, 20 Aug 2013 15:00:52 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 67E77160219; Tue, 20 Aug 2013 15:00:52 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id E490038B559F; Wed, 21 Aug 2013 01:00:41 +1000 (EST) To: Toerless Eckert From: Mark Andrews References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820141029.GQ32655@cisco.com> In-reply-to: Your message of "Tue, 20 Aug 2013 07:10:29 -0700." <20130820141029.GQ32655@cisco.com> Date: Wed, 21 Aug 2013 01:00:41 +1000 Message-Id: <20130820150041.E490038B559F@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Pete Resnick , "dnsext@ietf.org Group" , F@cisco.com, Patrik@cisco.com Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 15:01:05 -0000 In message <20130820141029.GQ32655@cisco.com>, Toerless Eckert writes: > Probably stupid question: > > I assume that a key reason for some part of the community preferring TXT > records is that they allow to quickly adopt them because it is possible to > configure them on any existing DNS server. Are there any examples of DNS > servers that allow to define new RR types and some value encoding - without > having to wait for a software upgrade of the DNS server software. Yes. Named has supported unknown records for over a decade now. All the tools that ship with named support unknown records. The only reason there wasn't support earlier is that there wasn't a agreeded apon master file format. B.T.W. people have added private types to named in the past. Any semi competant C programmer can. Named was designed to make adding new types easy. You don't even need to fiddle with Makefiles. Just add the .c and .h files that describe how to parse and print the text format and wire formats. There is plenty of example code with all the other types. As for adding SPF to named it was: cp lib/dns/rdata/generic/txt_16.c lib/dns/rdata/generic/spf_99.c cp lib/dns/rdata/generic/txt_16.h lib/dns/rdata/generic/spf_99.h change all the "txt" to "spf" in the method names. change all the type checks to 99 instead of 16. make clean; make; make install Once that was done all the tools supported SPF. dig, host, nslookup, nsupdate, dnssec-signzone etc. > Likewise, > are the DNS client APIs where the apps can leverage new RR types unknown at > the time the client SDK was written. Libresolv/libbind written in the 1980's supported unknown types. It is still shipped with unix based systems. Unfortunately that doesn't help because unless you have the mnemonic in a header file people won't use it. http://www.ietf.org/mail-archive/web/spfbis/current/msg00645.html n = res_query(name, C_IN, 99, buf, sizeof(buf)); was all that was needed for unix / linux machines to make SPF lookup but that wasn't enough. The libraries named is currently built upon support unknown query types. Support for looking up unknown types in resolvers libraries was a requirement of RFC 1034. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From presnick@qti.qualcomm.com Tue Aug 20 08:05:20 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 5F57911E824B for ; Tue, 20 Aug 2013 08:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 W0un0Db9C0GP for ; Tue, 20 Aug 2013 08:05:16 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 07AD711E824D for ; Tue, 20 Aug 2013 08:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1377011115; x=1408547115; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jCErRbVJ6PSbzmevtRAIuZnJ9iZb+pPM/apCtKk6Gr8=; b=S8cchJo6KbkhpPqquNgTCjN2t0oNUkH1NjNFJYORA6JCOWMtYW3exi0O PrQJh2UWp6sFr9W5j+pXCSQEMIBELwptWUp9FaBf2frb755QbtfRqHI3n mGicHcmv/clnFBiFWW3H9j5ZebLSlxC1ehUi1uUX6PCYw4gawCDQ/jpW0 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7172"; a="49954689" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 20 Aug 2013 08:05:15 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7172"; a="498558591" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Aug 2013 08:05:15 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.146.2; Tue, 20 Aug 2013 08:05:15 -0700 Message-ID: <521385AA.9080401@qti.qualcomm.com> Date: Tue, 20 Aug 2013 10:05:14 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> In-Reply-To: <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.48.1] Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 15:05:20 -0000 On 8/20/13 1:00 AM, Patrik Fältström wrote: > The problem is that people like me feel we have already stated our view, strongly, several times, and we give up. > As far as I can tell, the views that you state below (and I don't remember views stated earlier) have *nothing* to do with the deprecation of RR 99 issue. What you are saying is that the original use of TXT was wrong. I probably agree with that, but that's not relevant to the current discussion. The question is whether the deprecation of 99 is appropriate, and if not what the document should do instead. > People that support deprecation of RR 99 has just repeated their view that anything but TXT is useless and that as both TXT and 99 is in use, we can simply deprecate use of RR 99. > I have not heard that argument being used, and certainly have not heard that this is what the chairs have based their call of consensus on. If you have examples of messages where this was the basis for the deprecation, I would like pointers to those messages. > If that argument IS something IETF (including IAB) is listening to. Then who am I to say that that is an extremely bad architectural choice. > > I.e. the question is a fundamental architectural question on the DNS. Should we use different or same RR Types. > Again, that is not the argument. There is vast agreement that using a new RR and not overloading TXT is the better architectural decision. The question is about a currently deployed protocol. It is using TXT records. It was written into an Experimental RFC quite some time ago that it should transition to SPF records. It provided a transition plan that, in practice, has failed to date. In fact, the transition plan introduced an interoperability problem. So the question is how to address that. There were several choices: - Let the transition plan run longer; it will work in the end - Fix the transition plan to a use a different algorithm and let that run for a while - Declare a flag day and say that TXT is no longer supported by the protocol - Declare failure of the transition and say that SPF is no longer supported by the protocol Each of these (well, maybe except the 3rd one) was seriously considered and discussed in the WG. The arguments used to defend the first two were not convincing to the WG. The third was a non-starter. They landed on the last choice. If you have a more convincing case for any of the above, you should be stating it. If you have an proposal that hasn't been heard, you should be stating it. But going back to first principles and saying the protocol should not have used TXT in the first place is not helpful to me or the chairs figuring out the consensus. I'm happy to grant that TXT should not have been used in the first place; so what? What does that tell me about what should be done now with a deployed base? > If we should use TXT and overload that RR, and IAB accepts that (even if IAB has written a document on Choices with DNS (which I was a co-author of), well, then lets do that fully, for everything. > OK, we should not use TXT and overload it from now on. What do we do now with this protocol? > I should btw also solve the problem with A+AAAA queries. > > If we deprecate 99, we should also deprecate both A and AAAA and reuse TXT instead. That would make deployment of IPv6 easier. :-) > Oh? Is there a large deployed base of TXT records for A and AAAA records in use? We should figure out what to do about that. > Yes, I think the discussion is that silly, and because of that I have given up this discussion. :-( > The A/AAAA discussion is silly, but it's because it has nothing to do with the question on the table. The question on the table regards what to do with the currently deployed protocol that made a poor decision some time ago (and one that would likely not have to be made today because the ecosystem is different). What should be done *in that protocol*? (The idea is not to "win" or "lose" the argument; this is not a debating society. The idea is to explain and convince people who have made an error in a technical choice. You seem to believe that the wrong technical choice was made by this WG. What was that error and why should they have chosen something different?) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From carsten@strotmann.de Tue Aug 20 07:58: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 014EF11E823E for ; Tue, 20 Aug 2013 07:58:27 -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 MBVC1zXUgi2a for ; Tue, 20 Aug 2013 07:58:26 -0700 (PDT) Received: from csgate3.strotmann.de (cstrotm-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:f1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 64F9C21F83EF for ; Tue, 20 Aug 2013 07:57:51 -0700 (PDT) Received: from Carstens-MacBook-Pro.local (unknown [212.255.19.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by csgate3.strotmann.de (Postfix) with ESMTPSA id 3B48150F2; Tue, 20 Aug 2013 16:57:47 +0200 (CEST) Message-ID: <521383E9.4080800@strotmann.de> Date: Tue, 20 Aug 2013 16:57:45 +0200 From: Carsten Strotmann User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Joe Abley References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820141029.GQ32655@cisco.com> In-Reply-To: X-Enigmail-Version: 1.2.3 OpenPGP: id=3479ABA2; url=pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 20 Aug 2013 08:06:53 -0700 Cc: Pete Resnick , Patrik@cisco.com, "dnsext@ietf.org Group" , F@cisco.com Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 14:58:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Joe Abley wrote: > Yes, including BIND9 which is probably the most widely-deployed DNS > server software. > > But my vague recollection is that this is not supported by > Microsoft's DNS server implementation on Windows, and since many > Windows environment are tied to that implementation because of > requirements to use Active Directory, and since many people have mail > systems running on Windows, TXT was a pragmatic path forward. > I did some tests on Windows 2008 (R2) in 2009 or 2010 and found that the Microsoft server does support RFC 3597 for zones loaded from a master (by zonetransfer) or from a masterfile, but there is no way to add or edit the data through the GUI (if is however possible to add the records to a plain text DNS master file using a text editor, if I remember correctly). I haven't tested zones stored in Active Directory. - -- Carsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlITg+kACgkQiDbv+TR5q6LXoQCgl+/DQ5SzwRFn/eqhsJqECQVq zLMAn2gNpOGvYJXRkxTxz2zmQr7YuXIL =XK+A -----END PGP SIGNATURE----- From paf@frobbit.se Tue Aug 20 08:18:08 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 825CD11E8255 for ; Tue, 20 Aug 2013 08:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, 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 uTrq5rXCmAMa for ; Tue, 20 Aug 2013 08:18:08 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id E95C711E80E3 for ; Tue, 20 Aug 2013 08:18:00 -0700 (PDT) Received: from [172.18.241.142] (w193-11-200-253.eduroam.sunet.se [193.11.200.253]) by mail.frobbit.se (Postfix) with ESMTPSA id C147821B31; Tue, 20 Aug 2013 17:17:59 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20130820144211.GD20618@mx1.yitter.info> Date: Tue, 20 Aug 2013 17:17:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 15:18:08 -0000 On 20 aug 2013, at 16:42, Andrew Sullivan = wrote: > The argument is instead that the overwhelming majority of actual > deployed uses are either using TXT or are using both TXT and SPF. Absolutely understood, as all examples in for example the RFC in = question is using TXT (except one, that show how to handle the case when = using TXT and SPF). And the fact people use both TXT and SPF is to me an indication the = migration plan works, and that the fix should be to clarify how to = continue that migration given that we have what I would call an unclear = paragraph exists in the original RFC. YMMV, which is obvious, as the consensus in the wg is to deprecate SPF = RR Type according to the wg chair. Otherwise there should not be this = I-D on the table. Patrik From paf@frobbit.se Tue Aug 20 08:28:27 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 1367211E8229 for ; Tue, 20 Aug 2013 08:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, 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 11p79m2deyjy for ; Tue, 20 Aug 2013 08:28:26 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6B911E8249 for ; Tue, 20 Aug 2013 08:28:21 -0700 (PDT) Received: from [172.18.241.142] (w193-11-200-253.eduroam.sunet.se [193.11.200.253]) by mail.frobbit.se (Postfix) with ESMTPSA id 60E6F23F76; Tue, 20 Aug 2013 17:28:19 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <521385AA.9080401@qti.qualcomm.com> Date: Tue, 20 Aug 2013 17:28:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <933357EA-6472-4C77-AED3-E6411BC684B6@frobbit.se> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <521385AA.9080401@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 15:28:27 -0000 On 20 aug 2013, at 17:05, Pete Resnick = wrote: > You seem to believe that the wrong technical choice was made by this = WG. What was that error and why should they have chosen something = different? The consensus related to how to fix RFC 4408 will be very rough. That is = clear. And I feel sorry for responsible AD and IESG to be forced to make = a decision that such a large rough part of the rough consensus will not = be happy with. Regardless of what the decision will be. An architectural correct solution is to change: OLD: An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type. If a domain has records of both types, they MUST have identical content. NEW: An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at type SPF, code 99. Lookup MUST first be of type SPF and SHOULD if no response is received be of type TXT. Reasoning: The use of the TXT record for SPF is not sounds for a number = of reasons: 1. The TXT record already can have multiple fields, and it is very = unfortunate that the SPF use of TXT records do not use that feature. = Instead the SPF specification do say that the first field should be = used, and if there are more than one they should be concatenated. After = one have one and only one field, that field should be parsed and divided = in fields. 2. It is even (compared to some other TXT related documents) pointed out = in RFC 4408 that collisions as described in RFC 5507 might happen. 3. It is also pointed out that there might be size issues with the = records, and experience from use of NAPTR show that selecting a = preferred mechanism that potentially blows the size of the RRSet is not = very wise. This is btw why the URI RR Type do not use a prefixed length = "text" field in the RDATA but do set the string the URI is to the full = length of the RDATA, i.e. without any 255 byte limitation. 4. DNS is by design (as pointed out in RFC 5507) created with a tuple = consisting of owner, type and class for selection by the client what = record set to be retrieved. This RRSet architecture is something that = comes back not only in the query/response architecture of the DNS = protocol, but also in the DNSSEC architecture where RRSets are the units = that are signed. Not explicitly ensuring an RRSet is used for SPF (and = nothing more) is an architectural choice I strongly am against. Because of these reasons, I do believe the choice is wrong to say that = TXT MUST be implemented and instead I am in favor of having type SPF be = mandatory for interoperability with fallback to lookup of TXT. Patrik From ajs@anvilwalrusden.com Tue Aug 20 08:37: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 72BE411E8110 for ; Tue, 20 Aug 2013 08:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 pH+vsAux49Xp for ; Tue, 20 Aug 2013 08:37:03 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0A16B21F9A72 for ; Tue, 20 Aug 2013 08:36:57 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4282C8A031 for ; Tue, 20 Aug 2013 15:36:57 +0000 (UTC) Date: Tue, 20 Aug 2013 11:36:56 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130820153656.GB21439@mx1.yitter.info> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 15:37:42 -0000 On Tue, Aug 20, 2013 at 05:17:59PM +0200, Patrik Fältström wrote: > > And the fact people use both TXT and SPF is to me an indication the > migration plan works, and that the fix should be to clarify how to > continue that migration given that we have what I would call an > unclear paragraph exists in the original RFC. RFC 6686 tells us the extent to which people are "using both". see section 3.1. No survey was able to find people "using both" at even 2% of all the domains surveyed. SPF records using TXT ranged between just under 40% to more than 50%. I find it hard to interpret that data as an indication that the migration plan is having any real effect at all. I don't think anyone can accuse me of being sanguine about the overloading of TXT. But the IETF is made ridiculous if it stands around trying to tell the sea to stay back. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Tue Aug 20 09:11:35 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 2D45511E8247 for ; Tue, 20 Aug 2013 09:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 JADceCRLLBQz for ; Tue, 20 Aug 2013 09:11:31 -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 B7AC711E80E1 for ; Tue, 20 Aug 2013 09:11:30 -0700 (PDT) Received: (qmail 896 invoked from network); 20 Aug 2013 16:11:24 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Aug 2013 16:11:24 -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=5213952c.xn--30v786c.k1308; i=johnl@user.iecc.com; bh=4rZ+IG9P0jeFCMGMMA8hO8Nlry59qiXW3KAebOp5zIg=; b=CtGdE2nUpFPs6BL3jw3/xGkyGLH1/N6viRDkQzfmsabJt70o9c2DawnpjmXDBcFbx30dx9CIba1xjSR2hmMKRqHsk83ILOxXq8TQ7lPvI0AzanhZluPwj3IgoHOM7q3Yl3M2046+Jh1Nees3PbHDLvpLhOXrvN/9Y8R4JeY0AzPtDf8/jdBHaHSBYBJS3OIOMjxhe3e+AmZE5z+qcX+LxfLPAwEKxo3jEPz4oXTxTXQ234h5nAZbWEGV9i7TIprK 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=5213952c.xn--30v786c.k1308; olt=johnl@user.iecc.com; bh=4rZ+IG9P0jeFCMGMMA8hO8Nlry59qiXW3KAebOp5zIg=; b=bWpEUNoe/2lPGZDjjB/7v7Vv4UZI25pQ6qqSHYhCn29K3bpsamGcc4ndgvbETOByL6/IFntwPPIEOa7p2pvGrhkUJ2ig7w3RTqAcafDgi1mAUIk2sGQ6ahjxk6obmIvQQi5I1EfgKuFaD9ZTC13+cQyw9fajJ18bJmhdAL4gzbzu7WGGo0I6/9BBG8VEyvBlzN/XtOjrwS/6IHp01T9TN29St09M6M9hC5WlH55T1mQdoNYQfYhCE6MKIBUERJ5Y Date: 20 Aug 2013 16:11:02 -0000 Message-ID: <20130820161102.79213.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20130820141029.GQ32655@cisco.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] new RRRTYPEs, was Deprecating SPF 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, 20 Aug 2013 16:11:35 -0000 >Probably stupid question: > >I assume that a key reason for some part of the community preferring TXT >records is that they allow to quickly adopt them because it is possible to >configure them on any existing DNS server. Are there any examples of DNS >servers that allow to define new RR types and some value encoding - without >having to wait for a software upgrade of the DNS server software. Likewise, >are the DNS client APIs where the apps can leverage new RR types unknown at >the time the client SDK was written. Most DNS servers let you stick in unknown RRs using generic hex or octal values. I've written preprocessors to massage zone info to handle RRs that my server doesn't, and I'm sure I'm not the only one. Vixie and I have a proposal to publish the syntax of new RRs in the DNS itself, both so that DNS servers can automatically configure, but equally importantly, so the configuration web crudware that most people use to manage their DNS info can automatically configure as well. It's not a complete solution, since it can't handle major changes like DNSSEC that require semantic changes to the DNS servers and caches, but for the large majority of RRs that are just RRs, it seems useful to me. It got a surprisingly hostile reaction here, but people are interested in appsarea. The draft is draft-levine-dnsextlang-06 R's, John From eckert@cisco.com Tue Aug 20 09:11: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 65FF221F83EF for ; Tue, 20 Aug 2013 09:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.951 X-Spam-Level: X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 oTwM-ykN+dGx for ; Tue, 20 Aug 2013 09:11:37 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id D50DA11E80E1 for ; Tue, 20 Aug 2013 09:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3402; q=dns/txt; s=iport; t=1377015095; x=1378224695; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=AawGOqYty/NCuBFj5WWr6/a9CWBALgMcm0n3bYYUQTA=; b=KHfUvF19hhXFqT7cr0JK0YgiVMBA+lmjbmhs52ounxT/ddsBO8mhhtpO s/GSOEgUQkXII6pKBjS+0nVcF22QbtBiSO/HGusCucNKhAsDl6tCUxlXL cdZC/Z9AA3bSSiao2iRDOP7nbHgWiX4EmPEQ1larAhTSOpzCFcIMn1C6L A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAHWUE1KrRDoI/2dsb2JhbABagwU1wCqBJBZ0giQBAQEEOj8OAgsSBgklDwUHLhQTCQuHew2tPASPGIE5B4QUA4ktjjcBkVaDPByBNQ X-IronPort-AV: E=Sophos;i="4.89,921,1367971200"; d="scan'208";a="86335122" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 20 Aug 2013 16:11:34 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7KGBXop017638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 16:11:33 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r7KGBXLv030903; Tue, 20 Aug 2013 09:11:33 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r7KGBX7C030902; Tue, 20 Aug 2013 09:11:33 -0700 Date: Tue, 20 Aug 2013 09:11:33 -0700 From: Toerless Eckert To: Mark Andrews Message-ID: <20130820161133.GR32655@cisco.com> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820141029.GQ32655@cisco.com> <20130820150041.E490038B559F@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130820150041.E490038B559F@drugs.dv.isc.org> User-Agent: Mutt/1.4.2.2i Cc: Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 16:11:41 -0000 Any URL that would easily explain how to configure an "unkown" record without having to start doing C-programming ? Of course, if there was a stanardized definitoin file one could drop into arbitrary DNS servers to define both name of new RR types and their value encoding, then new RRs could be easier to use than more obfuscated TXT encoding of new data. As long as its not really easier to do for folks who do not want/can-not update their DNS software, i can see the appeal of TXT. Cheers Toerless P.S.: COmpiling new bind does certainly not fall into the ubiquitously accepted realm of "ease-of-use", even though i'd certainly have fun with it ;-) On Wed, Aug 21, 2013 at 01:00:41AM +1000, Mark Andrews wrote: > > In message <20130820141029.GQ32655@cisco.com>, Toerless Eckert writes: > > Probably stupid question: > > > > I assume that a key reason for some part of the community preferring TXT > > records is that they allow to quickly adopt them because it is possible to > > configure them on any existing DNS server. Are there any examples of DNS > > servers that allow to define new RR types and some value encoding - without > > having to wait for a software upgrade of the DNS server software. > > Yes. Named has supported unknown records for over a decade now. > > All the tools that ship with named support unknown records. The > only reason there wasn't support earlier is that there wasn't a > agreeded apon master file format. > > B.T.W. people have added private types to named in the past. Any > semi competant C programmer can. Named was designed to make adding > new types easy. You don't even need to fiddle with Makefiles. Just > add the .c and .h files that describe how to parse and print the > text format and wire formats. There is plenty of example code > with all the other types. > > As for adding SPF to named it was: > > cp lib/dns/rdata/generic/txt_16.c lib/dns/rdata/generic/spf_99.c > cp lib/dns/rdata/generic/txt_16.h lib/dns/rdata/generic/spf_99.h > > change all the "txt" to "spf" in the method names. > change all the type checks to 99 instead of 16. > > make clean; make; make install > > Once that was done all the tools supported SPF. dig, host, nslookup, > nsupdate, dnssec-signzone etc. > > > Likewise, > > are the DNS client APIs where the apps can leverage new RR types unknown at > > the time the client SDK was written. > > Libresolv/libbind written in the 1980's supported unknown types. > It is still shipped with unix based systems. Unfortunately that > doesn't help because unless you have the mnemonic in a header > file people won't use it. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00645.html > > n = res_query(name, C_IN, 99, buf, sizeof(buf)); > > was all that was needed for unix / linux machines to make SPF lookup > but that wasn't enough. > > The libraries named is currently built upon support unknown query > types. > > Support for looking up unknown types in resolvers libraries was a > requirement of RFC 1034. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From jabley@hopcount.ca Tue Aug 20 09:15:34 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 8156C11E8232 for ; Tue, 20 Aug 2013 09:15:34 -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 5kFa8ro6GK2H for ; Tue, 20 Aug 2013 09:15:33 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7C111E8123 for ; Tue, 20 Aug 2013 09:15:33 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id up15so595771pbc.40 for ; Tue, 20 Aug 2013 09:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P+Bxz+39MqpKCpYTLyFCu8nn/QQXQF6KrGIgFekocIU=; b=hpoegJeaZaJcR3YN19oIZ5l6JrZXmrCy0qILjRFEdcQvJXz3BB073FvJXX0f8F9KW3 ui5dtJY7yFHbAbqkV7DhXgPXIM1XHFsGnscHTZPuVYmVEQSnF9tXuIwDdsqSnXW6gCd1 PGJiauBR+EC3uKza01u/y8LGrkZY085mTv+dA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=P+Bxz+39MqpKCpYTLyFCu8nn/QQXQF6KrGIgFekocIU=; b=CmWFRVaDAP91Jd1uoGc9hhcKtupSc9E3hDNHjZcVnNRgMrYAoQSNJvrPs2v0qOEtej FmaurAB+84/yy/0I1Rjn8Qo23u+aBF5//P99lvacmQgaqP8enRUkrGPdnbl2HRHA/zZA q8b7EWEIMKlN1eDVD387zQj36Od6QhDcc9U/+nMZH/WrCdkOuaqxagYwdgAzgtu/rX0c vIvbIHQ0lXrPNhvE1rzibiGEKVLt8A77ZPLgM0l1k8DEIYXt0Mh3w5BANU0t/8B9eVyO RvWAXAPvzMaK/Tu/e3aW8N06yo/Q+4+YonPnxUaAjSV9gVL344RIzJrI33OYluhikwz6 11PQ== X-Gm-Message-State: ALoCoQnasuu8og1MsBysmcGXc+xKINCNWn/isglyjpQByJ+Slgui/aExz+mJngFG7ZfEwor9tW9a X-Received: by 10.68.6.100 with SMTP id z4mr2761058pbz.187.1377015333238; Tue, 20 Aug 2013 09:15:33 -0700 (PDT) Received: from [199.212.90.39] ([199.212.90.39]) by mx.google.com with ESMTPSA id py4sm3007821pbc.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Aug 2013 09:15:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Joe Abley In-Reply-To: <20130820161133.GR32655@cisco.com> Date: Tue, 20 Aug 2013 12:15:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820141029.GQ32655@cisco.com> <20130820150041.E490038B559F@drugs.dv.isc.org> <20130820161133.GR32655@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1508) Cc: Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 16:15:34 -0000 On 2013-08-20, at 12:11, Toerless Eckert wrote: > Any URL that would easily explain how to configure an "unkown" record > without having to start doing C-programming ? Yes, again, RFC 3597. > Of course, if there was a stanardized definitoin file one could drop = into > arbitrary DNS servers to define both name of new RR types and their=20 > value encoding, then new RRs could be easier to use than more = obfuscated TXT > encoding of new data. As long as its not really easier to do for folks > who do not want/can-not update their DNS software, i can see the = appeal > of TXT. Or a trivial preprocessor which could interpret current, modern RRTypes = and output 3597-compliant opaque types for any RRType that was not in = the base specification. Joe From eckert@cisco.com Tue Aug 20 09:26:40 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 C56DA21F9984 for ; Tue, 20 Aug 2013 09:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.167 X-Spam-Level: X-Spam-Status: No, score=-10.167 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Ti+E6Ky9g3Gs for ; Tue, 20 Aug 2013 09:26:35 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4C221F9BAD for ; Tue, 20 Aug 2013 09:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1956; q=dns/txt; s=iport; t=1377015978; x=1378225578; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=lTqyKaCHslXqHJBmeymv36DZDH9fl8HfvbOE1BBMAEg=; b=l9XgkqZsqxN4yIIil1pCZpokBXxezaosJ/Z2T5G7ceXOFc3RYrbcOuiY RtUZDuBps86ECpT6DAqlyAQfAv+yX90TFakkCvTGEPGD43y3MVlEhTD+m DXWMcQFOnN+alol6mygGAYi90TGHDRs9ctIYTJHdYWyFHEUfgm8w7XO7U s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FALqXE1KrRDoI/2dsb2JhbABagwXAX4EkFnSCJAEBAQQ6PxALEgYJJQ8FNRQTFAeHdK07kFUHhBQDiS2ONwGRVoM8HA X-IronPort-AV: E=Sophos;i="4.89,921,1367971200"; d="scan'208";a="87060346" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 20 Aug 2013 16:26:11 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7KGQA9E028546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 16:26:10 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r7KGQ9iL031526; Tue, 20 Aug 2013 09:26:10 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r7KGQ91w031525; Tue, 20 Aug 2013 09:26:09 -0700 Date: Tue, 20 Aug 2013 09:26:09 -0700 From: Toerless Eckert To: John Levine Message-ID: <20130820162609.GS32655@cisco.com> References: <20130820141029.GQ32655@cisco.com> <20130820161102.79213.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130820161102.79213.qmail@joyce.lan> User-Agent: Mutt/1.4.2.2i Cc: dnsext@ietf.org Subject: Re: [dnsext] new RRRTYPEs, was Deprecating SPF 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, 20 Aug 2013 16:26:41 -0000 Thanks, John. Sounds like a necessary direction to make new record types really easily useable. Any summary how the programmatic API on the client side would be abel to benefit from this approach ? What data types did you define ? Something similar to what JSON could express ? Cheers toerless On Tue, Aug 20, 2013 at 04:11:02PM +0000, John Levine wrote: > >Probably stupid question: > > > >I assume that a key reason for some part of the community preferring TXT > >records is that they allow to quickly adopt them because it is possible to > >configure them on any existing DNS server. Are there any examples of DNS > >servers that allow to define new RR types and some value encoding - without > >having to wait for a software upgrade of the DNS server software. Likewise, > >are the DNS client APIs where the apps can leverage new RR types unknown at > >the time the client SDK was written. > > Most DNS servers let you stick in unknown RRs using generic hex or > octal values. I've written preprocessors to massage zone info to > handle RRs that my server doesn't, and I'm sure I'm not the only one. > > Vixie and I have a proposal to publish the syntax of new RRs in the > DNS itself, both so that DNS servers can automatically configure, but > equally importantly, so the configuration web crudware that most > people use to manage their DNS info can automatically configure as > well. It's not a complete solution, since it can't handle major > changes like DNSSEC that require semantic changes to the DNS servers > and caches, but for the large majority of RRs that are just RRs, it > seems useful to me. > > It got a surprisingly hostile reaction here, but people are interested > in appsarea. The draft is draft-levine-dnsextlang-06 > > R's, > John > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From eckert@cisco.com Tue Aug 20 09:29:16 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 2111E11E826D for ; Tue, 20 Aug 2013 09:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.275 X-Spam-Level: X-Spam-Status: No, score=-10.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Ynca10AtjBTg for ; Tue, 20 Aug 2013 09:29:11 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAD111E8257 for ; Tue, 20 Aug 2013 09:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1253; q=dns/txt; s=iport; t=1377016148; x=1378225748; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=JS48jkkvnFUpNh+PwOwujm9X0O3ZWaW/lI+OX0w9l1M=; b=a18QQoFYqL7HJNZbPn4k/mada4wVa5oVAMkBMzh+sUoD7060ZJwwst0X RAhnI1rr2v10HT1HTmgJoYkqA2FyAcK2j3Qin48FuLFRf8/Pi0HcMevuG XLIz6hMavljtiIEe9EhdWz28ASCrwD8db248Nimk4nEjv2NeV3UGs5KsM o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAGmYE1KrRDoI/2dsb2JhbABagwXAX4EkFnSCJAEBAQQ6PxALDgQGCSUPBTUUE4gPrTuQVQeEFAOJLY43AZFWgzwc X-IronPort-AV: E=Sophos;i="4.89,921,1367971200"; d="scan'208";a="89570443" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 20 Aug 2013 16:29:07 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7KGT62r030530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 16:29:06 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r7KGT6iM031643; Tue, 20 Aug 2013 09:29:06 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r7KGT6P3031642; Tue, 20 Aug 2013 09:29:06 -0700 Date: Tue, 20 Aug 2013 09:29:06 -0700 From: Toerless Eckert To: Joe Abley Message-ID: <20130820162906.GT32655@cisco.com> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820141029.GQ32655@cisco.com> <20130820150041.E490038B559F@drugs.dv.isc.org> <20130820161133.GR32655@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 16:29:16 -0000 Thanks. I should read through that. ALways interested how operationally difficult/easy it would be to introduce SSM channel address RRs, which would be AA (S,G - IPv4) and AAAAAAAA (S,G IPv6) ;-)) Cheers Toerless On Tue, Aug 20, 2013 at 12:15:29PM -0400, Joe Abley wrote: > > On 2013-08-20, at 12:11, Toerless Eckert wrote: > > > Any URL that would easily explain how to configure an "unkown" record > > without having to start doing C-programming ? > > Yes, again, RFC 3597. > > > Of course, if there was a stanardized definitoin file one could drop into > > arbitrary DNS servers to define both name of new RR types and their > > value encoding, then new RRs could be easier to use than more obfuscated TXT > > encoding of new data. As long as its not really easier to do for folks > > who do not want/can-not update their DNS software, i can see the appeal > > of TXT. > > Or a trivial preprocessor which could interpret current, modern RRTypes and output 3597-compliant opaque types for any RRType that was not in the base specification. > > > Joe > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From johnl@taugh.com Tue Aug 20 09:51: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 0CB9811E8259 for ; Tue, 20 Aug 2013 09:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.012, 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 3xwmGfHWQHy1 for ; Tue, 20 Aug 2013 09:51:22 -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 04E7E11E8258 for ; Tue, 20 Aug 2013 09:51:15 -0700 (PDT) Received: (qmail 9011 invoked from network); 20 Aug 2013 16:51:14 -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=2332.52139e82.k1308; bh=sMCnbFtC0lIXkCqrhcw6hyuL6oRFK6DvyRReI2i9vHE=; b=PNlURnFSXNZA+A5JOSLJan5I2Nbt2EQMCKW2v7/chH+ZDvyjNGVZkoftND+OBG6Qlr9byD7famI7QGVL3uaiSA8IjiZnL19P7Tbn/YGCtA524p98D3cmEa2AnHySXL/ciTpjiYd5CVIkbn6qFPQSG4SKlDs3/NftWAqB3XrtXCkq7FL2zf5fsKdS0Ww9ntyfjKPkl3LicCibTZZIRF7IuVaKKExJE8XQ4PWxqnYKHWJG9lDfG94m0W1+VQGNf/la 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=2332.52139e82.k1308; bh=sMCnbFtC0lIXkCqrhcw6hyuL6oRFK6DvyRReI2i9vHE=; b=LZP2QIX2uxMsdA8q/3VwVeq+ZHwRH9/tIIW8dxryk3lw/gUOa249rl6uQAPZTTMydeABLgxhewUiSUJGbRQO6uPqYmWlHclbHUCfuXJQ7KfzORMQUdWanwWVmbu49Uhw+9Si8uTb3Jk2GE7XtvSRj1MihyBxIsI2s8uXGVym+9vFN1onwMyPvrYj9OgD5s6PA7k31LmrqBOM1AcRl5artwlRLjNN3qyERXbl7Mtc2LR0irRBmX5QenytDXarNcqr Received: (ofmipd 127.0.0.1); 20 Aug 2013 16:50:52 -0000 Date: 20 Aug 2013 12:51:13 -0400 Message-ID: From: "John R Levine" To: "Toerless Eckert" In-Reply-To: <20130820162609.GS32655@cisco.com> References: <20130820141029.GQ32655@cisco.com> <20130820161102.79213.qmail@joyce.lan> <20130820162609.GS32655@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] new RRRTYPEs, was Deprecating SPF 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, 20 Aug 2013 16:51:23 -0000 > Thanks, John. Sounds like a necessary direction to make new record types > really easily useable. Any summary how the programmatic API on the > client side would be abel to benefit from this approach ? > > What data types did you define ? Something similar to what JSON could express ? The draft is draft-levine-dnsextlang-06. It's not very long. I went through all of the existing RRs, and defined types for all of the field types that seemed useful in new RRs. R's, John > On Tue, Aug 20, 2013 at 04:11:02PM +0000, John Levine wrote: >>> Probably stupid question: >>> >>> I assume that a key reason for some part of the community preferring TXT >>> records is that they allow to quickly adopt them because it is possible to >>> configure them on any existing DNS server. Are there any examples of DNS >>> servers that allow to define new RR types and some value encoding - without >>> having to wait for a software upgrade of the DNS server software. Likewise, >>> are the DNS client APIs where the apps can leverage new RR types unknown at >>> the time the client SDK was written. >> >> Most DNS servers let you stick in unknown RRs using generic hex or >> octal values. I've written preprocessors to massage zone info to >> handle RRs that my server doesn't, and I'm sure I'm not the only one. >> >> Vixie and I have a proposal to publish the syntax of new RRs in the >> DNS itself, both so that DNS servers can automatically configure, but >> equally importantly, so the configuration web crudware that most >> people use to manage their DNS info can automatically configure as >> well. It's not a complete solution, since it can't handle major >> changes like DNSSEC that require semantic changes to the DNS servers >> and caches, but for the large majority of RRs that are just RRs, it >> seems useful to me. >> >> It got a surprisingly hostile reaction here, but people are interested >> in appsarea. The draft is draft-levine-dnsextlang-06 >> >> R's, >> John >> > > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From paf@frobbit.se Tue Aug 20 10:07:27 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 0870521F9AA8 for ; Tue, 20 Aug 2013 10:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] 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 bE+BqeCHItaE for ; Tue, 20 Aug 2013 10:07:26 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id A870F21F848A for ; Tue, 20 Aug 2013 10:06:49 -0700 (PDT) Received: from [172.18.207.57] (w193-11-200-253.eduroam.sunet.se [193.11.200.253]) by mail.frobbit.se (Postfix) with ESMTPSA id A93CF23FFD; Tue, 20 Aug 2013 19:06:44 +0200 (CEST) References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820141029.GQ32655@cisco.com> <20130820150041.E490038B559F@drugs.dv.isc.org> <20130820161133.GR32655@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3528AD21-6C04-4F79-894A-72944C76B6E5@frobbit.se> X-Mailer: iPhone Mail (10B329) From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Date: Tue, 20 Aug 2013 19:06:42 +0200 To: Joe Abley Cc: Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 17:07:27 -0000 On 20 aug 2013, at 18:15, Joe Abley wrote: > Or a trivial preprocessor which could interpret current, modern RRTypes an= d output 3597-compliant opaque types for any RRType that was not in the base= specification. One can also compare number of lines for this pre processor with number of l= ines for implementing the rest of the SPF specification. Patrik From michael@rancid.berkeley.edu Tue Aug 20 10:18: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 A45A411E8136 for ; Tue, 20 Aug 2013 10:18: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=[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 hANH0U+3mYzw for ; Tue, 20 Aug 2013 10:18:15 -0700 (PDT) Received: from burnttofu.net (cl-960.qas-01.us.sixxs.net [IPv6:2001:4830:1600:3bf::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C61C11E8259 for ; Tue, 20 Aug 2013 10:18:13 -0700 (PDT) Received: from schuylkill.es.net (schuylkill.es.net [198.128.1.116]) (authenticated bits=0) by burnttofu.net (8.14.6/8.14.5) with ESMTP id r7KHGnj5013596 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 20 Aug 2013 17:16:55 GMT (envelope-from michael@rancid.berkeley.edu) Message-ID: <5213A481.8010602@rancid.berkeley.edu> Date: Tue, 20 Aug 2013 10:16:49 -0700 From: Michael Sinatra User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Sullivan References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> In-Reply-To: <20130820153656.GB21439@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (burnttofu.net [208.86.225.220]); Tue, 20 Aug 2013 17:16:55 +0000 (UTC) Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 17:18:15 -0000 On 8/20/13 8:36 AM, Andrew Sullivan wrote: > On Tue, Aug 20, 2013 at 05:17:59PM +0200, Patrik Fältström wrote: >> >> And the fact people use both TXT and SPF is to me an indication the >> migration plan works, and that the fix should be to clarify how to >> continue that migration given that we have what I would call an >> unclear paragraph exists in the original RFC. > > RFC 6686 tells us the extent to which people are "using both". see > section 3.1. No survey was able to find people "using both" at even > 2% of all the domains surveyed. SPF records using TXT ranged between > just under 40% to more than 50%. I find it hard to interpret that > data as an indication that the migration plan is having any real > effect at all. > > I don't think anyone can accuse me of being sanguine about the > overloading of TXT. But the IETF is made ridiculous if it stands > around trying to tell the sea to stay back. There seems to be an unstated philosophical argument about what the role of the IETF should be. It's like the perennial prescriptive/descriptive argument that dictionary-writers have. Should the role of the IETF be to describe implemented standards or should it be to prescribe new or evolved standards? Should it be trying to push SPF in a slightly-different direction or should it be trying to maximize the *current* (short-term?) utility and interoperability of SPF? As someone who is primarily an operator, I want to trust the IETF to prescribe a standard--or be willing to prescriptively modify a standard--that is architecturally optimal, while not ignoring operational realities. Maybe I am just being lazy. There's no question that some honest mistakes have been made in previous standards that attempted to be too architecturally "pure" and ignored the issues that that architectural purity created with respect to implementation and operations. The IETF got treated unnecessarily badly in the ops community for this, IMO. At the same time, I don't think the answer is to err on the descriptive side. Some compromise between description and prescription ought to be possible. There may be other issues within the SPFBIS effort where there is more of a prescriptive/descriptive balance, but in the case of RRTYPE 99, it seems that the IETF is taking a very descriptive approach. In reading through the archives, both recently and last September when this issue arose here, it's clear that many people believe that overloading of TXT is a bad idea, but they believe that this is reality and it's not really the IETF's job to say what should be done. I don't totally agree with that because that's not how I view the IETF's role. In other words, to my inexperienced eyes, there is a lot of room between trying to tell the sea to stay back and deprecating RRTYPE 99. But Pete and Andrew are much deeper in the SPFBIS effort than I am, and I don't envy them as they try to walk the line in getting this draft shepherded and published. As for my own opinion, I think the use of the TXT record by SPF has always looked kludgy to me and has made me consistently reluctant to adopt SPF. It has also made me push back against implementing it for others, unless it turns out to be absolutely necessary to prevent someone's mail from being rejected. michael From Ted.Lemon@nominum.com Tue Aug 20 10:33: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 61FE611E812E for ; Tue, 20 Aug 2013 10:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 qHT09fObhJd9 for ; Tue, 20 Aug 2013 10:33:42 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2641311E8137 for ; Tue, 20 Aug 2013 10:33:42 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUhOodAWJJe3NM4JuS317q03aZYZLbL3j@postini.com; Tue, 20 Aug 2013 10:33:42 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 6BC501B827D for ; Tue, 20 Aug 2013 10:33:40 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 6453F19006C; Tue, 20 Aug 2013 10:33:40 -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; Tue, 20 Aug 2013 10:33:40 -0700 From: Ted Lemon To: Michael Sinatra Thread-Topic: [dnsext] Deprecating SPF Thread-Index: AQHOnSjBNfc5jIvzzEeabK322dk3P5mdj7EAgACAmwCAAJGjgIAACgCAgAAFTACAABvogIAABLSA Date: Tue, 20 Aug 2013 17:33:39 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> In-Reply-To: <5213A481.8010602@rancid.berkeley.edu> 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: <97D864FF89986641AE68A6C7BDC5016D@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 17:33:49 -0000 On Aug 20, 2013, at 10:16 AM, Michael Sinatra = wrote: > Should the role of the IETF be to describe implemented standards or > should it be to prescribe new or evolved standards? Should it be trying > to push SPF in a slightly-different direction or should it be trying to > maximize the *current* (short-term?) utility and interoperability of SPF? I don't think either of these dichotomies captures the tension that is bein= g addressed in this particular case. In this particular case, spfbis cons= idered at length whether the IETF _could_ do the architecturally clean thin= g here, and concluded that we could not. So the dichotomy you want here is, does the IETF propose a standard _knowin= g full well that nobody will ever implement it_, or does the IETF try for a= substantial functional improvement to a standard that people have already = shown they will implement? The architecturally clean thing to do here is to get rid of SMTP, which is = a protocol designed for a gentler time, and is ill-suited to the current In= ternet, with its spammers and botnets and snoops (oh my!). If you are int= erested in architectural hygiene, get to work on that, and stop wasting you= r energy fussing about the relative ugliness of two ugly band-aids, one of = which spfbis decided to deprecate, the other of which they decided to keep. From mje@posix.co.za Tue Aug 20 10:37: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 D6DB421F9B4B for ; Tue, 20 Aug 2013 10:37:37 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...] 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 NyTYRIsIYAta for ; Tue, 20 Aug 2013 10:37:36 -0700 (PDT) Received: from mje99.posix.co.za (mje99.posix.co.za [IPv6:2001:42a0:1000:48::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DE021F9C83 for ; Tue, 20 Aug 2013 10:37:31 -0700 (PDT) Received: from [2001:42a0:1000:48:9ca9:26f4:95fb:419d] by mje99.posix.co.za with esmtpsa (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80.1) (envelope-from ) id 1VBprn-0002XX-0e; Tue, 20 Aug 2013 19:37:20 +0200 From: Mark Elkins To: "dnsext@ietf.org Group" In-Reply-To: <933357EA-6472-4C77-AED3-E6411BC684B6@frobbit.se> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <521385AA.9080401@qti.qualcomm.com> <933357EA-6472-4C77-AED3-E6411BC684B6@frobbit.se> Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-JAUVz4zluzeA4GC5ZCIO" Organization: Posix Systems Date: Tue, 20 Aug 2013 19:37:13 +0200 Message-ID: <1377020233.7055.68.camel@mjelap.posix.co.za> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Subject: Re: [dnsext] Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mje@posix.co.za List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:37:38 -0000 --=-JAUVz4zluzeA4GC5ZCIO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2013-08-20 at 17:28 +0200, Patrik F=C3=A4ltstr=C3=B6m wrote: > On 20 aug 2013, at 17:05, Pete Resnick wrote: >=20 > > You seem to believe that the wrong technical choice was made by this WG= . What was that error and why should they have chosen something different? >=20 > The consensus related to how to fix RFC 4408 will be very rough. That is = clear. And I feel sorry for responsible AD and IESG to be forced to make a = decision that such a large rough part of the rough consensus will not be ha= ppy with. Regardless of what the decision will be. >=20 >=20 > An architectural correct solution is to change: >=20 > OLD: >=20 > An SPF-compliant domain name SHOULD have SPF records of both RR > types. A compliant domain name MUST have a record of at least one > type. If a domain has records of both types, they MUST have > identical content. >=20 > NEW: >=20 > An SPF-compliant domain name SHOULD have SPF records of both RR > types. A compliant domain name MUST have a record of at type SPF, > code 99. Lookup MUST first be of type SPF and SHOULD if no response > is received be of type TXT. >=20 >=20 > Reasoning: The use of the TXT record for SPF is not sounds for a number o= f reasons: >=20 > 1. The TXT record already can have multiple fields, and it is very unfort= unate that the SPF use of TXT records do not use that feature. Instead the = SPF specification do say that the first field should be used, and if there = are more than one they should be concatenated. After one have one and only = one field, that field should be parsed and divided in fields. >=20 > 2. It is even (compared to some other TXT related documents) pointed out = in RFC 4408 that collisions as described in RFC 5507 might happen. >=20 > 3. It is also pointed out that there might be size issues with the record= s, and experience from use of NAPTR show that selecting a preferred mechani= sm that potentially blows the size of the RRSet is not very wise. This is b= tw why the URI RR Type do not use a prefixed length "text" field in the RDA= TA but do set the string the URI is to the full length of the RDATA, i.e. w= ithout any 255 byte limitation. >=20 > 4. DNS is by design (as pointed out in RFC 5507) created with a tuple con= sisting of owner, type and class for selection by the client what record se= t to be retrieved. This RRSet architecture is something that comes back not= only in the query/response architecture of the DNS protocol, but also in t= he DNSSEC architecture where RRSets are the units that are signed. Not expl= icitly ensuring an RRSet is used for SPF (and nothing more) is an architect= ural choice I strongly am against. >=20 >=20 > Because of these reasons, I do believe the choice is wrong to say that TX= T MUST be implemented and instead I am in favor of having type SPF be manda= tory for interoperability with fallback to lookup of TXT. >=20 > Patrik I agree with what you say. I run a small ISP business. Out of 849 domain running full DNS locally,=20 9 have SPF records of which 4 are TXT records only, the other 5 have both SPF and TXT records. Both my Virtual-Web interface control panel (a home-grown affair) and the machines local Nameserver (BIND - for now...) support the SPF record. I'm now plotting to automatically create the SPF record equivalent if the customer creates a TXT based SPF record. --=20 . . ___. .__ Posix Systems - (South) Africa /| /| / /__ mje@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 --=-JAUVz4zluzeA4GC5ZCIO Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUVjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHCzCCBfOg AwIBAgIDBRX+MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIxMDEwMTQwNzA5WhcNMTMxMDEyMTI0MzMwWjBVMRkwFwYDVQQNExBNdjlyUDJVMXJxUjBKY1V5 MRgwFgYDVQQDDA9tamVAcG9zaXguY28uemExHjAcBgkqhkiG9w0BCQEWD21qZUBwb3NpeC5jby56 YTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKxQ9nxQ08Sc7gryudzm/DSWaRg8CKSd 1jksu8qShkcM2WbByGlV3dAjIwbN1IOcNWDO+A7L2aDf3/T0DWI74y1ZHCqP2ke4JQaIvj8FblRl 3ypA2YVCk+8mZ5kXeJMxmPPlfBUehMnN61niYhE2uWz0EGEVN9pInDH7f6HTYtkYe1gKxaoK5vJv HlNR57yNZZKGtSpszWmIM1/cUc246vB0gvgn1OfSzxN7mObIYJeccceFvUsXgM077J8oBlSZdHaQ 85OqYwmV/Mk8dfZyDwioavI3M+SQPjJJMqMjG1/Apxo5UG/zrObBH2bWAHvXVLPER78Myq5pp51a bXM4OCcCAwEAAaOCA6owggOmMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUV7JIQzT5T8CJp2mpg2Z6zHl4HS8wHwYDVR0jBBgw FoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGgYDVR0RBBMwEYEPbWplQHBvc2l4LmNvLnphMIICIQYD VR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wu Y29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3Jk aW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENv bSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNv bXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCB jzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5k IHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEF BQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAdSWC8C1Zriz+8ajsOeZOAv5U9UD0HXJLVLa7g/Y3B7jivLgDvV1t0qtJe47O2mt5NDLocsTA hpWZg7QkHtyPpyzmigfbP9SBwpEZfX/eF5xJFUDQsnB9SrX/YkbV2lgsjKSfxJW8R2JN8N7CsfJz r9cVQ705hgqDdnct6SL2qaWbkSSEk7S5D9nCwL/8j3oNnraBFadjLJmjI5CSu+AE386Dy986NpGG bTUPDGpYLHAVHqpPK7B/yC09r/PRpH8Bx4UpUP5z0ELLvXf0dYCzRWU228BEHJp0pQlpjVMD/W18 1NkKs83XtBCGDa0lKbcynnPqV5RO4XVTfXuPtplVgzCCBwswggXzoAMCAQICAwUV/jANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMTAxMDE0MDcwOVoXDTEz MTAxMjEyNDMzMFowVTEZMBcGA1UEDRMQTXY5clAyVTFycVIwSmNVeTEYMBYGA1UEAwwPbWplQHBv c2l4LmNvLnphMR4wHAYJKoZIhvcNAQkBFg9tamVAcG9zaXguY28uemEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCsUPZ8UNPEnO4K8rnc5vw0lmkYPAikndY5LLvKkoZHDNlmwchpVd3Q IyMGzdSDnDVgzvgOy9mg39/09A1iO+MtWRwqj9pHuCUGiL4/BW5UZd8qQNmFQpPvJmeZF3iTMZjz 5XwVHoTJzetZ4mIRNrls9BBhFTfaSJwx+3+h02LZGHtYCsWqCubybx5TUee8jWWShrUqbM1piDNf 3FHNuOrwdIL4J9Tn0s8Te5jmyGCXnHHHhb1LF4DNO+yfKAZUmXR2kPOTqmMJlfzJPHX2cg8IqGry NzPkkD4ySTKjIxtfwKcaOVBv86zmwR9m1gB711SzxEe/DMquaaedWm1zODgnAgMBAAGjggOqMIID pjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQw HQYDVR0OBBYEFFeySEM0+U/AiadpqYNmesx5eB0vMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1 TvLUuFGCMBoGA1UdEQQTMBGBD21qZUBwb3NpeC5jby56YTCCAiEGA1UdIASCAhgwggIUMIICEAYL KwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xp Y3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAD AgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3Mg MSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxp YW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSBy ZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBs aW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEu c3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhho dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAHUlgvAtWa4s/vGo7Dnm TgL+VPVA9B1yS1S2u4P2Nwe44ry4A71dbdKrSXuOztpreTQy6HLEwIaVmYO0JB7cj6cs5ooH2z/U gcKRGX1/3hecSRVA0LJwfUq1/2JG1dpYLIykn8SVvEdiTfDewrHyc6/XFUO9OYYKg3Z3Leki9qml m5EkhJO0uQ/ZwsC//I96DZ62gRWnYyyZoyOQkrvgBN/Og8vfOjaRhm01DwxqWCxwFR6qTyuwf8gt Pa/z0aR/AceFKVD+c9BCy7139HWAs0VlNtvARByadKUJaY1TA/1tfNTZCrPN17QQhg2tJSm3Mp5z 6leUTuF1U317j7aZVYMxggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMFFf4wCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTMwODIwMTczNzEzWjAjBgkqhkiG9w0BCQQxFgQULx502pF5nNyChr0YZPV2FmyLFZIw gaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFFf4wgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwUV/jANBgkq hkiG9w0BAQEFAASCAQCF4umLqDce7WsAkFDkOIL1qNXAcU1mKpbpN7Ue0y/ALth2gjJ8Cgd12uH6 pV5i4q0IcLCcvX9+0AIyHeuhp54AvXny9w+58CqmJv9LLCg2PQzjL1Xv/f+J5QfKS7gPSZPKdYUc JThwozKzbXFyNaE+L96gsbvhYJxPk45l+wIPQ2q2mb1+h/QpMwHhXmje4ugk6EqvgUO4RWJmfLQ8 uSltczc51UjyVp9eRTlooGw7WW9AKuEYTo0YmdjQw4zPbKyIZnGtQcliow2+jX78BtLwdv7hJK1R zHp/AawSgRtDzdt9yrpOBEa3khFPlDR24fm9fb3fIaAC7dO7iCDmeVjdAAAAAAAA --=-JAUVz4zluzeA4GC5ZCIO-- From ajs@anvilwalrusden.com Tue Aug 20 10:49:34 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 5CD9511E813D for ; Tue, 20 Aug 2013 10:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 qney24eK0d2r for ; Tue, 20 Aug 2013 10:49:17 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id CD16411E8119 for ; Tue, 20 Aug 2013 10:49:16 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 538E78A031 for ; Tue, 20 Aug 2013 17:49:16 +0000 (UTC) Date: Tue, 20 Aug 2013 13:49:15 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130820174915.GC22140@mx1.yitter.info> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 17:49:34 -0000 On Tue, Aug 20, 2013 at 05:33:39PM +0000, Ted Lemon wrote: > The architecturally clean thing to do here is to get rid of SMTP, which is a protocol designed for a gentler time And, while you're at it, you might want to tackle DNSng, too. What the heck? A -- Andrew Sullivan ajs@anvilwalrusden.com From doug.mtview@gmail.com Tue Aug 20 11:12: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 6D7DD21F93D4 for ; Tue, 20 Aug 2013 11:12:09 -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 mI3CVL5XUM+W for ; Tue, 20 Aug 2013 11:12:09 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 041A921F90FD for ; Tue, 20 Aug 2013 11:12:08 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp2so708300pbb.28 for ; Tue, 20 Aug 2013 11:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D48gG80cAOlmHdkB3lYHnMDCPx6Vv/kr18RSNOsYNgo=; b=q1tmKeeK4CM4tjacPsw7oExnfEOWad/eIIWlVgjD0UiYkMV1D+LRDoTcQKXoHAoL6t /TXx+46JvPG5kbi8L8f1O1AxuW3C6nvk2KSryE8VVXyWgLgatCADJ4rfPc76MW575hQY UE1pawaiL74QxNXdbVRxDmnP8aO2C9r8DO9WkJWMeGOE5774zTeSAHVYoI9iehWY4wc7 ZqnL6T1qy7gaYnr77irJVQ2ZaaPU7VcAkZo6Se+I5GZlW6ODcRX+B5oSwrGUWJt1sxvB UDBQwgTc6X5BQmO5YuKxhvt3GWHe8zMdoJG1/uZ1Zczpg3M3rtwEIxCeJggYvAPBKN/S Kl9g== X-Received: by 10.68.137.201 with SMTP id qk9mr3296267pbb.199.1377022328527; Tue, 20 Aug 2013 11:12:08 -0700 (PDT) Received: from [192.168.2.233] (c-98-207-206-162.hsd1.ca.comcast.net. [98.207.206.162]) by mx.google.com with ESMTPSA id sx7sm3421888pbc.41.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Aug 2013 11:12:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Douglas Otis In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> Date: Tue, 20 Aug 2013 11:12:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <31E73AB4-DDD5-4C2A-B8B7-F9B845C8A613@gmail.com> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 18:12:09 -0000 On Aug 20, 2013, at 10:33 AM, Ted Lemon wrote: > So the dichotomy you want here is, does the IETF propose a standard = _knowing full well that nobody will ever implement it_, or does the IETF = try for a substantial functional improvement to a standard that people = have already shown they will implement? Dear Ted, Should the IETF protect current infrastructure from being degraded by = expediency hacks, or should the IETF insist in having compatible (less = threatening) approaches. Otherwise, why bother with the IETF where then = anything can be called authentication? Never mind SMTP. BGP, DNS, and CAs can't be trusted either. Employing = DNSsec, DANE, and StartTLS should help restore sanity and security. The mess caused by SMTP will get uglier if one ineffective bandaid is = applied one on another under the guise of standardization. Frankly, the = APL RR defined well ahead of SPF offers a far safer and more effective = solution. Even the "policy" asserted by SPF is often ignored due to an = endless number of exceptions with typical use. Also considering the = security issues related with amount of specialized code mandated to = support SPF macros used by 0.053% of the domains and ignored by large = providers means retaining this feature will degrade and not enhance = interchange. This is a process wedged on top of DNS that does not even = understand the difference between a DNS message and a UDP packet. Regards, Douglas Otis From sm@elandsys.com Tue Aug 20 11:38:35 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 23BCE11E80DF; Tue, 20 Aug 2013 11:38:35 -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 kM9-DDV9BJmi; Tue, 20 Aug 2013 11:38:33 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A7611E812F; Tue, 20 Aug 2013 11:38:32 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.26]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7KIc8uK028387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 11:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377023903; bh=Sv2/3w0QtBWCaWv4IqgxOwuIZ4KLQVhbKrq7HRrTKYc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sKPkKo/7vEBVo11hQFvp2jk6zefhXJdSw/SpggksQBV8kNo3to+QBnbs2KG7YuFRx WiXx37oXUifLyQN4JDFNcgbChalfFEeqNxR6Ohr72WGQDYhHKHagYouKJtLZ+yXrWS v4NjDUZbpHuiS6mQZgKiF/CJOh/aUmARyrjy9H1Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377023903; i=@elandsys.com; bh=Sv2/3w0QtBWCaWv4IqgxOwuIZ4KLQVhbKrq7HRrTKYc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=d7Q124M7iq+YSbXrWeIJuEIyrEicR/XQNH8Nnh1IQRMepnKc7HlLW2gzHkKjtO1oW vHHJT7Kl1e9NeCExNSurtxzneb3glRcZLvXQrWa459GDcbIPkha7Dh9a4UwSnwJoey KRe6LQui6dhGp9ibfXdIRyXeNnFFOLM+oQKfI2AM= Message-Id: <6.2.5.6.2.20130820110057.0bead1e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 20 Aug 2013 11:36:55 -0700 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: S Moonesamy In-Reply-To: <933357EA-6472-4C77-AED3-E6411BC684B6@frobbit.se> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <521385AA.9080401@qti.qualcomm.com> <933357EA-6472-4C77-AED3-E6411BC684B6@frobbit.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Pete Resnick , dnsext@ietf.org, ietf@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 18:38:35 -0000 Hi Patrik, I am copying the message to ieft@ as there is an ongoing Last Call. At 08:28 20-08-2013, Patrik F=E4ltstr=F6m wrote: >The consensus related to how to fix RFC 4408=20 >will be very rough. That is clear. And I feel=20 >sorry for responsible AD and IESG to be forced=20 >to make a decision that such a large rough part=20 >of the rough consensus will not be happy with.=20 >Regardless of what the decision will be. > > >An architectural correct solution is to change: > >OLD: > > An SPF-compliant domain name SHOULD have SPF records of both RR > types. A compliant domain name MUST have a record of at least one > type. If a domain has records of both types, they MUST have > identical content. > >NEW: > > An SPF-compliant domain name SHOULD have SPF records of both RR > types. A compliant domain name MUST have a record of at type SPF, > code 99. Lookup MUST first be of type SPF and SHOULD if no response > is received be of type TXT. > > >Reasoning: The use of the TXT record for SPF is=20 >not sounds for a number of reasons: > >1. The TXT record already can have multiple=20 >fields, and it is very unfortunate that the SPF=20 >use of TXT records do not use that feature.=20 >Instead the SPF specification do say that the=20 >first field should be used, and if there are=20 >more than one they should be concatenated. After=20 >one have one and only one field, that field=20 >should be parsed and divided in fields. > >2. It is even (compared to some other TXT=20 >related documents) pointed out in RFC 4408 that=20 >collisions as described in RFC 5507 might happen. > >3. It is also pointed out that there might be=20 >size issues with the records, and experience=20 >from use of NAPTR show that selecting a=20 >preferred mechanism that potentially blows the=20 >size of the RRSet is not very wise. This is btw=20 >why the URI RR Type do not use a prefixed length=20 >"text" field in the RDATA but do set the string=20 >the URI is to the full length of the RDATA, i.e.=20 >without any 255 byte limitation. > >4. DNS is by design (as pointed out in RFC 5507)=20 >created with a tuple consisting of owner, type=20 >and class for selection by the client what=20 >record set to be retrieved. This RRSet=20 >architecture is something that comes back not=20 >only in the query/response architecture of the=20 >DNS protocol, but also in the DNSSEC=20 >architecture where RRSets are the units that are=20 >signed. Not explicitly ensuring an RRSet is used=20 >for SPF (and nothing more) is an architectural choice I strongly am= against. > > >Because of these reasons, I do believe the=20 >choice is wrong to say that TXT MUST be=20 >implemented and instead I am in favor of having=20 >type SPF be mandatory for interoperability with fallback to lookup of TXT. From Section 3.1 of draft-ietf-spfbis-4408bis-19: "SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in SPF's experimental phase, but has been discontinued." There is a message from Pete Resnick about RFC=20 2119 usage (=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html=20 ). The interpretation of "SHOULD" and MUST" in=20 that part of RFC 4408 was an issue which the SPFBIS WG discussed about. It would be better to have the discussion on the=20 ietf@ mailing list as that's the venue which the=20 IESG identified for last Call comments. Regards, S. Moonesamy=20 From paf@frobbit.se Tue Aug 20 11:45:27 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 ADBC211E8131; Tue, 20 Aug 2013 11:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 HQd99d779BwU; Tue, 20 Aug 2013 11:45:26 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id AAACF11E812F; Tue, 20 Aug 2013 11:45:25 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::e0a8:d413:1cf1:c2f5] (unknown [IPv6:2a02:80:3ffc:0:e0a8:d413:1cf1:c2f5]) by mail.frobbit.se (Postfix) with ESMTPSA id 0702F21F96; Tue, 20 Aug 2013 20:45:24 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <6.2.5.6.2.20130820110057.0bead1e8@resistor.net> Date: Tue, 20 Aug 2013 20:45:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <521385AA.9080401@qti.qualcomm.com> <933357EA-6472-4C77-AED3-E6411BC684B6@frobbit.se> <6.2.5.6.2.20130820110057.0bead1e8@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1508) Cc: Pete Resnick , dnsext@ietf.org, ietf@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 18:45:27 -0000 On 20 aug 2013, at 20:36, S Moonesamy wrote: > It would be better to have the discussion on the ietf@ mailing list as = that's the venue which the IESG identified for last Call comments. Understood, and thanks. The reason why I did not post there at first was that a) I did not feel = I had followed the rules laid out for discussions [read all messages in = the mailing list archives] and b) the discussion on the dnsext list was = more general on overload of TXT records [something DNS people have = always been against -- see IAB document on DNS choices]. But, when having that discussion on the dnsext mailing list, to which I = cc:ed Pete as responsible AD for full disclosure, Pete did ask me for a = complete explanation of my view, which I posted. Once again, without re-reading the mailing list archives. Patrik From paf@frobbit.se Tue Aug 20 11:59:35 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 D9B7E21F91F2; Tue, 20 Aug 2013 11:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.225, 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 7H1RijMU8LNx; Tue, 20 Aug 2013 11:59:34 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7A911E8274; Tue, 20 Aug 2013 11:58:16 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::e0a8:d413:1cf1:c2f5] (unknown [IPv6:2a02:80:3ffc:0:e0a8:d413:1cf1:c2f5]) by mail.frobbit.se (Postfix) with ESMTPSA id A2EAA23F2B; Tue, 20 Aug 2013 20:58:10 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <6.2.5.6.2.20130820110057.0bead1e8@resistor.net> Date: Tue, 20 Aug 2013 20:58:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6DEE47E1-885D-4F12-A766-D9BB2284BA09@frobbit.se> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <521385AA.9080401@qti.qualcomm.com> <933357EA-6472-4C77-AED3-E6411BC684B6@frobbit.se> <6.2.5.6.2.20130820110057.0bead1e8@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1508) Cc: Pete Resnick , dnsext@ietf.org, ietf@ietf.org Subject: [dnsext] Last call of draft-ietf-spfbis-4408bis-19 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, 20 Aug 2013 18:59:35 -0000 As the bottle is opened, I hereby state my objection to Section 3.1 of = draft-ietf-spfbis-4408bis-19 for the reasons explained below. I do agree = (as stated below) that the section of RFC 4408 that specify how to use = both SPF and TXT resource record types include an error as it does not = lead to interoperability. As the intention with use of both TXT and SPF originally was to migrate = from TXT to SPF I instead of what is outlined in the draft suggest that = a proper migration strategy is laid out (look up mandatory to implement = SPF and fall back to TXT). This instead of deprecation of the SPF = record. In general I do believe, for example when looking at IPv6 and DNSSEC and = similar technologies, that the lifetime of RFC 4408 is too short to = deprecate any of the proposed records that are in use, specifically as = RFC 4408 explicitly do allow use of both. Patrik On 20 aug 2013, at 20:36, S Moonesamy wrote: > Hi Patrik, >=20 > I am copying the message to ieft@ as there is an ongoing Last Call. >=20 > At 08:28 20-08-2013, Patrik F=E4ltstr=F6m wrote: >> The consensus related to how to fix RFC 4408 will be very rough. That = is clear. And I feel sorry for responsible AD and IESG to be forced to = make a decision that such a large rough part of the rough consensus will = not be happy with. Regardless of what the decision will be. >>=20 >>=20 >> An architectural correct solution is to change: >>=20 >> OLD: >>=20 >> An SPF-compliant domain name SHOULD have SPF records of both RR >> types. A compliant domain name MUST have a record of at least one >> type. If a domain has records of both types, they MUST have >> identical content. >>=20 >> NEW: >>=20 >> An SPF-compliant domain name SHOULD have SPF records of both RR >> types. A compliant domain name MUST have a record of at type SPF, >> code 99. Lookup MUST first be of type SPF and SHOULD if no = response >> is received be of type TXT. >>=20 >>=20 >> Reasoning: The use of the TXT record for SPF is not sounds for a = number of reasons: >>=20 >> 1. The TXT record already can have multiple fields, and it is very = unfortunate that the SPF use of TXT records do not use that feature. = Instead the SPF specification do say that the first field should be = used, and if there are more than one they should be concatenated. After = one have one and only one field, that field should be parsed and divided = in fields. >>=20 >> 2. It is even (compared to some other TXT related documents) pointed = out in RFC 4408 that collisions as described in RFC 5507 might happen. >>=20 >> 3. It is also pointed out that there might be size issues with the = records, and experience from use of NAPTR show that selecting a = preferred mechanism that potentially blows the size of the RRSet is not = very wise. This is btw why the URI RR Type do not use a prefixed length = "text" field in the RDATA but do set the string the URI is to the full = length of the RDATA, i.e. without any 255 byte limitation. >>=20 >> 4. DNS is by design (as pointed out in RFC 5507) created with a tuple = consisting of owner, type and class for selection by the client what = record set to be retrieved. This RRSet architecture is something that = comes back not only in the query/response architecture of the DNS = protocol, but also in the DNSSEC architecture where RRSets are the units = that are signed. Not explicitly ensuring an RRSet is used for SPF (and = nothing more) is an architectural choice I strongly am against. >>=20 >>=20 >> Because of these reasons, I do believe the choice is wrong to say = that TXT MUST be implemented and instead I am in favor of having type = SPF be mandatory for interoperability with fallback to lookup of TXT. >=20 > =46rom Section 3.1 of draft-ietf-spfbis-4408bis-19: >=20 > "SPF records MUST be published as a DNS TXT (type 16) Resource Record > (RR) [RFC1035] only. The character content of the record is encoded > as [US-ASCII]. Use of alternative DNS RR types was supported in > SPF's experimental phase, but has been discontinued." >=20 > There is a message from Pete Resnick about RFC 2119 usage ( = http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html ). = The interpretation of "SHOULD" and MUST" in that part of RFC 4408 was an = issue which the SPFBIS WG discussed about. >=20 > It would be better to have the discussion on the ietf@ mailing list as = that's the venue which the IESG identified for last Call comments. >=20 > Regards, > S. Moonesamy=20 From hallam@gmail.com Tue Aug 20 12:23: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 A8FDF11E826E for ; Tue, 20 Aug 2013 12:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 TEcF70hhRmKR for ; Tue, 20 Aug 2013 12:23:47 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1C96211E8260 for ; Tue, 20 Aug 2013 12:23:46 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id l12so39454wiv.4 for ; Tue, 20 Aug 2013 12:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lC5WT6nr0ttBXmo67G1l5z1a5EQRKC6j3pU/M5iXcqM=; b=VqsFFKagz2pjYV0scQ/uFJZlTpvRFSZUgLiAnek+aBw5YIh+S8Cm1cCIA4HkXIbqjp /JybR6ekfUbr+ZQxHr4U8Sx+dRst2WAAWGzWyv2lvNokCG+LVlSKD91RU/nGH2d/E2LH j1C7kkQYkxs1vqW5xr7UuIlwpYSZKueEodRvA4atx1vDRRjFe46iPjXSPw0mFlZvfrf/ QUXq+hKbj1iE4JpVDoZLzeLO4ylbUNQ30IumMqNJ3zy1SIigi0VUNXcPdKOgsEgJMOa2 8XCBl+HgxXb3j4EO90iBM0spWl32v2Zv4fXCOgIZJFt4NVc9xQCCmU3Mpqs8nVAFWAES eXkQ== MIME-Version: 1.0 X-Received: by 10.194.176.98 with SMTP id ch2mr2614168wjc.60.1377026623298; Tue, 20 Aug 2013 12:23:43 -0700 (PDT) Received: by 10.194.6.67 with HTTP; Tue, 20 Aug 2013 12:23:43 -0700 (PDT) In-Reply-To: <5213A481.8010602@rancid.berkeley.edu> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> Date: Tue, 20 Aug 2013 15:23:43 -0400 Message-ID: From: Phillip Hallam-Baker To: Michael Sinatra Content-Type: multipart/alternative; boundary=089e0122ea82ba63b904e465fea1 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 19:23:51 -0000 --089e0122ea82ba63b904e465fea1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 20, 2013 at 1:16 PM, Michael Sinatra < michael@rancid.berkeley.edu> wrote: > On 8/20/13 8:36 AM, Andrew Sullivan wrote: > > On Tue, Aug 20, 2013 at 05:17:59PM +0200, Patrik F=E4ltstr=F6m wrote: > >> > >> And the fact people use both TXT and SPF is to me an indication the > >> migration plan works, and that the fix should be to clarify how to > >> continue that migration given that we have what I would call an > >> unclear paragraph exists in the original RFC. > > > > RFC 6686 tells us the extent to which people are "using both". see > > section 3.1. No survey was able to find people "using both" at even > > 2% of all the domains surveyed. SPF records using TXT ranged between > > just under 40% to more than 50%. I find it hard to interpret that > > data as an indication that the migration plan is having any real > > effect at all. > > > > I don't think anyone can accuse me of being sanguine about the > > overloading of TXT. But the IETF is made ridiculous if it stands > > around trying to tell the sea to stay back. > > There seems to be an unstated philosophical argument about what the role > of the IETF should be. It's like the perennial prescriptive/descriptive > argument that dictionary-writers have. > > Should the role of the IETF be to describe implemented standards or > should it be to prescribe new or evolved standards? Should it be trying > to push SPF in a slightly-different direction or should it be trying to > maximize the *current* (short-term?) utility and interoperability of SPF? > The question that needs to be asked but isn't is 'what role do the governance structures permit'? he IAB is tasked with architecture but does not solicit or build consensus for its architectural proposals. Which is why Patrik's DNS options proposal was stillborn. That IAB is not elected by the IETF membership or accountable to it. So the IETF feels no obligation to follow the guidance it attempts to give. Worse, the old boys club method of selection ensures that members are picked for the conformity rather than the novelty of their views. So it tends to be a reactionary body. In the case of Patrik's RFC, there were many problems: 1) The SPF Working Group was justifiably peeved by the attempt by the DNSEXT group to trump their work by presenting their opinion in the form of an IAB ultimatum. 2) The RFC is broken. It makes assertions that are demonstrably untrue and makes erroneous conclusions. 3) The method of extension proposed is obviously unscalable as there are only 65535 possible RRs and far more Web Services requiring discovery. 4) The draft does not acknowledge the fact that at the time it was written one of the principle DNS servers in use could not in fact support unknown RR types. 5) The document does not admit that the real agenda was to push through the infrastructure needed to support DNSSEC. The last was subject to a long dispute between the SPF group and the DNS WG. At one point Microsoft presented the actual code for their DNS server and showed that it absolutely does not have the ability to save a zone file. Despite this DNSEXT members continued to insist that black was white and Microsoft's DNS server could be used to serve unknown DNS RRs based on the fact that one of them had written some sort of script that could somehow wedge them into the cache. A hack that any network manager using it should be sacked for touching since it was clearly not maintainable. Having watched the interaction between the SPF and DNSEXT WGs, this outcome is no surprise to me. Indeed it was inevitable. We should have a proper IAB that comes out with architectural guidance so we don't have six different WGs make six different decisions on how to do the same thing. But that can only work if the process delivers a result that has widespread consensus. Which is not going to happen if the process is that an elite club meets in secret and issues edicts. The IETF mission statement is botched. The mission of the IETF is not to produce documents, they are only a byproduct. The mission of the IETF is to produce consensus. The reason I am peeved by the CBOR fiasco is that we have a situation where we need a common approach but the mechanism chosen ensures that the chosen winner has no consensus and will thus be ignored. We do need a proper discovery architecture. One that makes it possible to discover policy information as part of the discovery process. The DNS options draft was a missed opportunity in that respect. I have suggested to Patrik on several occasions that we extend his URI discovery proposal to allow policy attributes to be included in the URI specification. But never received an answer. --=20 Website: http://hallambaker.com/ --089e0122ea82ba63b904e465fea1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 20, 2013 at 1:16 PM, Michael Sinatra = <michae= l@rancid.berkeley.edu> wrote:
On 8/20/13 8:36 AM, Andrew= Sullivan wrote:
> On Tue, Aug 20, 2013 at 05:17:59PM +0200, Patrik F=E4ltstr=F6m wrote:<= br> >>
>> And the fact people use both TXT and SPF is to me an indication th= e
>> migration plan works, and that the fix should be to clarify how to=
>> continue that migration given that we have what I would call an >> unclear paragraph exists in the original RFC.
>
> RFC 6686 tells us the extent to which people are "using both"= ;. =A0see
> section 3.1. =A0No survey was able to find people "using both&quo= t; at even
> 2% of all the domains surveyed. =A0SPF records using TXT ranged betwee= n
> just under 40% to more than 50%. =A0I find it hard to interpret that > data as an indication that the migration plan is having any real
> effect at all.
>
> I don't think anyone can accuse me of being sanguine about the
> overloading of TXT. =A0But the IETF is made ridiculous if it stands > around trying to tell the sea to stay back.

There seems to be an unstated philosophical argument about what the r= ole
of the IETF should be. =A0It's like the perennial prescriptive/descript= ive
argument that dictionary-writers have.

Should the role of the IETF be to describe implemented standards or
should it be to prescribe new or evolved standards? =A0Should it be trying<= br> to push SPF in a slightly-different direction or should it be trying to
maximize the *current* (short-term?) utility and interoperability of SPF?

The question that needs to be asked but = isn't is 'what role do the governance structures permit'?

he IAB is tasked with architecture but does not solicit= or build consensus for its architectural proposals. Which is why Patrik= 9;s DNS options proposal was stillborn.=A0

That IA= B is not elected by the IETF membership or accountable to it. So the IETF f= eels no obligation to follow the guidance it attempts to give. Worse, the o= ld boys club method of selection ensures that members are picked for the co= nformity rather than the novelty of their views. So it tends to be a reacti= onary body.

In the case of Patrik's RFC, there were many proble= ms:

1) The SPF Working Group was justifiably peeve= d by the attempt by the DNSEXT group to trump their work by presenting thei= r opinion in the form of an IAB ultimatum.=A0

2) The RFC is broken. It makes assertions that are demo= nstrably untrue and makes erroneous conclusions.=A0

3) The method of extension proposed is obviously unscalable as there are = only 65535 possible RRs and far more Web Services requiring discovery.

4) The draft does not acknowledge the fact that at the = time it was written one of the principle DNS servers in use could not in fa= ct support unknown RR types.

5) The document does = not admit that the real agenda was to push through the infrastructure neede= d to support DNSSEC.=A0

The last was subject to a long dispute between the SPF = group and the DNS WG. At one point Microsoft presented the actual code for = their DNS server and showed that it absolutely does not have the ability to= save a zone file. Despite this DNSEXT members continued to insist that bla= ck was white and Microsoft's DNS server could be used to serve unknown = DNS RRs based on the fact that one of them had written some sort of script = that could somehow wedge them into the cache. A hack that any network manag= er using it should be sacked for touching since it was clearly not maintain= able.

Having watched the interaction between the SPF and DNSE= XT WGs, this outcome is no surprise to me. Indeed it was inevitable.=A0


We should have a proper IAB that comes= out with architectural guidance so we don't have six different WGs mak= e six different decisions on how to do the same thing. But that can only wo= rk if the process delivers a result that has widespread consensus. Which is= not going to happen if the process is that an elite club meets in secret a= nd issues edicts.

The IETF mission statement is botched. The mission of t= he IETF is not to produce documents, they are only a byproduct. The mission= of the IETF is to produce consensus.=A0

The reaso= n I am peeved by the CBOR fiasco is that we have a situation where we need = a common approach but the mechanism chosen ensures that the chosen winner h= as no consensus and will thus be ignored.


We do need a proper discovery architectu= re. One that makes it possible to discover policy information as part of th= e discovery process. The DNS options draft was a missed opportunity in that= respect.

I have suggested to Patrik on several occasions that we= extend his URI discovery proposal to allow policy attributes to be include= d in the URI specification. But never received an answer.

--
Website: http://hall= ambaker.com/
--089e0122ea82ba63b904e465fea1-- From paf@frobbit.se Tue Aug 20 12:29:43 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 B670E11E819C for ; Tue, 20 Aug 2013 12:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 VplC32YZetMj for ; Tue, 20 Aug 2013 12:29:43 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 37EAB11E8153 for ; Tue, 20 Aug 2013 12:29:43 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::e0a8:d413:1cf1:c2f5] (unknown [IPv6:2a02:80:3ffc:0:e0a8:d413:1cf1:c2f5]) by mail.frobbit.se (Postfix) with ESMTPSA id 6046024000; Tue, 20 Aug 2013 21:29:42 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_14CEE3DD-1837-44E1-9BD1-58DE5FD51024" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Tue, 20 Aug 2013 21:29:42 +0200 Message-Id: <929614FF-280D-4832-8F01-09DD46ED2DEA@frobbit.se> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 19:29:43 -0000 --Apple-Mail=_14CEE3DD-1837-44E1-9BD1-58DE5FD51024 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 20 aug 2013, at 21:23, Phillip Hallam-Baker wrote: > I have suggested to Patrik on several occasions that we extend his URI = discovery proposal to allow policy attributes to be included in the URI = specification. But never received an answer. My apologies for you believing the ball is on my side of the courtyard. I did think it was up to you to "send text". I am taking this offline. It is not related to this SPF discussion. Patrik --Apple-Mail=_14CEE3DD-1837-44E1-9BD1-58DE5FD51024 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 hallam@gmail.com> = wrote:

I have = suggested to Patrik on several occasions that we extend his URI = discovery proposal to allow policy attributes to be included in the URI = specification. But never received an = answer.

My apologies for you believing = the ball is on my side of the courtyard.

I did = think it was up to you to "send text".

I am = taking this offline. It is not related to this SPF = discussion.

  =  Patrik

= --Apple-Mail=_14CEE3DD-1837-44E1-9BD1-58DE5FD51024-- From sm@elandsys.com Tue Aug 20 12:33:00 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 378C621F92E7; Tue, 20 Aug 2013 12:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 aT62nsdWx0gR; Tue, 20 Aug 2013 12:32:59 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA7311E80DF; Tue, 20 Aug 2013 12:32:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.26]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7KJWPLl023456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 12:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377027158; bh=eTv+GC/SA2M/uQuSIfnNNxetTJA2eM+eb1Il4e8xd44=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MKdBzAOrR94b/+AJ7eplb0SMhe1XVisCfKgxgh9GuhOGxo8kgbnNMCQJ6jonLUIWr iUjVXzjpkjACrpgPNopGiBIC+kL1VBqXyh56ioH5dE9WWW/KWk3jhWGGwfnjRprdw4 2ziQfcv/B9vhVb6nCtJnfQ088ckcE+okfWr3SH8I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377027158; i=@elandsys.com; bh=eTv+GC/SA2M/uQuSIfnNNxetTJA2eM+eb1Il4e8xd44=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HpeEJdWeskaSqH4BAEXtanKg6ZriVnaaBUAtIwEjXzirweNrvsdKjtcvPY2l4CIm0 vdg4BgfSsGE+GCtat2jrwNsMPd+LaxDfaGIKVohr7DZWJxIO6krOFQJg5528yf8e9Z ShTpJYbAeBX+4X8I0ALTC7CgTNjPEbZU8SfUHXrU= Message-Id: <6.2.5.6.2.20130820115012.0de38728@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 20 Aug 2013 12:30:48 -0700 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: S Moonesamy In-Reply-To: References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <521385AA.9080401@qti.qualcomm.com> <933357EA-6472-4C77-AED3-E6411BC684B6@frobbit.se> <6.2.5.6.2.20130820110057.0bead1e8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Pete Resnick , dnsext@ietf.org, ietf@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 19:33:00 -0000 Hi Patrik, At 11:45 20-08-2013, Patrik F=E4ltstr=F6m wrote: >The reason why I did not post there at first was=20 >that a) I did not feel I had followed the rules=20 >laid out for discussions [read all messages in=20 >the mailing list archives] and b) the discussion=20 >on the dnsext list was more general on overload=20 >of TXT records [something DNS people have always=20 >been against -- see IAB document on DNS choices]. > >But, when having that discussion on the dnsext=20 >mailing list, to which I cc:ed Pete as=20 >responsible AD for full disclosure, Pete did ask=20 >me for a complete explanation of my view, which I posted. > >Once again, without re-reading the mailing list archives. First of all, I apologize for copying the message=20 to ietf@. The advice given was to read the=20 comments in the SPFBIS mailing list archives. It=20 is not a rule. If a person did not read all the=20 messages and the person raises a point or=20 provides arguments which were not discussed=20 previously I will ask the SPFBIS WG to address them. I don't know whether to process your comments or=20 the other comments posted on dnsext@ as part of=20 the Last Call or not. It is unclear to me as to=20 whether I should only consider messages with the=20 appropriate Last Call subject line. My sense is=20 that I should listen to your concerns. Regards, S. Moonesamy=20 From paf@frobbit.se Tue Aug 20 12: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 A3C9F11E8226; Tue, 20 Aug 2013 12:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.150, 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 HNDiqq8NUt3W; Tue, 20 Aug 2013 12:37:21 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 360EA11E8171; Tue, 20 Aug 2013 12:37:21 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::e0a8:d413:1cf1:c2f5] (unknown [IPv6:2a02:80:3ffc:0:e0a8:d413:1cf1:c2f5]) by mail.frobbit.se (Postfix) with ESMTPSA id 8E66524015; Tue, 20 Aug 2013 21:37:20 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <6.2.5.6.2.20130820115012.0de38728@resistor.net> Date: Tue, 20 Aug 2013 21:37:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <67725DA7-EB62-494C-BB79-0692C32057A6@frobbit.se> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <521385AA.9080401@qti.qualcomm.com> <933357EA-6472-4C77-AED3-E6411BC684B6@frobbit.se> <6.2.5.6.2.20130820110057.0bead1e8@resistor.net> <6.2.5.6.2.20130820115012.0de38728@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1508) Cc: Pete Resnick , dnsext@ietf.org, ietf@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 19:37:21 -0000 On 20 aug 2013, at 21:30, S Moonesamy wrote: > First of all, I apologize for copying the message to ietf@. No apology needed. > I don't know whether to process your comments or the other comments = posted on dnsext@ as part of the Last Call or not. It is unclear to me = as to whether I should only consider messages with the appropriate Last = Call subject line. My sense is that I should listen to your concerns. I was the one making mistakes. Mea culpa. Patrik From michael@rancid.berkeley.edu Tue Aug 20 13:04: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 1EC1811E8191 for ; Tue, 20 Aug 2013 13:04: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=[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 VX-nLfMiRTZl for ; Tue, 20 Aug 2013 13:04:23 -0700 (PDT) Received: from burnttofu.net (cl-960.qas-01.us.sixxs.net [IPv6:2001:4830:1600:3bf::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB5511E8160 for ; Tue, 20 Aug 2013 13:04:23 -0700 (PDT) Received: from sonicyouth.es.net (sonicyouth.es.net [198.128.1.117]) (authenticated bits=0) by burnttofu.net (8.14.6/8.14.5) with ESMTP id r7KK4KgM013892 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Tue, 20 Aug 2013 20:04:21 GMT (envelope-from michael@rancid.berkeley.edu) Message-ID: <5213CBC4.4020401@rancid.berkeley.edu> Date: Tue, 20 Aug 2013 13:04:20 -0700 From: Michael Sinatra User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820174915.GC22140@mx1.yitter.info> In-Reply-To: <20130820174915.GC22140@mx1.yitter.info> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (burnttofu.net [208.86.225.220]); Tue, 20 Aug 2013 20:04:22 +0000 (UTC) Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 20:04:24 -0000 On Tue, Aug 20, 2013 at 05:33:39PM +0000, Ted Lemon wrote: > So the dichotomy you want here is, does the IETF propose a standard > _knowing full well that nobody will ever implement it_, or does the > IETF try for a substantial functional improvement to a standard that > people have already shown they will implement? You're right; I was trying to proffer a false dichotomy to show that the answer is somewhere in the middle, but that wasn't laid out in the questions I was asking. (It was hinted in my statement about "architectural purity.") The (false) dichotomy ought to represent both extremes, knowing that the correct answer is somewhere in the middle. In other words: Should the IETF propose a standard _knowing full well that nobody will ever implement it_, or should it describe as a standard what lots of people are doing now, no matter how broken or unsustainable the current behavior is? I am NOT arguing that SPFBIS, even as currently proposed with the RRTYPE 99 deprecation, is close to either extreme. However, I am concerned when I hear lots of people--here and in the SPFBIS archives--state that they don't like the txt record, but they think that the IETF will get laughed at/sneered at/ignored if it tries to transition to the SPF record. I don't quite agree with that--I think there is more middle in the middle ground. If that were the only consideration that the WG gave to the topic, then I would disagree. As it is, I am merely concerned. I am not interested in the "architecturally clean" solution. Apologies if that didn't come through in my message. michael From hallam@gmail.com Tue Aug 20 13:23:59 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 DE7A211E829B for ; Tue, 20 Aug 2013 13:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 n0MLa+uFQxbs for ; Tue, 20 Aug 2013 13:23:58 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id BCAA511E829A for ; Tue, 20 Aug 2013 13:23:57 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id x12so98700wgg.11 for ; Tue, 20 Aug 2013 13:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZoK/0c+ZG6E5rkqBvUU6bl1kP/zGNlOqnEv7rPjhOoI=; b=gpXlqBxcaUdI3L1PriLidjk0nERDugEGBgEELmA5lDWE7YfR4TV9LqF9BbH/Xyz73G qQNn5aU299ypio6WZkdHcSlCEjLhXTG29FXME5pFVZ/v7rYqsk0C/UynsfI8yYquP/nE sCsbMBJQX/Po/Z9lcHehU/6F2CIFmy6KsHT//psdlumtoS4wZ46xSyfwIxK+7QfUP8sx pmAcTuSweziSImJAfhbq4Trn1wqzRunZgiFDld6va+8P0IBXW0ZcflltMJJLfahLKo92 Vf6XHeM3NEdsSXIo+YqeAVFn0hIHNpvAlgFXqb3m3jFjTX6IMQP+5z7ZC+6gcAf0gBmH +RRw== MIME-Version: 1.0 X-Received: by 10.194.48.74 with SMTP id j10mr2852259wjn.41.1377030235520; Tue, 20 Aug 2013 13:23:55 -0700 (PDT) Received: by 10.194.6.67 with HTTP; Tue, 20 Aug 2013 13:23:55 -0700 (PDT) In-Reply-To: References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> Date: Tue, 20 Aug 2013 16:23:55 -0400 Message-ID: From: Phillip Hallam-Baker To: Michael Sinatra Content-Type: multipart/alternative; boundary=047d7ba975c808894504e466d66c Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 20:24:00 -0000 --047d7ba975c808894504e466d66c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My apologies, seems like we had a miscommunication and Patrick was waiting for input from me. Taking that discussion offline. On Tue, Aug 20, 2013 at 3:23 PM, Phillip Hallam-Baker wro= te: > > > > On Tue, Aug 20, 2013 at 1:16 PM, Michael Sinatra < > michael@rancid.berkeley.edu> wrote: > >> On 8/20/13 8:36 AM, Andrew Sullivan wrote: >> > On Tue, Aug 20, 2013 at 05:17:59PM +0200, Patrik F=E4ltstr=F6m wrote: >> >> >> >> And the fact people use both TXT and SPF is to me an indication the >> >> migration plan works, and that the fix should be to clarify how to >> >> continue that migration given that we have what I would call an >> >> unclear paragraph exists in the original RFC. >> > >> > RFC 6686 tells us the extent to which people are "using both". see >> > section 3.1. No survey was able to find people "using both" at even >> > 2% of all the domains surveyed. SPF records using TXT ranged between >> > just under 40% to more than 50%. I find it hard to interpret that >> > data as an indication that the migration plan is having any real >> > effect at all. >> > >> > I don't think anyone can accuse me of being sanguine about the >> > overloading of TXT. But the IETF is made ridiculous if it stands >> > around trying to tell the sea to stay back. >> >> There seems to be an unstated philosophical argument about what the role >> of the IETF should be. It's like the perennial prescriptive/descriptive >> argument that dictionary-writers have. >> >> Should the role of the IETF be to describe implemented standards or >> should it be to prescribe new or evolved standards? Should it be trying >> to push SPF in a slightly-different direction or should it be trying to >> maximize the *current* (short-term?) utility and interoperability of SPF= ? >> > > The question that needs to be asked but isn't is 'what role do the > governance structures permit'? > > he IAB is tasked with architecture but does not solicit or build consensu= s > for its architectural proposals. Which is why Patrik's DNS options propos= al > was stillborn. > > That IAB is not elected by the IETF membership or accountable to it. So > the IETF feels no obligation to follow the guidance it attempts to give. > Worse, the old boys club method of selection ensures that members are > picked for the conformity rather than the novelty of their views. So it > tends to be a reactionary body. > > In the case of Patrik's RFC, there were many problems: > > 1) The SPF Working Group was justifiably peeved by the attempt by the > DNSEXT group to trump their work by presenting their opinion in the form = of > an IAB ultimatum. > > 2) The RFC is broken. It makes assertions that are demonstrably untrue an= d > makes erroneous conclusions. > > 3) The method of extension proposed is obviously unscalable as there are > only 65535 possible RRs and far more Web Services requiring discovery. > > 4) The draft does not acknowledge the fact that at the time it was writte= n > one of the principle DNS servers in use could not in fact support unknown > RR types. > > 5) The document does not admit that the real agenda was to push through > the infrastructure needed to support DNSSEC. > > The last was subject to a long dispute between the SPF group and the DNS > WG. At one point Microsoft presented the actual code for their DNS server > and showed that it absolutely does not have the ability to save a zone > file. Despite this DNSEXT members continued to insist that black was whit= e > and Microsoft's DNS server could be used to serve unknown DNS RRs based o= n > the fact that one of them had written some sort of script that could > somehow wedge them into the cache. A hack that any network manager using = it > should be sacked for touching since it was clearly not maintainable. > > Having watched the interaction between the SPF and DNSEXT WGs, this > outcome is no surprise to me. Indeed it was inevitable. > > > We should have a proper IAB that comes out with architectural guidance so > we don't have six different WGs make six different decisions on how to do > the same thing. But that can only work if the process delivers a result > that has widespread consensus. Which is not going to happen if the proces= s > is that an elite club meets in secret and issues edicts. > > The IETF mission statement is botched. The mission of the IETF is not to > produce documents, they are only a byproduct. The mission of the IETF is = to > produce consensus. > > The reason I am peeved by the CBOR fiasco is that we have a situation > where we need a common approach but the mechanism chosen ensures that the > chosen winner has no consensus and will thus be ignored. > > > We do need a proper discovery architecture. One that makes it possible to > discover policy information as part of the discovery process. The DNS > options draft was a missed opportunity in that respect. > > I have suggested to Patrik on several occasions that we extend his URI > discovery proposal to allow policy attributes to be included in the URI > specification. But never received an answer. > > -- > Website: http://hallambaker.com/ > --=20 Website: http://hallambaker.com/ --047d7ba975c808894504e466d66c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My apologies, seems like we had a miscommunication and Pat= rick was waiting for input from me. Taking that discussion offline.


On Tue, Aug 20,= 2013 at 3:23 PM, Phillip Hallam-Baker <hallam@gmail.com> wro= te:



On Tue, Aug 20, 20= 13 at 1:16 PM, Michael Sinatra <michael@rancid.berkeley.edu&= gt; wrote:
On 8/20/13 8:36 AM, Andrew Sullivan wro= te:
> On Tue, Aug 20, 2013 at 05:17:59PM +0200, Patrik F=E4ltstr=F6m wrote:<= br> >>
>> And the fact people use both TXT and SPF is to me an indication th= e
>> migration plan works, and that the fix should be to clarify how to=
>> continue that migration given that we have what I would call an >> unclear paragraph exists in the original RFC.
>
> RFC 6686 tells us the extent to which people are "using both"= ;. =A0see
> section 3.1. =A0No survey was able to find people "using both&quo= t; at even
> 2% of all the domains surveyed. =A0SPF records using TXT ranged betwee= n
> just under 40% to more than 50%. =A0I find it hard to interpret that > data as an indication that the migration plan is having any real
> effect at all.
>
> I don't think anyone can accuse me of being sanguine about the
> overloading of TXT. =A0But the IETF is made ridiculous if it stands > around trying to tell the sea to stay back.

There seems to be an unstated philosophical argument about what the r= ole
of the IETF should be. =A0It's like the perennial prescriptive/descript= ive
argument that dictionary-writers have.

Should the role of the IETF be to describe implemented standards or
should it be to prescribe new or evolved standards? =A0Should it be trying<= br> to push SPF in a slightly-different direction or should it be trying to
maximize the *current* (short-term?) utility and interoperability of SPF?

The question that needs to be aske= d but isn't is 'what role do the governance structures permit'?=

he IAB is tasked with architecture but does not solicit= or build consensus for its architectural proposals. Which is why Patrik= 9;s DNS options proposal was stillborn.=A0

That IA= B is not elected by the IETF membership or accountable to it. So the IETF f= eels no obligation to follow the guidance it attempts to give. Worse, the o= ld boys club method of selection ensures that members are picked for the co= nformity rather than the novelty of their views. So it tends to be a reacti= onary body.

In the case of Patrik's RFC, there were many proble= ms:

1) The SPF Working Group was justifiably peeve= d by the attempt by the DNSEXT group to trump their work by presenting thei= r opinion in the form of an IAB ultimatum.=A0

2) The RFC is broken. It makes assertions that are demo= nstrably untrue and makes erroneous conclusions.=A0

3) The method of extension proposed is obviously unscalable as there are = only 65535 possible RRs and far more Web Services requiring discovery.

4) The draft does not acknowledge the fact that at the = time it was written one of the principle DNS servers in use could not in fa= ct support unknown RR types.

5) The document does = not admit that the real agenda was to push through the infrastructure neede= d to support DNSSEC.=A0

The last was subject to a long dispute between the SPF = group and the DNS WG. At one point Microsoft presented the actual code for = their DNS server and showed that it absolutely does not have the ability to= save a zone file. Despite this DNSEXT members continued to insist that bla= ck was white and Microsoft's DNS server could be used to serve unknown = DNS RRs based on the fact that one of them had written some sort of script = that could somehow wedge them into the cache. A hack that any network manag= er using it should be sacked for touching since it was clearly not maintain= able.

Having watched the interaction between the SPF and DNSE= XT WGs, this outcome is no surprise to me. Indeed it was inevitable.=A0


We should have a proper IAB that comes= out with architectural guidance so we don't have six different WGs mak= e six different decisions on how to do the same thing. But that can only wo= rk if the process delivers a result that has widespread consensus. Which is= not going to happen if the process is that an elite club meets in secret a= nd issues edicts.

The IETF mission statement is botched. The mission of t= he IETF is not to produce documents, they are only a byproduct. The mission= of the IETF is to produce consensus.=A0

The reaso= n I am peeved by the CBOR fiasco is that we have a situation where we need = a common approach but the mechanism chosen ensures that the chosen winner h= as no consensus and will thus be ignored.


We do need a proper discovery architectu= re. One that makes it possible to discover policy information as part of th= e discovery process. The DNS options draft was a missed opportunity in that= respect.

I have suggested to Patrik on several occasions that we= extend his URI discovery proposal to allow policy attributes to be include= d in the URI specification. But never received an answer.

--=
Website: http://= hallambaker.com/



--
Website: http://hallambaker.com/
--047d7ba975c808894504e466d66c-- From drc@virtualized.org Tue Aug 20 13:54: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 91F1411E82A2 for ; Tue, 20 Aug 2013 13:54:25 -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 mrkBP8Xng18H for ; Tue, 20 Aug 2013 13:54:19 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id 877B811E8286 for ; Tue, 20 Aug 2013 13:54:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id 78DB18712A; Tue, 20 Aug 2013 16:54:18 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 14680-08; Tue, 20 Aug 2013 16:54:18 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id C191487128; Tue, 20 Aug 2013 16:54:17 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_419F9912-E4AB-4E6C-96AC-AAA518A6AC6B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> Date: Tue, 20 Aug 2013 13:54:15 -0700 Message-Id: References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 20:54:25 -0000 --Apple-Mail=_419F9912-E4AB-4E6C-96AC-AAA518A6AC6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ted, On Aug 20, 2013, at 10:33 AM, Ted Lemon wrote: > I don't think either of these dichotomies captures the tension that is = being addressed in this particular case. In this particular case, = spfbis considered at length whether the IETF _could_ do the = architecturally clean thing here, and concluded that we could not. I am honestly curious how such a conclusion could possibly be reached. =20= I can easily see an argument that it might take a long time or that = "legacy TXT" will always be with us (just as IPv4 will always be with = us), but a better migration strategy, one that numerous people including = Mans, Patrik, and others have already mentioned, would, I believe, allow = for a transition to SPF over time. Can you provide a pointer to where in the 28MBytes of mailing list = archives the SPFBIS working group justified that it was impossible to = transition? I've read the entire archives a couple of times now and = don't recall the definitive objective arguments. > So the dichotomy you want here is, does the IETF propose a standard = _knowing full well that nobody will ever implement it_, or does the IETF = try for a substantial functional improvement to a standard that people = have > already shown they will implement? False dichotomy. People have already implemented SPF RRs. As far as I know, all popular = name servers already support the SPF RR type in one form or another. I = am aware of multiple UIs that allow for SPF RRs to be entered and I know = from personal experience that there are SPF validators that will make = use of SPF RRs: not having followed the 4408{,bis} discussions, when I = set up SPF on my personal domain a while back, I naively used the SPF RR = (didn't occur to me to use TXT). I noticed in my logs that people were = querying for my SPF records. What folks are suggesting is that the SPFBIS working group _fix the = migration strategy_. As far as I can tell, no one thinks the 4408bis = approach is a good idea, rather it is justified as being pragmatic. I'm = unsure why the SPFBIS believes the time for migration is now over and = that the Internet community must abandon the effort to replace TXT with = SPF, permanently embedding a hack and forcing every other application = that might want to use TXT at the zone apex either now or in the future = to deal with strings that start with "v=3Dspf". > The architecturally clean thing to do here is to get rid of SMTP, = which is a protocol designed for a gentler time, and is ill-suited to = the current Internet, with its spammers and botnets and snoops (oh my!). = If you are interested in architectural hygiene, get to work on that, and = stop wasting your energy fussing about the relative ugliness of two ugly = band-aids, one of which spfbis decided to deprecate, the other of which = they decided to keep. I suspect it might take significantly longer to transition away from = SMTP than to migrate from TXT to SPF. Regards, -drc --Apple-Mail=_419F9912-E4AB-4E6C-96AC-AAA518A6AC6B 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSE9d4AAoJEIzZ2DQOJFbKvHoIAKr9+LiFME+ChcgZVa4egH7d gddV7sm8bPGSjEjUDDyg00ZciPISEzT7Aetl+chxWUuNrjtwPHIjcSQakNIGqzsr xHoxbg5Yu7fVfSv8qdxzO+QnWQ1smWB9W1uVVSivwz1TST7VvwSwZ9X3jDHJR/uZ b1+ZxpW+BpajYcBCz1sTnh2awI04BGldiCC80JZn37p69cmkV3tCzN2UK9rHEppy agauE9lye671aeI2MVyWtK0F6Eld7SaXbjnQyNisoDVWvzlJggHCrhERPi7NkmP2 X+nyxJagDFSQave8kN4vqv7XB19ixmReJCcT1eVnXW8doS48rBt+2cLySLuVitI= =Ojp7 -----END PGP SIGNATURE----- --Apple-Mail=_419F9912-E4AB-4E6C-96AC-AAA518A6AC6B-- From ajs@anvilwalrusden.com Tue Aug 20 14:15:34 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 4050E11E82CA for ; Tue, 20 Aug 2013 14:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 L93Upy8QGrBF for ; Tue, 20 Aug 2013 14:15:28 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 18C6811E82A4 for ; Tue, 20 Aug 2013 14:15:27 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 2002D8A031 for ; Tue, 20 Aug 2013 21:15:22 +0000 (UTC) Date: Tue, 20 Aug 2013 17:15:21 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130820211521.GC23740@mx1.yitter.info> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 21:15:34 -0000 On Tue, Aug 20, 2013 at 01:54:15PM -0700, David Conrad wrote: > I can easily see an argument that it might take a long time or that > "legacy TXT" will always be with us (just as IPv4 will always be > with us), but a better migration strategy, one that numerous people > including Mans, Patrik, and others have already mentioned, would, I > believe, allow for a transition to SPF over time. > > Can you provide a pointer to where in the 28MBytes of mailing list > archives the SPFBIS working group justified that it was impossible > to transition? I've read the entire archives a couple of times now > and don't recall the definitive objective arguments. I believe the actual argument, which I have already repeated here once, did not hinge on claims of impossibility or possibility. That would be rather an absurd bar, since it is obviously logically possible[1] that the transition happens. Rather, the argument was that the transition strategy as defined in 4408 hadn't caused much use of SPF yet; that requiring SPF query first would involve a useless lookup on day 0, which would increase network use and might increase latency; that requiring TXT query first would automatically provide a disincentive to any possible transition; and that both strategies were more complicated than just picking one, and interoperability effectively required picking TXT. As a pragmatic matter of protocol engineering _given a deployed base_, I'd like to hear an argument against the above argument, because I was unable to advance a strong, sound one despite my preference for a move away from TXT. Best, A [1] As David Lewis (the philosopher, not the politican) was reputedly fond of pointing out, there is a logically-possible world in which I am a mud puddle. I'm taking it for granted that we are not trying to optimise for such worlds, but for the actual world in which we all subsist. In that world, network effects are important, so that the overwhelming preference of existing deployers is a TXT record is significant. I grant, however, that that same actual world is a logically-possible world in which my name ought better to be spelled MUD. -- Andrew Sullivan ajs@anvilwalrusden.com From jay@nzrs.net.nz Tue Aug 20 14:25: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 5E91211E8145 for ; Tue, 20 Aug 2013 14:25:54 -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 gtpM+w5yFsmc for ; Tue, 20 Aug 2013 14:25:49 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 41B8611E82DF for ; Tue, 20 Aug 2013 14:25:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 2CE094B6935 for ; Wed, 21 Aug 2013 09:25:29 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyUvJ7JvbUKZ for ; Wed, 21 Aug 2013 09:25:22 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 0A6C54B690C for ; Wed, 21 Aug 2013 09:25:22 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <20130820211521.GC23740@mx1.yitter.info> Date: Wed, 21 Aug 2013 09:25:21 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> To: dnsext@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 21:25:55 -0000 It seems that the real problem here is that there were very many people = who knew that using TXT records in the first place was the wrong idea, = made their views known and were ignored. Worse still a number of people = predicted this inevitable end point, that using TXT would become the = standard if was promoted as an interim step to start with. So for me the real question now is how to prevent another poor decision = like that from happening again. Personally I think the best way is to = push the pain on those that have caused the problem by deprecating the = use of TXT for SPF and setting a flag day. That's seems a fair and = reasonable consequence for making such an obviously poor decision in the = first place. Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From Ted.Lemon@nominum.com Tue Aug 20 14:29: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 0D29011E8280 for ; Tue, 20 Aug 2013 14:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 GPaG-lzCLc2O for ; Tue, 20 Aug 2013 14:29:38 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4192B11E8129 for ; Tue, 20 Aug 2013 14:29:38 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUhPfwZYjZzGiTEVnGDWHy+gOrUOEg2Ca@postini.com; Tue, 20 Aug 2013 14:29: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 D92F11B82AB for ; Tue, 20 Aug 2013 14:29:36 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-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 8E04D19006C; Tue, 20 Aug 2013 14:29:35 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Tue, 20 Aug 2013 14:29:35 -0700 From: Ted Lemon To: David Conrad Thread-Topic: [dnsext] Deprecating SPF Thread-Index: AQHOnSjBNfc5jIvzzEeabK322dk3P5mdj7EAgACAmwCAAJGjgIAACgCAgAAFTACAABvogIAABLSAgAA4DICAAAncAA== Date: Tue, 20 Aug 2013 21:29:34 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077525E57A@mbx-01.win.nominum.com> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> 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: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 21:29:46 -0000 On Aug 20, 2013, at 1:54 PM, David Conrad wrote: > On Aug 20, 2013, at 10:33 AM, Ted Lemon wrote: >> I don't think either of these dichotomies captures the tension that is b= eing addressed in this particular case. In this particular case, spfbis c= onsidered at length whether the IETF _could_ do the architecturally clean t= hing here, and concluded that we could not. >=20 > I am honestly curious how such a conclusion could possibly be reached. =20 In order to do something architecturally clean, two things have to be true.= First, you have have an architecturally clean solution in mind that you = propose to deploy. Second, you have to be able to deploy it. The IETF c= ould indeed meet the former requirement; the evidence though is that we can= 't meet the second requirement during the useful life of SPF, and hence we = can't satisfy the second requirement. This case was in fact convincingly made on the mailing list. It can't be = proven, because predicting the details of the future is not within our gras= p, so if you insist that it must be proven in order to satisfy your objecti= on, your objection can't be satisfied. I will not answer the points you m= ade subsequent to your above question, because these points were already an= swered during the spfbis discussion. >> The architecturally clean thing to do here is to get rid of SMTP, which = is a protocol designed for a gentler time, and is ill-suited to the current= Internet, with its spammers and botnets and snoops (oh my!). If you are in= terested in architectural hygiene, get to work on that, and stop wasting yo= ur energy fussing about the relative ugliness of two ugly band-aids, one of= which spfbis decided to deprecate, the other of which they decided to keep= . >=20 > I suspect it might take significantly longer to transition away from SMTP= than to migrate from TXT to SPF. The transition away from SMTP has already happened. There are still legac= y users of SMTP (we happen to be among them), but SMTP carries very little = of the text-based interpersonal communication that occurs on the internet t= oday, and we can expect that trend to continue. The pity is that the IETF= doesn't currently have a replacement protocol in mind; the transition has = been from an open standard to a plethora of carefully and deliberately clos= ed systems. From jay@nzrs.net.nz Tue Aug 20 14:34: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 D2B3E11E82DD for ; Tue, 20 Aug 2013 14:34: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=[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 aVVKXjrguM2L for ; Tue, 20 Aug 2013 14:34:41 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 34F8011E8280 for ; Tue, 20 Aug 2013 14:34:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 658DD4B6954; Wed, 21 Aug 2013 09:34:36 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOcW5A6m7dwl; Wed, 21 Aug 2013 09:34:28 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 964A84B6A46; Wed, 21 Aug 2013 09:31:47 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: Date: Wed, 21 Aug 2013 09:31:47 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130820141029.GQ32655@cisco.com> <20130820161102.79213.qmail@joyce.lan> <20130820162609.GS32655@cisco.com> To: John R Levine X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] new RRRTYPEs, was Deprecating SPF 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, 20 Aug 2013 21:34:46 -0000 On 21/08/2013, at 4:51 AM, John R Levine wrote: > The draft is draft-levine-dnsextlang-06. It's not very long. >=20 > I went through all of the existing RRs, and defined types for all of = the field types that seemed useful in new RRs. Sounds excellent and I will read it. I did the same thing (defining all = field types) in draft-daley-dnsxml-00 and I know just how much hard work = that takes and the value that could come from it. On 21/08/2013, at 4:11 AM, John Levine wrote: > It got a surprisingly hostile reaction here, but people are interested > in appsarea. The draft is draft-levine-dnsextlang-06 I'm not sure if you've noticed yet, but there's an often repeated = pattern to innovative ideas being brought to this list when a sufficient = gap is left between attempts: 1st attempt: surprisingly hostile reaction 2nd attempt: apathy 3rd attempt: lament that we never did it on the 1st attempt Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From johnl@iecc.com Tue Aug 20 14:49:38 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 311C911E8156 for ; Tue, 20 Aug 2013 14:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 sAe3hNKH-uc9 for ; Tue, 20 Aug 2013 14:49:33 -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 AFBEE11E82E6 for ; Tue, 20 Aug 2013 14:49:28 -0700 (PDT) Received: (qmail 67001 invoked from network); 20 Aug 2013 21:49:26 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Aug 2013 21:49:26 -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=5213e466.xn--30v786c.k1308; i=johnl@user.iecc.com; bh=am9RRj6iErZW8nyFmlnN5jg3aC49I01xuwI/busifkA=; b=k3ZABGU8xFfsJPPVprlpu0Jn02cJzEhq3AIWYlX5MTQ8f6spszoTJ5hWeTRddEUoesigCN8SA9jOWByI2GsE5ytOZI1eZr/XxGKxP61DukXaN2exOWcdhpgv6Z3wWeaz1w5sCEUkPc+rN2VHABInURU25sAyxGBRfMn4n1K3WCB3MTUCyWWXuHbuBrVvCyaOq+DfZwlhSY6mekE9ab40cWvrQ82+9t5Kb97LsBEP/QB60cJ/x4zCkzej1kSAz9Dr 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=5213e466.xn--30v786c.k1308; olt=johnl@user.iecc.com; bh=am9RRj6iErZW8nyFmlnN5jg3aC49I01xuwI/busifkA=; b=cjpzyQsl0TIybvL8OZmbnNTrPNVldrkAkhFzLMGihgrbdU3e+ylgEgTaM8emlY44JYSU+s05F7uDSG+TMOM/SQJejE/Vbu7Jtx4TgmYTAnpEGKFPyA5zyTzojhjWBK9g1yxYkbj/VjyGLEP+gcEER5u3Al7cSOFBudNStLFIq8phBlrrfI0O6C42xsb59kXEyPh0kQBE/vrIcK7Q3yzvybcUduYa6evuvJsNXQQPDKxLkwXy2MYYCA+0IP6ZUp2u Date: 20 Aug 2013 21:49:04 -0000 Message-ID: <20130820214904.82405.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 21:49:38 -0000 >numerous people including Mans, Patrik, and others have already mentioned, would, I believe, >allow for a transition to SPF over time. I did a little extrapolation, and based on adoption rates from 2006 to now, it'd be about 200 years until we could turn off TXT records. The people who actually use SPF have spoken, loudly. The only large mail system that ever checked type 99 records was Yahoo, and they don't any more. Google, Hotmail, AOL, Comcast, et al., all publish and check TXT records, and have never checked type 99 (not because they don't know how.) The libraries that people use to check SPF mostly have the type 99 check turned off because it just slows things down. This ship sailed so long ago it's fallen off the other side of the world, particularly since switching from TXT to SPF provides no operational benefit whatsoevever to the mail system operators that publish ahd use them. R's, John From hsantos@isdg.net Tue Aug 20 15:19: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 6EF7D11E82C1 for ; Tue, 20 Aug 2013 15:19:46 -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 4tDcmyvPyRXg for ; Tue, 20 Aug 2013 15:19:41 -0700 (PDT) Received: from secure.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AE7F811E810B for ; Tue, 20 Aug 2013 15:19:40 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1997; t=1377037179; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=5yL7Karwm+EoVsO/JyqUvuYUa3Q=; b=sZcBnspthlddC1i9tPvh +6Q4GNfZNvW+74QGh/QRBlGYas8eaJzfBLBD9NsBWFxAZioNYfQTuxMFqeGce1eD H/Lsk8Z6NXZuZxjA22pMVJ5DewHhoOHMon69zQGrb9kKpncMMOlZTjjjeeSA8azE fbsrfXWvO/gPm0c2HppYpoE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Tue, 20 Aug 2013 18:19:39 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3499696073.3.4508; Tue, 20 Aug 2013 18:19:38 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1997; t=1377036869; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RADnPHi yLWwtkFUdbYzaSRaGTNs2809tS8UBaAD9UUE=; b=CXhQPQBayJvsMj0mlH9GwMl gaJHaZfdFpIJ96R3kP0HFD/w4pgt0kmZ14St4YfoNGaFM9BM8LjZCTVzxmJwUMSE qYzr2jL+5fYlgwvuTLE4PSN+YGz3chJ6X3wbxId6pZ0xtm33ayfcnMVd5QYSq+WV 6QLVaZl4oPofO8wBA1vw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Tue, 20 Aug 2013 18:14:29 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2946116830.9.4556; Tue, 20 Aug 2013 18:14:28 -0400 Message-ID: <5213EB6C.7040008@isdg.net> Date: Tue, 20 Aug 2013 18:19:24 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: dnsext@ietf.org References: <20130820214904.82405.qmail@joyce.lan> In-Reply-To: <20130820214904.82405.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 22:19:46 -0000 John Levine wrote: >> numerous people including Mans, Patrik, and others have already mentioned, would, I believe, >> allow for a transition to SPF over time. > > I did a little extrapolation, and based on adoption rates from 2006 to > now, it'd be about 200 years until we could turn off TXT records. > > The people who actually use SPF have spoken, loudly. The only large > mail system that ever checked type 99 records was Yahoo, and they > don't any more. Google, Hotmail, AOL, Comcast, et al., all publish > and check TXT records, and have never checked type 99 (not because > they don't know how.) The irony is that there is still a huge dual TXT/TXT overhead in queries to get SPF information with the big boys switching to _spf prefix subdomain zones. The larger ESP should optimize their calling requirements to a single call for the same of the rest of the community to support them. For example: google.com, facebook.com google.com v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all" facebook.com: v=spf1 redirect=_spf.facebook.com At least with Facebook, their SPF corporate policy is a HARD FAIL, so their spoof protection payoff is very high and google.com is just a waste in calls with its softfail policy. > The libraries that people use to check SPF > mostly have the type 99 check turned off because it just slows things > down. That can all easily change once major DNS servers, like Microsoft support unnamed RR type processing. Its the only reason Windows shops don't (could not) support it. > This ship sailed so long ago it's fallen off the other side of the > world, particularly since switching from TXT to SPF provides no > operational benefit whatsoevever to the mail system operators that > publish ahd use them. So what you are saying is that TXT applications is it, its the acceptable record to use from now on for all future DNS applications. Why bother with anything else? -- HLS From sm@elandsys.com Tue Aug 20 16:35: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 00AC411E831D for ; Tue, 20 Aug 2013 16:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 E3hdkDFmrieg for ; Tue, 20 Aug 2013 16:35:09 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F1E11E81C6 for ; Tue, 20 Aug 2013 16:35:07 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.108]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7KNYqVI000726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 16:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377041705; bh=wov7HQ+t39ZjzZvtRUgdPaQe53Pa8/0UEZKh8z2su5w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cWszWFXtHiEtSJEndm6Go3XjPeTLgR370WwpYOD3MyPBZp1NOPx9DGT0nKf9wMKlQ +f9m9CRkpKFnoGNYpxNjQkqZoskzld6vMPmVm3mrniA0ivQL2HW1zeuZfi68Fbq34K H/WxDSXsP3NYmJLHHkupxXzCx55tc0Y25YQy9t9A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377041705; i=@elandsys.com; bh=wov7HQ+t39ZjzZvtRUgdPaQe53Pa8/0UEZKh8z2su5w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=S1rGi147xe1W6nNlqjjZ8+EJ70IG1IMoyav5D1c405uBjx/GxR/2cLpZw/o/b35UH N/kumN1OiOd2aMiuLy8i7KarXYsUkq+1/Yoo94iATRyli4E2K7lLKaDtFyyqN99jAa clvwpi/j9GvJa9A1KT2PxjQQLuWUTQm7k5W3yi3w= Message-Id: <6.2.5.6.2.20130820155829.0deae848@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 20 Aug 2013 16:07:41 -0700 To: Jay Daley From: S Moonesamy In-Reply-To: References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 20 Aug 2013 23:35:10 -0000 Hi Jay, At 14:25 20-08-2013, Jay Daley wrote: >So for me the real question now is how to prevent another poor >decision like that from happening again. Personally I think the >best way is to push the pain on those that have This is an individual comment. See http://www.ietf.org/mail-archive/web/dnsext/current/msg13086.html specifically: "I was the document shepherd for RFC 6686. There wasn't any comments during the Last Call." All it takes is people volunteering to review drafts instead of expecting Area Directors or the usual people to do all the work. Regards, S. Moonesamy From sm@elandsys.com Tue Aug 20 17:22:32 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 3865D11E815F for ; Tue, 20 Aug 2013 17:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 bupVKm7+Cmmz for ; Tue, 20 Aug 2013 17:22:31 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E832221F9D12 for ; Tue, 20 Aug 2013 17:22:30 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.108]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7L0MCw5016632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 17:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377044544; bh=/j82BixBt9PKONMcbZ3+drQAVgfgTiNudUk9durv+0Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=b0GhsUV63CZkp3NmgFJ4de8Iym/H9RCg1upy/zbD8xF8wGf8ZCVnnojpRbwDpOVtE mU3Hk6lloBPArw+jSIbnRQwd26ythDAKUc5ebRfRrTbhnujvAYofGqRE/VfOvWxlau pgSWZclpNxJ1DwztC1375R1AQi0DuXca2aXnQOIw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377044544; i=@elandsys.com; bh=/j82BixBt9PKONMcbZ3+drQAVgfgTiNudUk9durv+0Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dPHloWy2JvNX8rLLSx1qvyEbDYwlXquDn+ZvnjzuWRxVycffvIItEzLfZq51ELHud gvYLlA9iV70pttr7+9O7xaz/iDmm2JxEo5j87O+wF2ZFpMjF/mR1et3mlSy1RBceGk TyO25XcS0a8zdk/zSlQ2n+98bThrcBqTEuruLa+o= Message-Id: <6.2.5.6.2.20130820164709.0de68c08@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 20 Aug 2013 17:20:24 -0700 To: David Conrad From: S Moonesamy In-Reply-To: References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 00:22:32 -0000 Hi David, At 13:54 20-08-2013, David Conrad wrote: >Can you provide a pointer to where in the 28MBytes of mailing list >archives the SPFBIS working group justified that it was impossible >to transition? I've read the entire archives a couple of times now >and don't recall the definitive objective arguments. The thread starts at http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html See http://www.ietf.org/mail-archive/web/spfbis/current/msg00594.html too. There is also a thread at http://www.ietf.org/mail-archive/web/spfbis/current/msg00533.html I would attempt to explain the path to the RRTYPE decision as follows: The SPFBIS effort started with a request for experimental evidence ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00255.html ). Murray Kucherawy asked about the SPF RR Type ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00329.html ). Philip Gladstone posted some data ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00354.html ). There was a question about what evidence was being requested ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00355.html ). Issue #9 about the RRTYPE was raised ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00361.html ). The working group was asked to comment about it ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html ). The SPFBIS Chairs concluded that there wasn't consensus for the removal of TYPE 99 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00594.html ). The SPFBIS Chairs noted a concern about interoperability ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00692.html ). As it was difficult to resolve the issue of the RRTYPE the matter was discussed at a meeting ( http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt ). Regards, S. Moonesamy From drc@virtualized.org Tue Aug 20 19:35:47 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 9EF1D1F0D52 for ; Tue, 20 Aug 2013 19:35:47 -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 n3VvN8HnmpZt for ; Tue, 20 Aug 2013 19:35:41 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id AB0501F0D5F for ; Tue, 20 Aug 2013 19:35:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id 4FA328712A; Tue, 20 Aug 2013 22:35:40 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 17757-02; Tue, 20 Aug 2013 22:35:39 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id 633DF87128; Tue, 20 Aug 2013 22:35:39 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A52BD333-2414-42D5-9208-108083547EEC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: <20130820211521.GC23740@mx1.yitter.info> Date: Tue, 20 Aug 2013 19:35:36 -0700 Message-Id: <6A08C0EC-6CFB-4ECD-9C71-585BC8A3293C@virtualized.org> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 02:35:47 -0000 --Apple-Mail=_A52BD333-2414-42D5-9208-108083547EEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Andrew, On Aug 20, 2013, at 2:15 PM, Andrew Sullivan = wrote: > the argument was that the transition strategy as defined in 4408 = hadn't caused much use of SPF yet; The transition strategy was noted as broken in RFC 6686, appendix A, #4, = hence this isn't really a surprise. What is surprising to me is that = instead of fixing the broken transition strategy and trying again, = SPFBIS has decided to permanently embed a hack that impacts other = protocols. > that requiring SPF query first would involve a useless lookup on day = 0, RFC 6686 indicates 2% of tested sites have SPF records, so not quite = useless. And if you're going to say "2% is too small", I'll simply = point to IPv6 and DNSSEC like so many others have. Deploying something = new takes time, even if the transition strategy isn't broken. If you = have a broken transition strategy, the time is infinite. Again, no = surprise. > which would increase network use and might increase latency; For the 98% (according to RFC 6686) that haven't deployed SPF RRs, = definitely. Easy fix for that if the transition strategy is fixed. > that requiring TXT query first would automatically provide a = disincentive to any possible transition; Well, yes. Not sure this is a useful argument. > and that both strategies were more complicated than just picking one, Undoubtedly. > and interoperability effectively required picking TXT. =20 Not really. Interoperability requires TXT be queried. The suggestion is = that it be queried last. But you know this. > As a pragmatic > matter of protocol engineering _given a deployed base_, I'd like to > hear an argument against the above argument, because I was unable to > advance a strong, sound one despite my preference for a move away from > TXT. It's obvious that no new arguments are being made here, so if you didn't = consider the above convincing before, you're unlikely to consider it = convincing now and this is a waste of time. Not surprising. Regards, -drc --Apple-Mail=_A52BD333-2414-42D5-9208-108083547EEC 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSFCd4AAoJEIzZ2DQOJFbKbDwH/Rg+DT2a4vZNqm/fm0SLlC5e XwMdlhvsizSWLEfeDeiNESzcBnFnG1N7+H1o+RM6+OgOMGledPEa19ZoAIKWSNvy 6rcgpJvBatEcgGFklrRbVhK3+OGZwy4kNadUZhVWgqAHeWaqmfgBuL1AkI2ZzZAM QAb1IuUUT/1qivtkszooc1806FOKIR6gGDWoh1DhzpviwjqcaJ0oAg/t2RAIdmlx rYq0jWe1j/hdwXiLJF7n3WFXhduDQFVIiqBjwyQNOrWkgCp0gVzrXocHR4ZDY1U8 kbxhriqkA7iOLLrPdDRmTfV9oXS7SX5kcmM+O8ui+wC3+xRWTRGjigbv/5zZV0Y= =z4zQ -----END PGP SIGNATURE----- --Apple-Mail=_A52BD333-2414-42D5-9208-108083547EEC-- From drc@virtualized.org Tue Aug 20 19:39: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 2A1F011E830E for ; Tue, 20 Aug 2013 19:39:17 -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 2Dc4c1N5QvDC for ; Tue, 20 Aug 2013 19:39:11 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id 5509411E81A6 for ; Tue, 20 Aug 2013 19:39:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id 6292F8712E; Tue, 20 Aug 2013 22:39:09 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 17757-03; Tue, 20 Aug 2013 22:39:09 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id BE09F8712D; Tue, 20 Aug 2013 22:39:08 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9E79005A-43F2-44DF-913B-3CCED0DE3ED8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: Date: Tue, 20 Aug 2013 19:39:05 -0700 Message-Id: <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> To: Jay Daley X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 02:39:17 -0000 --Apple-Mail=_9E79005A-43F2-44DF-913B-3CCED0DE3ED8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jay, On Aug 20, 2013, at 2:25 PM, Jay Daley wrote: > So for me the real question now is how to prevent another poor = decision like that from happening again. =20 My understanding is that when SPF was being developed initially, it was = exceedingly difficult to get a new RR defined. That problem has been = solved. Obviously, if someone still chooses to use TXT (for whatever = reason) and then standardize a broken transition strategy, the same = problem will reoccur. Hopefully, the IESG has learned the lesson here. Regards, -drc --Apple-Mail=_9E79005A-43F2-44DF-913B-3CCED0DE3ED8 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSFChJAAoJEIzZ2DQOJFbKAQsIAIkpVs3ulzPwsSxWjqxQ8TOr ePNayDPn+Xk7+QwSHDdHVRU1h2Wn2WhdpK8g4QW8gCFxYfnFZ4Z9WWsoKtTpQKYi B1D1zenDD6mDGx7ZnqQUS0K9g1kEkj4l3q8r7V4t3ZFI3yqic2r2jfTJcMbj55S3 PZ4TkBLG75tA78IGCkexx4I5RGALje2I6Hv1ks/0iNU9/G53cKV28bLbEg0PRRb2 Ou/0ji8zzDQUQrbMf/t2h85/w0FDcdnNrNeI9C2fQ6bLkmoe/LhjR9kP4Qfb/g7r UyDjByqS+5QnQhkMnu84fXJkKbKHi4EJZjP2YpuXxmDi97Pa6qRsr5KV6AaH5Iw= =UnHd -----END PGP SIGNATURE----- --Apple-Mail=_9E79005A-43F2-44DF-913B-3CCED0DE3ED8-- From dhc2@dcrocker.net Tue Aug 20 19:58:34 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 C777811E8367 for ; Tue, 20 Aug 2013 19:58:34 -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 G6ClWtfxPIKJ for ; Tue, 20 Aug 2013 19:58:30 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 45DF611E835F for ; Tue, 20 Aug 2013 19:58:30 -0700 (PDT) Received: from [192.168.2.26] (adsl-99-183-241-57.dsl.pltn13.sbcglobal.net [99.183.241.57]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7L2wQEM007097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Aug 2013 19:58:29 -0700 Message-ID: <52142CBA.30801@dcrocker.net> Date: Tue, 20 Aug 2013 19:58:02 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ted Lemon References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 20 Aug 2013 19:58:29 -0700 (PDT) Cc: "" Subject: [dnsext] getting rid of smtp (was Re: Deprecating SPF) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 02:58:34 -0000 On 8/20/2013 10:33 AM, Ted Lemon wrote: > The architecturally clean thing to do here is to get rid of SMTP, which is a protocol designed for a gentler time, and is ill-suited to the current Internet, with its spammers and botnets and snoops (oh my!). The premise for this oft-voiced view is that we know what a 'safe and proper and equally usable' mail transfer infrastructure service should look like and how it is different from the current SMTP infrastructure. The premise is comforting but false. I have a standard response to views like this: 1. We have a long and successful history of figuring out how to successfully add capabilities to Internet mail (including SMTP.) No doubt, at some point, we will need to add something that we won't be able to figure out how to do workably. At that point, we will have to replace SMTP. 2. Before it is reasonable to throw out SMTP, there needs to be a functional specification for a feature that has community consensus, and we need to try to implement it via SMTP, but then fail to find a way to do it. 3. To date, there is no community consensus proposal. There are many individuals who are certain they know the Truth for this topic, but they haven't developed a clear community consensus for modifying this global infrastructure service. Such folk are encouraged to review: http://craphound.com/spamsolutions.txt It's Cory Doctorow's purportedly humorous checklist on the topic, but he did a good enough job to be useful for those of us who regularly field claims of knowing what is known in the trade as the Final Ultimate Solution to the Spam Problem (FUSSP) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From marka@isc.org Tue Aug 20 19:59:43 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 B752F11E8372 for ; Tue, 20 Aug 2013 19:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, 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 aFtfOve0GbXd for ; Tue, 20 Aug 2013 19:59:38 -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 E84EB11E835F for ; Tue, 20 Aug 2013 19:59:38 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id D45E0C9428; Wed, 21 Aug 2013 02:59:25 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377053978; bh=QbI12zVE0Kce0wHIjSdN8ZbCRcnQa4Me9bd1tKCeTGg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=L+tfhl1fNExjfj5fOJc9Xxq5B3+99AjTYviDjhhc0EQl3/QhvEQSsEQs98QzzOU/+ FfgyNB/u7yEBXAjhaQPGysfm45geh8Tn7lZq19qZSukhPRTGWfsTQwRZacsC/LNZ6s gCbGRu9WsgBEPvZEhcdX9FWVKEnZgI1zJ18dc00Q= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 21 Aug 2013 02:59:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3A41E1602B4; Wed, 21 Aug 2013 02:59:34 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 0AD8E160219; Wed, 21 Aug 2013 02:59:34 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id EA0E838B7E8B; Wed, 21 Aug 2013 12:59:21 +1000 (EST) To: David Conrad From: Mark Andrews References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org> In-reply-to: Your message of "Tue, 20 Aug 2013 19:39:05 -0700." <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org> Date: Wed, 21 Aug 2013 12:59:21 +1000 Message-Id: <20130821025921.EA0E838B7E8B@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 02:59:43 -0000 In message <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org>, David Conrad writes: > > Jay, > > On Aug 20, 2013, at 2:25 PM, Jay Daley wrote: > > So for me the real question now is how to prevent another poor decision > like that from happening again. > > My understanding is that when SPF was being developed initially, it was > exceedingly difficult to get a new RR defined. That problem has been > solved. Obviously, if someone still chooses to use TXT (for whatever > reason) and then standardize a broken transition strategy, the same > problem will reoccur. Hopefully, the IESG has learned the lesson here. > > Regards, > -drc It wasn't difficult at all. Just no one involved with SPF would attempt to get a record. There was this whole mythology that it was hard with no evidence to back it up. I say this as someone that got much more contraversial records in the same time period. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jay@nzrs.net.nz Tue Aug 20 20:06: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 EE58711E8375 for ; Tue, 20 Aug 2013 20:06: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] 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 Fm-phRbcJa9i for ; Tue, 20 Aug 2013 20:06:01 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCFB11E836D for ; Tue, 20 Aug 2013 20:06:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 6A0FD4B6A01; Wed, 21 Aug 2013 15:05:59 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3UZWuHVnM9x; Wed, 21 Aug 2013 15:05:52 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 38CD24B69D0; Wed, 21 Aug 2013 15:05:52 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org> Date: Wed, 21 Aug 2013 15:05:52 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <765AE933-D9A8-4106-A110-F1B296D74D09@nzrs.net.nz> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 03:06:06 -0000 On 21/08/2013, at 2:39 PM, David Conrad wrote: > My understanding is that when SPF was being developed initially, it = was exceedingly difficult to get a new RR defined. That problem has = been solved. Obviously, if someone still chooses to use TXT (for = whatever reason) and then standardize a broken transition strategy, the = same problem will reoccur. Hopefully, the IESG has learned the lesson = here. Thanks David. I understood that another key issue was the lack of = support in MS DNS products for unknown RRs, which I gather is still the = case. So despite the change to the process for creating new RRs we'll = still have the risk of people using TXT for prototyping and then = declaring a sufficiently installed base of TXT for the new usage to be = formalised. =20 Jay >=20 > Regards, > -drc >=20 >=20 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From drc@virtualized.org Tue Aug 20 20:13: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 2FAB111E811D for ; Tue, 20 Aug 2013 20:13:17 -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 0GJ-2eIpIsju for ; Tue, 20 Aug 2013 20:13:12 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id 4F94611E8331 for ; Tue, 20 Aug 2013 20:13:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id B5E338712A; Tue, 20 Aug 2013 23:13:10 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 17757-04; Tue, 20 Aug 2013 23:13:08 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id 6BC9187128; Tue, 20 Aug 2013 23:13:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077525E57A@mbx-01.win.nominum.com> Date: Tue, 20 Aug 2013 20:13:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <68F940DF-1F8C-487D-A7D4-F5BECA24CA39@virtualized.org> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077525E57A@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 03:13:17 -0000 Ted, On Aug 20, 2013, at 2:29 PM, Ted Lemon wrote: > The transition away from SMTP has already happened. =20 The 250ish queries per second the "L" root server is getting for MX = records might suggest http://www.youtube.com/watch?v=3DUPatfgoNBRo. > There are still legacy users of SMTP (we happen to be among them), but = SMTP carries very little of the text-based interpersonal communication = that occurs on the internet today, and we can expect that trend to = continue. =20 Without agreeing or disagreeing with your view on SMTP, this might = suggest the SPFBIS solution of putting a TXT record at the zone apex for = a dying protocol (if I'm understanding your view correctly) thereby = imposing a parsing requirement to ignore "v=3Dspf..." for all future = protocols that might want to query TXT at the zone apex would make even = less sense. In any event, as I responded to Andrew, there are no new arguments here. = Fundamentally, I believe the SPFBIS solution is wrong and I've provided = my input reflecting my view in response to the last call on the IETF = list. I encourage others to provide their input on the last call as well = (regardless of whether their view is pro or con). I'll admit I feel I've = wasted more than enough time tilting against this particular windmill. Regards, -drc From drc@virtualized.org Tue Aug 20 20:29: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 5EC6D11E8379 for ; Tue, 20 Aug 2013 20:29: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 kUjZQHezRpBz for ; Tue, 20 Aug 2013 20:29:06 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id 96AA511E818E for ; Tue, 20 Aug 2013 20:29:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id 8B0C18712A; Tue, 20 Aug 2013 23:29:04 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 17252-06; Tue, 20 Aug 2013 23:29:03 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id 913ED87128; Tue, 20 Aug 2013 23:29:01 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B510CC16-4230-452F-9EDE-1241F9909B62"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: <765AE933-D9A8-4106-A110-F1B296D74D09@nzrs.net.nz> Date: Tue, 20 Aug 2013 20:28:59 -0700 Message-Id: <1A3F153D-7BA5-4DD1-BB5D-F8B6C4A83B5E@virtualized.org> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org> <765AE933-D9A8-4106-A110-F1B296D74D09@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 03:29:11 -0000 --Apple-Mail=_B510CC16-4230-452F-9EDE-1241F9909B62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jay, On Aug 20, 2013, at 8:05 PM, Jay Daley wrote: > Thanks David. I understood that another key issue was the lack of = support in MS DNS products for unknown RRs, which I gather is still the = case. Yes and no (mostly no) -- see the note from Carsten Strotman below. = Sad. Based on the fact Microsoft doesn't support unknown RR types after a = decade (3 years longer than SPF RRs), I gather we should deprecate = unknown RRs... :) Regards, -drc Begin forwarded message: > From: Carsten Strotmann > Subject: Re: [dnsext] Deprecating SPF > Date: August 20, 2013 7:57:45 AM PDT > To: Joe Abley > Cc: Pete Resnick , Patrik@cisco.com, = "dnsext@ietf.org Group" , F@cisco.com >=20 > Signed PGP part > Hi, >=20 > Joe Abley wrote: >=20 > > Yes, including BIND9 which is probably the most widely-deployed DNS > > server software. > >=20 > > But my vague recollection is that this is not supported by > > Microsoft's DNS server implementation on Windows, and since many > > Windows environment are tied to that implementation because of > > requirements to use Active Directory, and since many people have = mail > > systems running on Windows, TXT was a pragmatic path forward. > >=20 >=20 > I did some tests on Windows 2008 (R2) in 2009 or 2010 and found that = the > Microsoft server does support RFC 3597 for zones loaded from a master > (by zonetransfer) or from a masterfile, but there is no way to add or > edit the data through the GUI (if is however possible to add the = records > to a plain text DNS master file using a text editor, if I remember > correctly). I haven't tested zones stored in Active Directory. >=20 > - -- Carsten >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --Apple-Mail=_B510CC16-4230-452F-9EDE-1241F9909B62 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSFDP7AAoJEIzZ2DQOJFbKdW0IALDE4MqS+DyyyBXaRjqtYUzl xomrw4ARuOecazu0dtYQmWTarCYr3cRbWT0rrAhNq1ZPWE8gh3DJTqoRwopXeYfJ FIQAWzYb8jNMqo47jN1cMs0w94g4npF6ZGnEVQcCGXQlT0Im3sSTzBu2X+yY4sZx b48xq5176qe8am4r/ngVAtKhhGVNm5O2XzltICYbTmGB8gkWhKJI973/Vqohv3p2 J7EVpZQv8vOu61uePAqLwx7LFhseNvrtz1NRmfIiYomR4TEkJeL5ZSziAHFccrIH kLOviYxnU71I7HndKqS//ktb4FCy/ha0VM/OXFgCqk6lRe8GLgS4YWvNs7R9HBg= =cyNd -----END PGP SIGNATURE----- --Apple-Mail=_B510CC16-4230-452F-9EDE-1241F9909B62-- From ajs@anvilwalrusden.com Tue Aug 20 20:37: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 E025B11E818E for ; Tue, 20 Aug 2013 20:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 JiIwotgA+yQ7 for ; Tue, 20 Aug 2013 20:37:23 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id E546211E8150 for ; Tue, 20 Aug 2013 20:37:22 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 8C9AE8A031 for ; Wed, 21 Aug 2013 03:37:21 +0000 (UTC) Date: Tue, 20 Aug 2013 23:37:19 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130821033719.GJ607@mx1.yitter.info> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <6A08C0EC-6CFB-4ECD-9C71-585BC8A3293C@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A08C0EC-6CFB-4ECD-9C71-585BC8A3293C@virtualized.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 03:37:29 -0000 On Tue, Aug 20, 2013 at 07:35:36PM -0700, David Conrad wrote: > RFC 6686 indicates 2% of tested sites have SPF records Actually, I think it says that fewer than 2% of such sites have SPF records. > I'll simply point to IPv6 and DNSSEC like so many others have. But the analogy there is preposterous, because SPF is, by any measure, a much more successful technology than either of those others. If in the case of either DNSSEC or IPv6 we had anything remotely resembling the alternate path to deployment that the TXT record for SPF has, we'd standardize it. Alternatively, we could say that in the case of v6 we _do_ have such a technology: NAT44. And indeed, long after the success of the lalala-I-can't-hear-you crowd on NAT44, the IETF got around to trying to figure out the least broken way to cope with this. A whole working group (BEHAVE) got set up for that purpose. > Deploying something new takes time, even if the transition > strategy isn't broken. Yes, but if the transition strategy relies on people who get no benefit of any sort from making the transition, the end recedes permanently into the future. Mail operators have voted with their feet. This is yet another difference with DNSSEC and IPv6. In the case of both of those transitions, there's at least some argument to be made that some benefit redounds to the operator who needs to make a transition. A DNSSSEC signer gets assurance that at least validating clients can determine whether the data is legit. A DNSSEC validator gets assurance that the validated source data is legit. An IPv6 service offering ensures that the v6 network can get the service, and an IPv6 client might have no other choice due to address scarcity. In the case of SPF, the incentive to publish TYPE99 depends entirely on SPF validators looking it up. The SPFBIS WG's surveys detected almost no use of the lookup of TYPE 99, and even fewer such lookups that appeared to be anything other than concurrent lookups of the functionally equivalent TXT record. Nobody is using this thing, and there is nothing that provides an incentive to do it. The IETF insisting that it's a good idea would do exactly nothing to advance that state of affairs. I would dearly love evidence to the contrary, but unless you have some new data to suggest why RFC 6686 is wrong, there is really no incentive anywhere on the network to move, and if the IETF published a standard saying, "Move, darnit," that would do nothing except make the IETF look even more out of touch than usual. > > and interoperability effectively required picking TXT. > > Not really. Interoperability requires TXT be queried. The suggestion is that it be queried last. But you know this. > So, you would prefer that on day 0 everyone send a query that in almost every case offers no benefit in order to get an advantage that is mostly a matter of architectural correctness? What do you think the chances are that validators will follow that reasoning? Do you think the chances are better than, say, deployment of BCP 38? Why? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From joelja@bogus.com Tue Aug 20 20:59: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 6569411E81A0 for ; Tue, 20 Aug 2013 20:59:05 -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 FNOW5egLEJRD for ; Tue, 20 Aug 2013 20:59:05 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id DCAB811E80FF for ; Tue, 20 Aug 2013 20:59:04 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r7L3x1Ul084852 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 21 Aug 2013 03:59:02 GMT (envelope-from joelja@bogus.com) Message-ID: <52143B02.8040506@bogus.com> Date: Tue, 20 Aug 2013 20:58:58 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: David Conrad , Jay Daley References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org> In-Reply-To: <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 21 Aug 2013 03:59:03 +0000 (UTC) Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 03:59:05 -0000 On 8/20/13 7:39 PM, David Conrad wrote: > Jay, > > On Aug 20, 2013, at 2:25 PM, Jay Daley wrote: >> So for me the real question now is how to prevent another poor decision like that from happening again. > My understanding is that when SPF was being developed initially, it was exceedingly difficult to get a new RR defined. That problem has been solved. Obviously, if someone still chooses to use TXT (for whatever reason) and then standardize a broken transition strategy, the same problem will reoccur. Hopefully, the IESG has learned the lesson here. Assigning a new rr is demonstrably simple at this time (expert review), it doesn't require stardards action, and you can do so without an rfc. > Regards, > -drc > > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From paf@frobbit.se Tue Aug 20 23:06:40 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 DA9A811E8378 for ; Tue, 20 Aug 2013 23:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.129, 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 B3hxUioT-FMT for ; Tue, 20 Aug 2013 23:06:39 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 112D411E80FD for ; Tue, 20 Aug 2013 23:06:39 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::e0a8:d413:1cf1:c2f5] (unknown [IPv6:2a02:80:3ffc:0:e0a8:d413:1cf1:c2f5]) by mail.frobbit.se (Postfix) with ESMTPSA id 6345324000; Wed, 21 Aug 2013 08:06:33 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <52143B02.8040506@bogus.com> Date: Wed, 21 Aug 2013 08:06:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <703EAE64-E818-4991-B4C1-F4BDE95C7520@frobbit.se> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org> <52143B02.8040506@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 06:06:40 -0000 On 21 aug 2013, at 05:58, joel jaeggli wrote: > Assigning a new rr is demonstrably simple at this time (expert = review), > it doesn't require stardards action, and you can do so without an rfc. Which was done with for example URI, which confuses people so much that = we now write an RFC explaining the RR Type. Patrik From Jelte.Jansen@sidn.nl Wed Aug 21 01:13: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 EC2DD11E81CB for ; Wed, 21 Aug 2013 01:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119] 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 H9LbUrF9E-iO for ; Wed, 21 Aug 2013 01:13:29 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 0296311E8326 for ; Wed, 21 Aug 2013 01:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=tWuOeuUELVMUUtkoKZPWIGyL60ibZ7GEoBzkzM/YJYo=; b=S/3XvuWtQC6jEgyfiv2thXjaBPG6WbZIMqQw1rzx54aW/EVOTcRutdzMYFlnAIj3RkTVQ1jdM8EFUQoNPkXhiyBJOS0c44dywnvy8P1JMKDuY6B1AbxcNGFmdY1yMZfvBCDInNH08BclglIH83OaVY+X3GAmbwySzGjwzkvm9fA= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r7L8DHRm018705-r7L8DHRo018705 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Wed, 21 Aug 2013 10:13:17 +0200 Received: from [94.198.152.217] (94.198.152.217) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 21 Aug 2013 10:13:16 +0200 Message-ID: <5214769C.1030708@sidn.nl> Date: Wed, 21 Aug 2013 10:13:16 +0200 From: Jelte Jansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Conrad References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org> <765AE933-D9A8-4106-A110-F1B296D74D09@nzrs.net.nz> <1A3F153D-7BA5-4DD1-BB5D-F8B6C4A83B5E@virtualized.org> In-Reply-To: <1A3F153D-7BA5-4DD1-BB5D-F8B6C4A83B5E@virtualized.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.217] Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 08:13:34 -0000 On 08/21/2013 05:28 AM, David Conrad wrote: > > Based on the fact Microsoft doesn't support unknown RR types after > a decade (3 years longer than SPF RRs), I gather we should > deprecate unknown RRs... :) > SMTP is older, and unless they fixed it last year, Hotmail doesn't follow the RFC regarding MX lookups either. So while we're deprecating things... ;) That doesn't give much hope for any additional use of DNS for their mail, be it using TXT or a protocol-specific type, or a fallback approach, TBH. Jelte From hallam@gmail.com Wed Aug 21 01:35:30 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 BF6C611E81E0 for ; Wed, 21 Aug 2013 01:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 elKHV+AGpEiY for ; Wed, 21 Aug 2013 01:35:29 -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 7977411E81A3 for ; Wed, 21 Aug 2013 01:35:29 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t60so129513wes.3 for ; Wed, 21 Aug 2013 01:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0wLuMrkP+OJW3CMlEQ1Ddzop5HkRHNs4vGtxFYQbGcw=; b=jsuRcy70FNE+oekhkbeihgy/dhA/tCkF0Ds7W/yRA4q8ydUnmh9RyLJVatHFoW7CHi /4/VrCDz52mOpQqHKx1h7yNRx5rqgOpAIDTnoiQx2T6Q0VsMpI1mqcu63f2+6OlyJ9LX 3LmP1sc2PeA2F9o38SEDjV6sZxL8E01fvcaXYjSNCAw9Cv0b4i2OsohVvfsULUKp++pW PGThbTq1m3g3JMYuRz7Ez5bfajnvCoaV+IwGw/GYmsAPlPcBGQInAwe/lGNenAY9GGTK tdPCeO7Xeku0GcfpSuIm53T86m4uIVyuGugi3KAUSvPCCNHRR4gnZJ2k5lld0hjDSoN/ wTfQ== MIME-Version: 1.0 X-Received: by 10.180.184.84 with SMTP id es20mr16536529wic.37.1377074128578; Wed, 21 Aug 2013 01:35:28 -0700 (PDT) Received: by 10.194.6.67 with HTTP; Wed, 21 Aug 2013 01:35:28 -0700 (PDT) In-Reply-To: <20130821025921.EA0E838B7E8B@drugs.dv.isc.org> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org> <20130821025921.EA0E838B7E8B@drugs.dv.isc.org> Date: Wed, 21 Aug 2013 04:35:28 -0400 Message-ID: From: Phillip Hallam-Baker To: Mark Andrews Content-Type: multipart/alternative; boundary=001a11c2259c436e9804e4710e42 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 08:35:30 -0000 --001a11c2259c436e9804e4710e42 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 20, 2013 at 10:59 PM, Mark Andrews wrote: > > In message <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org>, David > Conrad > writes: > > > > Jay, > > > > On Aug 20, 2013, at 2:25 PM, Jay Daley wrote: > > > So for me the real question now is how to prevent another poor decision > > like that from happening again. > > > > My understanding is that when SPF was being developed initially, it was > > exceedingly difficult to get a new RR defined. That problem has been > > solved. Obviously, if someone still chooses to use TXT (for whatever > > reason) and then standardize a broken transition strategy, the same > > problem will reoccur. Hopefully, the IESG has learned the lesson here. > > > > Regards, > > -drc > > It wasn't difficult at all. Just no one involved with SPF would attempt > to get a record. There was this whole mythology that it was hard with > no evidence to back it up. > > I say this as someone that got much more contraversial records in the same > time period. Apart from the wee problem of Windows Server DNS not supporting unknown records and being 4 years off an update as demonstrated by the Microsoft team showing the source code. Nobody disputed the ability to get a new RR, the issue was getting support for the new RR from DNS resolution providers who were not running recent versions of BIND. The support for unknown records had not been defined when the Microsoft product was launched. -- Website: http://hallambaker.com/ --001a11c2259c436e9804e4710e42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 20, 2013 at 10:59 PM, Mark Andrews &l= t;marka@isc.org><= /span> wrote:

In message <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org>, D= avid Conrad
=A0writes:
>
> Jay,
>
> On Aug 20, 2013, at 2:25 PM, Jay Daley <jay@nzrs.net.nz> wrote:
> > So for me the real question now is how to prevent another poor de= cision
> like that from happening again.
>
> My understanding is that when SPF was being developed initially, it wa= s
> exceedingly difficult to get a new RR defined. =A0That problem has bee= n
> solved. =A0Obviously, if someone still chooses to use TXT (for whateve= r
> reason) and then standardize a broken transition strategy, the same > problem will reoccur. =A0Hopefully, the IESG has learned the lesson he= re.
>
> Regards,
> -drc

It wasn't difficult at all. =A0Just no one involved with SP= F would attempt
to get a record. =A0There was this whole mythology that it was hard with no evidence to back it up.

I say this as someone that got much more contraversial records in the same<= br> time period.

Apart from the wee problem of = Windows Server DNS not supporting unknown records and being 4 years off an = update as demonstrated by the Microsoft team showing the source code.

Nobody disputed the ability to get a new RR, the issue = was getting support for the new RR from DNS resolution providers who were n= ot running recent versions of BIND. The support for unknown records had not= been defined when the Microsoft product was launched.



--
Website: http://hallambaker.com/
--001a11c2259c436e9804e4710e42-- From hadriel.kaplan@oracle.com Wed Aug 21 04:56:16 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 1D05711E81ED for ; Wed, 21 Aug 2013 04:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 Qz7wk9-3QPLP for ; Wed, 21 Aug 2013 04:56:09 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 953E011E8386 for ; Wed, 21 Aug 2013 04:56:09 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7LBu6cL018722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Aug 2013 11:56:07 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7LBu4ww013060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 11:56:05 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7LBu3Bl013503; Wed, 21 Aug 2013 11:56:03 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Aug 2013 04:56:03 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <6A08C0EC-6CFB-4ECD-9C71-585BC8A3293C@virtualized.org> Date: Wed, 21 Aug 2013 07:56:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <6A08C0EC-6CFB-4ECD-9C71-585BC8A3293C@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 11:56:16 -0000 On Aug 20, 2013, at 10:35 PM, David Conrad wrote: > It's obvious that no new arguments are being made here, so if you = didn't consider the above convincing before, you're unlikely to consider = it convincing now and this is a waste of time. Not surprising. What would be more convincing, I think, is if people showed the actual = harm with using TXT. That it's not what DNS folks wished for I got, but = if it ain't broken it's hard to figure out why it's worth fixing or why = people would pay attention. For example, the argument's been made that because it's in the zone apex = it will cause issues with other TXT RRs. ISTM the solution to that is to put the TXT in a prefixed node like = "_spf" (as some folks already do, I believe). The "transition" strategy = could be to query that prefixed name first, and only the non-prefixed = TXT if the first isn't found. After all we have evidence that 100% of = clients already can and do query TXT for this stuff and can support it, = including MS DNS. ;) But the response to such a suggestion would likely be: "why would people = change to doing that?!?" Yet that's exactly the argument being made = against SPF RR, isn't it? If you believe that transitioning to SPF RR = is the right thing to do, to avoid the problems of TXT RR in the apex, = then it seems like you should be willing to go for a prefixed name TXT = instead... unless you think a separate RRType avoids some harm that = hasn't yet been identified? -hadriel From marka@isc.org Wed Aug 21 06:15:31 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 7D50511E8219 for ; Wed, 21 Aug 2013 06:15:31 -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=[AWL=0.350, 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 AoQhDs-rsUaQ for ; Wed, 21 Aug 2013 06:15:26 -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 15A2911E80D3 for ; Wed, 21 Aug 2013 06:15:26 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 8D08EC9422; Wed, 21 Aug 2013 13:14:59 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377090913; bh=0qnTvGBpfaplaLSC9OZtNTwHQM2ni0BEYWkvuUeI/3A=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=EL1dOtkn/ib1e8+d0688FmcP8ql92umN1z9qVfS0QHo0NeBg3OSXOOEkFzr92hfIE 1GTkei+Xsi3/RnTO082y2Nx6QYogpvcUvrHqWuAo2OOpZ0vl72JWYxh0/eCI0KCHxV aV1PtjiIAkHG1lFuEbBHabxr1i4fYLfAiKmQ0+9g= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 21 Aug 2013 13:14:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C609B1602E9; Wed, 21 Aug 2013 13:15:09 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5F6F21602B4; Wed, 21 Aug 2013 13:15:09 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4070738BDF3A; Wed, 21 Aug 2013 23:14:48 +1000 (EST) To: Hadriel Kaplan From: Mark Andrews References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <6A08C0EC-6CFB-4ECD-9C71-585BC8A3293C@virtualized.org> In-reply-to: Your message of "Wed, 21 Aug 2013 07:56:03 -0400." Date: Wed, 21 Aug 2013 23:14:48 +1000 Message-Id: <20130821131448.4070738BDF3A@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 13:15:31 -0000 In message , Hadriel Kaplan wr ites: > > On Aug 20, 2013, at 10:35 PM, David Conrad wrote: > > > It's obvious that no new arguments are being made here, so if you didn't co > nsider the above convincing before, you're unlikely to consider it convincing > now and this is a waste of time. Not surprising. > > What would be more convincing, I think, is if people showed the actual harm w > ith using TXT. That it's not what DNS folks wished for I got, but if it ain' > t broken it's hard to figure out why it's worth fixing or why people would pa > y attention. One protocol using TXT isn't a real issue. When you get to 10, 50 or 500 using TXT it becomes a real issue. The point of having types is to be able to split out data for one protocol from another. We have already had to renumber types is the DNS because the uses were too overloaded. TXT is a great prototyping tool. It makes a lousy long term solution however. Not splitting out SPF means that you can't just let someone have the ability to update TXT records without impacting on the SPF policy. With SPF first you can hand someone the ability to update TXT records without risking impacts on SPF policy. > For example, the argument's been made that because it's in the zone apex it w > ill cause issues with other TXT RRs. The issues with using TXT is independent of the apex of a zone. > ISTM the solution to that is to put the TXT in a prefixed node like "_spf" (a > s some folks already do, I believe). The "transition" strategy could be to q > uery that prefixed name first, and only the non-prefixed TXT if the first isn > 't found. After all we have evidence that 100% of clients already can and do > query TXT for this stuff and can support it, including MS DNS. ;) You just broke anyone that uses a wildcard SPF record to say that wildcarded names don't send email. Works: *.example.net A
*.example.net AAAA
*.example.net SPF "v=spf1 -all" Doesn't work: *.example.net A
_spf.*.example.net TXT "v=spf1 -all" SPF records MUST be deployable where ever a A, AAAA or MX is deployable. > But the response to such a suggestion would likely be: "why would people chan > ge to doing that?!?" Yet that's exactly the argument being made against SPF > RR, isn't it? If you believe that transitioning to SPF RR is the right thing > to do, to avoid the problems of TXT RR in the apex, then it seems like you s > hould be willing to go for a prefixed name TXT instead... unless you think a > separate RRType avoids some harm that hasn't yet been identified? > > -hadriel > > _______________________________________________ > 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 hadriel.kaplan@oracle.com Wed Aug 21 06:33: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 70DC711E83B5 for ; Wed, 21 Aug 2013 06:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 CSkzHQMNsZgx for ; Wed, 21 Aug 2013 06:32:56 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id AA6A511E8396 for ; Wed, 21 Aug 2013 06:32:51 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7LDWoPi022900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Aug 2013 13:32:51 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7LDWl0k021940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 13:32:49 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7LDWloe021936; Wed, 21 Aug 2013 13:32:47 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Aug 2013 06:32:47 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <20130821131448.4070738BDF3A@drugs.dv.isc.org> Date: Wed, 21 Aug 2013 09:32:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26E7D0CA-0814-4324-828F-2DC68513568E@oracle.com> References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <6A08C0EC-6CFB-4ECD-9C71-585BC8A3293C@virtualized.org> <20130821131448.4070738BDF3A@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 13:33:02 -0000 On Aug 21, 2013, at 9:14 AM, Mark Andrews wrote: > One protocol using TXT isn't a real issue. When you get to 10, 50 or = 500 > using TXT it becomes a real issue. The point of having types is to be > able to split out data for one protocol from another. We have already > had to renumber types is the DNS because the uses were too overloaded. Yup, makes sense. > Not splitting out SPF means that you can't just let someone have the > ability to update TXT records without impacting on the SPF policy. > With SPF first you can hand someone the ability to update TXT records > without risking impacts on SPF policy. Yup, makes sense (though not as big an issue one would think, but ymmv). >> For example, the argument's been made that because it's in the zone = apex it w >> ill cause issues with other TXT RRs. >=20 > The issues with using TXT is independent of the apex of a zone. Except that the issues above seem to be solved by moving it out of the = apex into a prefixed name. (not the issue below though) > You just broke anyone that uses a wildcard SPF record to say that = wildcarded > names don't send email. >=20 > Works: > *.example.net A
> *.example.net AAAA
> *.example.net SPF "v=3Dspf1 -all" >=20 > Doesn't work: > *.example.net A
> _spf.*.example.net TXT "v=3Dspf1 -all" >=20 > SPF records MUST be deployable where ever a A, AAAA or MX is = deployable. Right, so is that fixable in any way? (I don't know the answer, just = asking) -hadriel From marka@isc.org Wed Aug 21 06:36: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 E616911E83B5 for ; Wed, 21 Aug 2013 06:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 ieQFOkSrtNCU for ; Wed, 21 Aug 2013 06:36:03 -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 89D9D11E83B8 for ; Wed, 21 Aug 2013 06:36:03 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 582B4C94AC; Wed, 21 Aug 2013 13:35:50 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377092163; bh=jqvd5lhIyQauC/ongi8nPLM92BwfeOC2k//0h66L3l4=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=H6CX+7zp74IW1LjB+eg8hmbaf+Gsd9nS0AEPa6gYg1Djw4V3Fkomvn679pQlrKOC2 Y+ngcXTDozB/TnziI/vlyJFPvH/UsZon+6HPqmGqdB4FpTrsWL7PqzWMbugZbCkfYG zCZg11KqilvoqJ8UmALg/C7hJ9d7KkSYjEliSYTw= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 21 Aug 2013 13:35:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A34821602E9; Wed, 21 Aug 2013 13:36:00 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 737AF1602B4; Wed, 21 Aug 2013 13:36:00 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0154838BE0AF; Wed, 21 Aug 2013 23:35:48 +1000 (EST) To: Hadriel Kaplan From: Mark Andrews References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <6A08C0EC-6CFB-4ECD-9C71-585BC8A3293C@virtualized.org> <20130821131448.4070738BDF3A@drugs.dv.isc.org> <26E7D0CA-0814-4324-828F-2DC68513568E@oracle.com> In-reply-to: Your message of "Wed, 21 Aug 2013 09:32:46 -0400." <26E7D0CA-0814-4324-828F-2DC68513568E@oracle.com> Date: Wed, 21 Aug 2013 23:35:47 +1000 Message-Id: <20130821133548.0154838BE0AF@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 13:36:09 -0000 In message <26E7D0CA-0814-4324-828F-2DC68513568E@oracle.com>, Hadriel Kaplan wr ites: > > On Aug 21, 2013, at 9:14 AM, Mark Andrews wrote: > > > One protocol using TXT isn't a real issue. When you get to 10, 50 or = > 500 > > using TXT it becomes a real issue. The point of having types is to be > > able to split out data for one protocol from another. We have already > > had to renumber types is the DNS because the uses were too overloaded. > > Yup, makes sense. > > > > Not splitting out SPF means that you can't just let someone have the > > ability to update TXT records without impacting on the SPF policy. > > With SPF first you can hand someone the ability to update TXT records > > without risking impacts on SPF policy. > > Yup, makes sense (though not as big an issue one would think, but ymmv). > > > >> For example, the argument's been made that because it's in the zone = > apex it w > >> ill cause issues with other TXT RRs. > >=20 > > The issues with using TXT is independent of the apex of a zone. > > Except that the issues above seem to be solved by moving it out of the = > apex into a prefixed name. (not the issue below though) > > > > > You just broke anyone that uses a wildcard SPF record to say that = > wildcarded > > names don't send email. > >=20 > > Works: > > *.example.net A
> > *.example.net AAAA
> > *.example.net SPF "v=3Dspf1 -all" > >=20 > > Doesn't work: > > *.example.net A
> > _spf.*.example.net TXT "v=3Dspf1 -all" > >=20 > > SPF records MUST be deployable where ever a A, AAAA or MX is = > deployable. > > Right, so is that fixable in any way? (I don't know the answer, just = > asking) No. > -hadriel > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From kcd@chrysler.com Wed Aug 21 12:13: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 CE65321F89C3 for ; Wed, 21 Aug 2013 12:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 If9vPPsqUS2d for ; Wed, 21 Aug 2013 12:13:02 -0700 (PDT) Received: from shbmap01.extra.chrysler.com (shbmap01.out.extra.chrysler.com [129.9.168.35]) by ietfa.amsl.com (Postfix) with ESMTP id 09FD021F9E80 for ; Wed, 21 Aug 2013 12:13:00 -0700 (PDT) Received: from odbmap04.oddc.chrysler.com (Unknown_Domain [53.28.32.58]) by shbmap01.extra.chrysler.com (Symantec Messaging Gateway) with SMTP id 8E.98.27415.5D015125; Wed, 21 Aug 2013 15:11:17 -0400 (EDT) X-AuditID: 8109a822-b7fd16d000006b17-b6-521510d56eba Received: from shh006smtp01.shdc.chrysler.com (shh006smtp01.shdc.chrysler.com [151.171.97.83]) by odbmap04.oddc.chrysler.com (Symantec Messaging Gateway) with SMTP id 10.00.30679.5D015125; Wed, 21 Aug 2013 15:11:17 -0400 (EDT) Received: from [10.143.0.242] (CITMNCNU1410TPT.cg.chrysler.com [10.143.0.242]) by shh006smtp01.shdc.chrysler.com (8.13.8/8.13.8/chrysler-relay-1.4-kcd) with ESMTP id r7LJBHQ0010976 for ; Wed, 21 Aug 2013 15:11:17 -0400 Message-ID: <521510D5.8090507@chrysler.com> Date: Wed, 21 Aug 2013 15:11:17 -0400 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <6A08C0EC-6CFB-4ECD-9C71-585BC8A3293C@virtualized.org> <20130821131448.4070738BDF3A@drugs.dv.isc.org> In-Reply-To: <20130821131448.4070738BDF3A@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA12TaUwTQRiGnXYL29qR7ULbcUHFVaNoBDQaL6ImBhX1h/CTxGPBtdtQoO62 AsYgohiCEe+DolEMpmiCBvGKaCT1QI0XxoOgojGIaLxjMMaYOrO0sPXfl+f9vnnn/SZD69nz NEc7CzyiXCC4+CgTNT0hcfbkWRZrVmqwwTCzpfytYT5YXF//W7ccZJvS1ogu53pRTpm72iQ1 Hj1IuW+bin+0PdOVgd10FTDSiJmGtjTup/prG3rUdSaK1CzzEKDyjoXhngv1t6L7eTdAr3ql KmDC9VeAmk7+wgJNQ2YSqnhoJz0UMw5VP96mnhPFjEWXO/3qrJXJRodPv1E5ZCzoTk03RUbj mFhUWaGOxuLRvnd1oP/4cgOqufkckB4jMwfVbY4npR6XfS0yadczo9DFz4f1pB0xe6PRn0Pt UbsA69M4+AZHfJqRY0B/CsQrUk6+4E6dkiwWe2QhOVeSSxSXKCfnFuafBXi5m40N/CVwxwcD II/W8VaYFGPNYoflFK4pkQRFWiV7XaLCx8F2guEAzvG68ngO6hhMYwdogViED/fgp+NHwhMr 4rJY+4CmeBW3M9dZ6FVWeWVXAMTTFG+HmT8zMlnGIXjEPFF0i3K/XwAU0TSPYCExtciiQyxe 63R5wjKeW0JhhdEq6o1GwLLn2NWmFTSXGg0PXLFksZxW/v9eOtoYAA7ajDPvUzMrbiFfcTpC 1rHwxjBMzWGq2g6H70grG4YayxHwBdmDLSxF2t0FJZwdlpJhhnRI3oKBlJwNpn/Bt43RCMSN S4CWq5hbNXzQkEuEOcXYcLhGjfQkX2pTMBj8CHJpgPP4iLsZf7jBkCw8DjEcGoJqRgS/q68R YpqICbCXRLSGlEi3j3iXOrzL2gks2aVH8Gh3uZgEMYdpaJfpBLJhGLHLhUSyhaVIJ64MCOMN r512fpuD653X5JfemsW+qQvetF8rrx3Sk7G0NFi1r6e17e+GGd6xQ9NetHY8eZre9a26OvBh 5b2EdZ/8d/3B+7PHt7a+XGQsWr8naWPlA5O5OyXdf6RGXDa/a+uEhtqeDb3vvz7uSW1+GnPz iGF/8/YdzjHXR3WWUucqWlIydvbxlCIJUybqZUX4B5DFtkbIBAAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUyfXVisO5VAdEgg1v/VSx2Nz1idWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtr501kKTnBVfDp+jamBcSJHFyMnh4SAicS2JcfYIWwxiQv3 1rOB2EICTxgl7r7I6GLkArLfM0psXPkdqIiDg1dAW6L1vDhIDYuAqkTfpTawejYBFYldt5aD zREViJKYs+4BWJxXQFDi5MwnLCCtIgLCEh2tYK3CQK3fni5khBjfxCox8+h1RpAaTgFriYWN 0iAmM5D5bXcRSDmzgLzE9rdzmCcw8s9CMnQWQtUsJFULGJlXMUrlpyTlJhYYmOjlp6Qk6yVn FFUW56QW6SXn525iBAabqYyC5Q7GuTfkDzEKcDAq8fC68okGCbEmlhVX5h5ilORgUhLl1eQH CvEl5adUZiQWZ8QXleakFh9ilOBgVhLhXcwGlONNSaysSi3Kh0lJc7AoifMahD0JFBJITyxJ zU5NLUgtgsnKcHAoSfCuAhkqWJSanlqRlplTgpBm4uAEGc4DNHwKSA1vcUFibnFmOkT+FKOi lDhvHUhCACSRUZoH1wtKBvX///9/xSgO9IowbzxIFQ8wkcB1vwIazAQ0eLaGEMjgkkSElFQD 44pP/+QU1D/94k274ei8ctGeE+bui+fPkjt/gvHImfRXs+Q5uz9+EF3f13ggaeqMpynT9K2+ BYSGzHH/dOPp3qAHC3yusfxU1Z5/fe8M56gDq7i0ZbVKe/33PV5r1P7ZZqH/6xoVfsHnbseW Kmlr3WHmq/VVNjA8WCv56cCX6bwL105oP3dUdpYSS3FGoqEWc1FxIgB5nDVj4QIAAA== Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 19:13:07 -0000 On 8/21/2013 9:14 AM, Mark Andrews wrote: > In message , Hadriel Kaplan wr > ites: >> On Aug 20, 2013, at 10:35 PM, David Conrad wrote: >> >>> It's obvious that no new arguments are being made here, so if you didn't co >> nsider the above convincing before, you're unlikely to consider it convincing >> now and this is a waste of time. Not surprising. >> >> What would be more convincing, I think, is if people showed the actual harm w >> ith using TXT. That it's not what DNS folks wished for I got, but if it ain' >> t broken it's hard to figure out why it's worth fixing or why people would pa >> y attention. > One protocol using TXT isn't a real issue. When you get to 10, 50 or 500 > using TXT it becomes a real issue. The point of having types is to be > able to split out data for one protocol from another. We have already > had to renumber types is the DNS because the uses were too overloaded. > > See also, Tragedy of the Commons. http://en.wikipedia.org/wiki/Tragedy_of_the_commons As stewards of the "commons" here, the SPF folks might do well to heed our concerns about "overgrazing" of a shared resource (TXT RR semantic space). Or, to put it another way, "get off of my lawn". - Kevin From b+dns@bruce-2013.zerlargal.org Wed Aug 21 14:38: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 199A711E8234 for ; Wed, 21 Aug 2013 14:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 VCNEFKexZT4R for ; Wed, 21 Aug 2013 14:38:06 -0700 (PDT) Received: from zularific.zerlargal.org (zularific.zerlargal.org [173.203.119.164]) by ietfa.amsl.com (Postfix) with ESMTP id 84F4711E819C for ; Wed, 21 Aug 2013 14:38:06 -0700 (PDT) Received: from zularific.zerlargal.org ([173.203.119.164]) by zularific.zerlargal.org with esmtp (Exim 4.71) (envelope-from ) id 1VCG6L-00048J-IV; Wed, 21 Aug 2013 21:38:04 +0000 Date: Wed, 21 Aug 2013 21:37:58 +0000 (GMT) From: Bruce Campbell To: Kevin Darcy In-Reply-To: <521510D5.8090507@chrysler.com> Message-ID: References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <6A08C0EC-6CFB-4ECD-9C71-585BC8A3293C@virtualized.org> <20130821131448.4070738BDF3A@drugs.dv.isc.org> <521510D5.8090507@chrysler.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 21 Aug 2013 21:59:11 -0000 On Wed, 21 Aug 2013, Kevin Darcy wrote: > On 8/21/2013 9:14 AM, Mark Andrews wrote: >> One protocol using TXT isn't a real issue. When you get to 10, 50 or 500 >> using TXT it becomes a real issue. The point of having types is to be >> able to split out data for one protocol from another. We have already >> had to renumber types is the DNS because the uses were too overloaded. >> > See also, Tragedy of the Commons. > http://en.wikipedia.org/wiki/Tragedy_of_the_commons > > As stewards of the "commons" here, the SPF folks might do well to heed our > concerns about "overgrazing" of a shared resource (TXT RR semantic space). > > Or, to put it another way, "get off of my lawn". RFC4408, 6.1 defines the 'redirect' attribute, which sends the client off to another record, commonly '_spf.same.domain' or '_spf.common.domain' in the case of a hosting provider with multiple zones. To _partially_ alleviate concerns about SPF records filling up the TXT record at the zone apex to the detriment of other uses, 4408bis could have something similar to the following under 3.4: Where non-SPF records are also present in the domain's TXT record, the SPF record SHOULD be limited to a redirect to a dedicated SPF record as defined in Section 6.1. Where possible, non-SPF records should also use similar redirects. For example: example.com. IN TXT "v=spf1 redirect=_spf.example.com" example.com. IN TXT "Can the SPF RR-99 or TXT record be phased out?" example.com. IN TXT "THERE IS AS YET INSUFFICIENT DATA FOR A" example.com. IN TXT "MEANINGFUL RESPONSE." example.com. IN TXT "v=quoteref redirect=_lastquestion.example.com" -- Bruce Campbell. Personally I think the biggest failure of SPF was a lack of insistence on it using a SRV-style prefix from the start. At the very least, the IETF should use SPF as a case study on why _not_ having dedicated record locations is a bad idea. From johnl@iecc.com Wed Aug 21 16:12:19 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 190D021F9A13 for ; Wed, 21 Aug 2013 16:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.719 X-Spam-Level: X-Spam-Status: No, score=-102.719 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 ciN6h-J4K3sQ for ; Wed, 21 Aug 2013 16:12:15 -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 C8E5C11E8261 for ; Wed, 21 Aug 2013 16:12:14 -0700 (PDT) Received: (qmail 51841 invoked from network); 21 Aug 2013 23:12:13 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Aug 2013 23:12:13 -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=5215494d.xn--btvx9d.k1308; i=johnl@user.iecc.com; bh=B3qG0SvGBLNiE2BSnuYajNiDzMqvhZ9t0HkShJOESD4=; b=rxWc2EGgThEiwZ76yYfhkNVrVpfixLYLCWXXWRPzgv2wTLuhAe7VXMpAopusuiscHGTZq122Prpeo4pXhsfK8B0iTFshzGBnEnlc94TlQWmhfKdwGRf3MStIeIsfTxMSJ7OjS7/tE9MGP0DQ+Zq4KSDD+rdKUNFmqtWWUSXSdXNdrc49Y1clqsMVxFZNr4Anl97kJTRApx1UCqhBMr4spn3ci74zLpbKPIQueAuGObBS7UQTzOFh1C+0s9d+0yMA 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=5215494d.xn--btvx9d.k1308; olt=johnl@user.iecc.com; bh=B3qG0SvGBLNiE2BSnuYajNiDzMqvhZ9t0HkShJOESD4=; b=unlp1g//ENsy4t8h4pFL/OPK9ZD3Z6kfIVgkoGAZJyWYZpWhkIWVD6QQxV/gWMjU/f6HTJqIZw/gJ0ebLQDNBRLK66j9EL0gU8PlRN36w6YEppAsu81Rn+tUv+uxBanp1caqCVUKfn12LhcTAUyI2vGmPKTS/aX0wPGy/Rf4+pIHc6+pxhgfh29N06qvS0biGPkPzYS9CmElIj2hHP2JHiaSRyPPKrItLlyImqQvaPHsxyLSDyjVM9LeMceq0Qw+ Date: 21 Aug 2013 23:11:50 -0000 Message-ID: <20130821231150.91097.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 21 Aug 2013 23:12:19 -0000 >ISTM the solution to that is to put the TXT in a prefixed node like "_spf" (as some >folks already do, I believe). Not really. See RFC 4408 and 4408bis. SPF does provide the ability to indirect to another name, and some people use various prefixes when they indirect, but that's not part of the protocol, nor are there any widespread conventions about what names to use. For some bad examples, see the TXT records at hotmail.com, outlook.com. and microsoft.com. If you will review the past million messages or so on this topic, you will find broad agreement that if we were designing SPF from scratch, we would do it differently. But we're not, we're talking about a widely deployed protocol which, no matter what the IETF might do, will not appeciably change from what's deployed now. R's, John From johnl@iecc.com Wed Aug 21 16:14: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 0D38A21F9A97 for ; Wed, 21 Aug 2013 16:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.712 X-Spam-Level: X-Spam-Status: No, score=-102.712 tagged_above=-999 required=5 tests=[AWL=-0.113, 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 N7Vd24Lr4SUj for ; Wed, 21 Aug 2013 16:13:57 -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 9E55F11E810B for ; Wed, 21 Aug 2013 16:13:57 -0700 (PDT) Received: (qmail 52163 invoked from network); 21 Aug 2013 23:13:56 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Aug 2013 23:13:56 -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=521549b4.xn--yuvv84g.k1308; i=johnl@user.iecc.com; bh=evnnKzr56OVbQUk02Zhi+bNO1rBTapKygfG7AZM6A0w=; b=KGobOyTl6Icnmxk5IC6uvVXXlsoXz/B4ffVWu9glPTP3b/wsr8N6DpOC+JfaDQEd31HddN8O1F8l8FjtGviawIh8EAkTkzCqmbBormRiDtXLv60HFvrFP7WhcpLowLSwJEn2XjcE/8InlSXya51uNEWj0H4w/x/SzL/ez7lpuGUS2dzGBOc/6sL1gd+2p27e+TbimtQK46dIR8oOSel/WHyTMAfYkVlY4YQIXzDATX6oeqT8HNqAEp6lY8CLGWbh 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=521549b4.xn--yuvv84g.k1308; olt=johnl@user.iecc.com; bh=evnnKzr56OVbQUk02Zhi+bNO1rBTapKygfG7AZM6A0w=; b=eGxhlT/8yfwcHXf0y4hk9JoTj5MkwzeN4CMfff/aL9TDb68rK8wkhKSt+ZTAwTnut5iTQlkUtFcNqsZ1lBLaNPEeJGG0NoOCNrdFoo5KlAoR43zEbo1cQi27TnveQz7MQFbiZbgaWhtBN1WSpXqFAHZNPax2TVLTd403y8U1fds9fWNAwUnIuflEEh3ztl+VU8ZwClep/SmMsVSiCMJOccYrXfr1bbhCK07vPnnmzvGAd0coCcGSeEw9K8Oz5bkG Date: 21 Aug 2013 23:13:34 -0000 Message-ID: <20130821231334.91165.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <1A3F153D-7BA5-4DD1-BB5D-F8B6C4A83B5E@virtualized.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 21 Aug 2013 23:14:02 -0000 >> I did some tests on Windows 2008 (R2) in 2009 or 2010 and found that the >> Microsoft server does support RFC 3597 for zones loaded from a master >> (by zonetransfer) or from a masterfile, but there is no way to add or >> edit the data through the GUI (if is however possible to add the records >> to a plain text DNS master file using a text editor, if I remember >> correctly). I haven't tested zones stored in Active Directory. Sounds exactly like the situation with BIND. R's, John From alex@alex.org.uk Wed Aug 21 16:19: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 6109911E8252 for ; Wed, 21 Aug 2013 16:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, 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 4ih-BVsDTR-N for ; Wed, 21 Aug 2013 16:19:11 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2AA11E826D for ; Wed, 21 Aug 2013 16:19:07 -0700 (PDT) Received: by mail.avalus.com (Postfix) with ESMTPSA id A8C58C560B4; Thu, 22 Aug 2013 00:18:48 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Alex Bligh In-Reply-To: <20130821231150.91097.qmail@joyce.lan> Date: Thu, 22 Aug 2013 00:18:47 +0100 Content-Transfer-Encoding: 7bit Message-Id: <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> References: <20130821231150.91097.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1085) Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 21 Aug 2013 23:19:11 -0000 On 22 Aug 2013, at 00:11, John Levine wrote: > But we're not, we're talking about a widely > deployed protocol which, no matter what the IETF might do, will not > appeciably change from what's deployed now. Genuine question: if a protocol is widely deployed, poorly standardised, and poorly designed, does that mean it merits RFC standards track? IE are standards track RFCs meant to document what is out there and used, or should be out there and used? I have always been of the opinion it was the latter, but most of this conversation has presumed the former. -- Alex Bligh From drc@virtualized.org Wed Aug 21 16:24: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 2905C21F9034 for ; Wed, 21 Aug 2013 16:24:13 -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 O+krY+byCmSX for ; Wed, 21 Aug 2013 16:24:07 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id E646321F9A05 for ; Wed, 21 Aug 2013 16:24:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id 5DAAB8712A; Wed, 21 Aug 2013 19:24:04 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 29570-06; Wed, 21 Aug 2013 19:24:03 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id 516AF87128; Wed, 21 Aug 2013 19:24:03 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_823CBF71-F211-45D1-B646-63296BBFF2FB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: <20130821231334.91165.qmail@joyce.lan> Date: Wed, 21 Aug 2013 16:24:01 -0700 Message-Id: <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> References: <20130821231334.91165.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 21 Aug 2013 23:24:19 -0000 --Apple-Mail=_823CBF71-F211-45D1-B646-63296BBFF2FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii John, On Aug 21, 2013, at 4:13 PM, John Levine wrote: >>> I did some tests on Windows 2008 (R2) in 2009 or 2010 and found that = the >>> Microsoft server does support RFC 3597 for zones loaded from a = master >>> (by zonetransfer) or from a masterfile, but there is no way to add = or >>> edit the data through the GUI (if is however possible to add the = records >>> to a plain text DNS master file using a text editor, if I remember >>> correctly). I haven't tested zones stored in Active Directory. >=20 > Sounds exactly like the situation with BIND. My impression was that it was impossible in MSDNS to add RFC 3597-style = unknown RRs to the master directly, but that it was possible for a MSDNS = slave to zone transfer in unknown RRs from a non-MSDNS master that = allowed the insertion of RFC 3597-style unknown RRs. However, I may = have misunderstood. Regardless, Microsoft's inability to deal with unknown RRs in any sort = of reasonable fashion after a decade is surprising and unfortunate. BIND (since early BINDv9), of course, has no problem with RFC 3597-style = unknown RRs, either as master or slave. Regards, -drc --Apple-Mail=_823CBF71-F211-45D1-B646-63296BBFF2FB 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSFUwSAAoJEIzZ2DQOJFbKELcH/2QBeOUW+GECQbHrb7EQU7Rt 9T2gmCyMa0xQPXX+jaW4tZD0HWwJZTrHhpcZ7hMhTZp3SYzMKiWUvVey+qOHadBO bfgbj9+ncxyxDqTjtFI+7bhwa7gYlnT38hNjneos6d+lRTOh5yhDglsgqo8wp4Kd 5Ivusd1z3kwnXeGrjkbS7t29M+HFmzZXz3tDqF/5UshuCwWFoDKDbGr4aQb94nCx 7qXsdqnkuvzWMAzBbQ1ED25P9LcJ1mi0m9cfvXOV6ge6yOJuj6EN5svQnimJgGVj WOoTPUWjtbdK5k4kAD9JBVFnu9m38aVJj1NSGs8QS/mSxC/Fs0PlKR3uIJLN/5k= =RQDr -----END PGP SIGNATURE----- --Apple-Mail=_823CBF71-F211-45D1-B646-63296BBFF2FB-- From johnl@taugh.com Wed Aug 21 16:31: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 A30B611E8183 for ; Wed, 21 Aug 2013 16:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.009, 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 2+fj8-sIPMdy for ; Wed, 21 Aug 2013 16:31:05 -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 C12C811E8182 for ; Wed, 21 Aug 2013 16:31:04 -0700 (PDT) Received: (qmail 55420 invoked from network); 21 Aug 2013 23:30:59 -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=d87b.52154db3.k1308; bh=SzT3rHiBct+Omt4oYeIILkqkMZjKzbuxkoyReBNLwb4=; b=VamLRZe9Nl1bAVLVQ8QUw+tQRSn84fLsQX+IYGYpYqc9WZ0U7wLK8zhTLvEkNRKsS4j9aI4eJYwP7ugctAEl393eYYNKks3vQhomkJ+P91CgPPBYLQ5Y+V24vBSmDiLJraJH3neMfcZ+5SH78OJsXH2uHJ8Ekxb7PEP/4nt037b5ij83YqKPaL/D9ncoujZKnOAYzUNVTAswZh3IwjHqgmXrfhrX8cvtYnxgXlaH9o2+GZN2SzX/tPuT291gYWUf 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=d87b.52154db3.k1308; bh=SzT3rHiBct+Omt4oYeIILkqkMZjKzbuxkoyReBNLwb4=; b=Sqe64lYd9ycfp0NDzSFRsHkq1tWZSSmsQpyvZP5Atpfg4JK6+wBpQdfiVP2x/Sxd7qrpMnYKi2YOYu+HKSqv77VI9xT07HSMcKUtnpepthSr3+TWqn/z3eCBPXgbTX9n+k5TWRhlMW6fQYo/MRvQWHyum6LWYcqt+Ba17ZjXwG9uoEszvSp9vyiVHo+O7XM+SlQErCZ0iqpB+aQ2q+noxg8yKQAVBRdoC1VQyjJXlxG9YOr2hT4xOaROJXiKpSlP Received: (ofmipd 127.0.0.1); 21 Aug 2013 23:30:37 -0000 Date: 21 Aug 2013 19:30:59 -0400 Message-ID: From: "John R Levine" To: "David Conrad" In-Reply-To: <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 21 Aug 2013 23:31:05 -0000 > On Aug 21, 2013, at 4:13 PM, John Levine wrote: >>>> I did some tests on Windows 2008 (R2) in 2009 or 2010 and found that the >>>> Microsoft server does support RFC 3597 for zones loaded from a master >>>> (by zonetransfer) or from a masterfile, but there is no way to add or >>>> edit the data through the GUI (if is however possible to add the records >>>> to a plain text DNS master file using a text editor, if I remember >>>> correctly). I haven't tested zones stored in Active Directory. >> >> Sounds exactly like the situation with BIND. > > My impression was that it was impossible in MSDNS to add RFC 3597-style > unknown RRs to the master directly, but that it was possible for a MSDNS > slave to zone transfer in unknown RRs from a non-MSDNS master that > allowed the insertion of RFC 3597-style unknown RRs. However, I may > have misunderstood. > > Regardless, Microsoft's inability to deal with unknown RRs in any sort > of reasonable fashion after a decade is surprising and unfortunate. > > BIND (since early BINDv9), of course, has no problem with RFC 3597-style > unknown RRs, either as master or slave. Right, but the web provisioning crudware that people use in front of BIND generally can't handle anything other than A, MX, CNAME, and TXT, so for anything else you have to get someone with direct access to the host to edit the master file. Like I said, sounds just the same. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From Ted.Lemon@nominum.com Wed Aug 21 16:44: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 E5CE911E8178 for ; Wed, 21 Aug 2013 16:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 wP9dyWwn3pnH for ; Wed, 21 Aug 2013 16:44:29 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 5D75211E8143 for ; Wed, 21 Aug 2013 16:44:29 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUhVQ3Njrjj3oGczPQHCT5BCtznSezUEh@postini.com; Wed, 21 Aug 2013 16:44:29 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 985DA1B82BC for ; Wed, 21 Aug 2013 16:44:28 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-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 7F3B519006E; Wed, 21 Aug 2013 16:44:28 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 21 Aug 2013 16:44:28 -0700 From: Ted Lemon To: Alex Bligh Thread-Topic: [dnsext] SPF isn't going to change, was Deprecating SPF Thread-Index: AQHOnsPoaJ0y+35VZ0OIBGmJ0ZRB35mgwWOAgAAHLIA= Date: Wed, 21 Aug 2013 23:44:28 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775260E94@mbx-01.win.nominum.com> References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> In-Reply-To: <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 21 Aug 2013 23:44:45 -0000 On Aug 21, 2013, at 4:18 PM, Alex Bligh wrote: > Genuine question: if a protocol is widely deployed, poorly > standardised, and poorly designed, does that mean it merits > RFC standards track? IE are standards track RFCs meant to > document what is out there and used, or should be out there > and used? It's not a question of "merit," and even if it were, I think it would be a = bit much to say that this document has no merit, or is "poorly designed," j= ust because you don't like the use of the TXT record, which is a small part= of the whole. It is a technical standard, developed in the IETF, which has applicability = on the internet. Those are the criteria for something being standards-tra= ck. From johnl@taugh.com Wed Aug 21 16:46:32 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 0AA9111E8178 for ; Wed, 21 Aug 2013 16:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.008, 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 lRfZ+9WKSBMY for ; Wed, 21 Aug 2013 16:46:31 -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 3FE2D21F8FAC for ; Wed, 21 Aug 2013 16:46:31 -0700 (PDT) Received: (qmail 58132 invoked from network); 21 Aug 2013 23:46:30 -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=e313.52155156.k1308; bh=0tiaLwnzDkl5C7XgZH7t2Oe3r8pVYk9draTkqn6GQBU=; b=A2NCABugVDIW5ZrtO25xiFJKi5sge2QwVbIxdDBHFQ4f6G6+ev809thliuRwJNgmMB+kAuE0fnFpzpAhEG3792HwVODhntx9jh5erh9BPAEKmY7m0Dtaj/JaRQIOv2ik4Bo5X2h5YxrNq++jsmSZCKl14JGEnYZGvSE7g+OYgFIVZWRIkDAXtubzZeJ+mF8qp1XoBxikUU4TU2rvyqS/VRrgf+ZL2Sd0eLug5EGFa7XiC0ZiM1TvUNoV21q3PnoQ 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=e313.52155156.k1308; bh=0tiaLwnzDkl5C7XgZH7t2Oe3r8pVYk9draTkqn6GQBU=; b=xSJOFLHxg2BCMIiPFaspSbE+po8H+/T0CFfECqC2gYahmg1XYdzZm/daUR3EBfi9JCvKd9CqpxggXBaMSXVj/1Nmci4B7bZgSi4EzH+72sQdOw7rF8zHM3ks69BdtoXrOQeaagaOMWMPRNGweHTD64YiiWhfwLihQ5I62KUafpbwzlWXQNol8f2y94eaz3cgNsKP9vnM37n9RUFgdUFurNjUNvpUZNrGQGc2OFCiNV20GFic0GK6+b35zEjv8w56 Received: (ofmipd 127.0.0.1); 21 Aug 2013 23:46:07 -0000 Date: 21 Aug 2013 19:46:29 -0400 Message-ID: From: "John R Levine" To: "Alex Bligh" In-Reply-To: <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 21 Aug 2013 23:46:32 -0000 > Genuine question: if a protocol is widely deployed, poorly > standardised, and poorly designed, does that mean it merits > RFC standards track? IE are standards track RFCs meant to > document what is out there and used, or should be out there > and used? It's a reasonable question. RFC 4408 currently exists and isn't going away, and SPF is probably more widely deployed than most standards track RFCs. We all agree that it's ugly, and we wouldn't design it this way if we were doing it from scratch. The choices are to stick our fingers in our ears and pretend it'll go away, or to acknowledge reality and make what fixes we can, keeping in mind that the installed base isn't going to make changes that cause a lot of breakage, or that have no perceptible benefit to them. The IETF has in the past often made the wrong choice in similar situations,* and I have to say it's dismaying that so many people seem determined to do it again. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. * - NAT From miek@miek.nl Wed Aug 21 16:52: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 2360A21F8F24 for ; Wed, 21 Aug 2013 16:52:24 -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=[AWL=1.300, 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 WdJZq-vDs4C0 for ; Wed, 21 Aug 2013 16:52:19 -0700 (PDT) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id DA1D911E817D for ; Wed, 21 Aug 2013 16:52:14 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id uo5so1051430pbc.9 for ; Wed, 21 Aug 2013 16:52:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=XR/wZ7N86paqRFyIDNqRxKTN5c3nEtZgmiOasu1mNxw=; b=OTnz9JtjVJ8r3mlaG41mYOfbasdi0mcL9Vg6wu2P6Yok5mg+6dVzQ3/coxi0begHPR KecnorcWiSiMAB9HcIKc9ratItTGEmrm0N6pb226unReMqA8f67DKQvQ8IOA17/yJXt/ TIkO/I8PeCvzoacKC+FiqMsY0CgHX1uJgqHSFYEXNK9IPWyGdTNkzza+73JJBT10+p7T JAIKVwpYoAU5Izfwe2BK2fsJYsmoqZdtR+acHtvp4fO6s1f5f54tOJFqaw8ptZqQ/RO5 gh7wUFv6vxz9Q0xzkeLPQ9INYrS0GfhNf+ZGqlqph8KXi+YpV9ihOmTJJ5fqovYVvKKO TGOg== X-Gm-Message-State: ALoCoQlYBeTLR9a1+tJ5IcuvVljBILXnmoxK3dZqJ42JjSc756EE6R+F98izxf9e22FQV+tH0m/1 X-Received: by 10.68.254.42 with SMTP id af10mr2209377pbd.154.1377129124391; Wed, 21 Aug 2013 16:52:04 -0700 (PDT) Received: from miek.nl (c-98-248-32-3.hsd1.ca.comcast.net. [98.248.32.3]) by mx.google.com with ESMTPSA id sx7sm10848451pbc.41.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 21 Aug 2013 16:52:03 -0700 (PDT) Date: Wed, 21 Aug 2013 16:52:01 -0700 From: Miek Gieben To: Jay Daley Message-ID: <20130821235201.GA3192@miek.nl> Mail-Followup-To: Jay Daley , dnsext@ietf.org References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813033143.GA24608@miek.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Cc: dnsext@ietf.org Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 21 Aug 2013 23:52:24 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "Re: [dnsext] A new DNS message - SE..." ] > > http://doc.powerdns.com/html/slave.html#supermaster >=20 > Ah yes I'd forgotten about that. Not quite the same as supermasters is on= ly > for provisioning slaves whereas servezones can provision both masters and > slaves. Also, if I remember rightly, supermasters can only add zones and = not > remove them whereas servezones can do both. I just rememered how I "solved" this once. Just set a low(er) expiration on your zone. Who cares if a zone is still running on a server somewhat longer? grtz Miek --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlIVUqEACgkQJYuFzziA0PZagwCfWqVqsolBZZN/WNgQ+VQaM7vh yf4AoKuxMN//GntATzkbmG2WNqSWLbUV =ZnJR -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From drc@virtualized.org Wed Aug 21 16:55: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 A913921F92A5 for ; Wed, 21 Aug 2013 16:55:20 -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 dZMXhWhnV0zW for ; Wed, 21 Aug 2013 16:55:14 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id C5C0821F99E9 for ; Wed, 21 Aug 2013 16:55:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id 859E68712A; Wed, 21 Aug 2013 19:55:10 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 30121-05; Wed, 21 Aug 2013 19:55:10 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id B262887128; Wed, 21 Aug 2013 19:55:09 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2665B7F2-3DC0-4FFB-881D-49EDFBE39881"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: Date: Wed, 21 Aug 2013 16:55:07 -0700 Message-Id: References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> To: John R Levine X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 21 Aug 2013 23:55:21 -0000 --Apple-Mail=_2665B7F2-3DC0-4FFB-881D-49EDFBE39881 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii John, On Aug 21, 2013, at 4:30 PM, John R Levine wrote: >> Regardless, Microsoft's inability to deal with unknown RRs in any = sort of reasonable fashion after a decade is surprising and unfortunate. >>=20 >> BIND (since early BINDv9), of course, has no problem with RFC = 3597-style unknown RRs, either as master or slave. >=20 > Right, but the web provisioning crudware that people use in front of = BIND generally can't handle anything other than A, MX, CNAME, and TXT, = so for anything else you have to get someone with direct access to the = host to edit the master file. Like I said, sounds just the same. In one case, the backend system doesn't support something. In the other case, the backend system does. Sounds different to me, but I guess that depends on your agenda and the = rhetorical points you're trying to score. Regards, -drc --Apple-Mail=_2665B7F2-3DC0-4FFB-881D-49EDFBE39881 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSFVNcAAoJEIzZ2DQOJFbKtMQH/3T0zaxmHrDoxVP3Cg9lsxSt g6UCXArOk7v8KsfrC55WQynTacpJJ8bcP3u0GKi71XqitDqrV8lEhR1KVvtRwgU/ VwtcNlpE15adnMN2Nl90iv4Ncwq6cQ5lMA+TISLwhRKXGr3Sg+quhwqbREpRz6s3 68rbOoNL3hic7clWzjZs5yRd98CJbSlfM+2VpkWbHDHVTKIK+KlIsAlhaP2vK7Ml koMLPB4TVFPSfBmv3JlBnNDsN6oj0fwEl9coUvZKn8hRlMteGsFBuWvqwGyLUDY8 GjSMZHwy9mjnQcT48fxly/kYsB2TJraLgogDKW3QN966UxidmhNX5hCFHaLOKic= =Lutc -----END PGP SIGNATURE----- --Apple-Mail=_2665B7F2-3DC0-4FFB-881D-49EDFBE39881-- From drc@virtualized.org Wed Aug 21 17:25:53 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 1E20C11E8134 for ; Wed, 21 Aug 2013 17:25:53 -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 sVaNUQHPJ3sd for ; Wed, 21 Aug 2013 17:25:48 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id E651E11E8145 for ; Wed, 21 Aug 2013 17:25:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id 318548712A; Wed, 21 Aug 2013 20:25:46 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 29570-10; Wed, 21 Aug 2013 20:25:45 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id 7941787128; Wed, 21 Aug 2013 20:25:45 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4AF4BD3A-349A-4EFF-9B39-C429CB0E1CBC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: Date: Wed, 21 Aug 2013 17:25:43 -0700 Message-Id: References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> To: John R Levine X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 22 Aug 2013 00:25:53 -0000 --Apple-Mail=_4AF4BD3A-349A-4EFF-9B39-C429CB0E1CBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 21, 2013, at 4:46 PM, John R Levine wrote: > The choices are to stick our fingers in our ears and pretend it'll go = away, or to acknowledge reality and make what fixes we can, keeping in = mind that the installed base isn't going to make changes that cause a = lot of breakage, or that have no perceptible benefit to them. Except parts of the future "installed base" are waiting for a decision = from the IETF, e.g.: = http://support.godaddy.com/groups/domains-management-and-services/forum/to= pic/spf-type-99/ = http://features.cpanel.net/responses/ability-to-create-spf-type-99-records= Regards, -drc --Apple-Mail=_4AF4BD3A-349A-4EFF-9B39-C429CB0E1CBC 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSFVqIAAoJEIzZ2DQOJFbK3nQH/2Lbo5yA2t+h5I+DKRMY8MaC tBIvkDOHaRZJh6OOIroWxMgLVM0qqhqYh5adiwB4Rpkq+GDvbjh/oyfI6vGrYDKK aH7oui79UyVChitNxR+g7zde1wQ9oOylB/JvLnuvJ5EXMM1Bd14o9f9/ImUZQucx UweS8Kv9UOZUTuzAkgY+RoUliBwsX8yDa1jofk5vdD8pNp2JT/IZ7ejAO/GBo33p Lj3f6YuFnqgpxkSJuNUhL2MpAm7OrwqJVtLv766Xp6f9LUwibiX4zGBcOH/RNxho lmEukgTmwKHmmjrgdAl9c6ujTdbAkz/qGAbo+/2t8pRfv4Gm7mZMonC1x7F18hU= =2CtA -----END PGP SIGNATURE----- --Apple-Mail=_4AF4BD3A-349A-4EFF-9B39-C429CB0E1CBC-- From andras@dns.net Thu Aug 22 03:59: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 D06B911E80F4 for ; Thu, 22 Aug 2013 03:59:56 -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 wrMlHuOIVHhZ for ; Thu, 22 Aug 2013 03:59:51 -0700 (PDT) Received: from server2.gaon.net (server2.gaon.net [46.4.121.115]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8FC11E81A4 for ; Thu, 22 Aug 2013 03:59:45 -0700 (PDT) Received: from server2.gaon.net (localhost [127.0.0.1]) by server2.gaon.net (8.14.3/8.14.3) with ESMTP id r7MAxix3011136; Thu, 22 Aug 2013 10:59:44 GMT Received: (from asalamon@localhost) by server2.gaon.net (8.14.3/8.14.3/Submit 0.2) id r7MAxiM3011135; Thu, 22 Aug 2013 10:59:44 GMT Date: Thu, 22 Aug 2013 12:01:18 +0100 From: Andras Salamon To: dnsext@ietf.org Message-ID: <20130822110118.GA34037@gaon.net> References: <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <8D23D4052ABE7A4490E77B1A012B63077525DCC4@mbx-01.win.nominum.com> <20130820211521.GC23740@mx1.yitter.info> <879DC3CA-7F24-44A3-A13A-D9BF90FD2222@virtualized.org> <765AE933-D9A8-4106-A110-F1B296D74D09@nzrs.net.nz> <1A3F153D-7BA5-4DD1-BB5D-F8B6C4A83B5E@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: <1A3F153D-7BA5-4DD1-BB5D-F8B6C4A83B5E@virtualized.org> Sender: andras@gaon.net Subject: Re: [dnsext] Deprecating SPF 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, 22 Aug 2013 10:59:57 -0000 On Tue, Aug 20, 2013 at 08:28:59PM -0700, David Conrad wrote: >Based on the fact Microsoft doesn't support unknown RR types after a decade (3 years longer than SPF RRs), I gather we should deprecate unknown RRs... :) Arguing that SPF (and other "unknown") records should be deprecated is pushing in the wrong direction, as drc indicates via sarcasm, assuming that the IETF is meant to have any prescriptive role at all. The right thing seems to be to write an RFC mandating that every DNS server connected to the public Internet MUST accept unknown RR types, and that every system that feeds data into DNS servers SHOULD accept unknown RR types gracefully. Then to push for this RFC to become a Standard. Then to push for RFPs to mandate conformance with the RFC. I've watched several vendors through incompetence and/or deliberate design try to kill DNS in favour of their own directory service "solutions" for twenty years. They have not yet succeeded. So there seems no reason those who think DNS is a net win should sit back and let them do it. (Those who think DNS is a dead loss, or that the IETF should simply describe what vendors have cooked up and are trying to hawk, should just ignore all this.) -- Andras Salamon andras@dns.net From johnl@iecc.com Thu Aug 22 10:55: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 40D6911E8100 for ; Thu, 22 Aug 2013 10:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.679 X-Spam-Level: X-Spam-Status: No, score=-102.679 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 hyQxYBf1bWk4 for ; Thu, 22 Aug 2013 10:55:28 -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 CB03221F9F34 for ; Thu, 22 Aug 2013 10:55:27 -0700 (PDT) Received: (qmail 13221 invoked from network); 22 Aug 2013 17:55:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Aug 2013 17:55:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52165088.xn--30v786c.k1308; i=johnl@user.iecc.com; bh=wHiPIaeZQaESjjpmTitRR8ptX3+yI1LnMH4HzFMuy3A=; b=ognZHDvGzXBJhTUfrtD5yl6ijINLlQlPmUREp0siDKspjAVxkLlK8bzZi/GJsn+Efh1u3ELGus0Q5a/vinH5yJL51I7F/r1Bs57zGE19GH2+MOF3PzkfVfSKSJSHLdANjY4Hs7OMXfb9sjWaMsGAMKW+XgufBz8PSqUehO3b3Y4LLQQYTGvVBvQb1LQODDFN3ppthcKo5QCt9zbQMJsr/nQkjpw0GmKdW5CSILJ7xk0TT1Bm2DMaj/sssgYFUqWs 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=52165088.xn--30v786c.k1308; olt=johnl@user.iecc.com; bh=wHiPIaeZQaESjjpmTitRR8ptX3+yI1LnMH4HzFMuy3A=; b=e3LlsnlqKbOJfsuaSHhQbgoHXlbb/6aQMHDLSVwxH7QiSCC/i3+2iQCF2XuLRBmrBb7BP2FObmCFsWj/9Ci5EvCfu0a6/RpHWWc/dhxSbvKITDmdOGoz5n6McAgVcjWZgG2MpegyfZ/kLX7oXFah3rFzM2nIo26+cWMgkGORM0QfAylLmY8FpusaWGNwW6nCIKtrtU8GCDK1DKPkUS0WIdruhCE2Av3I9JlFrvAj6V3V40Wdt4Eex2hula/bmt+e Date: 22 Aug 2013 17:54:57 -0000 Message-ID: <20130822175457.5657.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20130822110118.GA34037@gaon.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] Deprecating SPF 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, 22 Aug 2013 17:55:33 -0000 >The right thing seems to be to write an RFC mandating that every DNS >server connected to the public Internet MUST accept unknown RR types, >and that every system that feeds data into DNS servers SHOULD accept >unknown RR types gracefully. Then to push for this RFC to become >a Standard. Then to push for RFPs to mandate conformance with the RFC. How would this RFC differ from RFC 3597? R's, John From johnl@iecc.com Thu Aug 22 11:46:47 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 C907611E81CD for ; Thu, 22 Aug 2013 11:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 5Wmmag53-ONY for ; Thu, 22 Aug 2013 11:46:34 -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 9FDB511E80F8 for ; Thu, 22 Aug 2013 11:46:34 -0700 (PDT) Received: (qmail 27820 invoked from network); 22 Aug 2013 18:46:33 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Aug 2013 18:46:33 -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=52165c89.xn--30v786c.k1308; i=johnl@user.iecc.com; bh=nrZKIgwUjQc62ypOaP2UY2a43EURqJHPya4ycko8gQk=; b=lq6KVSk+hCoUpGU0uRco2V9xc8ELHIBUEfeMsfOrA4VYXnhCdAfedaGmyDnMlSZJasq/t/vu1wKblj40kxwjxa2A+06pz+lpLy07wB8FIwJrVE9JMiUL44asRTybFeGd4kUj6ma+EVQT1wyLrZw2Yg5471xZatBEqVkYm+aKz5qqU4grGsm9/HhaCOCJFuRqgrrZfj4wK08VVT5nE4CLDErO/CNs3A47aiuEVeRyfZ3heJz0eka/euCX1Dzzcu30 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=52165c89.xn--30v786c.k1308; olt=johnl@user.iecc.com; bh=nrZKIgwUjQc62ypOaP2UY2a43EURqJHPya4ycko8gQk=; b=DdT59BmsEQBw2nkJKlJ5VDNryAi/M9k2IV8boLhWXyUHIx9oXC+QI7+qd7qEb+XfK6rC6xhEoNk2oChFbIsTb62NyMpcay8VlfC0Bj3ndoAeji/EoYAKAnsd5fXdHykgL/PBB3p5B1C7eJYrgASCkAk2qgrB5GmhzpRm2WoNi/ap+klujP2h/7PC2UM+O3J5kETO+d9HbKoKZ6gENcocTLLoOXE320QciVrWym3jKYwOfXwiDSPpXeut0KbUh0AM Date: 22 Aug 2013 18:46:10 -0000 Message-ID: <20130822184610.2640.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20130819222037.GA55876@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] Deprecating SPF 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, 22 Aug 2013 18:46:48 -0000 This analysis sums up the situation pretty well: http://dnsreactions.tumblr.com/post/58998841753/spf-txt-vs-type-99-thanks-tjeb R's, John From hallam@gmail.com Thu Aug 22 12:14: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 7E8AA21F9E48 for ; Thu, 22 Aug 2013 12:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 q-aMS6pbLBhj for ; Thu, 22 Aug 2013 12:14:35 -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 3C2CB21F9D65 for ; Thu, 22 Aug 2013 12:14:35 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id c11so2016090wgh.20 for ; Thu, 22 Aug 2013 12:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2L0of5JDPczrFVUKhBWpSqbbY21ib5v0vo654Izu6bA=; b=XIsEdlUZoEezrDiM3ShsQ6wkWAgfBnoKpRB//wUj6CUGF1QFsaF9Kzin17y5NQwkhx RFcHvRf7SAO5slrkLhm7H1/dWSN1B8Vv0goGVFyY9DFrwXkyXNFnRlPcGmRhn5BZg0X5 IpPUN4Rk41HV+HirbiKd2lIpV51aMfQx6K9tp+d8o5jbZiO9tSefo00uzTrCpNWMtoIG AlSyCU5SCUAFh3fv7EIumGq0v7ibIvzTiHl8EQi2BxsQ3TMxXx+ibgaf2RK+vqfjNrSx tf3htX6HJ+FCBvZHfL9PH0xEZQWQmX9/Snv107CyGhexlmuhJWpxDneRRD5rClNWJ7pp KTGg== MIME-Version: 1.0 X-Received: by 10.180.72.47 with SMTP id a15mr11017270wiv.63.1377198874449; Thu, 22 Aug 2013 12:14:34 -0700 (PDT) Received: by 10.194.6.67 with HTTP; Thu, 22 Aug 2013 12:14:33 -0700 (PDT) In-Reply-To: <20130822184610.2640.qmail@joyce.lan> References: <20130819222037.GA55876@mx1.yitter.info> <20130822184610.2640.qmail@joyce.lan> Date: Thu, 22 Aug 2013 20:14:33 +0100 Message-ID: From: Phillip Hallam-Baker To: John Levine Content-Type: multipart/alternative; boundary=001a11c2567cb25c5704e48e1931 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Deprecating SPF 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, 22 Aug 2013 19:14:36 -0000 --001a11c2567cb25c5704e48e1931 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 22, 2013 at 7:46 PM, John Levine wrote: > This analysis sums up the situation pretty well: > > > http://dnsreactions.tumblr.com/post/58998841753/spf-txt-vs-type-99-thanks-tjeb > > Or this http://en.wikipedia.org/wiki/Cnut_the_Great#Ruler_of_the_waves Henry of Huntingdon , the 12th-century chronicler, tells how Cnut set his throne by the sea shore and commanded the tide to halt and not wet his feet and robes. Yet "continuing to rise as usual [the tide] dashed over his feet and legs without respect to his royal person. Then the king leapt backwards, saying: 'Let all men know how empty and worthless is the power of kings, for there is none worthy of the name, but He whom heaven, earth, and sea obey by eternal laws.' He then hung his gold crown on a crucifix, and never wore it again "to the honour of God the almighty King". The question at issue is whether the IETF is going to write specs that make people in the IETF feel good or specs that deployers trust as the best source of advice on how to configure their systems. There is a technical argument to be made for keeping SPF records but it is a small one. And the idea that there will be a transition from TXT is silly. One of the problems here is that folk in the DNSEXT group believed what they wanted to believe. When someone told them that the Windows DNS server did too support unknown records they believed it because they wanted to believe it. And so when Microsoft told them 'no it does not' they decided they must be lying. I was accused of lying when I mentioned the fact during the discussions of the SPF record. The way that the SPF record was imposed on the working group to placate the DNSEXT folk guaranteed that none of them would ever push for it being supported in practice. -- Website: http://hallambaker.com/ --001a11c2567cb25c5704e48e1931 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable





= On Thu, Aug 22, 2013 at 7:46 PM, John Levine <johnl@taugh.com> wrote:
This analysis sums up the situation pretty well:

http://dnsreactions.tumblr.com/post/58998= 841753/spf-txt-vs-type-99-thanks-tjeb


Or this


Henry of Huntingdon, the 12th-century chronicler,= tells how Cnut set his throne by the sea shore and commanded the tide to h= alt and not wet his feet and robes. Yet "continuing to rise as usual [= the tide] dashed over his feet and legs without respect to his royal person= . Then the king leapt backwards, saying: 'Let all men know how empty an= d worthless is the power of kings, for there is none worthy of the name, bu= t He whom heaven, earth, and sea obey by eternal laws.' He then hung hi= s gold crown on a=A0crucifix, and never wore it again "to the ho= nour of God the almighty King".

The question= at issue is whether the IETF is going to write specs that make people in t= he IETF feel good or specs that deployers trust as the best source of advic= e on how to configure their systems.

There is a technical argume= nt to be made for keeping SPF records but it is a small one. And the idea t= hat there will be a transition from TXT is silly.


One of the problems here is that folk in= the DNSEXT group believed what they wanted to believe. When someone told t= hem that the Windows DNS server did too support unknown records they believ= ed it because they wanted to believe it. And so when Microsoft told them &#= 39;no it does not' they decided they must be lying. I was accused of ly= ing when I mentioned the fact during the discussions of the SPF record.

The way that the SPF record was imposed on the working = group to placate the DNSEXT folk guaranteed that none of them would ever pu= sh for it being supported in practice.
=A0
--
Webs= ite: http://hallambaker.com/
--001a11c2567cb25c5704e48e1931-- From jay@nzrs.net.nz Thu Aug 22 12:38:59 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 99A4811E8218 for ; Thu, 22 Aug 2013 12:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 eZ69olxiiSnd for ; Thu, 22 Aug 2013 12:38:55 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6A621F9C91 for ; Thu, 22 Aug 2013 12:38:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 8B1CC4B6BED for ; Fri, 23 Aug 2013 07:38:52 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxywWZaPEgnA for ; Fri, 23 Aug 2013 07:38:45 +1200 (NZST) Received: from [192.168.43.229] (unknown [122.56.234.100]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 0A81D4B6BEA for ; Fri, 23 Aug 2013 07:38:44 +1200 (NZST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: Date: Fri, 23 Aug 2013 07:38:43 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <1B8AAF77-A4CA-4328-A110-DF7833CCDE92@nzrs.net.nz> References: <20130819222037.GA55876@mx1.yitter.info> <20130822184610.2640.qmail@joyce.lan> To: "dnsext@ietf.org Group" X-Mailer: Apple Mail (2.1508) Subject: Re: [dnsext] Deprecating SPF 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, 22 Aug 2013 19:38:59 -0000 > One of the problems here is that folk in the DNSEXT group believed = what they wanted to believe. When someone told them that the Windows DNS = server did too support unknown records they believed it because they = wanted to believe it. And so when Microsoft told them 'no it does not' = they decided they must be lying. I was accused of lying when I mentioned = the fact during the discussions of the SPF record. I'm now really confused about what Microsoft DNS does and doesn't = support. Does anyone have any up to date, genuine evidence to answer = the following questions: Does it support in the authoritative server: 1. Direct provisioning of unknown RR types via its own management = tools? 2. Direct provisioning via DDNS? 3. Indirect provisioning of unknown RR types (i.e. via AXFR/IXFR from = another server) Does it support in the caching server: 4. Resolution of unknown RR types? cheers Jay >=20 > The way that the SPF record was imposed on the working group to = placate the DNSEXT folk guaranteed that none of them would ever push for = it being supported in practice. > =20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From jay@nzrs.net.nz Thu Aug 22 13:15:27 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 4F83311E8200 for ; Thu, 22 Aug 2013 13:15: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=[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 TTRopB5XVopK for ; Thu, 22 Aug 2013 13:15:21 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 259EA11E81C5 for ; Thu, 22 Aug 2013 13:15:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 7FF434B6BF2; Fri, 23 Aug 2013 08:15:17 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U05Dddg1bgRw; Fri, 23 Aug 2013 08:15:10 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 3E8A44B6C01; Fri, 23 Aug 2013 08:15:10 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <20130821235201.GA3192@miek.nl> Date: Fri, 23 Aug 2013 08:15:12 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <4F1D903D-E10E-400B-AE6A-D40AF9B1855C@nzrs.net.nz> References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813033143.GA24608@miek.nl> <20130821235201.GA3192@miek.nl> To: Miek Gieben X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 22 Aug 2013 20:15:27 -0000 On 22/08/2013, at 11:52 AM, Miek Gieben wrote: > I just rememered how I "solved" this once. Just set a low(er) = expiration on > your zone. Who cares if a zone is still running on a server somewhat > longer? I am surprised that you would ask that. =20 We regularly get complaints from a registrant that they moved registrar = and shifted their website but customers of the old registrar still see = their old website. When the old registrar is one of the largest ISPs in = the country, this is a big problem. I am sure that many other = registries get the same complaints. I would not want to set a low enough expiry to make this a problem as = that then introduces a very high dependency on the uptime of the master. = It's unnecessary. Jay >=20 > grtz Miek --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From johnl@iecc.com Thu Aug 22 13:36:14 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 2D70011E818C for ; Thu, 22 Aug 2013 13:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.673 X-Spam-Level: X-Spam-Status: No, score=-102.673 tagged_above=-999 required=5 tests=[AWL=-0.074, 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 pO6kNphyyazX for ; Thu, 22 Aug 2013 13:36:09 -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 0B88D11E80FA for ; Thu, 22 Aug 2013 13:36:05 -0700 (PDT) Received: (qmail 57455 invoked from network); 22 Aug 2013 20:35:52 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Aug 2013 20:35:52 -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=52167627.xn--hew.k1308; i=johnl@user.iecc.com; bh=P2aoxoo0S/qVdX5orAaKPKheBF/hru9M3g5VkU33+jI=; b=MQvRRYFR2GYswLZ8Ri4rgLa9x0KhCJFi+Y1tx0iqg/VKpjvoHmqMEqJvvPpALGiqmdu2JCjaWDipKNC/ggG7vEWQsXZGxG8FXK9ei+9waomx76uhnMBBkUhi3OD12R2mWJbhYKULi7rrUyDroSOBOemiuNzqMd/4zMb/5vG2jYAwcR8aEAayMzUVRz2lqn7NF5ip2LpQRu3HAJUiHpn50T7QLUVssTWMcbDzYMEQ+ACYMxbZL7UFh2jFOpyDmkDi 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=52167627.xn--hew.k1308; olt=johnl@user.iecc.com; bh=P2aoxoo0S/qVdX5orAaKPKheBF/hru9M3g5VkU33+jI=; b=OzcQ3WJB9xKJBlXrAgkaQdxHdrPp01nk6fjzeEOcOfVlAYo2pSQJEc1+JfoV91aqq7O2x2fqxejDy2pyBFaOJtQDHSAHeW6F594CGmJ8CwmGJewgOuM1Y3y72YlrJ/akA5dhQxpd3YHLKnLJoHwigXlbRARNyEU4evsnDPc6wIPsxjC21Mflnuq06ZIqgA3u7gyEkQw1xonVWDf+vcATw+w7tplEzRraf8WkDWZr2sDhoi8G7KQQzbwDG9X+h6qt Date: 22 Aug 2013 20:35:29 -0000 Message-ID: <20130822203529.3173.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <1B8AAF77-A4CA-4328-A110-DF7833CCDE92@nzrs.net.nz> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] Microsoft software, was Deprecating SPF 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, 22 Aug 2013 20:36:14 -0000 >I'm now really confused about what Microsoft DNS does and doesn't support. Does anyone >have any up to date, genuine evidence to answer the following questions: If you think that's important, why don't you research it and see what you find? It's not germane to the SPF discussion, so there's no hurry. R's, John From miek@miek.nl Thu Aug 22 13:58:40 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 6112421F9F01 for ; Thu, 22 Aug 2013 13:58:40 -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 x3INEFCJ1N9r for ; Thu, 22 Aug 2013 13:58:35 -0700 (PDT) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0E19821F9D0E for ; Thu, 22 Aug 2013 13:58:34 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id l10so1169019eei.7 for ; Thu, 22 Aug 2013 13:58:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=Dfam5StTPd9vgVL0wASxZRet5lpOHXkc18QeISrwsPo=; b=Dr3wZeV6rna5k9jXXWqG5sI70xYdis0ukTwC7kMG+0nPaQonwDrIP4MxJc7dL3Wcue JbtgU3IhkOdW/2nC7nrfj0J64ldllOl54P8IIuPqTWV8VXIzyDUm5O4EKl0Pk9KL17iB /rq4qaUXTKvL9JCeHUsjdCVrWALZZ1lDDyU4cna1z9L1RLZIAiawnc6BHadm5JCZ2RuC 9ZhE7XCD83R6psH5qJNjSPze0dN3WDn19KLDoLnXy1HSnT1K3KtvZFOkMVi2cFnvKUPu cOrSyckQoDRYIv2bLhiTAdG7Dhm1BGwl8WXbt6xHK80VO/W4hn5WSTvqta/M2XNJWRv8 GWgQ== X-Gm-Message-State: ALoCoQkrbHt49mT9oYdTJI4lRBpEQwwHDTMb6xCpfhTs+FLm9fiRSisgtksvFYNWGvp9jggn/bX9 X-Received: by 10.15.22.69 with SMTP id e45mr6048717eeu.59.1377205112675; Thu, 22 Aug 2013 13:58:32 -0700 (PDT) Received: from miek.nl ([2a01:7e00::f03c:91ff:feae:e74c]) by mx.google.com with ESMTPSA id a6sm20041559eei.10.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 22 Aug 2013 13:58:31 -0700 (PDT) Date: Thu, 22 Aug 2013 20:58:30 +0000 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20130822205830.GA6348@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <7C847EDB-F833-4D0E-94B5-1C8C780D63E8@nzrs.net.nz> <20130813033143.GA24608@miek.nl> <20130821235201.GA3192@miek.nl> <4F1D903D-E10E-400B-AE6A-D40AF9B1855C@nzrs.net.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <4F1D903D-E10E-400B-AE6A-D40AF9B1855C@nzrs.net.nz> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] A new DNS message - SERVEZONES 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, 22 Aug 2013 20:58:40 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "Re: [dnsext] A new DNS message - SE..." ] > I am surprised that you would ask that. =20 >=20 > We regularly get complaints from a registrant that they moved registrar a= nd > shifted their website but customers of the old registrar still see their = old > website. When the old registrar is one of the largest ISPs in the country, > this is a big problem. I am sure that many other registries get the same > complaints. > > I would not want to set a low enough expiry to make this a problem as that > then introduces a very high dependency on the uptime of the master. It's > unnecessary. Ok, fair enough. The usecase for when I needed this was different. grtz Miek --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlIWe3YACgkQJYuFzziA0PYzWwCfbYRgHA2JM8G/0AWuFJUXvLFn +BgAn1SSd6vfECGR79LTi8J4Dd0fuDGa =Jv/E -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From sm@elandsys.com Thu Aug 22 13:59:58 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 9996B11E820D for ; Thu, 22 Aug 2013 13:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 mXPRPzn14RGs for ; Thu, 22 Aug 2013 13:59:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E449D21F9D0E for ; Thu, 22 Aug 2013 13:59:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.102]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7MKxShw026462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 13:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377205180; bh=PBdM+CXcJlOtUdveztpLwQCWv/SAq4WoJqx5pTSnpq8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=24QTTYrxTZFsdFQ2ElwZJssEIMwNSObZE1GPizUFfYWi2shM+Lxi3qsQzi1n9RR8I 21BwKkS2PLkxt9G6f+0LXtd6iwIDpehHaaodprljclDRLtXMqf+pe3ZCqJR5Q9Ns/q 7T04PkQ+JTRA2HlNpSN/+rGatjZfpdXBRAcYwogo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377205180; i=@elandsys.com; bh=PBdM+CXcJlOtUdveztpLwQCWv/SAq4WoJqx5pTSnpq8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GGHSIWz3a2pykAk4u49POrWubhUZIwOtwWTXXlnXEV4M3G98ZJIt1z2wkHRwqOdNv 0ICwbE+yvnAXNd/S9ErVxeoZzkGXx8TuGVDAoZMsEsnGYClUrwEd51k3t39+sN6NxE eMe1c/ZcFJIJwMeRJgqoc3IMVk1WytJqWG7tKXnI= Message-Id: <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Aug 2013 13:55:34 -0700 To: Alex Bligh From: S Moonesamy In-Reply-To: <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 22 Aug 2013 20:59:58 -0000 Hi Alex, At 16:18 21-08-2013, Alex Bligh wrote: >Genuine question: if a protocol is widely deployed, poorly >standardised, and poorly designed, does that mean it merits >RFC standards track? IE are standards track RFCs meant to >document what is out there and used, or should be out there >and used? That's a good question. I cannot comment on the answer. There was a comment from Patrik F=E4ltstr=F6m. It=20 was very insightful and it describes the issue=20 clearly. My guess is that Patrik F=E4ltstr=F6m was being nice. Regards, S. Moonesamy=20 From marka@isc.org Thu Aug 22 14:24: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 7840A11E8124; Thu, 22 Aug 2013 14:24:04 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, 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 XrHH6sO84jlI; Thu, 22 Aug 2013 14:23:59 -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 6359E11E812C; Thu, 22 Aug 2013 14:23:59 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id A47D3C9493; Thu, 22 Aug 2013 21:23:40 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377206633; bh=6KKfpPBjhSaiOPRkYIxPTo7dJTBcBL3q9H2GzwTmq7U=; h=To:Cc:cc:From:References:Subject:In-reply-to:Date; b=R0Q5ByvjfsPkFFJMTk+C2bOFbRsJyJ9fMoTIS+2Gl8fY2Y449sohxdsHeJpXuV0Ig v3bSYWlVgqIqURUGTGiqFdc0Mw0OB2nT8AhZk5hV3NJtJFvdfb/RvXaFH09j8Y3iiX CjxxJLpzoSmI5jZMGwhbqQhSNeLm2mYCZC+Mn/8g= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 22 Aug 2013 21:23:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BA1F31602E9; Thu, 22 Aug 2013 21:23:56 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8AC831602B4; Thu, 22 Aug 2013 21:23:56 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id B37A838CBDA2; Fri, 23 Aug 2013 07:23:37 +1000 (EST) To: Phillip Hallam-Baker From: Mark Andrews References: <20130819222037.GA55876@mx1.yitter.info> <20130822184610.2640.qmail@joyce.lan> In-reply-to: Your message of "Thu, 22 Aug 2013 20:14:33 +0100." Date: Fri, 23 Aug 2013 07:23:37 +1000 Message-Id: <20130822212337.B37A838CBDA2@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsext@ietf.org" , ietf@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 22 Aug 2013 21:24:04 -0000 Part of the question is whether the IETF is going to work with ICANN, IANA and the ccTLD to audit delegations for servers that are not RFC 103[45] compliant and suspend delegations where the servers are not compliant. * no responding to queries based on query type * not having a NS rrset at the delegation point Enforcing that ccTLD and ICANN TLD regularly audit delegations and have mismatches corrected. This is REQUIRED by RFC 1034 in part to stop the sorts of problems we are seeing today. We don't have to put up people putting up misconfigured / broken servers. For the non responding servers I have written draft-andrews-dns-no-response-issue to try to capture the issues. It was on the dnsop agenda for Berlin but didn't get covered as time ran out. I would like everyone to read it and comment on it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From andras@dns.net Thu Aug 22 15:13:47 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 0AC2B11E8122 for ; Thu, 22 Aug 2013 15:13:47 -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 APLrqEfmkxFs for ; Thu, 22 Aug 2013 15:13:42 -0700 (PDT) Received: from server2.gaon.net (server2.gaon.net [46.4.121.115]) by ietfa.amsl.com (Postfix) with ESMTP id B42E311E812B for ; Thu, 22 Aug 2013 15:13:40 -0700 (PDT) Received: from server2.gaon.net (localhost [127.0.0.1]) by server2.gaon.net (8.14.3/8.14.3) with ESMTP id r7MMDeth016171; Thu, 22 Aug 2013 22:13:40 GMT Received: (from asalamon@localhost) by server2.gaon.net (8.14.3/8.14.3/Submit 0.2) id r7MMDele016170; Thu, 22 Aug 2013 22:13:40 GMT Date: Thu, 22 Aug 2013 23:15:15 +0100 From: Andras Salamon To: dnsext@ietf.org Message-ID: <20130822221515.GA35645@gaon.net> References: <20130822110118.GA34037@gaon.net> <20130822175457.5657.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: <20130822175457.5657.qmail@joyce.lan> Sender: andras@gaon.net Subject: Re: [dnsext] Deprecating SPF 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, 22 Aug 2013 22:13:47 -0000 On Thu, Aug 22, 2013 at 05:54:57PM -0000, John Levine wrote: >>Then to push for this RFC to become >>a Standard. Then to push for RFPs to mandate conformance with the RFC. > >How would this RFC differ from RFC 3597? It would not: the problem is that we in the IETF seem to have stopped moving standards from Draft Standard through to Standard status. RFC 3597 has been in Proposed then Draft standard status since 2003. This may give RFP writers at various vendors useful wiggle room, but undercuts the usefulness of having standards in the first place for the majority of Internet users who are not beholden to the dynamics of enterprise procurement. It is clear that at least three implementations have achieved "widespread deployment" and conform to RFC 3597. Perhaps we could celebrate the tenth anniversary of RFC 3597 by trying to move it forward? Were the oft-raised concern that "SPF records will break some servers that are unable to handle unknown record types" to be pushed aside with "we can ignore those since they are not standards-compliant", then we could have a real discussion about the merits of SPF vs. TXT-for-SPF. Until then, not so much. -- Andras Salamon andras@dns.net From hallam@gmail.com Thu Aug 22 15:43: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 B2EFB11E8118 for ; Thu, 22 Aug 2013 15:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 u5R58jATWTCL for ; Thu, 22 Aug 2013 15:43:47 -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 9013B21F9991 for ; Thu, 22 Aug 2013 15:43:46 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q54so2305696wes.33 for ; Thu, 22 Aug 2013 15:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bBP2JzUmkvQ3phmYjGXO58/hDtY4dZGyEytVvGNUjZI=; b=SkPFg6lVNG5oeYsOYC290SzGWngjwvmmGmXED5N/Ppl5btClolU4i/xdPWDpsSQSFi s6ndQpuhVuLiWZdOWZu4WNeJ52TEW2wAI08hJYj2rE2T7ECAwLXl0JXtXKgFPH6mQf+y 2Rev7nK0cHaWfJZR2qRoNAPFxvmBbQYTHtE/ELwaeWCi/jlbjuYdNanvrM4ucQIGXIjT 6KNlRgveMEFZFWmReqCN2ZIiwOHIUlQ0qkAxqnf3694+Uq3FGp0RQhsWw7XgTm6gmsm1 JzITtcPj9+bFKMQXhUgPnNrozdSfiW6y/eYwSSF4zQ4TVj2tUoF0byg0+Svk2af0g7Db FROQ== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr11490944wic.33.1377211425681; Thu, 22 Aug 2013 15:43:45 -0700 (PDT) Received: by 10.194.6.67 with HTTP; Thu, 22 Aug 2013 15:43:45 -0700 (PDT) In-Reply-To: <1B8AAF77-A4CA-4328-A110-DF7833CCDE92@nzrs.net.nz> References: <20130819222037.GA55876@mx1.yitter.info> <20130822184610.2640.qmail@joyce.lan> <1B8AAF77-A4CA-4328-A110-DF7833CCDE92@nzrs.net.nz> Date: Thu, 22 Aug 2013 18:43:45 -0400 Message-ID: From: Phillip Hallam-Baker To: Jay Daley Content-Type: multipart/alternative; boundary=001a11c3844ccefca104e4910555 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 22 Aug 2013 22:43:48 -0000 --001a11c3844ccefca104e4910555 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 22, 2013 at 3:38 PM, Jay Daley wrote: > > > One of the problems here is that folk in the DNSEXT group believed what > they wanted to believe. When someone told them that the Windows DNS server > did too support unknown records they believed it because they wanted to > believe it. And so when Microsoft told them 'no it does not' they decided > they must be lying. I was accused of lying when I mentioned the fact during > the discussions of the SPF record. > > I'm now really confused about what Microsoft DNS does and doesn't > support. Does anyone have any up to date, genuine evidence to answer the > following questions: > > Does it support in the authoritative server: > Well the issue is what it did support during the SPF development and the insistence of some that it did things that the vendor swore it did not. > 1. Direct provisioning of unknown RR types via its own management tools? > Nope, not possible > 2. Direct provisioning via DDNS? > Nope > 3. Indirect provisioning of unknown RR types (i.e. via AXFR/IXFR from > another server) > Yes, but the config would be lost on a reboot as the server could not save out the unknown records in the zone file. > Does it support in the caching server: > > 4. Resolution of unknown RR types? > The server would behave properly but the config was not supported. > cheers > Jay > > > > > The way that the SPF record was imposed on the working group to placate > the DNSEXT folk guaranteed that none of them would ever push for it being > supported in practice. > > > > -- > > Website: http://hallambaker.com/ > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > > -- > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 > linkedin: www.linkedin.com/in/jaydaley > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --001a11c3844ccefca104e4910555 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 22, 2013 at 3:38 PM, Jay Daley <jay@nzrs.net.nz><= /span> wrote:

> One of the problems here is that folk in the DNSEXT group believed wha= t they wanted to believe. When someone told them that the Windows DNS serve= r did too support unknown records they believed it because they wanted to b= elieve it. And so when Microsoft told them 'no it does not' they de= cided they must be lying. I was accused of lying when I mentioned the fact = during the discussions of the SPF record.

I'm now really confused about what =A0Microsoft DNS does and does= n't support. =A0Does anyone have any up to date, genuine evidence to an= swer the following questions:

Does it support in the authoritative server:

Well the issue is what it did support during the SPF development and = the insistence of some that it did things that the vendor swore it did not.=

=A0
1. =A0Direct provisioning of unknown RR types via its own management tools?=

Nope, not possible

=A0
2. =A0Direct provisioning via DDNS?

Nop= e

=A0
3. =A0Indirect provisioning of unknown RR types (i.e. via AXFR/IXFR from an= other server)

Yes, but the config would= be lost on a reboot as the server could not save out the unknown records i= n the zone file.

=A0
Does it support in the caching server:

4. =A0Resolution of unknown RR types?

T= he server would behave properly but the config was not supported.


=A0
cheers
Jay

>
> The way that the SPF record was imposed on the working group to placat= e the DNSEXT folk guaranteed that none of them would ever push for it being= supported in practice.
>
> --
> Website: http://= hallambaker.com/
> _______________________________________= ________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext


--
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 93= 1 6977
mobile: +64 21 67= 8840
linkedin: www.linkedin.com/in/jaydaley

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



--
= Website: http://hallambaker.com/
--001a11c3844ccefca104e4910555-- From marka@isc.org Thu Aug 22 15:54:00 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 06AE811E822C for ; Thu, 22 Aug 2013 15:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 6Qi-Eochml9V for ; Thu, 22 Aug 2013 15:53:55 -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 B39ED11E8169 for ; Thu, 22 Aug 2013 15:53:55 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B1E4CC9484; Thu, 22 Aug 2013 22:53:42 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377212035; bh=OqGAdJ0Kqog5urZA/XeTdJ6QbG6c22fyqw3jK1yPt94=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=laBbHu0F1dE8g4i4+LVxKJHK47YOlOmCU0ANaTBzOS4/ARq+mHVOe/cSKgPadz6Xz 38Hh0vzbcWQ22pdeZSHK+AsuWsaec+pehHnq7MXAZlPk+EzQSov0TVq0IpDOek9xsV ZldtzGrwYZcBseD+QvB14cE83Q+hq/b9GvWP4S4k= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 22 Aug 2013 22:53:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 187231602E9; Thu, 22 Aug 2013 22:53:59 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id DE40B1602B4; Thu, 22 Aug 2013 22:53:58 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7991238CC331; Fri, 23 Aug 2013 08:53:40 +1000 (EST) To: Andras Salamon From: Mark Andrews References: <20130822110118.GA34037@gaon.net> <20130822175457.5657.qmail@joyce.lan> <20130822221515.GA35645@gaon.net> In-reply-to: Your message of "Thu, 22 Aug 2013 23:15:15 +0100." <20130822221515.GA35645@gaon.net> Date: Fri, 23 Aug 2013 08:53:40 +1000 Message-Id: <20130822225340.7991238CC331@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] Deprecating SPF 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, 22 Aug 2013 22:54:00 -0000 In message <20130822221515.GA35645@gaon.net>, Andras Salamon writes: > On Thu, Aug 22, 2013 at 05:54:57PM -0000, John Levine wrote: > >>Then to push for this RFC to become > >>a Standard. Then to push for RFPs to mandate conformance with the RFC. > > > >How would this RFC differ from RFC 3597? > > It would not: the problem is that we in the IETF seem to have stopped > moving standards from Draft Standard through to Standard status. > RFC 3597 has been in Proposed then Draft standard status since 2003. > This may give RFP writers at various vendors useful wiggle room, but > undercuts the usefulness of having standards in the first place for > the majority of Internet users who are not beholden to the dynamics > of enterprise procurement. > > It is clear that at least three implementations have achieved > "widespread deployment" and conform to RFC 3597. Perhaps we could > celebrate the tenth anniversary of RFC 3597 by trying to move it > forward? > > Were the oft-raised concern that "SPF records will break some servers > that are unable to handle unknown record types" to be pushed aside with > "we can ignore those since they are not standards-compliant", then we > could have a real discussion about the merits of SPF vs. TXT-for-SPF. > Until then, not so much. Nameservers that refuse to answer SPF queries are NOT STANDARDS COMPLIANT. Yes, that is FULL STANDARD. Resolvers that don't support arbitary query types are NOT STANDARDS COMPLIANT. RFC 1034 3. General lookup function This function retrieves arbitrary information from the DNS, and has no counterpart in previous systems. The caller supplies a QNAME, QTYPE, and QCLASS, and wants all of the matching RRs. This function will often use the DNS format for all RR data instead of the local host's, and returns all RR content (e.g., TTL) instead of a processed form with local quoting conventions. > -- Andras Salamon andras@dns.net > _______________________________________________ > 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 johnl@iecc.com Thu Aug 22 16:54: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 E232011E8278 for ; Thu, 22 Aug 2013 16:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.668 X-Spam-Level: X-Spam-Status: No, score=-102.668 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 e+vdXpvdv2Pl for ; Thu, 22 Aug 2013 16:53:59 -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 195DF11E8271 for ; Thu, 22 Aug 2013 16:53:58 -0700 (PDT) Received: (qmail 3921 invoked from network); 22 Aug 2013 23:53:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Aug 2013 23:53:51 -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=5216a48f.xn--9vv.k1308; i=johnl@user.iecc.com; bh=SPeb0UBTvGJ+wRd2eZZR8pvQWp1GTE8HflF3LFdFpxE=; b=AAKnzRPlBSyXLt5TErXIwnDcoxT1ISyukwNGT4qzQHEHGW5GwrvdTDLnt6DLvenBf24MpG0PaqeDdjztfI/VsmVt8pXf4k9Dej7jMJfLivbzm8jdaR2lsgRbPLEanMRycd7vhoRihVFecZOEOSXr7VJXpEw1u4n7hSOLihg7PIclbj2vTkAbMpgYQdWTyny8gqm+C8iq4F+VePbUAqs0mjfObcwkDeMZnV01I7X3ZW5Yj23y6ezCgR9TQ71RGIws 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=5216a48f.xn--9vv.k1308; olt=johnl@user.iecc.com; bh=SPeb0UBTvGJ+wRd2eZZR8pvQWp1GTE8HflF3LFdFpxE=; b=hmL6bXAiwSUizE3iLckJ4UzWYERrBB2551D+eBSW2cyYDopTsH/CG6zv734AOaaiqfFOMaBJWykISTPjBPB6yD2dHW0GZxCqmNY10MQrpM3Z6OiqA9Q3yg47tpMXwDj8vcVUseI8o/REjpYuamq+bSXWJP/bbDHtmIW50NUXnjOc0Cx6phSVJzo/odGclGzatxGdh9VONHYt+uncohEilAwNdtlykoqTHOo827fNvFpV+9qlVidhZ8Osjc6vCOD3 Date: 22 Aug 2013 23:53:29 -0000 Message-ID: <20130822235329.3752.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20130822221515.GA35645@gaon.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] full standards, Deprecating SPF 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, 22 Aug 2013 23:54:06 -0000 >>How would this RFC differ from RFC 3597? > >It would not: the problem is that we in the IETF seem to have stopped >moving standards from Draft Standard through to Standard status. >RFC 3597 has been in Proposed then Draft standard status since 2003. If you think it's important to move it to full standard, why don't you do somthing about it? A quick look suggests that 3597 meets the requirements in sec 2.2 of RFC 6410 I wouldn't think that it'd be hard to persuade someone on the IESG to sponsor the required last call. R's, John PS: On the other hand, I wouldn't expect it to make much practical difference. In the outside world, most people can't tell a full standard RFC from and April 1. From bmanning@karoshi.com Thu Aug 22 19:27:51 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 5F5C821F9CD1 for ; Thu, 22 Aug 2013 19:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 va92RZSj7bqe for ; Thu, 22 Aug 2013 19:27:47 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCF921F9AD2 for ; Thu, 22 Aug 2013 19:27:47 -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 r7N2QJdr023733; Fri, 23 Aug 2013 02:26:19 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r7N2QG2R023729; Fri, 23 Aug 2013 02:26:16 GMT Date: Fri, 23 Aug 2013 02:26:11 +0000 From: bmanning@vacation.karoshi.com To: S Moonesamy Message-ID: <20130823022611.GA23695@vacation.karoshi.com.> References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> User-Agent: Mutt/1.4.1i Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 02:27:51 -0000 having been in the pond for a few years, I'd suggest that it is reasonable to document existing practice. It is also prudent to pick the best technical choice. The use of multiplexing/overloading is known to be problematic. I would not depricate the SPF RR. I would make the claim that both 16 and 99 RRtypes are used for the purpose for which RRtype 99 was designed. Absent data on rates of adoption, I'd postpone the LC for a period of time to collect a second set of data points (besides the ones PAF and DRC have published in the last week) I'd suggest that SPF data MUST (in the RFC 2026 sense) be prefered in publication and SPF data encoding in TXT records MAY (in the RFC 2026 sense) be included. E.G. RRtype 99 is mandatory to implement for compliant servers. The technical arguemnts for unique RRtypes are small but real. /bill On Thu, Aug 22, 2013 at 01:55:34PM -0700, S Moonesamy wrote: > Hi Alex, > At 16:18 21-08-2013, Alex Bligh wrote: > >Genuine question: if a protocol is widely deployed, poorly > >standardised, and poorly designed, does that mean it merits > >RFC standards track? IE are standards track RFCs meant to > >document what is out there and used, or should be out there > >and used? > > That's a good question. I cannot comment on the answer. > > There was a comment from Patrik Fdltstrvm. It > was very insightful and it describes the issue > clearly. My guess is that Patrik Fdltstrvm was being nice. > > Regards, > S. Moonesamy > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From sm@elandsys.com Thu Aug 22 23:06:14 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 8CA9011E8233 for ; Thu, 22 Aug 2013 23:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 6LoMGyk-LXvG for ; Thu, 22 Aug 2013 23:05:59 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6640011E81C6 for ; Thu, 22 Aug 2013 23:05:58 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.74]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7N65VYH004438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 23:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377237944; bh=8SCrMdJi1CTDkhmXZHq/EGRRTGK81qmT14lmXzp/eis=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W10QIW23+LRLBel2881OZQuJu83kGyo106gthgz4A+PWoYokIA+snJBPswGFQISM4 1oRakjd6L84PQFZANtN/cWxgHxNfJwDzYbNmbwOMCYzBqKnDaX9NeNWepoWBfMcFYG lYvGAtmbbm8IVzBChYq663hePKq7gYPdNF6GOZdc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377237944; i=@elandsys.com; bh=8SCrMdJi1CTDkhmXZHq/EGRRTGK81qmT14lmXzp/eis=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QBu0Fj9Z7NuXCH8GUexoiyy5cH+7La6a3VAarhi8m4/gRagYJy9BI+3gHh2iIhly9 l1qrxy7+nWM8wcH1bRxdy6J2H7wOeGe+qCGFOCUTVUnOvQ0Tb0LApEnV2wUqc6Rgev nR7A/2fRQqDSVfABobwVjtxSn9ZSjI/SNKhDL1Q0= Message-Id: <6.2.5.6.2.20130822214838.0cc97ad8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Aug 2013 23:04:43 -0700 To: bmanning@vacation.karoshi.com From: S Moonesamy In-Reply-To: <20130823022611.GA23695@vacation.karoshi.com.> References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 06:06:15 -0000 Hi Bill, At 19:26 22-08-2013, bmanning@vacation.karoshi.com wrote: >having been in the pond for a few years, I'd suggest that >it is reasonable to document existing practice. It is also >prudent to pick the best technical choice. The use of >multiplexing/overloading is known to be problematic. > >I would not depricate the SPF RR. I would make the claim that >both 16 and 99 RRtypes are used for the purpose for which RRtype >99 was designed. Absent data on rates of adoption, I'd postpone >the LC for a period of time to collect a second set of data points >(besides the ones PAF and DRC have published in the last week) > >I'd suggest that SPF data MUST (in the RFC 2026 sense) be prefered > in publication and SPF data encoding in TXT records MAY (in the > RFC 2026 sense) >be included. E.G. RRtype 99 is mandatory to implement for compliant >servers. The technical arguemnts for unique RRtypes are small but real. I'll mention: http://www.ietf.org/mail-archive/web/spfbis/current/msg01662.html http://www.ietf.org/mail-archive/web/spfbis/current/msg01904.html And I'll quote Andrew ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01948.html ): "If I put my hat on for a moment, either SM or I would have to shepherd this document. We would have to explain to the IESG that, yes, our charter said we wouldn't remove any features we knew to be in use, and yes, we had evidence that these features were sometimes, only rarely, in use by some people; but we decided to ditch them anyway, because we didn't care about those uses and thought they were dumb and decided not to count those people because there were too few of them. As a simple process matter, that's a problem." I need a good explanation to be able to ask the Responsible Area Director to suspend the Last Call. I have to take into account that the explanation can be challenged and that will cause process issues. I suggest that you make a formal request. I can treat the message at http://www.ietf.org/mail-archive/web/dnsext/current/msg13339.html as a formal request if you wish. Please note that I am not ignoring your comment. Regards, S. Moonesamy From alex@alex.org.uk Thu Aug 22 23:25:58 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 21D4511E82C5 for ; Thu, 22 Aug 2013 23:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, 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 YB5SttEeHbTb for ; Thu, 22 Aug 2013 23:25:57 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBDB11E8243 for ; Thu, 22 Aug 2013 23:25:56 -0700 (PDT) Received: by mail.avalus.com (Postfix) with ESMTPSA id C1106C560C6; Fri, 23 Aug 2013 07:25:43 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Alex Bligh In-Reply-To: <6.2.5.6.2.20130822214838.0cc97ad8@elandnews.com> Date: Fri, 23 Aug 2013 07:25:43 +0100 Content-Transfer-Encoding: 7bit Message-Id: <526B25C7-988D-4A84-AC8E-09D9D01A84AB@alex.org.uk> References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <6.2.5.6.2.20130822214838.0cc97ad8@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1085) Cc: bmanning@vacation.karoshi.com, dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 06:25:58 -0000 On 23 Aug 2013, at 07:04, S Moonesamy wrote: > "If I put my hat on for a moment, either SM or I would have to shepherd > this document. We would have to explain to the IESG that, yes, our > charter said we wouldn't remove any features we knew to be in use, and > yes, we had evidence that these features were sometimes, only rarely, > in use by some people; but we decided to ditch them anyway, because we > didn't care about those uses and thought they were dumb and decided > not to count those people because there were too few of them. As a > simple process matter, that's a problem." This makes little sense to me. Deprecating SPF is removing a feature we know to be in use (perhaps less than TXT, but still in use). Are you saying that a draft that deprecated overloading of TXT would be out of scope because people are doing it? How would this be different from a draft that pointed out other 'bad' things you should not do with existing records (we've had plenty of those) even when those things have been found in the wild? -- Alex Bligh From sm@elandsys.com Thu Aug 22 23:54:32 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 9606411E82C9 for ; Thu, 22 Aug 2013 23:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 9JJXZKAbE0W7 for ; Thu, 22 Aug 2013 23:54:27 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C98511E8236 for ; Thu, 22 Aug 2013 23:54:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.74]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7N6rstn022071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 23:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377240849; bh=nuopw0P9ZwWwfci8hlhW3wFxpnmH0owvpVc8ToMeQhA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PeRJ1Kr+BxrHEXBqi3CbNd8SkGCKy9orwMJ3AzUnL0II0MEZQdG0kw/pML/2yJqDy em/yulD0/fXOnxq0DojBC0MnssjzMjSYtsxB5G1zaX6fMowdsUIEjshS0L2yCJkiOq FA5D2TxNnTf4DxFEpwFpqvM1bYqiHNeF5U/owCjc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377240849; i=@elandsys.com; bh=nuopw0P9ZwWwfci8hlhW3wFxpnmH0owvpVc8ToMeQhA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2XYFsUfjqqQbSt1AJaJpE4/cG27wZJEFRpckhho+bJ9WkBNL1eMZAEpJGtw/45/4H goEpoEEJDd4nYRdD0uh8XZqCM1h7BZXf8IIdHe3MDOfgD9WuymJpWV+Pr51rWwhvcY JKfVFBvPXmVNRsXn6EXNdqxZCHX3qrPe8MKBmbuQ= Message-Id: <6.2.5.6.2.20130822232903.0cc7cee8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Aug 2013 23:52:19 -0700 To: Alex Bligh From: S Moonesamy In-Reply-To: <526B25C7-988D-4A84-AC8E-09D9D01A84AB@alex.org.uk> References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <6.2.5.6.2.20130822214838.0cc97ad8@elandnews.com> <526B25C7-988D-4A84-AC8E-09D9D01A84AB@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: bmanning@vacation.karoshi.com, dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 06:54:32 -0000 Hi Alex, At 23:25 22-08-2013, Alex Bligh wrote: >This makes little sense to me. > >Deprecating SPF is removing a feature we know to be in use (perhaps >less than TXT, but still in use). > >Are you saying that a draft that deprecated overloading of TXT >would be out of scope because people are doing it? How would this >be different from a draft that pointed out other 'bad' things >you should not do with existing records (we've had plenty of those) >even when those things have been found in the wild? I was explaining it would be a process problem if every comment is not carefully considered. For example, if you are the only person making an argument, I cannot ignore it; I cannot give it less weight than the arguments being made by a significant number of persons. The answers to the above questions is a matter of opinion. I have not formed an opinion as it would then be difficult for me to try and figure out what to suggest to address the issues which have been raised. Regards, S. Moonesamy From mansaxel@besserwisser.org Fri Aug 23 00:56: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 6CD2B1F0EDD for ; Fri, 23 Aug 2013 00:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.111, 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 Wl6HwHzbMi52 for ; Fri, 23 Aug 2013 00:56:16 -0700 (PDT) Received: from jaja.besserwisser.org (jaja.besserwisser.org [IPv6:2a01:298:4:0:211:43ff:fe36:1299]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC261F0EDE for ; Fri, 23 Aug 2013 00:56:16 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 485CE9E98; Fri, 23 Aug 2013 09:56:12 +0200 (CEST) Date: Fri, 23 Aug 2013 09:56:12 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: bmanning@vacation.karoshi.com Message-ID: <20130823075612.GA19081@besserwisser.org> References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <20130823022611.GA23695@vacation.karoshi.com.> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: S Moonesamy , dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 07:56:17 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF Date: = Fri, Aug 23, 2013 at 02:26:11AM +0000 Quoting bmanning@vacation.karoshi.com= (bmanning@vacation.karoshi.com): >=20 >=20 > having been in the pond for a few years, I'd suggest that > it is reasonable to document existing practice. It is also > prudent to pick the best technical choice. The use of=20 > multiplexing/overloading is known to be problematic. =20 >=20 > I would not depricate the SPF RR. I would make the claim that > both 16 and 99 RRtypes are used for the purpose for which RRtype > 99 was designed. Absent data on rates of adoption, I'd postpone > the LC for a period of time to collect a second set of data points > (besides the ones PAF and DRC have published in the last week) >=20 > I'd suggest that SPF data MUST (in the RFC 2026 sense) be prefered > in publication and SPF data encoding in TXT records MAY (in the RFC 2026= sense) > be included. E.G. RRtype 99 is mandatory to implement for compliant > servers. The technical arguemnts for unique RRtypes are small but real. ++; on bill above. Some logging and a grepish snapshot:=20 (background: I serve around 150 zones from my name server pair. This is query logs from my BIND master. Not much traffic, but a 45MiB log buffer, at least. Further, none of the nodes recurse; this is only resolvers looking at name servers.) $ ls -lh q* -rw-r--r-- 1 bind wheel 4.1M Aug 23 07:21 queries.log -rw-r--r-- 1 bind wheel 10M Aug 23 04:36 queries.log.0 -rw-r--r-- 1 bind wheel 10M Aug 22 20:22 queries.log.1 -rw-r--r-- 1 bind wheel 10M Aug 22 13:48 queries.log.2 -rw-r--r-- 1 bind wheel 10M Aug 22 06:11 queries.log.3 $ cat queries* | awk ' /TXT/ { txt++; };=20 /SPF/ {spf++; };=20 END { printf "TXT: %d\tSPF: %d\n",=20 txt,=20 spf; }' TXT: 2032 SPF: 396 The disclaimer of course is that all whining around my misunderstanding of the payload in SPF records has caused the entire IETF list membership to look up my SPF "records" to point fingers and laugh at them, thereby skewing the numbers. If I'm doing anything worng wrt counting the records above, please point it out and I'll try to rectify. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 It don't mean a THING if you ain't got that SWING!! --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlIXFZsACgkQ02/pMZDM1cUItACeLm5yiRXvVl1XHvYrGBJID51F KCcAoInY99IOb0ga/q1D7PeKglvey8tu =MDmb -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From Marco.Davids@sidn.nl Fri Aug 23 02:53: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 EDDF611E82C9 for ; Fri, 23 Aug 2013 02:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119] 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 tffH1cY6cX48 for ; Fri, 23 Aug 2013 02:53:29 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 96A2911E8169 for ; Fri, 23 Aug 2013 02:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:x-originating-ip; bh=E4m6k17Y/1mhpv1SNa5Wz6qv5v4R7iSJvKGM+A0mV7c=; b=hWfGyn+071bm+sSQj4LG2tLdYo0HxcVezUr4Xs1927DljlzPejG27wCr7OEVsOE0mWQU/sy5gqPI0mNrQ1GlQj+ut4CPERLzUF0xFodiYEGrqoMQmIPe1w18h+QDJc/6Ip4H6yoyWdUwYFYL5uxI4HeWy3G6JDGjtRcCuiZ7ZXI= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r7N9rNio031028-r7N9rNiq031028 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Fri, 23 Aug 2013 11:53:24 +0200 Received: from [94.198.152.217] (94.198.152.217) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 23 Aug 2013 11:53:23 +0200 Message-ID: <52173113.4000705@sidn.nl> Date: Fri, 23 Aug 2013 11:53:23 +0200 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <20130822235329.3752.qmail@joyce.lan> In-Reply-To: <20130822235329.3752.qmail@joyce.lan> X-Enigmail-Version: 1.5.2 OpenPGP: id=9F781B52 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060409080809000902000807" X-Originating-IP: [94.198.152.217] Subject: Re: [dnsext] full standards, Deprecating SPF 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, 23 Aug 2013 09:53:34 -0000 --------------ms060409080809000902000807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 08/23/13 01:53, John Levine wrote: >>> How would this RFC differ from RFC 3597? >> >> It would not: the problem is that we in the IETF seem to have stopped >> moving standards from Draft Standard through to Standard status. > If you think it's important to move it to full standard, why don't you > do somthing about it?=20 > PS: On the other hand, I wouldn't expect it to make much practical > difference. In the outside world, most people can't tell a full > standard RFC from and April 1. In my view, that says more about us, the IETF-community, than about the outside world. There work to be done here, for the IETF. -- Marco --------------ms060409080809000902000807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMZjCC BiowggUSoAMCAQICAwa6NTANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTEzMDUzMTExMDk0MloXDTE0MDYwMjAzMjc1NFowRDEdMBsGA1UE AwwUbWFyY28uZGF2aWRzQHNpZG4ubmwxIzAhBgkqhkiG9w0BCQEWFG1hcmNvLmRhdmlkc0Bz aWRuLm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyajTCa3uBAPAiQrrqCDe mzW5wvxaovW3h1/dCzfEuR/OZRYlgQg0dRsrGPMs+Wg2wwqPvvjsF/YQ2AeXxpzAIQVHywI5 zgZwptg0+Lv4UvFZFwHw5xdB2STvVIXFG7fuTyk5D0MkhhsO/MHjOmSucDzkH6CW/TgiBxkJ bSXIc+YOKZlI1E1q9V10rR2NW4VD27/AO71Va6sfA33qbY2MGvjR9UPB9bBjwsczeCulpNhE rIU7K4tWhgcd1DTUgz8P6pHw5bqRMzxfIQW3yHg5SnXjugCxLIfKBxIN7uXrqVmf0+haU3K/ tc6Wjl9JYjzXsdhempN1eRI3clyl6jS8YQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADALBgNV HQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRn3ugN 5hkGkJ5A8hb1D6n4GcsppTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HREEGDAWgRRtYXJjby5kYXZpZHNAc2lkbi5ubDCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYB BAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xp Y3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0 aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21w bGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcB AQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNz MS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBALqkjS+NnMxn/trjz71UHJEeiNJ7rbgNxk1+ RdhMw2TKiGocYa2Ql7TfCjgknCaakk7m54Spmr7AdbSVKVffmxQFzUaq5Or5HAMtqRfWJLh1 A94gOMPaRErdoRF0PLGPrwJPbxMAH4lTOIwpRqSVnUepG4pJKEBYFMXRWBW6nSs4/RJSscAP 70qoyX/MOPWFZjuxRU9d/gqQt4rNjf3Ojq+j3omI3oS/LgVUAyCdEsg7M0SEC5eG/kxLTCH9 bzY7A98/g55OENAsVQlP43GNr+hojOva9VDyeYQTktt0AtYheb29Za/Grw7cP9UAFzOdlsDA 5uL4TzfzDsk2BIwt2ZEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zP f1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG /FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSy rrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIB qTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUH AQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYB BQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCeg JaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBm MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqG SIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95 CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A +hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcL N5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/ O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI27 0g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z 77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/Q vVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8 BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGU MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwa6NTAJBgUrDgMCGgUAoIIC HTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA4MjMwOTUz MjNaMCMGCSqGSIb3DQEJBDEWBBR6oyNjSLRXqZEJzwsRA2XQwI/73TBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3 EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBro1MIGnBgsq hkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMG ujUwDQYJKoZIhvcNAQEBBQAEggEAnY6K3ItdjueUiIoePUaqdAHC4ezC/nlSGtOYZUr6woVj XG0b4/8DQI8C3jYq6Zyzeke7agjPPF6kZdq2ibEYiBMWoFGISeYZGvgcK7YlhlS+yOdqZh1W Ch1FrCkA7RaPMvz7ec3efC9l98S0H50yRYRiIiqWfl8OW36I0D1HGT4VTR/9NDnQnlDG8rap xI3iXM6+pCwNSoSx6XK1d/vcP+cje/0TRbUK00DepuSkCmGEDHXV9+jghnXe6AdszlF3xL0p B3wXnD+ahDrlgiD0gk6fIEyhtU71K3pQaJGr+K0J7xWenvU620iAW1o/ApEU8yWHfz9iheEm 7x7SEJ4/awAAAAAAAA== --------------ms060409080809000902000807-- From Jelte.Jansen@sidn.nl Fri Aug 23 06:18: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 BCFCA21F9CAC for ; Fri, 23 Aug 2013 06:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, 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 fe4dyyZMLXTo for ; Fri, 23 Aug 2013 06:17:59 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 8445621F9B9F for ; Fri, 23 Aug 2013 06:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=7jt23dG3SPniHSFBZfdM6leFN5uaTI/kYoAx4eXi5lQ=; b=ygZCVxWK0BTBPvaLTg9bXugN1Z5KhT9zKvL/FDnTlfinirPR2ghSvZJR9+0RKAA5Neyfsyy3ZNi7AbNba04IwcnIigsOMwokHKnGIlci3shH897+ah05VC9O6oOIFBr+Y4811kb8iLqbwa/BUYx77z4OGnx5B/VFG85yQngXfnA= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r7NDHock001729-r7NDHocm001729 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Fri, 23 Aug 2013 15:17:50 +0200 Received: from [94.198.152.214] (94.198.152.214) by kahubcasn02.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 23 Aug 2013 15:17:50 +0200 Message-ID: <521760FD.7090202@sidn.nl> Date: Fri, 23 Aug 2013 15:17:49 +0200 From: Jelte Jansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?ISO-8859-1?Q?M=E5ns_Nilsson?= References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <20130823075612.GA19081@besserwisser.org> In-Reply-To: <20130823075612.GA19081@besserwisser.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Originating-IP: [94.198.152.214] Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 13:18:03 -0000 On 08/23/2013 09:56 AM, Måns Nilsson wrote: > > $ cat queries* | awk ' /TXT/ { txt++; }; /SPF/ {spf++; }; END { > printf "TXT: %d\tSPF: %d\n", txt, spf; }' TXT: 2032 SPF: 396 > moar data: I have been monitoring one of our nameservers over the last 48 hours (disclaimers the usual: only looking at type, not qname, sender, or content, only looking at queries, this is above the cache, txt may be for other things as well, etc.), Queries for type=SPF: 899349 Queries for type=TXT: 2839482 Jelte From johnl@iecc.com Fri Aug 23 08:15: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 A288C11E81B8 for ; Fri, 23 Aug 2013 08:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.661 X-Spam-Level: X-Spam-Status: No, score=-102.661 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 1VMvZZcZPnhl for ; Fri, 23 Aug 2013 08:15:01 -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 0F7AF11E8115 for ; Fri, 23 Aug 2013 08:15:00 -0700 (PDT) Received: (qmail 8611 invoked from network); 23 Aug 2013 15:15:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Aug 2013 15:15:00 -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=52177c74.xn--30v786c.k1308; i=johnl@user.iecc.com; bh=vN5blVdWG4wUzK4aeelrEvdTCsdTzaV04pajsBnjWoo=; b=KcZ1sxYJ800ZSRtDQYERI7BSSeta25m3v84rg2SJLXytMSS9eV/RXCCbAfKDKP+bupzxe5Obwr68/cQOXJbFVvXMg1+V7qZlzOeuUduZIfasXo39jBIGiqFOnx85ZCefp2XpCbDDAOC7YZXIO2a7T5dsJ+5OH8b2s1nZSnEXadzJ18KHodBt6Dzo93H76Ecr8JlS4yVzB5MHO8TZr1FeIe3AxgTa3BsAfA/r2DQ+Qd2rKn65QArHjC4206iVumA4 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=52177c74.xn--30v786c.k1308; olt=johnl@user.iecc.com; bh=vN5blVdWG4wUzK4aeelrEvdTCsdTzaV04pajsBnjWoo=; b=mgkMqtTzA+P1QquFNEWIS3Yi99YLnXclNdnGy9R2C97BsyJ6znC9HMC7VRAXmnNpv8g/xSwjDXrrXYMH55yslEjMIqHGGcWDJKpLXQ2+cXcCh0AypYhfjWl7DijE1B/SY6JLGZ02AQWzMrc5V//Ph/P7b2DhSTiQULgue0I0inL918gFueA7/ECx5S3FnHvWUSrjuJLLovIjRxKkCM95tSLpGsrKDgUg8PKCs6TdqprXucQEZg8wXg4sxm6qjuMj Date: 23 Aug 2013 15:14:38 -0000 Message-ID: <20130823151438.50212.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20130823075612.GA19081@besserwisser.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 15:15:05 -0000 I counted my queries from a few days ago and got 7086 TXT, 263 SPF, or 3.7%. Nobody has argued that SPF usage is zero, and the reasons for deprecating SPF have been described repeatedly here and on the ietf list, so this exercise seems fairly pointless. R's, John From andras@dns.net Fri Aug 23 09:23: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 B33C311E8170 for ; Fri, 23 Aug 2013 09:23:47 -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 u6ziydSouQZQ for ; Fri, 23 Aug 2013 09:23:43 -0700 (PDT) Received: from server2.gaon.net (server2.gaon.net [46.4.121.115]) by ietfa.amsl.com (Postfix) with ESMTP id 543C011E8103 for ; Fri, 23 Aug 2013 09:23:39 -0700 (PDT) Received: from server2.gaon.net (localhost [127.0.0.1]) by server2.gaon.net (8.14.3/8.14.3) with ESMTP id r7NGNbHj022003; Fri, 23 Aug 2013 16:23:37 GMT Received: (from asalamon@localhost) by server2.gaon.net (8.14.3/8.14.3/Submit 0.2) id r7NGNbmR022002; Fri, 23 Aug 2013 16:23:37 GMT Date: Fri, 23 Aug 2013 17:25:14 +0100 From: Andras Salamon To: dnsext@ietf.org Message-ID: <20130823162514.GA38870@gaon.net> References: <20130822221515.GA35645@gaon.net> <20130822235329.3752.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130822235329.3752.qmail@joyce.lan> Sender: andras@gaon.net Subject: Re: [dnsext] full standards, Deprecating SPF 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, 23 Aug 2013 16:23:48 -0000 On Thu, Aug 22, 2013 at 11:53:29PM -0000, John Levine wrote: >If you think it's important to move it to full standard, why don't you >do somthing about it? A quick look suggests that 3597 meets the >requirements in sec 2.2 of RFC 6410 I wouldn't think that it'd be hard >to persuade someone on the IESG to sponsor the required last call. Ólafur Gudmundsson nominated RFC 3597 to advance from Proposed to Draft Standard in message <6.1.0.6.2.20040819092046.02d2dec0@localhost> of 19 Aug 2004. This was based on -00 of Jakob Schlyter's draft, of which the most recent version is from May 2005: http://tools.ietf.org/id/draft-ietf-dnsext-interop3597-02.txt Since Jakob already did an important part of the work, I would first like to understand what happened to the advancement request, especially in light of the two revisions of the interoperability report after the request. Does anyone have pointers? (I know that PS/DS were merged a couple of years ago, but would still like to understand how the PS->DS process went, and if it failed, why.) -- Andras Salamon andras@dns.net From hsantos@isdg.net Fri Aug 23 09:59:20 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 0A95711E81BF for ; Fri, 23 Aug 2013 09:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 ej81gHNezrRM for ; Fri, 23 Aug 2013 09:59:08 -0700 (PDT) Received: from mail.santronics.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id EE62F11E81B3 for ; Fri, 23 Aug 2013 09:59:07 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2488; t=1377277143; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=GEJLZwzb5r/6I6y0buXPCEY64bA=; b=Quuhoq3zheisFX5QOmdq ip4awYFbViOJuco7kthC/HUcY545JRxIoGabaXorOIINBBALbGgheoEz/zHI4wq1 aTiQXgPp4MoaiTkma3J2eymbzwcKORCTpAQ+8hmN3Hd/ON++s9QnmbFIQLBO1RLJ 7nMgCgit05G7P2D81P4iIzU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Fri, 23 Aug 2013 12:59:03 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3739656530.3203.3560; Fri, 23 Aug 2013 12:59:02 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2488; t=1377276830; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=/zNgHic lvCsbdVMvsFcZkwhD7yiATIaoFj77jZmPw84=; b=D9Z6TNOoRZtY+T+JEXiC+hf JCEqTsWafORZqzAEe0OFS+OqGEiMWscTXnRnfa5o3gQrRrimibls97hJs1uUMmFh ZWBvFvDnoK1OJbwlop9Kx0F6ZFSb0CyQtgcH4/7LD6TQqUMQvt5aaMmbMqRoxAlK kedSlkFsBENWBUWDE1zw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Fri, 23 Aug 2013 12:53:50 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3186077924.9.6440; Fri, 23 Aug 2013 12:53:49 -0400 Message-ID: <521794CE.7040002@isdg.net> Date: Fri, 23 Aug 2013 12:58:54 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andras Salamon References: <20130822221515.GA35645@gaon.net> <20130822235329.3752.qmail@joyce.lan> <20130823162514.GA38870@gaon.net> In-Reply-To: <20130823162514.GA38870@gaon.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: dnsext@ietf.org, IETF General Discussion Mailing List Subject: Re: [dnsext] full standards, Deprecating SPF 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, 23 Aug 2013 16:59:20 -0000 Andras Salamon wrote: > On Thu, Aug 22, 2013 at 11:53:29PM -0000, John Levine wrote: >> If you think it's important to move it to full standard, why don't you >> do somthing about it? A quick look suggests that 3597 meets the >> requirements in sec 2.2 of RFC 6410 I wouldn't think that it'd be hard >> to persuade someone on the IESG to sponsor the required last call. > > Ólafur Gudmundsson nominated RFC 3597 to advance from Proposed to > Draft Standard in message <6.1.0.6.2.20040819092046.02d2dec0@localhost> > of 19 Aug 2004. This was based on -00 of Jakob Schlyter's draft, > of which the most recent version is from May 2005: > http://tools.ietf.org/id/draft-ietf-dnsext-interop3597-02.txt > > Since Jakob already did an important part of the work, I would > first like to understand what happened to the advancement request, > especially in light of the two revisions of the interoperability > report after the request. Does anyone have pointers? > > (I know that PS/DS were merged a couple of years ago, but would still > like to understand how the PS->DS process went, and if it failed, why.) I appreciate this level of work to see why it fell through the cracks. I believe it is one of the IETF growing lack of diversity issues, i.e., improving electronic communications, collaborations and networking among industry peers. This should be a project leader(s) responsibility to make sure the basic technology requirements are realistic or not, i.e., consult and get input from the DNS industry vendors, make them aware and/or to find out why this has not happen yet. For example, why hasn't Microsoft supported RFC 3597 yet? You will be surprise that a well respected Microsoft DNS Expert and MVP (Most Valuable Player) was unaware of such needs, nor was his microsoft contacts and the MSDNS beta team based on a discussion with him: http://social.technet.microsoft.com/Forums/windowsserver/en-US/5841e884-db22-42a1-8530-615a375662cc/dns-server-support-for-new-or-unamed-rr-type-records This was back in March/April 2012. If Microsoft isn't going to bother to add direct support for the SPF type99 RR, nor support RFC 3597 at the very least, I believe this matter is decided and closed. TXT only is proper for SPFBIF and for future DNS applications as well. I am sure there are key IETF decision makers with Microsoft DNS product manager contacts who can find out whats going on to help resolve this LC issue. -- HLS From bmanning@karoshi.com Fri Aug 23 10:03: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 F299811E81EA for ; Fri, 23 Aug 2013 10:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 0fKlVskLjjYN for ; Fri, 23 Aug 2013 10:03:32 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id CA58511E81DA for ; Fri, 23 Aug 2013 10:03:32 -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 r7NH3Wdr027260; Fri, 23 Aug 2013 17:03:32 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r7NH3WT3027259; Fri, 23 Aug 2013 17:03:32 GMT Date: Fri, 23 Aug 2013 17:03:26 +0000 From: bmanning@vacation.karoshi.com To: John Levine Message-ID: <20130823170326.GA24644@vacation.karoshi.com.> References: <20130823075612.GA19081@besserwisser.org> <20130823151438.50212.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130823151438.50212.qmail@joyce.lan> User-Agent: Mutt/1.4.1i Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 17:03:37 -0000 On Fri, Aug 23, 2013 at 03:14:38PM -0000, John Levine wrote: > I counted my queries from a few days ago and got 7086 TXT, 263 SPF, or 3.7%. > > Nobody has argued that SPF usage is zero, and the reasons for > deprecating SPF have been described repeatedly here and on the ietf > list, so this exercise seems fairly pointless. the reasons for not deprecating SPF have been described here and on the ietf list repeatedly ... yet there has been little concrete data regarding deployment uptake. These published snapshots form a baseline - 201308, and it might be worthwhile to look again in six months to see if the magnitude and ratio have changed. The results of a second look should bring into focus the prevaling trends and solidify the argument. Surely there is no compelling urgency to conclude the current LC - given the duration of this work a six month period to gain emperical insight would not be a bad thing. Would it? /bill > > R's, > John > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From cet1@hermes.cam.ac.uk Fri Aug 23 13:16:32 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 5DBD711E819C for ; Fri, 23 Aug 2013 13:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 VrHvw49OPNuK for ; Fri, 23 Aug 2013 13:16:32 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f52]) by ietfa.amsl.com (Postfix) with ESMTP id D463C11E81F3 for ; Fri, 23 Aug 2013 13:16:31 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:42872) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:cet1) id 1VCxmX-0004Qg-EV (Exim 4.80_167-5a66dd3) (return-path ); Fri, 23 Aug 2013 21:16:29 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1VCxmX-00022V-Cw (Exim 4.72) (return-path ); Fri, 23 Aug 2013 21:16:29 +0100 Received: from [131.111.11.47] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 23 Aug 2013 21:16:29 +0100 Date: 23 Aug 2013 21:16:29 +0100 From: Chris Thompson To: Jelte Jansen Message-ID: In-Reply-To: <521760FD.7090202@sidn.nl> References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: Chris Thompson Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 20:16:32 -0000 On Aug 23 2013, Jelte Jansen wrote: >On 08/23/2013 09:56 AM, M=E5ns Nilsson wrote: >>=20 >> $ cat queries* | awk ' /TXT/ { txt++; }; /SPF/ {spf++; }; END { >> printf "TXT: %d\tSPF: %d\n", txt, spf; }' TXT: 2032 SPF: 396 >>=20 > >moar data: > >I have been monitoring one of our nameservers over the last 48 hours >(disclaimers the usual: only looking at type, not qname, sender, or >content, only looking at queries, this is above the cache, txt may be >for other things as well, etc.), > >Queries for type=3DSPF: 899349 >Queries for type=3DTXT: 2839482 Our authoritative-only nameservers show a similar 3:1 ratio, again just using BIND's counts of query by type. In the last 4 weeks, they show TXT 399807, SPF 133903 and TXT 940038, SPF 340354 (the second is an official slave for rather more forward zones, some of which even have some SPF records). On the other hand, our central recursive nameservers (only for clients on the university network) show TXT:SPF over 250:1. But probably very few clients are receiving mail and checking its origin using these namesevers, and something else is responsible for the large count of TXT queries. --=20 Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From gson@araneus.fi Fri Aug 23 13:28: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 12E6511E8106 for ; Fri, 23 Aug 2013 13:28:13 -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 yCGZ2aQOgQyv for ; Fri, 23 Aug 2013 13:28:09 -0700 (PDT) Received: from gunk.araneus.fi (gunk.araneus.fi [166.84.6.82]) by ietfa.amsl.com (Postfix) with ESMTP id ED9BC21F9D5D for ; Fri, 23 Aug 2013 13:28:08 -0700 (PDT) Received: from guava.gson.org (guava.gson.org [10.0.11.2]) by gunk.araneus.fi (Postfix) with ESMTP id A2CFF1D0EBC; Fri, 23 Aug 2013 20:23:12 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id D073375E34; Fri, 23 Aug 2013 23:28:07 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <21015.50635.667570.124431@guava.gson.org> Date: Fri, 23 Aug 2013 23:27:55 +0300 To: Andras Salamon In-Reply-To: <20130823162514.GA38870@gaon.net> References: <20130822221515.GA35645@gaon.net> <20130822235329.3752.qmail@joyce.lan> <20130823162514.GA38870@gaon.net> X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf) From: Andreas Gustafsson Cc: dnsext@ietf.org Subject: Re: [dnsext] Advancing 3597 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, 23 Aug 2013 20:28:13 -0000 Andras Salamon wrote: > =D3lafur Gudmundsson nominated RFC 3597 to advance from Proposed to > Draft Standard in message <6.1.0.6.2.20040819092046.02d2dec0@localhos= t> > of 19 Aug 2004. This was based on -00 of Jakob Schlyter's draft, > of which the most recent version is from May 2005: > http://tools.ietf.org/id/draft-ietf-dnsext-interop3597-02.txt >=20 > Since Jakob already did an important part of the work, I would > first like to understand what happened to the advancement request, > especially in light of the two revisions of the interoperability > report after the request. Does anyone have pointers=3F The latest attempt at advancing 3597 was draft-ietf-dnsext-rfc3597-bis-= 02 in February 2010. For the WGLC summary, see http://www.ietf.org/mail-archive/web/dnsext/current/msg07633.html --=20 Andreas Gustafsson, gson@araneus.fi From jabley@hopcount.ca Fri Aug 23 13:28: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 CA2C911E81AA for ; Fri, 23 Aug 2013 13:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 P7bX1vlQcs9u for ; Fri, 23 Aug 2013 13:28:50 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 23CCE21F9D5D for ; Fri, 23 Aug 2013 13:28:50 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m6so1323387oag.4 for ; Fri, 23 Aug 2013 13:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/DrpRh3rEK6ZGRvOJz6tjdNGDTquM/anFLLiAp8RSvE=; b=QQ4u9b1idHsrxbb1tT5b88MnWDA05lgPR0/jJeP4DsjHwUTRHz5OL7D7qJdtYeNP6e 4l3zXKfNZXVEyh6zb2RzXCO1oXhbsIp9j8ZRS6i1TZBU0e6+1BdkoXn9K9Wct7lHZdX0 bkRP4wvGdflaml13aupFVrW1zKyTlSd63I/tg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:from:mime-version:in-reply-to:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=/DrpRh3rEK6ZGRvOJz6tjdNGDTquM/anFLLiAp8RSvE=; b=cxxkgabl0tHZjJ6/j0HVVIEB2H9QyQwUdrApJ/qAkKJUE0haRHP+MVhhUV2HWfRX8G jcu24E4bahw5NCF5KDwgdC5V9FhHCaEgqAoXLaXUXzsQi0dQp1BUk6hdlJKoqgIbTHSm dLialtuHDx3wMTtHQLVCn4A20cfbFDVWLKbSs06cmBXElqUN+7x5RKKu79wfOu6aWoGT ENrreYRyKxFxfr7rZnnpW+Z25WWc8H8Yk/Q8FhqtO30yQOc+Katxfy+MdzcgxqtXNomc Vk67y+ps8xSgLIc5tKPoaUIuL/R90UXWXyXrENjHwLNw1nKeqZ2RDF9nVUWFCAEuYfBm i4aA== X-Gm-Message-State: ALoCoQnDZOGUFxkKhsCfd3f9aiIcMQH825GahdlWVntt8gzzYOWtfax+fTkSBQEKYlf/sVnwpY9X X-Received: by 10.60.155.136 with SMTP id vw8mr1395055oeb.9.1377289729601; Fri, 23 Aug 2013 13:28:49 -0700 (PDT) References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> From: Joe Abley Mime-Version: 1.0 (1.0) In-Reply-To: Date: Fri, 23 Aug 2013 16:26:36 -0400 Message-ID: <5628654950817817361@unknownmsgid> To: "cet1@cam.ac.uk" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dnsext@ietf.org" Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 20:28:50 -0000 Hi Chris, It would be instructive to find a way to better characterise the TXT numbers in the counts that you and others have contributed to this thread. This does not seem obviously easy, since inferring the reason for a query even with knowledge of the full response (eg including SPF-identifying tokens or not) seems hard. It seems vaguely ironic that part of the reason it's hard to assess the relative use of SPF/16 and SPF/99 in queries is that 16 is overloaded, which is itself the root of the objection to its use. Joe Aue Te Ariki! He toki ki roto taku mahuna! On 2013-08-23, at 16:16, Chris Thompson wrote: > On Aug 23 2013, Jelte Jansen wrote: > >> On 08/23/2013 09:56 AM, M=E5ns Nilsson wrote: >>> $ cat queries* | awk ' /TXT/ { txt++; }; /SPF/ {spf++; }; END { >>> printf "TXT: %d\tSPF: %d\n", txt, spf; }' TXT: 2032 SPF: 396 >> >> moar data: >> >> I have been monitoring one of our nameservers over the last 48 hours >> (disclaimers the usual: only looking at type, not qname, sender, or >> content, only looking at queries, this is above the cache, txt may be >> for other things as well, etc.), >> >> Queries for type=3DSPF: 899349 >> Queries for type=3DTXT: 2839482 > > Our authoritative-only nameservers show a similar 3:1 ratio, again just > using BIND's counts of query by type. In the last 4 weeks, they show > TXT 399807, SPF 133903 and TXT 940038, SPF 340354 (the second is an > official slave for rather more forward zones, some of which even have > some SPF records). > > On the other hand, our central recursive nameservers (only for clients > on the university network) show TXT:SPF over 250:1. But probably very > few clients are receiving mail and checking its origin using these > namesevers, and something else is responsible for the large count > of TXT queries. > > -- > Chris Thompson University of Cambridge Computing Service, > Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, > Phone: +44 1223 334715 United Kingdom. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From bmanning@isi.edu Fri Aug 23 12:47:38 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 8FF8021F962D; Fri, 23 Aug 2013 12:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 YZ0fjzn2VaJR; Fri, 23 Aug 2013 12:47:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C082511E81F6; Fri, 23 Aug 2013 12:47:28 -0700 (PDT) Received: from [192.168.0.3] (cpe-24-24-228-167.socal.res.rr.com [24.24.228.167]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r7NJkSRw025210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 Aug 2013 12:46:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: <20130823180411.50961.qmail@joyce.lan> Date: Fri, 23 Aug 2013 12:46:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D4CC1CD-D897-4F46-91A7-02B8176F762A@isi.edu> References: <20130823180411.50961.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu X-Mailman-Approved-At: Fri, 23 Aug 2013 13:52:09 -0700 Cc: "ietf@ietf.org list" , dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 19:47:38 -0000 On 23August2013Friday, at 11:04, John Levine wrote: >>>> Nobody has argued that SPF usage is zero, and the reasons for >>>> deprecating SPF have been described repeatedly here and on the ietf >>>> list, so this exercise seems fairly pointless. >>>=20 >>> the reasons for not deprecating SPF have been described here >>> and on the ietf list repeatedly ... yet there has been little >>> concrete data regarding deployment uptake. >=20 > Sigh. We have RFC 6686. Since this is clearly an issue you consider > to be of vital importance, it is baffling that (as far as I can tell) > you did not contribute to or even comment on it when it was being > written and published. work assignments occasionally take me away from active engagement in IETF matters. sorry for the few years absence. =20 > Those of us in the mail community have a lot of anecdotal evidence, > too. Most notably, none of the large providers that dominate the mail > world publish or check type 99, and the one that used to check type 99 > (Yahoo) doesn't any more. You don't have to like it, but it's silly > to deny it. not sure why you think the DNS data presented is anecdotal. = Looked kind of empirical to me. i've not seen a yahoo person describe = what=20 they have or have not done or why. we have no data on why = Microsoft may or may not support type 99 (see Jay's questions). Much of = the mail community data seems anecdotal=85 very little first hand, = empirical=20 stuff. (and I thank you for your data) > In any event, it's purely a strawman that "nobody" checks type 99. A > few people do, the WG knows that, and we decided for well documented > reasons to deprecate it anyway. demuxing type 16 records is a choice. using type 99, which was = specifically designed for this use, is a choice. using application specific = types have distinct technological advantages (see PHB comments). They may be small, = but are real and have an impact on the DNS and the application. regarding the specific claims regarding adoption, I was asking = for a brief period to collect more empirical data to track the magnitude and ratio = of type 99 v. type 16 use (noting, as PAF has already noted, that not all type 16 =3D=3D= type 99, so for accurate understanding - someone needs to look at type 99 muxed into a = type 16 format=85 if only to correctly understand the change in ratio. the question is not that "nobody" checks type 99, the question = is "is the rate of adoption of type 99 -changing- in relation to type 16? >=20 > R's, > John From marka@isc.org Fri Aug 23 14:41: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 724E811E810A for ; Fri, 23 Aug 2013 14:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 yEwEaFQJetuK for ; Fri, 23 Aug 2013 14:41:51 -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 2CCFB11E80DF for ; Fri, 23 Aug 2013 14:41:51 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id D75A2C94C4; Fri, 23 Aug 2013 21:41:35 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377294110; bh=b5ESFddyAoR76nIZyin8XakhUw/Hy7YJN6ghHp8Df4M=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=ZmQOzQKWoRvhmd4rrBgsyL/G5sfCwKnIoNPgn31DagmiYxH5ywkq3j3i8o0z2hbwL CJhLrcf66UEoLMWOSr/axzgasGXHpmwmuKmNuWxfsXuUwITUq8JNYkTLru7hdCMoic CUR1lNTN1CHDgcwjB/C6ESNog8bUNplskvA1GR7U= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 23 Aug 2013 21:41:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 61099160363; Fri, 23 Aug 2013 21:41:56 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id F192E1602B4; Fri, 23 Aug 2013 21:41:55 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5D87038D252E; Sat, 24 Aug 2013 07:41:23 +1000 (EST) To: Joe Abley From: Mark Andrews References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> In-reply-to: Your message of "Fri, 23 Aug 2013 16:26:36 -0400." <5628654950817817361@unknownmsgid> Date: Sat, 24 Aug 2013 07:41:23 +1000 Message-Id: <20130823214123.5D87038D252E@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsext@ietf.org" Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 21:41:55 -0000 In message <5628654950817817361@unknownmsgid>, Joe Abley writes: > Hi Chris, > > It would be instructive to find a way to better characterise the TXT > numbers in the counts that you and others have contributed to this > thread. > > This does not seem obviously easy, since inferring the reason for a > query even with knowledge of the full response (eg including > SPF-identifying tokens or not) seems hard. > > It seems vaguely ironic that part of the reason it's hard to assess > the relative use of SPF/16 and SPF/99 in queries is that 16 is > overloaded, which is itself the root of the objection to its use. > > > Joe When you look at recursive servers you are looking at the direct clients of that server. When you look at authoritative servers you are seeing the world wide population of clients. Add to that you need to look at the differing TTLs for the responses for the two query types as most of these queries will be from a caching server and not the ultimate client. You also need to know if the SPF queries return a positive or negative response as that will also directly impact on the ratio of queries. You also need to know if the responses are for a existing name or result in name error. You also need to ensure that the delegations are all correct or the negative responses will be rejected by some of the recursive servers. You also need to look at whether the responses TTLs are being truncated or not. To eliminate most of the sources of bias you need to measuring on a site that doesn't have spf records of either form (spf/txt). Next best you need to be measuring on a site that publishes both with equal ttl (spf/(txt + spf)). Mixed mode servers are too difficult to quantify. > Aue Te Ariki! He toki ki roto taku mahuna! > > On 2013-08-23, at 16:16, Chris Thompson wrote: > > > On Aug 23 2013, Jelte Jansen wrote: > > > >> On 08/23/2013 09:56 AM, Mans Nilsson wrote: > >>> $ cat queries* | awk ' /TXT/ { txt++; }; /SPF/ {spf++; }; END { > >>> printf "TXT: %d\tSPF: %d\n", txt, spf; }' TXT: 2032 SPF: 396 > >> > >> moar data: > >> > >> I have been monitoring one of our nameservers over the last 48 hours > >> (disclaimers the usual: only looking at type, not qname, sender, or > >> content, only looking at queries, this is above the cache, txt may be > >> for other things as well, etc.), > >> > >> Queries for type=SPF: 899349 > >> Queries for type=TXT: 2839482 > > > > Our authoritative-only nameservers show a similar 3:1 ratio, again just > > using BIND's counts of query by type. In the last 4 weeks, they show > > TXT 399807, SPF 133903 and TXT 940038, SPF 340354 (the second is an > > official slave for rather more forward zones, some of which even have > > some SPF records). > > > > On the other hand, our central recursive nameservers (only for clients > > on the university network) show TXT:SPF over 250:1. But probably very > > few clients are receiving mail and checking its origin using these > > namesevers, and something else is responsible for the large count > > of TXT queries. > > > > -- > > Chris Thompson University of Cambridge Computing Service, > > Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, > > Phone: +44 1223 334715 United Kingdom. > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > _______________________________________________ > 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 ajs@anvilwalrusden.com Fri Aug 23 15:10:30 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 7477211E80EF for ; Fri, 23 Aug 2013 15:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 cbUlGl7GGp8m for ; Fri, 23 Aug 2013 15:10:22 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 944B611E8124 for ; Fri, 23 Aug 2013 15:10:20 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id ECCEB8A031 for ; Fri, 23 Aug 2013 22:10:18 +0000 (UTC) Date: Fri, 23 Aug 2013 18:10:16 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130823221016.GX37406@mx1.yitter.info> References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130823214123.5D87038D252E@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 22:10:30 -0000 On Sat, Aug 24, 2013 at 07:41:23AM +1000, Mark Andrews wrote: > of these queries will be from a caching server and not the ultimate > client. You also need to know if the SPF queries return a positive > or negative response as that will also directly impact on the ratio > of queries. You also need to know if the responses are for a > existing name or result in name error. You also need to ensure > that the delegations are all correct or the negative responses will > be rejected by some of the recursive servers. You also need to > look at whether the responses TTLs are being truncated or not. In this SPF/TXT case, you also need to look at whether the query came from someone named "google", "hotmail", "yahoo", and maybe another four or five systems on the Internet; or whether it came from someone else. This is related to the point that I think Ted Lemon made elsewhere on the topic: the big operators of mail are so big that if even one of them were doing something with SPF, it would really move the needle. The fact is that they're not, and the one who _was_ doing something with it has given up because the additional query adds load and latency for no benefit. Surely this point is not obscure to the participants of this list? Someone who pretended to do a survey about DNS that didn't contain any queries for .com would be laughed out of the room, and everyone interested in DNSSEC was doubtless cheered when the root and .com were announced to be signed, because after that there was reason to suppose that support could be useful. We have the same sorts of 10,000 pound gorillas in the email space. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Fri Aug 23 15:59: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 419F611E8114 for ; Fri, 23 Aug 2013 15:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, 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 MNzDBvzef5cj for ; Fri, 23 Aug 2013 15:59:39 -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 7E36411E80DF for ; Fri, 23 Aug 2013 15:59:39 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id AE6CAC9485; Fri, 23 Aug 2013 22:59:24 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377298777; bh=PRrStuD/3c1bI5ejnw5Jdc2HgaDnensdxLs/XXUZnfg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=s/qSXjqfHuv3WuAeuUcL55NouWEj/yoEUGaHdSrUWQU8gMSoGyb0XWkcnNtLX0YjB n+At1KvEvdbbHznLnACexYt/2uIKArIcFjFzFhMXjUsA5FpdPyQjHMhLrEFN5Brf2/ dBbGoJhgH5FR0Nmh8l69tSzmVtfLcAHZccuvzENQ= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 23 Aug 2013 22:59:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 73D56160363; Fri, 23 Aug 2013 22:59:45 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 4289A1602B4; Fri, 23 Aug 2013 22:59:45 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8040B38D2D30; Sat, 24 Aug 2013 08:59:20 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> In-reply-to: Your message of "Fri, 23 Aug 2013 18:10:16 -0400." <20130823221016.GX37406@mx1.yitter.info> Date: Sat, 24 Aug 2013 08:59:20 +1000 Message-Id: <20130823225920.8040B38D2D30@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 22:59:44 -0000 In message <20130823221016.GX37406@mx1.yitter.info>, Andrew Sullivan writes: > On Sat, Aug 24, 2013 at 07:41:23AM +1000, Mark Andrews wrote: > > > of these queries will be from a caching server and not the ultimate > > client. You also need to know if the SPF queries return a positive > > or negative response as that will also directly impact on the ratio > > of queries. You also need to know if the responses are for a > > existing name or result in name error. You also need to ensure > > that the delegations are all correct or the negative responses will > > be rejected by some of the recursive servers. You also need to > > look at whether the responses TTLs are being truncated or not. > > In this SPF/TXT case, you also need to look at whether the query came > from someone named "google", "hotmail", "yahoo", and maybe another > four or five systems on the Internet; or whether it came from someone > else. No. Big operators still have caches. They actually have little impact on authoritative server loads. You might be sending the millions of emails a day but if you TTL is for 1 day you may get 100 queries assuming the recursive server farm is that big. > This is related to the point that I think Ted Lemon made elsewhere on > the topic: the big operators of mail are so big that if even one of > them were doing something with SPF, it would really move the needle. > The fact is that they're not, and the one who _was_ doing something > with it has given up because the additional query adds load and > latency for no benefit. Actually they don't move the needle much at all. What moves the needle is new MTAs being installed. > Surely this point is not obscure to the participants of this list? > Someone who pretended to do a survey about DNS that didn't contain any > queries for .com would be laughed out of the room, and everyone > interested in DNSSEC was doubtless cheered when the root and .com were > announced to be signed, because after that there was reason to suppose > that support could be useful. We have the same sorts of 10,000 pound > gorillas in the email space. Big operators only move the needle on their own servers. For everybody else the have little impact on the ratio of queries. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Fri Aug 23 16:09: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 8F8FD21F9974 for ; Fri, 23 Aug 2013 16:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 CAv0gt6EkSnh for ; Fri, 23 Aug 2013 16:09: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 3137D21F9A81 for ; Fri, 23 Aug 2013 16:09:48 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id DA5F2C9476; Fri, 23 Aug 2013 23:09:34 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377299387; bh=nheachysH6ro+s2M+2xisdoIGMNWRdYyNxqmNQiEFHw=; h=Cc:From:References:Subject:In-reply-to:Date; b=aWatWuik+p6+8PymYNJvSCqj5XRZtwbaRlXfamZsslPq+xfUVCAIV2vVkdZ/qFJ5r QMxFyn5pzlgdNuwPhXDRM8BuBHOyHEY4+aUDCs/8tKozM0cI5W6oaV7j7fm5QM53Eq PVajg9KsvJ99OfZcXJkAXqU7wOW/g/h5JBUQUams= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 23 Aug 2013 23:09:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A160F160363; Fri, 23 Aug 2013 23:09:55 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 387F31602B4; Fri, 23 Aug 2013 23:09:55 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 353B738D2F1D; Sat, 24 Aug 2013 09:09:31 +1000 (EST) From: Mark Andrews References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <20130823225920.8040B38D2D30@drugs.dv.isc.org> In-reply-to: Your message of "Sat, 24 Aug 2013 08:59:20 +1000." <20130823225920.8040B38D2D30@drugs.dv.isc.org> Date: Sat, 24 Aug 2013 09:09:31 +1000 Message-Id: <20130823230931.353B738D2F1D@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 23:09:52 -0000 In message <20130823225920.8040B38D2D30@drugs.dv.isc.org>, Mark Andrews writes: > > In message <20130823221016.GX37406@mx1.yitter.info>, Andrew Sullivan writes: > > On Sat, Aug 24, 2013 at 07:41:23AM +1000, Mark Andrews wrote: > > > > > of these queries will be from a caching server and not the ultimate > > > client. You also need to know if the SPF queries return a positive > > > or negative response as that will also directly impact on the ratio > > > of queries. You also need to know if the responses are for a > > > existing name or result in name error. You also need to ensure > > > that the delegations are all correct or the negative responses will > > > be rejected by some of the recursive servers. You also need to > > > look at whether the responses TTLs are being truncated or not. > > > > In this SPF/TXT case, you also need to look at whether the query came > > from someone named "google", "hotmail", "yahoo", and maybe another > > four or five systems on the Internet; or whether it came from someone > > else. > > No. Big operators still have caches. They actually have little > impact on authoritative server loads. You might be sending the > millions of emails a day but if you TTL is for 1 day you may get > 100 queries assuming the recursive server farm is that big. > > > This is related to the point that I think Ted Lemon made elsewhere on > > the topic: the big operators of mail are so big that if even one of > > them were doing something with SPF, it would really move the needle. > > The fact is that they're not, and the one who _was_ doing something > > with it has given up because the additional query adds load and > > latency for no benefit. > > Actually they don't move the needle much at all. What moves the needle > is new MTAs being installed. More correctly the don't have much impact on authoritative servers. It they were to publish SPF records they would impact on the query load directed at recursive servers that have clients that look for both SPF and TXT. But we were discussing loads on authoritative servers. > > Surely this point is not obscure to the participants of this list? > > Someone who pretended to do a survey about DNS that didn't contain any > > queries for .com would be laughed out of the room, and everyone > > interested in DNSSEC was doubtless cheered when the root and .com were > > announced to be signed, because after that there was reason to suppose > > that support could be useful. We have the same sorts of 10,000 pound > > gorillas in the email space. > > Big operators only move the needle on their own servers. For everybody > else the have little impact on the ratio of queries. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > 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 ajs@anvilwalrusden.com Fri Aug 23 16:43: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 98E4D21F95DC for ; Fri, 23 Aug 2013 16:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.683 X-Spam-Level: X-Spam-Status: No, score=-0.683 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, 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 25HQS08Lm4dr for ; Fri, 23 Aug 2013 16:43:17 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B4EDD21F995A for ; Fri, 23 Aug 2013 16:43:17 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 753F98A031 for ; Fri, 23 Aug 2013 23:43:14 +0000 (UTC) Date: Fri, 23 Aug 2013 19:42:41 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130823234240.GA5629@mx1.yitter.info> References: <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <20130823225920.8040B38D2D30@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130823225920.8040B38D2D30@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 23 Aug 2013 23:43:23 -0000 On Sat, Aug 24, 2013 at 08:59:20AM +1000, Mark Andrews wrote: > > No. Big operators still have caches. They actually have little > impact on authoritative server loads. You might be sending the > millions of emails a day but if you TTL is for 1 day you may get > 100 queries assuming the recursive server farm is that big. Clearly, I'm an idiot. I thought that this discussion was actually about measuring the relative importance of SPF and TXT in the deployed environment on the Internet. So I was supposing that, because of the facts of the deployed environment of the Internet, when you're counting how many TXT or SPF records are queried, you have to consider who asked the question. If bobsmailandbaitshop.tld asks for an SPF or TXT record, that should count less in the "how is this deploye?d" estimation than if hotmail.com asks the same question. For these each have a cache, as you say; and there's a pretty good reason to suppose that a single SPF or TXT query from Hotmail relates to many more actual mail deliveries than Bob's Mail and Bait Shop. This is along the lines of what Ted Lemon (I think? Sorry if I attribute wrong) was asking about "per unit of mail delivered". But I gather from your comments that all we're trying to measure is the count of queries for a type at a given nameserver. Obviously for that, you're right: count the queries. I don't know why in the world would we care about that, though. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Fri Aug 23 17:10: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 8B9C321F9F70 for ; Fri, 23 Aug 2013 17:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, 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 kErpqfwg8+e5 for ; Fri, 23 Aug 2013 17:09:59 -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 B599321F9D96 for ; Fri, 23 Aug 2013 17:09:59 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 31D5EC94BA; Sat, 24 Aug 2013 00:09:47 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377302999; bh=WlDFHaeOyctPIUQVDJnEJo10OUuDCZriew/9sulTWDM=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=djZz8fBBK3JU6zEPGYo8VXBhM7mjVFDhWLtzfWgSRfiB08qiWoJEwc73/4P/jzq2M HKiZCLpKI1ac8SAIBW5yY/z7T3GGyb0wpqq1tJswZ3brVDtGw6DlbMBxFn98E9Jkzs fbU1LyoecwvZvV/KrcAVaN0uFDtx1iPvNw9bc+Lc= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sat, 24 Aug 2013 00:09:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2BAAA160482; Sat, 24 Aug 2013 00:10:08 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id EC43D160435; Sat, 24 Aug 2013 00:10:07 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 54BA338D366A; Sat, 24 Aug 2013 10:09:41 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <20130823225920.8040B38D2D30@drugs.dv.isc.org> <20130823234240.GA5629@mx1.yitter.info> In-reply-to: Your message of "Fri, 23 Aug 2013 19:42:41 -0400." <20130823234240.GA5629@mx1.yitter.info> Date: Sat, 24 Aug 2013 10:09:41 +1000 Message-Id: <20130824000941.54BA338D366A@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 00:10:04 -0000 In message <20130823234240.GA5629@mx1.yitter.info>, Andrew Sullivan writes: > On Sat, Aug 24, 2013 at 08:59:20AM +1000, Mark Andrews wrote: > > > > No. Big operators still have caches. They actually have little > > impact on authoritative server loads. You might be sending the > > millions of emails a day but if you TTL is for 1 day you may get > > 100 queries assuming the recursive server farm is that big. > > Clearly, I'm an idiot. > > I thought that this discussion was actually about measuring the > relative importance of SPF and TXT in the deployed environment on the > Internet. So I was supposing that, because of the facts of the > deployed environment of the Internet, when you're counting how many > TXT or SPF records are queried, you have to consider who asked the > question. We are trying to measure the installed base of MTA's that support SPF vs those that support just TXT. DNS caches hide the volume of email going through a MTA. There is no one-to-one relationship between email sent and SPF or TXT lookup. The figures are saying between a third and a quarter of the worlds MTAs doing spf support SPF record lookups if you neglect TTL values. Some of those MTA's handle million of emails a day. Others handle hundreds. > If bobsmailandbaitshop.tld asks for an SPF or TXT record, that should > count less in the "how is this deploye?d" estimation than if > hotmail.com asks the same question. For these each have a cache, as > you say; and there's a pretty good reason to suppose that a single SPF > or TXT query from Hotmail relates to many more actual mail deliveries > than Bob's Mail and Bait Shop. This is along the lines of what Ted > Lemon (I think? Sorry if I attribute wrong) was asking about "per > unit of mail delivered". Actually bobsmailandbaitshop.tld counts the same as gmail.com. > But I gather from your comments that all we're trying to measure is > the count of queries for a type at a given nameserver. Obviously for > that, you're right: count the queries. I don't know why in the world > would we care about that, though. Actually I was just trying to make clear what was being measured. What potential biases there were in the measurements. Figures mean nothing unless you have a good understanding of what they are saying. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jabley@hopcount.ca Fri Aug 23 17:15: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 0A44111E80EE for ; Fri, 23 Aug 2013 17:15:55 -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 x1Hf62gfm0ap for ; Fri, 23 Aug 2013 17:15:54 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id D0D8F11E80DF for ; Fri, 23 Aug 2013 17:15:53 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lf1so1246960pab.38 for ; Fri, 23 Aug 2013 17:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t1z3+RO0PAwlwEmzruWahUIzZOGQmD7OU1k8unXRRJk=; b=drgoOManbUhdYcsznz7gENYlE+J4lewQXC7fDfV6/rnP3++O+/5YjEZ47JDwSgboew vbeD8YHfFuzJkKnCQWq2/w9QI71dVumr50sGmV7rS7abpNVQwvekfamGF0/eBOCmQvkt eME0mH1YU5Y0562rF0FB3dmUYf3wFJfk+VekQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=t1z3+RO0PAwlwEmzruWahUIzZOGQmD7OU1k8unXRRJk=; b=oc8+SUsUmLli7MMdGdPnc+CS/SyyeWSzPdtNdMoI9wND/vXSEocuPbMj1xBcf2k7y7 b88NhikmprpnaMprDiFQrYiO7ViR/d6UWvdSZFT1kzE9tlpe7FGTXS0A2a3ft1cRuWRQ 0vEah7SjpdScYn22L/RxSY++PTzC+qKX+nGn74xzlIHzocRqzR/Bl0ZeXu+/6FFkT+0W aBGv2rsbJz5wtJNaWpcyOVjBS4nA/SDZuwKQul9Z/yyiuWuhAp+AzVIGz342S+ZXt5dP Ekva/nbU/xtNf/IPHs7yqUD2bOM3G4kuN7cP7FkhABnK6WzHMM8EEj50L/ArdjfNDiOP fg4A== X-Gm-Message-State: ALoCoQnkiKwGVoZFmMr1HBd2kF6xwMGj4ySqzxMy5ceBhQBxUyPJwMMF/KQmJPOT2QcWMY969S3r X-Received: by 10.66.179.143 with SMTP id dg15mr1679651pac.52.1377303345364; Fri, 23 Aug 2013 17:15:45 -0700 (PDT) Received: from [199.212.90.52] ([199.212.90.52]) by mx.google.com with ESMTPSA id xs1sm3770662pac.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 17:15:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Joe Abley In-Reply-To: <20130823221016.GX37406@mx1.yitter.info> Date: Fri, 23 Aug 2013 17:15:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <32389F5D-6B76-4286-BE21-08B71A9598F0@hopcount.ca> References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 00:15:55 -0000 On 2013-08-23, at 15:10, Andrew Sullivan wrote: > In this SPF/TXT case, you also need to look at whether the query came > from someone named "google", "hotmail", "yahoo", and maybe another > four or five systems on the Internet; or whether it came from someone > else. My point was it's hard, not really to invite people into proposals. I = think any real heuristic would need substantial experimentation and = justification before it could be used in anger. There are many, many = variables here that are difficult or impossible to quantify. And this doesn't even touch the question about whether we're counting = numbers of domains that use SPF, or numbers of users, or volume of mail, = or something else. Joe From ajs@anvilwalrusden.com Fri Aug 23 17:57:16 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 7C5F221F9F26 for ; Fri, 23 Aug 2013 17:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 bj-IMGWQ-XPo for ; Fri, 23 Aug 2013 17:57:07 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id D563321F9F23 for ; Fri, 23 Aug 2013 17:57:07 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 0ECA48A031 for ; Sat, 24 Aug 2013 00:57:07 +0000 (UTC) Date: Fri, 23 Aug 2013 20:57:05 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130824005705.GB5854@mx1.yitter.info> References: <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <32389F5D-6B76-4286-BE21-08B71A9598F0@hopcount.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32389F5D-6B76-4286-BE21-08B71A9598F0@hopcount.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 00:57:16 -0000 On Fri, Aug 23, 2013 at 05:15:44PM -0700, Joe Abley wrote: > > My point was it's hard Also my point. There were people who wanted to make _much_ stronger claims on the basis of the evidence that SPFBIS collected that I simply couldn't subscribe to. That's partly why the SPFBIS conclusions are somewhat tentative, I think. I would certainly be delighted if we had people or (more likely) money to conduct a really rigourous study, but that seems to me like wishful thinking. A -- Andrew Sullivan ajs@anvilwalrusden.com From drc@virtualized.org Fri Aug 23 18:40:16 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 9E2DE21F9D92 for ; Fri, 23 Aug 2013 18:40:16 -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 Zex68rVDZREi for ; Fri, 23 Aug 2013 18:40:10 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id C4FEA21F9D8D for ; Fri, 23 Aug 2013 18:40:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id C945087127; Fri, 23 Aug 2013 21:40:08 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 58844-03; Fri, 23 Aug 2013 21:40:08 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id 30BF1868D4; Fri, 23 Aug 2013 21:40:08 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A2511CA9-368F-43B6-BF52-EE9DB202993C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: <20130824005705.GB5854@mx1.yitter.info> Date: Fri, 23 Aug 2013 18:40:05 -0700 Message-Id: <00B88CDF-B349-4DB0-AF33-BBEA1BA106EA@virtualized.org> References: <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <32389F5D-6B76-4286-BE21-08B71A9598F0@hopcount.ca> <20130824005705.GB5854@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 01:40:16 -0000 --Apple-Mail=_A2511CA9-368F-43B6-BF52-EE9DB202993C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Andrew, On Aug 23, 2013, at 5:57 PM, Andrew Sullivan = wrote: > I would certainly be > delighted if we had people or (more likely) money to conduct a really > rigourous study, but that seems to me like wishful thinking. What would a more rigorous study show? As far as I can tell, the issue isn't whether the SPF RR is being used = (it appears to be, albeit at a tiny percentage relative to TXT = currently), rather it's whether or not a handful of major mail service = providers will use SPF RRs in the future if the IETF were to document a = fix to the broken transition strategy in 4408. The SPFBIS WG appears to = be asserting that despite no one thinking using TXT is a good idea, most = DNS servers supporting SPF (Microsoft being the notable exception), DNS = hosting and UI vendors saying they're waiting on the IETF to make up = their mind about the SPF RR, existing DNS editors supporting the SPF RR, = etc., no transition away from TXT is possible. I'm unclear what a rigorous study of existing data could possibly = demonstrate that would convince anyone who holds this view otherwise. Regards, -drc --Apple-Mail=_A2511CA9-368F-43B6-BF52-EE9DB202993C 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSGA71AAoJEIzZ2DQOJFbKuw4H/i0/0Y8776sfiqoDUl0KdpEg mYSjIeoPfU/Xr8YGXB6iWKsef+Xn7FnRbuPJBwUpY7bIVWE+vp2E1q80JxS+Xpmq pb3RZXXm5Hyo/OrcBc6xrnsCCkfT+PzBzuEmlK+KYZAREcwv0Xobe9++J5aqyfJl xWEzmY9LudXX3rYSGtZcru3WNWCo9At/bCZnl29cQamhcj/mwKB9czUnIgsno08I 7Y41RcElAc1vbvQpiQry4E65adzPL8rIeJ+duvF5aO0ZdrHswPvCNvHr4W6KTsgG WDOvcxypItfY+3xGlTDqBuuGvOZbiYsG/+8xWtohyUX9pLPSQOFYYNfcdbxo054= =57zW -----END PGP SIGNATURE----- --Apple-Mail=_A2511CA9-368F-43B6-BF52-EE9DB202993C-- From ajs@anvilwalrusden.com Fri Aug 23 19:02: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 CB62C21F9E0A for ; Fri, 23 Aug 2013 19:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 xiiJeFj5qt2p for ; Fri, 23 Aug 2013 19:02:23 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBCC21F9E01 for ; Fri, 23 Aug 2013 19:02:22 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 85C5D8A031 for ; Sat, 24 Aug 2013 02:02:20 +0000 (UTC) Date: Fri, 23 Aug 2013 22:02:19 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130824020218.GB5888@mx1.yitter.info> References: <20130823022611.GA23695@vacation.karoshi.com> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <32389F5D-6B76-4286-BE21-08B71A9598F0@hopcount.ca> <20130824005705.GB5854@mx1.yitter.info> <00B88CDF-B349-4DB0-AF33-BBEA1BA106EA@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00B88CDF-B349-4DB0-AF33-BBEA1BA106EA@virtualized.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 02:02:28 -0000 On Fri, Aug 23, 2013 at 06:40:05PM -0700, David Conrad wrote: > As far as I can tell, the issue isn't whether the SPF RR is being > used (it appears to be, albeit at a tiny percentage relative to TXT > currently) Right, despite the fact that 4408 actually suggested that it'd be good to use SPF. > , rather it's whether or not a handful of major mail > service providers will use SPF RRs in the future if the IETF were to > document a fix to the broken transition strategy in 4408. How would the IETF do that? The strategy in 4408 was roughly, "Try both," though admittedly in a flawed way. But this is exactly the nut of the problem. There is no way to create an incentive, given the actual world we live in, for anyone either to publish or to check 99 as the primary mechanism. As long as 16 is what everyone is already doing, network effects say that 16 wins. There is no advantage to anyone in moving to 99: neither on the check side nor on the publish side do you win. So nobody will. We either need something new that will make SPF worth doing -- call it SPF v3 that expresses new policy that's even better (and I can think of something! Think of EAI-using domains that need better granularity!) -- or else we need to embrace the lowest common denominator. Nobody in any of this has offered the slightest incentive to anyone, AFAICT, except, "DNS is better this way." Who cares? I do, you do, but we don't organize the universe. The above is my claim: nobody cares about this hygiene. If I'm wrong, then I want a rigourous study to show it, because none of the empirical evidence suggests so far that accepting and documenting the facts as they are today is different than the effects of saying, "You oughta like TYPE99 more." We don't have legislative power. A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Fri Aug 23 19: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 47DA021F9E7C for ; Fri, 23 Aug 2013 19:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 cneyN-bj7+eB for ; Fri, 23 Aug 2013 19:37:16 -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 DEB9A21F9E6A for ; Fri, 23 Aug 2013 19:37:16 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B4704C94AD; Sat, 24 Aug 2013 02:37:02 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377311836; bh=DGDl8UgOierb7pEd1A9KuTmzEvp2UcahGCMiRKDBepA=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=OfJdjloY8bHiV6xXXTSBJ0xogzqJZgIftBWfsBlzajl5uuVGaeEag/4pT/RAmk79W 64GBSt4GwT0de4dG1VQoXZEdZ76lmjOv7E+IQqjlhALGROhr3NEFwrVypS3Hcs9rIG lplrE7DmoFXLMv3CfwUgSMtgZ4TUqueF96xm1YOI= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sat, 24 Aug 2013 02:37:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 13EF4160363; Sat, 24 Aug 2013 02:37:24 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id D1CB31602B4; Sat, 24 Aug 2013 02:37:23 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 9777838D42FF; Sat, 24 Aug 2013 12:36:57 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <20130823022611.GA23695@vacation.karoshi.com> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <32389F5D-6B76-4286-BE21-08B71A9598F0@hopcount.ca> <20130824005705.GB5854@mx1.yitter.info> <00B88CDF-B349-4DB0-AF33-BBEA1BA106EA@virtualized.org> <20130824020218.GB5888@mx1.yitter.info> In-reply-to: Your message of "Fri, 23 Aug 2013 22:02:19 -0400." <20130824020218.GB5888@mx1.yitter.info> Date: Sat, 24 Aug 2013 12:36:57 +1000 Message-Id: <20130824023657.9777838D42FF@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 02:37:21 -0000 In message <20130824020218.GB5888@mx1.yitter.info>, Andrew Sullivan writes: > On Fri, Aug 23, 2013 at 06:40:05PM -0700, David Conrad wrote: > > > As far as I can tell, the issue isn't whether the SPF RR is being > > used (it appears to be, albeit at a tiny percentage relative to TXT > > currently) > > Right, despite the fact that 4408 actually suggested that it'd be good > to use SPF. > > > , rather it's whether or not a handful of major mail > > service providers will use SPF RRs in the future if the IETF were to > > document a fix to the broken transition strategy in 4408. > > How would the IETF do that? You say MUST query for SPF and if there is a NO DATA response you MAY query for TXT. Modern spf libraries already do this. Legacy SPF checkers are no longer compliant. Even checkers running under Windows can meet this MUST. You say that nameservers SHOULD synthesis SPF records from TXT v=spf1 records. This helps registrars stuck with broken web interfaces. Code for this is written. You say that nameservers SHOULD reject loading of zones without SPF records when there are v=spf1 TXT records. This provides education for everybody else. Code for this is written. You make all the examples use SPF not TXT. Again more education. You set a sunset date for the use of TXT for spf lookups. > The strategy in 4408 was roughly, "Try > both," though admittedly in a flawed way. But this is exactly the nut > of the problem. There is no way to create an incentive, given the > actual world we live in, for anyone either to publish or to check 99 > as the primary mechanism. As long as 16 is what everyone is already > doing, network effects say that 16 wins. There is no advantage to > anyone in moving to 99: neither on the check side nor on the publish > side do you win. So nobody will. > We either need something new that will make SPF worth doing -- call it > SPF v3 that expresses new policy that's even better (and I can think > of something! Think of EAI-using domains that need better > granularity!) -- or else we need to embrace the lowest common > denominator. Nobody in any of this has offered the slightest > incentive to anyone, AFAICT, except, "DNS is better this way." Who > cares? I do, you do, but we don't organize the universe. > > The above is my claim: nobody cares about this hygiene. If I'm wrong, > then I want a rigourous study to show it, because none of the > empirical evidence suggests so far that accepting and documenting the > facts as they are today is different than the effects of saying, "You > oughta like TYPE99 more." We don't have legislative power. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > 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 ajs@anvilwalrusden.com Fri Aug 23 20:18: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 B53DE21F9D15 for ; Fri, 23 Aug 2013 20:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.829 X-Spam-Level: X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 NVQ6QxfisWKn for ; Fri, 23 Aug 2013 20:18:02 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1AD21F8B12 for ; Fri, 23 Aug 2013 20:17:58 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 5FA8B8A031 for ; Sat, 24 Aug 2013 03:17:57 +0000 (UTC) Date: Fri, 23 Aug 2013 23:17:54 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130824031754.GC5888@mx1.yitter.info> References: <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <32389F5D-6B76-4286-BE21-08B71A9598F0@hopcount.ca> <20130824005705.GB5854@mx1.yitter.info> <00B88CDF-B349-4DB0-AF33-BBEA1BA106EA@virtualized.org> <20130824020218.GB5888@mx1.yitter.info> <20130824023657.9777838D42FF@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130824023657.9777838D42FF@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 03:18:07 -0000 Hi, Thanks for the outline of the transition strategy. Let me walk through it, piece by pice, and see how it works. I'm going to use "SPF-99" and "SPF-16" in what follows to disambiguate the query cases. I'll call the existing SPF implementations "SPFCheck" -- no matter what they do -- and the new implementations that prefer SPF-99 first, then SPF-16 "SPFCheckNG". On Sat, Aug 24, 2013 at 12:36:57PM +1000, Mark Andrews wrote: > You say MUST query for SPF and if there is a NO DATA response you > MAY query for TXT. Modern spf libraries already do this. Legacy > SPF checkers are no longer compliant. Even checkers running under > Windows can meet this MUST. I am an SPF validator. On day 0, there are very few people publishing SPF-99 records, and many publishing SPF-16 records. I have a lot of mail volume coming in. What is my incentive to embrace SPFCheckNG? Please address the latency effects for large mail operators. > You say that nameservers SHOULD synthesis SPF records from TXT > v=spf1 records. This helps registrars stuck with broken web > interfaces. Code for this is written. I'm an operator of a DNS zone. I publish TXT and SPF records. On day 0, there are very few people publishing SPF-99 records. What is my incentive to deploy code that aoutomatically increases my storage cost and my opportunity for bugs, given that everyone who accepts my mail is satisfied with SPF-16? > You say that nameservers SHOULD reject loading of zones without SPF > records when there are v=spf1 TXT records. This provides education > for everybody else. Code for this is written. I'm an operator of a DNS zone. On day 0, my zone works. What is my incentive to accept a new DNS server software update that makes my zone broken, given that it was working on day 0-1? I offer my thanks in advance for your investigation of the answers to the above. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Fri Aug 23 21:14: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 934C021F9D02 for ; Fri, 23 Aug 2013 21:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 YfR7ceXx72mk for ; Fri, 23 Aug 2013 21:14: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 441B121F8C3E for ; Fri, 23 Aug 2013 21:14:39 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id E0113C942D; Sat, 24 Aug 2013 04:14:25 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377317679; bh=kQ4/twdVUHxR82jk5JiR+sOLk253z2wRoEQBj6IodoI=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=HCVH8oV2ImMqryVW4eVk9MdDVaTwr8vmu/V6tR4kqdZGMSCbN7nIshZMzRG+3INpR yp/xV7iwP/Kx51y9mtkKV8aEtllmvRNv0zOOAEkCpQ99XkDTwbMtEzRsuQz30j1J6E f7DrEPtJwWLzJFCKKYFewbWTI4igZrnRq9kzSvBM= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sat, 24 Aug 2013 04:14:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 94E0A160363; Sat, 24 Aug 2013 04:14:47 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5DFE61602B4; Sat, 24 Aug 2013 04:14:47 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0D8DE38D4DFA; Sat, 24 Aug 2013 14:14:09 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <32389F5D-6B76-4286-BE21-08B71A9598F0@hopcount.ca> <20130824005705.GB5854@mx1.yitter.info> <00B88CDF-B349-4DB0-AF33-BBEA1BA106EA@virtualized.org> <20130824020218.GB5888@mx1.yitter.info> <20130824023657.9777838D42FF@drugs.dv.isc.org> <20130824031754.GC5888@mx1.yitter.info> In-reply-to: Your message of "Fri, 23 Aug 2013 23:17:54 -0400." <20130824031754.GC5888@mx1.yitter.info> Date: Sat, 24 Aug 2013 14:14:09 +1000 Message-Id: <20130824041410.0D8DE38D4DFA@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 04:14:45 -0000 In message <20130824031754.GC5888@mx1.yitter.info>, Andrew Sullivan writes: > Hi, > > Thanks for the outline of the transition strategy. Let me walk > through it, piece by pice, and see how it works. I'm going to use > "SPF-99" and "SPF-16" in what follows to disambiguate the query cases. > I'll call the existing SPF implementations "SPFCheck" -- no matter > what they do -- and the new implementations that prefer SPF-99 first, > then SPF-16 "SPFCheckNG". > > On Sat, Aug 24, 2013 at 12:36:57PM +1000, Mark Andrews wrote: > > > You say MUST query for SPF and if there is a NO DATA response you > > MAY query for TXT. Modern spf libraries already do this. Legacy > > SPF checkers are no longer compliant. Even checkers running under > > Windows can meet this MUST. > > I am an SPF validator. On day 0, there are very few people publishing > SPF-99 records, and many publishing SPF-16 records. I have a lot of > mail volume coming in. What is my incentive to embrace SPFCheckNG? > Please address the latency effects for large mail operators. Most of the latency should be handled be handled in app / on machine DNS caches. Add dns hammer support in the caches and almost all of the rest of the latency is gone. > > You say that nameservers SHOULD synthesis SPF records from TXT > > v=spf1 records. This helps registrars stuck with broken web > > interfaces. Code for this is written. > > I'm an operator of a DNS zone. I publish TXT and SPF records. On day > 0, there are very few people publishing SPF-99 records. What is my > incentive to deploy code that aoutomatically increases my storage cost > and my opportunity for bugs, given that everyone who accepts my mail > is satisfied with SPF-16? Given there is code that synthesizes SPF records at query time that is a essentially a subset of DNS64 code (only looks at answers being retrieved from zone data). I would say there are zero storage costs and the code to do SPF synthesis is simple so there really is extremely low risk of bugs here. Would you like to audit it? DNS64 was 100x more complicated than SPF record synthesis yet we have RFC's for how to do that. > > You say that nameservers SHOULD reject loading of zones without SPF > > records when there are v=spf1 TXT records. This provides education > > for everybody else. Code for this is written. > > I'm an operator of a DNS zone. On day 0, my zone works. What is my > incentive to accept a new DNS server software update that makes my > zone broken, given that it was working on day 0-1? > > I offer my thanks in advance for your investigation of the answers to > the above. > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > 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 bmanning@karoshi.com Sat Aug 24 04:49: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 4FD8B21F9CC8 for ; Sat, 24 Aug 2013 04:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.188, 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 e1oec-evJwuC for ; Sat, 24 Aug 2013 04:49:20 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 731C821F9C13 for ; Sat, 24 Aug 2013 04:49:10 -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 r7OBn2dr030874; Sat, 24 Aug 2013 11:49:02 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r7OBn1h6030873; Sat, 24 Aug 2013 11:49:01 GMT Date: Sat, 24 Aug 2013 11:49:01 +0000 From: bmanning@vacation.karoshi.com To: Andrew Sullivan Message-ID: <20130824114901.GA30859@vacation.karoshi.com.> References: <20130821231150.91097.qmail@joyce.lan> <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130823221016.GX37406@mx1.yitter.info> User-Agent: Mutt/1.4.1i Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 11:49:26 -0000 On Fri, Aug 23, 2013 at 06:10:16PM -0400, Andrew Sullivan wrote: > On Sat, Aug 24, 2013 at 07:41:23AM +1000, Mark Andrews wrote: > > This is related to the point that I think Ted Lemon made elsewhere on > the topic: the big operators of mail are so big that if even one of > them were doing something with SPF, it would really move the needle. > The fact is that they're not, and the one who _was_ doing something > with it has given up because the additional query adds load and > latency for no benefit. > > A so on one hand, you have the second query (load & latency) ((exactly like a CA lookup)) v. the RR demux that has to occur for type 16. sounds like the tradeoff between code complexity and network latency... (is there a statement from the "one who _was_ doing something" as to why they changed?) Am I missing something? /bill From hallam@gmail.com Sat Aug 24 05:39: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 D250311E80EE; Sat, 24 Aug 2013 05:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 T43lPVvtSyE3; Sat, 24 Aug 2013 05:39:39 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BBFB911E80E9; Sat, 24 Aug 2013 05:39:38 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id r12so302604lbi.1 for ; Sat, 24 Aug 2013 05:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NA1OMCFbmP/wiUbmMqFk3MYYnlvqvUiuOXFfRnq0BDY=; b=N6IL5x0bRxJcj48fFiiUrJRlS+0v91AU9YFLrFQvG3RFgHQtgeTJnwD6PxOq331DXp LaVnbTP6/N+vQVf0uQ8Pe2SjqZzhtblCN7oi+fCWzBIVt77Ptttpj7iC98mITjMM1LSq wCtEyVGeWlrpnlmrPJYrS0FbLjET8j2IotXOb6+kc3xcWgy9Tic0vqJSQbFFOwHtrksU OBqJOQKhpYXRv0Q02lBimugHuPycxFmyQXJeYkA44/8jjRCb7SdyJn1TyEPPrlvFORPg jeah2MzDA91834NqVQK2mTSkI7vxjzNI92AMyq7MkpfQT5zW7J7RpBZLTm+4i7igMSqU DNlQ== MIME-Version: 1.0 X-Received: by 10.152.6.97 with SMTP id z1mr1519639laz.26.1377347976423; Sat, 24 Aug 2013 05:39:36 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Sat, 24 Aug 2013 05:39:36 -0700 (PDT) In-Reply-To: <5D4CC1CD-D897-4F46-91A7-02B8176F762A@isi.edu> References: <20130823180411.50961.qmail@joyce.lan> <5D4CC1CD-D897-4F46-91A7-02B8176F762A@isi.edu> Date: Sat, 24 Aug 2013 08:39:36 -0400 Message-ID: From: Phillip Hallam-Baker To: manning bill Content-Type: multipart/alternative; boundary=089e01493964ddef0704e4b0d0a1 Cc: "ietf@ietf.org list" , "dnsext@ietf.org" Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 12:39:40 -0000 --089e01493964ddef0704e4b0d0a1 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 23, 2013 at 3:46 PM, manning bill wrote: > > the question is not that "nobody" checks type 99, the question is > "is the rate of adoption > of type 99 -changing- in relation to type 16? > As John pointed out, support for checking type 99 has decreased and continues to decrease rather than increase. So waiting longer is not going to solve the issue. Putting a statement in an RFC does not mean that the world will automatically advance towards that particular end state. Forcing a WG to adopt a position to suit another constituency is not going to lead them to advocate for that position in deployment constituencies. Particularly when the original constituency does nothing to advance deployment. -- Website: http://hallambaker.com/ --089e01493964ddef0704e4b0d0a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Aug 23, 2013 at 3:46 PM, manning bill <= ;bmanning@isi.edu= > wrote:

=A0 =A0 =A0 =A0 the question is not that "nobody" checks type 99,= the question is "is the rate of adoption
=A0 =A0 =A0 =A0 of type 99 -changing- in relation to type 16?

As John pointed out, support for checking type 99 ha= s decreased and continues to decrease rather than increase. So waiting long= er is not going to solve the issue.

Putting a statement in an RFC does not mean that the wo= rld will automatically advance towards that particular end state.

Forcing a WG to adopt a position to suit another constituen= cy is not going to lead them to advocate for that position in deployment co= nstituencies. Particularly when the original constituency does nothing to a= dvance deployment.=A0


--
Website: http://hallambaker.com/
--089e01493964ddef0704e4b0d0a1-- From cas@strotmann.de Sat Aug 24 07:29: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 7398911E80EF for ; Sat, 24 Aug 2013 07:29:41 -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 8jOYbN84JzIY for ; Sat, 24 Aug 2013 07:29:40 -0700 (PDT) Received: from csgate3.strotmann.de (cstrotm-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:f1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 67B8911E80DC for ; Sat, 24 Aug 2013 07:29:38 -0700 (PDT) Received: from csgate4.strotmann.de.strotmann.de (cstrotm-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:f1d::2]) by csgate3.strotmann.de (Postfix) with ESMTP id 6F58B50F8; Sat, 24 Aug 2013 16:29:32 +0200 (CEST) From: Carsten Strotmann To: Jay Daley References: <20130819222037.GA55876@mx1.yitter.info> <20130822184610.2640.qmail@joyce.lan> <1B8AAF77-A4CA-4328-A110-DF7833CCDE92@nzrs.net.nz> Date: Sat, 24 Aug 2013 16:29:31 +0200 In-Reply-To: <1B8AAF77-A4CA-4328-A110-DF7833CCDE92@nzrs.net.nz> (Jay Daley's message of "Fri, 23 Aug 2013 07:38:43 +1200") Message-ID: <877gfbrwl0.fsf@csgate4.strotmann.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Deprecating SPF 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, 24 Aug 2013 14:29:41 -0000 Hi Jay, below are my findings from a test I did in May 2008. I'm redoing the same test next week with the latest Windows 2012R2 and will post the results here. The zone-transfer issue mentioned in the text below has been reported to Microsoft and has been fixed soon after. Jay Daley writes: > > I'm now really confused about what Microsoft DNS does and doesn't > support. Does anyone have any up to date, genuine evidence to answer > the following questions: > ---- ( Text from May 2008 ) ----- I did some testing with the Windows 2008 DNS Server and if the DNS Server can work when receiving RRs unknown to this DNS Server from an other DNS Server by AXFR. The Windows 2009 DNS Server supports these RRs natively from the GUI or the Commandline tool (dnscmd.exe): AFSDB CNAME ATMA A AAAA HINFO ISDN MX MG MB MINFO NXT PTR KEY MR RP RT SRV SIG TXT WKS X25 WINS (link to WINS Forward lookup, non-standard) WINS-R (link to WINS Reverse lookup, non-standard) DNAME (only via dnscmd.exe) Test setup: Master-DNS: BIND 9.4.3b1 Slave-DNS: Windows 2008 Enterprise Server GA, Windows DNS Server Version 6.0.6001.18000 Queries tested with DIG 9.4.2 WINDOWS I've only done tests with a few RRs, namely with NAPTR, DNAME, SPF, DS and DLV. The results vary between a normal zone refresh and a newly create slave zone. When creating the slave zone fresh, all unknown RRs are transferred and stored: - ----------- SPF: Master (BIND): @ IN SPF "v=spf1 +mx a:mail.strotmann.de/32 -all" Slave (Windows 2008): @ 86400 #99 26 76 3d 73 70 66 31 20 2b 6d 78 20 61 3a 6d 61 69 6c 2e 73 74 72 6f 74 6d 61 6e 6e 2e 64 65 2f 33 32 20 2d 61 6c 6c - ----------- NAPTR: Master (BIND): _test IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:information@pbx.example.com!" . Slave (Windows 2008): _test 86400 NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:information@pbx.example.com!" . - ----------- DNAME: Master (BIND): dname IN DNAME example.com. Slave (Windows 2008): dname 86400 DNAME example.com. - ----------- DS: Master (BIND): dskey IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A 98631FAD1A292118 ) Slave (Windows 2008): dskey 86400 43 ffffffec 45 05 01 2b ffffffb1 ffffff83 ffffffaf 5f 22 58 ffffff81 79 ffffffa5 3b 0a ffffff98 63 1f ffffffad 1a 29 21 18 - ----------- DLV: Master (BIND): dlv IN DLV 60485 5 1 ( 2BB183AF5F22588179A53B0A 98631FAD1A292118 ) Slave (Windows 2008): dlv 86400 #32769 ffffffec 45 05 01 2b ffffffb1 ffffff83 ffffffaf 5f 22 58 ffffff81 79 ffffffa5 3b 0a ffffff98 63 1f ffffffad 1a 29 21 18 However, the situation is different when doing a incremental (AXFR style IXFR) zone refresh from the Slave to the master (non-initial update): NAPTR - shown as "Unknown" in GUI, but shown in correct format in the zone file on disk. Queries from DIG for these RR are answered correct. DNAME - shown as "Unknown" in GUI, but shown in correct format in the zone file on disk. Queries from DIG for these RR are answered correct. SPF/DS/DLV - when there is an SPF/DS/DLV record (and probably any other record unknown to the DNS Server engine) in the zone on the master, the Windows 2008 DNS Server only stores the new SOA record and does not load any other RR from the zone. There is no error message in the message log on this failed attempt to transfer the zone, instead there is an log message of type "INFORMATION" saying that the zone has been successful transferred ans written to disk. Queries against the zone are answered with NOERROR/NODATA except for the SOA record, which is returned as an answer. Attempts to do an AXFR against the slave zone on the Windows 2008 server are failing. So initially, when the zone is created, the zonetransfer including unknown RRs works. Windows 2008 is using a standard AXFR here. However when at a later time the zone changes, the zonetransfer fails silently and the slave zone becomes unusable. Windows 2008 DNS Server is using an "AXFR style IXFR" here. BIND log entry of initial AXFR from Windows 2008 DNS Server: 25-May-2008 22:42:29.671 client 217.255.147.5#35580: transfer of 'example.com/IN': AXFR started 25-May-2008 22:42:29.673 client 217.255.147.5#35580: transfer of 'example.com/IN': AXFR ended BIND log entry of refresh AXFR from Windows 2008 DNS Server: 25-May-2008 22:52:30.308 client 217.255.147.5#41923: transfer of 'example.com/IN': AXFR-style IXFR started 25-May-2008 22:52:30.309 client 217.255.147.5#41923: transfer of 'example.com/IN': AXFR-style IXFR ended -----( End text from May 2008 ) ------ Carsten Strotmann From cas@strotmann.de Sat Aug 24 07:57: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 045A511E810B for ; Sat, 24 Aug 2013 07:57:18 -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 TVTBYGprzGVZ for ; Sat, 24 Aug 2013 07:57:17 -0700 (PDT) Received: from csgate3.strotmann.de (cstrotm-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:f1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6315A11E80EF for ; Sat, 24 Aug 2013 07:57:17 -0700 (PDT) Received: from csgate4.strotmann.de.strotmann.de (cstrotm-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:f1d::2]) by csgate3.strotmann.de (Postfix) with ESMTP id 4B9D750F8; Sat, 24 Aug 2013 16:57:13 +0200 (CEST) From: Carsten Strotmann To: "John R Levine" References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> Date: Sat, 24 Aug 2013 16:57:13 +0200 In-Reply-To: (John R. Levine's message of "21 Aug 2013 19:30:59 -0400") Message-ID: <8738pzrvau.fsf@csgate4.strotmann.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 24 Aug 2013 14:57:19 -0000 "John R Levine" writes: > Right, but the web provisioning crudware that people use in front of > BIND generally can't handle anything other than A, MX, CNAME, and TXT, > so for anything else you have to get someone with direct access to the > host to edit the master file. Like I said, sounds just the same. There are some GUI tools that don't, there are some that do support SPF (and other 'new' RR types). Good IETF standards can help customers to make the right purchase decisions and give incentive to vendors/programmers to implement support for 'new' RR types. The current support in GUI tools should not be the guide for a standards discussion. As a teacher teaching DNS classes, I found that most of the students coming to class have never heard of the SPF record (although most of them deploy SPF with TXT records). The web is full of SPF tutorials using TXT records that will never be updated. The new warnings in BIND 9.9 (warns if TXT-SPF is in zone, but no SPF RR) is a low cost, very effective way to inform DNS admins about the exsistence of the SPF record, and a warning message in the logs is incentive for many DNS admins to look up information on SPF records, and then deploy the SPF record. Only a few DNS admins have updated to BIND 9.9 by now, I'm curious about the effect once BIND 9.9 will be in the big Linux server distros (RedHat, Ubuntu-Server, SLES ...). Maybe the SPF to TXT ration will change when that happens. -- Carsten From hsantos@isdg.net Sat Aug 24 08:18: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 5B14021F89A6 for ; Sat, 24 Aug 2013 08:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 5SgEtmA7FO3V for ; Sat, 24 Aug 2013 08:17:54 -0700 (PDT) Received: from mail.santronics.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E29A221F8925 for ; Sat, 24 Aug 2013 08:17:53 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2197; t=1377357471; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=C8lLelEkxoE2LZD7LiMcGhWYCIk=; b=jKKjjwAzIX+rA2n4D+Yp Y9CQuEH/9LHOyQGBOxz+n4lw97s5hu4se+uamL1F401WE0nKDUk/Wf8pVZhB9tYO ay0BBebcqbeTZ/+XFHdrz5HZgSRee0WyWTyCf6+BrGy8YsKMDiHIFEoOxL3t29ag 50r07kjq7B+hFDVLZMeVOJg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Sat, 24 Aug 2013 11:17:51 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3819983052.4187.5160; Sat, 24 Aug 2013 11:17:49 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2197; t=1377357154; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=uTGOIyA 3H1pfM7TwWjNdlutvOTTMlw2pyFUsfwroGNQ=; b=y6wYq/hSRd/3VzExJpAwnnr 2CpZ7zNd1SFOifGkDMra16VR25Puum2yvldOQDjYIyGh5LVo6ONOr4AQzauLq+WI fdA5R8K70jZhuXOHFtJvHKzyE6y3zyD9LTX024luh4rDPbUCrt/GhYnic5USiRY3 HRGKBtZvqRS+kSMHO+YI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Sat, 24 Aug 2013 11:12:34 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3266402440.9.4112; Sat, 24 Aug 2013 11:12:33 -0400 Message-ID: <5218CE91.1050508@isdg.net> Date: Sat, 24 Aug 2013 11:17:37 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Carsten Strotmann References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> In-Reply-To: <8738pzrvau.fsf@csgate4.strotmann.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 24 Aug 2013 15:18:07 -0000 +1 to all your points. Plus a visible Microsoft DNS support out of the box would also encourage Windows tools developers to support it. Where is Microsoft in these IETF DNS forums? Does anyone have a direct contact with the current MS DNS Product Manager? An awful lot of guessing going on when this can be resolved in no time. Its not just about SPF type99 support, but also RFC3597 and future support for new RR type proposals. -- HLS Carsten Strotmann wrote: > "John R Levine" writes: > >> Right, but the web provisioning crudware that people use in front of >> BIND generally can't handle anything other than A, MX, CNAME, and TXT, >> so for anything else you have to get someone with direct access to the >> host to edit the master file. Like I said, sounds just the same. > > There are some GUI tools that don't, there are some that do support SPF > (and other 'new' RR types). Good IETF standards can help customers to > make the right purchase decisions and give incentive to > vendors/programmers to implement support for 'new' RR types. > > The current support in GUI tools should not be the guide for a standards > discussion. > > As a teacher teaching DNS classes, I found that most of the students > coming to class have never heard of the SPF record (although most of > them deploy SPF with TXT records). The web is full of SPF tutorials > using TXT records that will never be updated. > > The new warnings in BIND 9.9 (warns if TXT-SPF is in zone, but no SPF > RR) is a low cost, very effective way to inform DNS admins about the > exsistence of the SPF record, and a warning message in the logs is > incentive for many DNS admins to look up information on SPF records, and > then deploy the SPF record. > > Only a few DNS admins have updated to BIND 9.9 by now, I'm curious about > the effect once BIND 9.9 will be in the big Linux server distros > (RedHat, Ubuntu-Server, SLES ...). Maybe the SPF to TXT ration will > change when that happens. > > -- Carsten > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > From hsantos@isdg.net Sat Aug 24 09:27: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 B4AF111E8136 for ; Sat, 24 Aug 2013 09:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 I290WgE0-nWk for ; Sat, 24 Aug 2013 09:27:05 -0700 (PDT) Received: from dkim.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 35C3A11E80D9 for ; Sat, 24 Aug 2013 09:27:04 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2368; t=1377361620; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=R/y9uqWIBRyn/0CeTsN7Qo0niEg=; b=GId9J2l5K+D3MB61dlB+ kVf4Qm3bOywEFzOww9Aeb+3nKz9x5+apFdJsK59MKWSCpQlXj20pyoMjq1buL2eU WH9M2WiMFdBRRjRZMgn/YvfqJmNuyZIf2PpnrYW6p0GK91lOcePxU/u9QLHdJ98e kMfQgFamoNCUG5mXv+tmNGQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Sat, 24 Aug 2013 12:27:00 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3824133256.4187.3792; Sat, 24 Aug 2013 12:26:59 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2368; t=1377361304; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=J1j3wK8 Fy/YnffF0cjgInHDB9Qtkn/81cStws6Ztq1Y=; b=emyjTpzjWI3Y1L9+wQ/T0T/ OO/NsSvDDJsHiZvj2Si7Xhmf4I0l4WmH5J/Yp4Ko5LbFY1wB5mioqWZXDSPWRj07 kO3h1EDr4eyADAKdhY50wmI/KpmETMDGDebbLQeAEW0YY5l3jZ2VWiAw8YquZjdK tN5GYAtABpJRSeYNMwJA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Sat, 24 Aug 2013 12:21:44 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3270551502.9.2168; Sat, 24 Aug 2013 12:21:42 -0400 Message-ID: <5218DEC9.3070600@isdg.net> Date: Sat, 24 Aug 2013 12:26:49 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 References: <20130823180411.50961.qmail@joyce.lan> <5D4CC1CD-D897-4F46-91A7-02B8176F762A@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: dnsext@ietf.org Cc: "ietf@ietf.org list" , "dnsext@ietf.org" Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 16:27:10 -0000 Phillip Hallam-Baker wrote: > On Fri, Aug 23, 2013 at 3:46 PM, manning bill wrote: > >> the question is not that "nobody" checks type 99, the question is >> "is the rate of adoption >> of type 99 -changing- in relation to type 16? >> > > As John pointed out, support for checking type 99 has decreased and > continues to decrease rather than increase. So waiting longer is not going > to solve the issue. However, the interest never disappeared. The issue is what are we waiting for now? The DNS infrastructure support? Why it that such a problem? Who goes to these IETF meetings? Where are the Microsoft DNS product managers in these discussions? What do they have to say? > > Putting a statement in an RFC does not mean that the world will > automatically advance towards that particular end state. Thats correct. No one is forced to support RFC 4408bis. From my perspective, there are four basic major changes to BIS - all optional: 1 - Add Authentication-Result: 5322.header. 2 - Relax SPF HardFail Policy rejections to Accept-Mark operations. 3 - If 2 is perform, then add code to separate user failed messages. 4 - Remove any support for SPF type99 queries and publishing. For our SPF implementation, we never did #4 for lack of infrastructure readiness but are ready to support once the the backbone is ready for it. We will probably will do #1 for all non-HARDFAIL result but we won't do #2 because it will cause a high redesign cost with #3. Not performing #3 would be a major security loophole is you begin to support #2. Until we are ready to do #3 and close that security loophole, #2 won't happen. > Forcing a WG to adopt a position to suit another constituency is not going > to lead them to advocate for that position in deployment constituencies. > Particularly when the original constituency does nothing to advance > deployment. +1, but the decision makers really haven't ask the main DNS constituencies why they have not advanced their (DNS) software or made it flexible enough for another operators and administrators to add/manage new RR types or capable of passive and transparent handling of unknown type recursive passthru queries. To me, this should be a project leadership responsibility to make sure the protocol requirements are realistic are not. -- HLS From hsantos@isdg.net Sat Aug 24 09:40:16 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 8A8CC11E813F for ; Sat, 24 Aug 2013 09:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 wqor1feZpTSq for ; Sat, 24 Aug 2013 09:40:11 -0700 (PDT) Received: from dkim.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD9411E8139 for ; Sat, 24 Aug 2013 09:40:07 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1752; t=1377362400; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=IbVsgFoxWMyYYfh9FPB8rbQms00=; b=woEwmXgdDhD9Hhw5kUzI 1Jz40upSE+fKLojiJvrlBs3+QGMVQjMVKulLTacqmSX2yJ706IUaiLeT0JRG9o6t vX1zxslsJ7Ob3tG3y2AodofURi8Cc9Ydr/Wm486Fw0MQxTGy5T67rhM+KEk8Znn0 18649ImJ3jxCfUjWLtSnkcU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Sat, 24 Aug 2013 12:40:00 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3824913401.4187.4900; Sat, 24 Aug 2013 12:39:59 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1752; t=1377362087; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=DXr0Xkr ZlLPx2lpc5ynV081kfcTdgogGFqnm4Qr3KmU=; b=wvfJVt/bRKyChV+cCpF6wI2 b3i2l4XFdXLGFPHL0G+ouhJqhgvW5/Xd6Y6W9/VUuRe/YVwa7R/0pTPMP2p4tEFZ zSrJadoxnHum3Ogx09hTlCzaGtoFN2aZNMjm0KUemAMTfX/kr8ex0nnkQFRd5iF8 tp5hTCYGO/qv96NyqWlc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Sat, 24 Aug 2013 12:34:47 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3271335237.9.2208; Sat, 24 Aug 2013 12:34:46 -0400 Message-ID: <5218E1D8.9000604@isdg.net> Date: Sat, 24 Aug 2013 12:39:52 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ietf@ietf.org References: <20130823180411.50961.qmail@joyce.lan> <5D4CC1CD-D897-4F46-91A7-02B8176F762A@isi.edu> <5218DEC9.3070600@isdg.net> In-Reply-To: <5218DEC9.3070600@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dnsext@ietf.org" Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 16:40:16 -0000 Hector Santos wrote: > Phillip Hallam-Baker wrote: >> Putting a statement in an RFC does not mean that the world will >> automatically advance towards that particular end state. > > Thats correct. No one is forced to support RFC 4408bis. From my > perspective, there are four basic major changes to BIS - all optional: > > 1 - Add Authentication-Result: 5322.header. > 2 - Relax SPF HardFail Policy rejections to Accept-Mark operations. > 3 - If 2 is perform, then add code to separate user failed messages. > 4 - Remove any support for SPF type99 queries and publishing. > > For our SPF implementation, we never did #4 for lack of infrastructure > readiness but are ready to support once the the backbone is ready for > it. We will probably will do #1 for all non-HARDFAIL result but we won't > do #2 because it will cause a high redesign cost with #3. Not > performing #3 would be a major security loophole is you begin to support > #2. Until we are ready to do #3 and close that security loophole, #2 > won't happen. I should add: 5- Deprecate PTR by removing PTR publishing support We won't advocate this because for our small to mid size market, this is the lowest cost setup for them - using a PTR. For all our domains, we use PTR as well. No need to change it. This is one of those "Set it and Forget it" SPF record setups. Using the PTR was the default arrangement for most small/mid operations provided by most if not all the SPF Web Wizards. This was removed in Scott's popular SPF wizard but not in other SPF wizards. Note: The overhead concerns are passe with the trend of SMTP receivers doing PTR lookups, thus any transaction SPF validator will not contribute to any PTR network overhead. -- HLS From johnl@taugh.com Sat Aug 24 09:40: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 0C59511E8145 for ; Sat, 24 Aug 2013 09:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.007, 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 NlThkUt1yRCr for ; Sat, 24 Aug 2013 09:40:20 -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 CD1E311E8142 for ; Sat, 24 Aug 2013 09:40:17 -0700 (PDT) Received: (qmail 48545 invoked from network); 24 Aug 2013 16:40:17 -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=bd9f.5218e1f1.k1308; bh=CKkeQXwDP7ViFrSbKgDLHf9PW/5atZurgFeyBeLkgJM=; b=XyoOIU9suKnIlTplhhJcQdQZLEZE2KXvQ0XQVhtq9S+Ou8cNdGTaIk1rsCrrf6Y/6BQvoFQLoro4cpWJfEeb18k8IEAIAeFp6Z15xauPUFR5W1+fa5uXX+csDHhJaTc8T39Hp8x0RWKIQcj4f1djZDJk9Y1zeJNvoSiR4fw9u8CW9OvrZLx1vJ8UR3FLkn65bHfb/QbxkgHv/3R+1zcqq7cJSToPzsuNFqGZ2saR5pkrowxSJqiJICSvRgrjVW77 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=bd9f.5218e1f1.k1308; bh=CKkeQXwDP7ViFrSbKgDLHf9PW/5atZurgFeyBeLkgJM=; b=FDJR7oL1cC41qouzO/fTzubu5pKtuJxeHllFV8+WLt15LDcU6VfNr1J5RAhaRPvSuIRCtWa0X2lmfnWPhwjhV7YdrBaGaEMKa1JRw9EXw3qgQkPtUKCL7g7i6SbU1KoRaQa5APmE/ke77WU1jLFJ0nQrfImC498x4vI8Q2YmfZdYWBukjmHpX5ngU35Cuq3p10aBmZ/Ztwlq0c2QVItrsM5/If83QHkgZB4xq3FJJP8fqYpAkov//cZruSCH2kh2 Received: (ofmipd 127.0.0.1); 24 Aug 2013 16:39:54 -0000 Date: 24 Aug 2013 12:40:16 -0400 Message-ID: From: "John R Levine" To: "Carsten Strotmann" In-Reply-To: <8738pzrvau.fsf@csgate4.strotmann.de> References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 24 Aug 2013 16:40:21 -0000 > The current support in GUI tools should not be the guide for a standards > discussion. The dnsext regulars have been denying for years that provisioning is an issue, so it's dismaying but not surprising to see that hasn't changed. Ten years ago when SPF was new, its designers considered and rejected using a _spf prefix because so many of the provisioning systems that mail managers had to use to provision real mail systems didn't permit underscores in names. That particular bug has been fixed, but support for type 99, seven years after the RR was defined, is where the underscores were a decade ago. A few provisioning systems handle it, most don't, so in practice people can't use it. You can tell your students to use it, but when they get back to their offices, their system managers will tell them sorry, can't do that. What use is that? Someone pointed out some mail exchanges earlier this year where users asked providers for type 99 support, and the providers said they'd wait to see what the IETF did. This tells us two things: one is that after seven years, providers still consider type 99 to be entirely optional, but the more important is that adding new RRs to provisioning systems is still much too hard. (If it were just adding three lines to a table, I expect the providers would have done so rather than arguing with their users.) Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. PS: Something like my dns extension proposal should allow providers to fix the new RR configuration problem once and for all, so I've always been surprised at the hostile reception to it. From hsantos@isdg.net Sat Aug 24 09:54:29 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 C24D111E8149 for ; Sat, 24 Aug 2013 09:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 6sC8aJ3OW+3j for ; Sat, 24 Aug 2013 09:54:24 -0700 (PDT) Received: from mail.santronics.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 155D911E813F for ; Sat, 24 Aug 2013 09:54:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=319; t=1377363250; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=ioC/syR8zcXX+yZNloPVS3kZGBU=; b=IsvXl/Go5PO8iETyM4Cw 8E8wHbzHafXxGJrI7tz8VATNSJjV42JByzfG5sJttDyFHrlGSnDIxtR8ek0lrg7g Q75PitbHtJxs2d2cCzqRIGfz6sjihPknzOBXmNYKyx3z4YelMAZIOAvUFeAp+s42 HPkr/aF+NRlUND5PCI/8j04= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Sat, 24 Aug 2013 12:54:10 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3825763669.4187.3288; Sat, 24 Aug 2013 12:54:10 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=319; t=1377362936; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=U/7v0vi fB2NyhW3f3AAqk7Fx0c/D8ja+yFzGdDTwDKE=; b=EcQIAYrBNn6krJDuJhfpzwA 4W1SAIpkfmfVl7/pmEjNoMgxkwARCb/+4DSWcM32nlz1fF4l/xZ1fXFUBSGi48Jy a3KiJheMz1DzmH3cblfLaEb3zyEhpg+us84PiFjIAlWmtPTjQRSmVD2E18thv32Y jeBXgmptcD9fiKhNu5tk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dnsext@ietf.org; Sat, 24 Aug 2013 12:48:56 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3272183987.9.4204; Sat, 24 Aug 2013 12:48:55 -0400 Message-ID: <5218E528.1080706@isdg.net> Date: Sat, 24 Aug 2013 12:54:00 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: dnsext@ietf.org References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 24 Aug 2013 16:54:29 -0000 John R Levine wrote: > PS: Something like my dns extension proposal should allow providers to > fix the new RR configuration problem once and for all, so I've always > been surprised at the hostile reception to it. Will it or can it work with Microsoft DNS servers? They are part of the world too. -- HLS From bmanning@karoshi.com Sat Aug 24 10:43: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 9A77911E8159; Sat, 24 Aug 2013 10:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 l2uOC9tbBETP; Sat, 24 Aug 2013 10:43:40 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 685CB11E80E3; Sat, 24 Aug 2013 10:43: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 r7OHhDdr031921; Sat, 24 Aug 2013 17:43:23 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r7OHhAXi031920; Sat, 24 Aug 2013 17:43:10 GMT Date: Sat, 24 Aug 2013 17:43:10 +0000 From: bmanning@vacation.karoshi.com To: Phillip Hallam-Baker Message-ID: <20130824174310.GB31770@vacation.karoshi.com.> References: <20130823180411.50961.qmail@joyce.lan> <5D4CC1CD-D897-4F46-91A7-02B8176F762A@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "dnsext@ietf.org" , "ietf@ietf.org list" , manning bill Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 17:43:44 -0000 On Sat, Aug 24, 2013 at 08:39:36AM -0400, Phillip Hallam-Baker wrote: > On Fri, Aug 23, 2013 at 3:46 PM, manning bill wrote: > > > > > the question is not that "nobody" checks type 99, the question is > > "is the rate of adoption > > of type 99 -changing- in relation to type 16? > > > > As John pointed out, support for checking type 99 has decreased and > continues to decrease rather than increase. So waiting longer is not going > to solve the issue. that is unclear... we have second hand reports, but only actual data from very recent DNS logs. did those numbers increase or decrease? No evidence has been presented. > Putting a statement in an RFC does not mean that the world will > automatically advance towards that particular end state. ain't it the truth. -BUT- its still worthwhile documenting the best technical path and why it was abandoned. The issues wrt wildcards (thanks), DNSSEC considerations, and code overhead to demux type 16 vs. the temporary problem of two lookups -IF- type 99 is not used, plus past guidance from the IAB and the IESG really need to make it into a document in the RFC cannon. > Forcing a WG to adopt a position to suit another constituency is not going > to lead them to advocate for that position in deployment constituencies. > Particularly when the original constituency does nothing to advance > deployment. Dorthy Parker said: "You can lead a whore to culture, but you can't make her think". Point the bias arrow either way youd like. And as stated elsewhere, if Yahoo, Google, Microsoft, AOL, et.al. were simply waiting for the IETF to settle on a solution, I'll raise O'Dells law; "The installed base does not matter". End of the day, the SPFBIS wg is adament in their choice, document, explain and move on. Robert Heinlein: Never try to teach a pig to sing; it wastes your time and it annoys the pig. I think the SPFBIS folks are annoyed enough... > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From ajs@anvilwalrusden.com Sat Aug 24 11:01: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 EF7C211E8152 for ; Sat, 24 Aug 2013 11:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 o6mvQAlswrcy for ; Sat, 24 Aug 2013 11:01:37 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 33C5911E8110 for ; Sat, 24 Aug 2013 11:01:37 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 75A148A031 for ; Sat, 24 Aug 2013 18:01:35 +0000 (UTC) Date: Sat, 24 Aug 2013 14:01:30 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130824180130.GA42558@mx1.yitter.info> References: <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com.> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <20130824114901.GA30859@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130824114901.GA30859@vacation.karoshi.com.> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 18:01:43 -0000 On Sat, Aug 24, 2013 at 11:49:01AM +0000, bmanning@vacation.karoshi.com wrote: > so on one hand, you have the second query (load & latency) > ((exactly like a CA lookup)) v. the RR demux that has to occur > for type 16. > > sounds like the tradeoff between code complexity and network latency... Except that as a matter of fact, one of them is very likely to be needless cost. That is, you're going to need to cope with the TXT record _anyway_, because that's what's deployed everywhere. So you have to pay cost of code complexity for demuxing no matter what. The question is only whether we'll still have the code complexity of handling two RRTYPEs and have the additional latency of the extra lookup. This is exactly the question the WG looked at, and concluded that it was a bad trade. This is all in the WG list archives, and you are making no new argument. > (is there a statement from the "one who _was_ doing something" as to > why they changed?) Not to my knowledge. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From hadriel.kaplan@oracle.com Sat Aug 24 11:39: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 8F53211E8139 for ; Sat, 24 Aug 2013 11:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 4YG6R9AFDYTm for ; Sat, 24 Aug 2013 11:39:49 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0416721F9A04 for ; Sat, 24 Aug 2013 11:39:48 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7OIdgU6021442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Aug 2013 18:39:44 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7OIdeZ5024192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Aug 2013 18:39:41 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7OIdeEo014801; Sat, 24 Aug 2013 18:39:40 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 24 Aug 2013 11:39:40 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <00B88CDF-B349-4DB0-AF33-BBEA1BA106EA@virtualized.org> Date: Sat, 24 Aug 2013 14:39:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4DFF5EA9-3858-46E8-ACDB-74BC76DCEF7D@oracle.com> References: <7198ADE6-80E9-4660-8613-43E9FCC04E70@alex.org.uk> <6.2.5.6.2.20130822134512.0b70d6f0@resistor.net> <20130823022611.GA23695@vacation.karoshi.com> <20130823075612.GA19081@besserwisser.org> <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <32389F5D-6B76-4286-BE21-08B71A9598F0@hopcount.ca> <20130824005705.GB5854@mx1.yitter.info> <00B88CDF-B349-4DB0-AF33-BBEA1BA106EA@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 18:39:55 -0000 On Aug 23, 2013, at 9:40 PM, David Conrad wrote: > As far as I can tell, the issue isn't whether the SPF RR is being used = (it appears to be, albeit at a tiny percentage relative to TXT = currently), rather it's whether or not a handful of major mail service = providers will use SPF RRs in the future if the IETF were to document a = fix to the broken transition strategy in 4408.=20 [not to counter your statement above, but rather to pile on...] I'm just a simple email user and not involved in the email world, but = ISTM it's not just what major mail service providers use, but major mail = servers/MTAs as well - for example those used by the corporate world. = MS Exchange, for example, and any "front-end" spam-filtering-thingies = put between it and the Internet. And other corporate-market-focused = server vendors. No? =20 My employer's email server products, for example, appear to only do = type-16 TXT SPF queries. (though I could easily be wrong on that - it's = just what I see in the publicly-accessible user docs) Likewise that's = what it appears to be for MS Exchange, of various versions, though again = I could be wrong. -hadriel disclaimer: this email does not represent Oracle in any way, I am merely = speaking as an individual. Oracle products may well do type-99 checking = already today, or in the near-future, for all I know. From hadriel.kaplan@oracle.com Sat Aug 24 11:40: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 2369A11E8169 for ; Sat, 24 Aug 2013 11:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 xDN6bhdIzj6x for ; Sat, 24 Aug 2013 11:40:14 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5F84E11E8168 for ; Sat, 24 Aug 2013 11:40:14 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7OIe8HM002861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Aug 2013 18:40:08 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7OIe7pM009551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Aug 2013 18:40:08 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7OIe7Ed009548; Sat, 24 Aug 2013 18:40:07 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 24 Aug 2013 11:40:07 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <20130824041410.0D8DE38D4DFA@drugs.dv.isc.org> Date: Sat, 24 Aug 2013 14:40:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1F19C898-711C-4EEE-9B01-189E4A575299@oracle.com> References: <521760FD.7090202@sidn.nl> <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <32389F5D-6B76-4286-BE21-08B71A9598F0@hopcount.ca> <20130824005705.GB5854@mx1.yitter.info> <00B88CDF-B349-4DB0-AF33-BBEA1BA106EA@virtualized.org> <20130824020218.GB5888@mx1.yitter.info> <20130824023657.9777838D42FF@drugs.dv.isc.org> <20130824031754.GC5888@mx1.yitter.info> <20130824041410.0D8DE38D4DFA@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 18:40:21 -0000 On Aug 24, 2013, at 12:14 AM, Mark Andrews wrote: >=20 > In message <20130824031754.GC5888@mx1.yitter.info>, Andrew Sullivan = writes: >> I am an SPF validator. On day 0, there are very few people = publishing >> SPF-99 records, and many publishing SPF-16 records. I have a lot of >> mail volume coming in. What is my incentive to embrace SPFCheckNG? >> Please address the latency effects for large mail operators. >=20 > Most of the latency should be handled be handled in app / on machine > DNS caches. Add dns hammer support in the caches and almost all > of the rest of the latency is gone. I don't follow that logic. I work for a vendor that makes an MTA. As = far as I can tell from publicly-accessible docs, it only does type-16 = today. If I were to put myself in a product manager's shoes, I don't see any = reason I'd implement a type-99 check. Obviously if type-99 was the = *only* RR available from some significant population of domains, we = might change our MTA to also do a type-99. But if everyone makes TXT = type-16 available in DNS as well, what motivation would we have to do = type-99 first, or even at all? Why would we bother with the additional = overhead? I mean if you didn't have a type-16 SPF in your DNS, what are = the odds you have a type-99? It's not as simple as: "but the code is easy to write". For one thing = any functional change in commercial products is far more work and cost = than just a developer changing some lines of code. For another, = customers don't really care about IETF RFC conformance checklists much - = they care about things working. Adding processing or delay overhead has = to provide some new real benefit, for them. Pain for no gain makes no = sense, to both vendors and their customers. And if major MTA vendors and providers only do type-16 checks, what = motivation is there for people to stop putting type-16 in their DNS? = You'd want *everyone* to be able to check your domain's SPF, I would = think. Not just those querying for type-99. Right? -hadriel disclaimer: this email does not represent Oracle in any way, I am merely = speaking as an individual. Oracle products may well do type-99 checking = already today, or in the near-future, for all I know. From johnl@iecc.com Sat Aug 24 13:13:35 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 74AEF11E8174 for ; Sat, 24 Aug 2013 13:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.621 X-Spam-Level: X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 24492iiEbVX9 for ; Sat, 24 Aug 2013 13:13:25 -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 AE5E111E8107 for ; Sat, 24 Aug 2013 13:13:23 -0700 (PDT) Received: (qmail 95004 invoked from network); 24 Aug 2013 20:13:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Aug 2013 20:13:20 -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=521913e0.xn--btvx9d.k1308; i=johnl@user.iecc.com; bh=qW12H65MipqqL4zIMR2V4NfTsLUY+ZvctipvfBZgvq0=; b=SEcC3CAuYynjDqac/n6jaxU5R96urWXeKbtq8Bu6IGYU7jTrusXJxxkO4n3q6ZIxJlSUTS71bve1N01mXINpWvKeAJS/UeiLJ7F5yhnRZKY+V8hiaQ0NdsHbgXoXsQio69SASiaxB+ftPdZxCGnv/CDbUrNSQWTUj1yo2HC9suewPq/haKGzTsabthKencCvYhJaXDIEBgU5cNtnoSnlvn2o66gC5QGsEmEMu17ogB8kjwmEZFQSbozScy/iC81Z 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=521913e0.xn--btvx9d.k1308; olt=johnl@user.iecc.com; bh=qW12H65MipqqL4zIMR2V4NfTsLUY+ZvctipvfBZgvq0=; b=KRAtDGDDLi96iraDpikUg7O0n6cMkzQcGWy71jdS7XmkhsDtYuMqaaBIPyrpPsU53edWkeUJkKjO7QrhbgBY46gu6YUGN2WwlVtZUPq0tY5K6O2HQYqmjXPwcZDGIDjabkfv1oov1DxPuuGHWsAEuJ4hvSE3aFx3MtjkcW29DqFW1uFN8vugxzBrdtfqPWGkdhkdj9oqwmsa3dYVp+GaAvwftbcPniDv0UhGAikz2UgcfZ8F2CVQ83qsYnBH/qXJ Date: 24 Aug 2013 20:12:58 -0000 Message-ID: <20130824201258.60969.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <5218E528.1080706@isdg.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 24 Aug 2013 20:13:35 -0000 >> PS: Something like my dns extension proposal should allow providers to >> fix the new RR configuration problem once and for all, so I've always >> been surprised at the hostile reception to it. > >Will it or can it work with Microsoft DNS servers? They are part of >the world too. I don't see why not, if Microsoft wanted to implement it. R's, John From johnl@iecc.com Sat Aug 24 13:18: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 4B4CA21F944C for ; Sat, 24 Aug 2013 13:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.62 X-Spam-Level: X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 3keoxg-eo1Vs for ; Sat, 24 Aug 2013 13:18:07 -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 8959621F940D for ; Sat, 24 Aug 2013 13:18:06 -0700 (PDT) Received: (qmail 95972 invoked from network); 24 Aug 2013 20:18:05 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Aug 2013 20:18:05 -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=521914fd.xn--30v786c.k1308; i=johnl@user.iecc.com; bh=Wruh2nvnRd01M2MTDAeq9duwToQAANOvYlHuM2RaFPQ=; b=R8B7rgqrUdaval9EWExyv0nFL9dqLO7dUIbw5zDarpGoiENRXqPa1aM2KKLQQQD6OPL0m0vevyaCciGHXxnEun7jGy75oDu5FnghKfBeQIPW7xO96HmvqdSk+z4nzwffOb6epk7BNiG1AHuwWSREz83sUPiWimHxv3ssg3xl9EHMJTxWtWH3QNJ/KyNKFWvL/E6TXycbqQ+SdqwwU/obMlTVgK7lxcaD+oT1CWGyMV3+B6DGUrXliFBAQ93piYd4 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=521914fd.xn--30v786c.k1308; olt=johnl@user.iecc.com; bh=Wruh2nvnRd01M2MTDAeq9duwToQAANOvYlHuM2RaFPQ=; b=cE1VQtXC5Kg2TExtZwGOtgIMIs9seUvhm7L/1FysHM/KQ2vmNWr/jTu1/0S1lC+5c6fASHUreRhN6JrXbLVZbwrr2n3O1Eti05RUa9CaDU36Vd3UcgXYmaGgNRwZPliTIEglZhrEQMkupcGSidP6nLk/Gx9ySzaDQgdMm0r7t5v8ELZuyt7uPRqO0ufmds3vGK4czB4f4NL12Xrt69N1YqA9+WZGgVHHZnyvo3LeputtTTMiHc4uDXd7azDQ1P81 Date: 24 Aug 2013 20:17:43 -0000 Message-ID: <20130824201743.61006.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20130824180130.GA42558@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 24 Aug 2013 20:18:11 -0000 >> so on one hand, you have the second query (load & latency) >> ((exactly like a CA lookup)) v. the RR demux that has to occur >> for type 16. >> >> sounds like the tradeoff between code complexity and network latency... > >Except that as a matter of fact, one of them is very likely to be >needless cost. That is, you're going to need to cope with the TXT >record _anyway_, because that's what's deployed everywhere. So you >have to pay cost of code complexity for demuxing no matter what. Actually, it's worse than that. The SPF rules for handling type 16 and type 99 records are identical, so you have to make the same checks that there's exactly one record with the SPF prefix tag for type 99 records as you do for type 16. You pay the demux penalty, such as it is, for both. In practice, there are likely to be fewer type 99 records than type 16, but the CPU time for the checks is trivial compared to everything else a mail server does. We've seen at least one live example of invalid type 99 records that would fail the checks here in the past week, so the checks are not wasted effort. R's, John From marka@isc.org Sat Aug 24 14:34: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 E56D511E8119 for ; Sat, 24 Aug 2013 14:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 2OHXOAgNhLsz for ; Sat, 24 Aug 2013 14:34:19 -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 6FD1A11E8109 for ; Sat, 24 Aug 2013 14:34:17 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 8A36FC94BB; Sat, 24 Aug 2013 21:33:59 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377380052; bh=QRsN4ivKUk05HUjOS7Gn2eXUkIar8RAzZpwj9JM6+xE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=SJTDljqupqx0DABE7D0OjYkiDBYYokuWnm/54SwRDHdEUb6UJDAeZTDZmkcOlKoD5 MzsLnuCWNV15BHMAwKSz0VJlxf1RY5mgKDjTo0X7dq50smS+behb3XRZJnsOrd78H8 0sjl1IflPGt/YC/A6IhliReaDLF3aLfkzFSv43bc= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sat, 24 Aug 2013 21:33:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6A37B16042E; Sat, 24 Aug 2013 21:34:24 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 36646160033; Sat, 24 Aug 2013 21:34:24 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id CB42138D63BE; Sun, 25 Aug 2013 07:33:56 +1000 (EST) To: "John R Levine" From: Mark Andrews References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> In-reply-to: Your message of "24 Aug 2013 12:40:16 -0400." Date: Sun, 25 Aug 2013 07:33:56 +1000 Message-Id: <20130824213356.CB42138D63BE@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 24 Aug 2013 21:34:24 -0000 In message , "John R Levine" wri tes: > > The current support in GUI tools should not be the guide for a standards > > discussion. > > The dnsext regulars have been denying for years that provisioning is an > issue, so it's dismaying but not surprising to see that hasn't changed. The problem is no one is doing maintenance on some of those tools. The number of RR types was expected to grow from day one. New RR types have been added at a rate of about 1 a year for the entire history of the DNS. It doesn't help when companies charge 500% more to allow you to enter a SPF record. Yes that is bundled with a whole lot of other stuff but if all you want is the ability to add SPF it is going to cost you 500% more. Part of the problem is people don't know they be being badly treated by their registrars. They don't know that there should be AAAA and DNSSEC support in the GUI's. If registrars were to lose acceditation if they didn't add support for a record within 3 years of it being allocated you would see a big difference. People keep saying leave it to market forces. Market force only really work when the market is properly informed. The great unwashed out there are not informed. The same thing can be said of many of the registrars. > Ten years ago when SPF was new, its designers considered and rejected > using a _spf prefix because so many of the provisioning systems that mail > managers had to use to provision real mail systems didn't permit > underscores in names. That particular bug has been fixed, but support > for > type 99, seven years after the RR was defined, is where the underscores > were a decade ago. A few provisioning systems handle it, most don't, so > in practice people can't use it. You can tell your students to use it, > but when they get back to their offices, their system managers will tell > them sorry, can't do that. What use is that? > > Someone pointed out some mail exchanges earlier this year where users > asked providers for type 99 support, and the providers said they'd wait > to > see what the IETF did. This tells us two things: one is that after seven > years, providers still consider type 99 to be entirely optional, but the > more important is that adding new RRs to provisioning systems is still > much too hard. (If it were just adding three lines to a table, I expect > the providers would have done so rather than arguing with their users.) It also tells us if we were to say MUST lookup up SPF then they would add support. > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > > PS: Something like my dns extension proposal should allow providers to > fix > the new RR configuration problem once and for all, so I've always been > surprised at the hostile reception to it. > _______________________________________________ > 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 sm@resistor.net Sat Aug 24 15:48:01 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 CF7BE21F9223 for ; Sat, 24 Aug 2013 15:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 hPe7evW85c6Y for ; Sat, 24 Aug 2013 15:48:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9129921F8DA3 for ; Sat, 24 Aug 2013 15:47:59 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7OMlsYM025091; Sat, 24 Aug 2013 15:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377384479; bh=M2mlpUu1ExboXKACN+zJtF66a/8MiN6HvR+yOMzo+wA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lN86ywxLltBmx70Rxdh0k/rYPIf+pV/czf7TOUfn8SMm1pRdJmtop22VKQgHuzMcZ PWF0XAPWhuBYrC6xdN8LKNz6h81LZuqhQlhls+nRsBsnlJEaykzQZ3birDtXldpzPo HDpS5pyb7b60eyTWvonMR4vDR3R/FQhftNaCR7fU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1377384479; i=@resistor.net; bh=M2mlpUu1ExboXKACN+zJtF66a/8MiN6HvR+yOMzo+wA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YNyvW/Y90SnKr4At3SF4NfvsEL1n4Q8wqq3InFSjUZPzU/BsZFouWq/Z2gfzHx63y JRUlX8bnd+IvK4yt66mCXn7swHG1EvGShXAF2rov5Sq0OGvxQWRCxJu9Utyt6KexO7 DL8V/On+IJPa8e3JGqBNtoMIlAeq2QTIDnQqhAZA= Message-Id: <6.2.5.6.2.20130824145426.0b9c9540@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 24 Aug 2013 15:12:24 -0700 To: Mark Andrews From: SM In-Reply-To: <20130824213356.CB42138D63BE@drugs.dv.isc.org> References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 24 Aug 2013 22:48:01 -0000 Hi Mark, At 14:33 24-08-2013, Mark Andrews wrote: >The problem is no one is doing maintenance on some of those tools. Yes. >Part of the problem is people don't know they be being badly treated >by their registrars. They don't know that there should be AAAA and >DNSSEC support in the GUI's. Yes. >If registrars were to lose acceditation if they didn't add support >for a record within 3 years of it being allocated you would see a >big difference. It's unlikely that it will happen. >People keep saying leave it to market forces. Market force only really >work when the market is properly informed. The great unwashed out there >are not informed. The same thing can be said of many of the registrars. Yes. There are things that can be changed. Regards, -sm From jabley@hopcount.ca Sat Aug 24 16:10:43 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 79A6911E8199 for ; Sat, 24 Aug 2013 16:10:43 -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 Cn+kNtjhqM1f for ; Sat, 24 Aug 2013 16:10:42 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id D3C3D11E8108 for ; Sat, 24 Aug 2013 16:10:42 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so2022933pbc.35 for ; Sat, 24 Aug 2013 16:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R/nntWrBrHJww9UpbrBcxQp661D8ly1YIIqCOwPrpAQ=; b=axrvM5H3lWXYl2EV2nmRrUbvVA4IF0agVZtd4O0CrhaLdn+/TSie38VjxTpcPDga1r Hk2FRVz/R2xDEjD72tblO5AJpYlVpMvynuUCMIur4Iq55dlxjOC77PF1FULB4qmcYr0A 7xSMshg7ZoPN/Kl2B7JyY17cTfiEA2pN7h5iA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=R/nntWrBrHJww9UpbrBcxQp661D8ly1YIIqCOwPrpAQ=; b=fqh/uGfrC3O1RIsGpRGTHMqzKO9R5g2wfAPrOEgOs9fSyfNHEfx8PjQ0Cl8ci+Vjnu eYrVJy+IXfPASPAmkhlWnIcHwibnUHiM8mYdxnIwsFrw6oOfw8cwxBDveyhCV2S5vYPn 77iELCImWzjbl7WQQk30Ftbr3lRnfgWhFVQTc/L/LvXND1SZoBqZuacFgSXmyeNjULRn pNYhV5ZjuLtiFvBtdZTbUAEfJ4yghM9ZCu3oZBmR/8AOp9iW7Idp40D/5Wp8PTdPY8MX WqRXR2kvxvPvic2T7jQHFnBuHaHuosSsssxPiV93G9Z2AEw1wyVCZQkfy4MTC/IuXIYS RSTg== X-Gm-Message-State: ALoCoQlVekt1MqjQQ2YXiutkFf4H8XQofTxvkUqzzsx4sw7fZ8NNPZu5afjTzKu7TDH+9cEpEssU X-Received: by 10.66.162.136 with SMTP id ya8mr6278473pab.110.1377385842496; Sat, 24 Aug 2013 16:10:42 -0700 (PDT) Received: from [199.212.90.52] ([199.212.90.52]) by mx.google.com with ESMTPSA id jf4sm8401677pbb.19.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 16:10:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Joe Abley In-Reply-To: <20130824213356.CB42138D63BE@drugs.dv.isc.org> Date: Sat, 24 Aug 2013 16:10:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 24 Aug 2013 23:10:43 -0000 On 2013-08-24, at 14:33, Mark Andrews wrote: > Part of the problem is people don't know they be being badly treated > by their registrars. They don't know that there should be AAAA and > DNSSEC support in the GUI's. You're conflating registrars with DNS providers. Registrars are agents who maintain database records in a registry on = behalf of registrants. They have no direct relationship to the DNS. Name service providers publish zones on behalf of zone managers. Some = such providers expose provisioning interfaces, and I presume those are = the interfaces you are lamenting about. > If registrars were to lose acceditation if they didn't add support > for a record within 3 years of it being allocated you would see a > big difference. The 2013 ICANN Registrar Accreditation Agreement mandates DNSSEC and = IPv6 support for registries that support them, and for registrants that = request them. Again, this is a database issue. The existence of novel = RRTypes has no relevance here, until the time where we see RRTypes other = than A, AAAA, NS and DS provisioned for registrants in the zones = registries publish. Note that the context here is gTLDs; ccTLDs make their own arrangements = with registrars. > People keep saying leave it to market forces. Market force only = really > work when the market is properly informed. The great unwashed out = there > are not informed. The same thing can be said of many of the = registrars. DNS providers are not regulated in the sense that gTLD registrars are. = If you're suggesting that they should be regulated, then I doubt this is = an appropriate venue for that discussion. People still have the ability to host their domains themselves. Joe From johnl@taugh.com Sat Aug 24 16:44:06 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 B6CB211E819E for ; Sat, 24 Aug 2013 16:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.007, 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 VMuUAXIUmSzz for ; Sat, 24 Aug 2013 16:44:05 -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 D6DFE21F99FB for ; Sat, 24 Aug 2013 16:43:59 -0700 (PDT) Received: (qmail 34825 invoked from network); 24 Aug 2013 23:43:57 -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=8807.5219453d.k1308; bh=hVwaRLUFSzsUzRO6ZJul2pFoGeqgjaIaQcf/6pYJr/g=; b=NslODZW91QUMV2m7RAMkCKQfammgnqjx2H/W5Nc/Al6SYbWxg8qThMsthiFc+7NTnWotOQBZqv7st3vS/d8SKZ3W3mK7CE4Xbxqki0IGWVtC4JCH2b+m/+8w+85Rur0988oeqFKe1Jvx1o8giiRPpVfIjepHeKY8+Ug62ftzTuKwDsE4y/OsYpXmVBan7ZEwg+Xl0DSZBbjYEfqxWSFQueU8DHO09rqUQ9gigTKIIIh4GOrLHkZSdUn6pmXgNP3G 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=8807.5219453d.k1308; bh=hVwaRLUFSzsUzRO6ZJul2pFoGeqgjaIaQcf/6pYJr/g=; b=I38bspcFKkZcq1iJgMbkCVeioFwKeQvaToPVtJG3AW/U2JMMtyZGYqqA42G2SiN06CAplW27ZcNRDixxsRugZpuaqgG3xan8tcvmupWxF1mcWPM1+hTxAi5/HDSa86d0Lx1LcQgiyUBY5p1w2jwJ+OnsQH8goi0GbQwyYHBu5mKzvVTk8leHtjlL2iuHrXfgIFmw7Z+VMKEyTw8yekZOstVG5XeCU4Yg7+U0Lh5GlNqz4nPni8JOVtOcLdbgC69C Received: (ofmipd 127.0.0.1); 24 Aug 2013 23:43:35 -0000 Date: 24 Aug 2013 19:43:57 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" In-Reply-To: <20130824213356.CB42138D63BE@drugs.dv.isc.org> References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 24 Aug 2013 23:44:06 -0000 > It also tells us if we were to say MUST lookup up SPF then they would add > support. I salute your wry sense of humor. R's, John From ebw@abenaki.wabanaki.net Sat Aug 24 16:58:38 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 1ABA811E81A5 for ; Sat, 24 Aug 2013 16:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 2lp2ckfeev2L for ; Sat, 24 Aug 2013 16:58:32 -0700 (PDT) Received: from wampumpeag.net (unknown [65.99.1.131]) by ietfa.amsl.com (Postfix) with ESMTP id 10ED711E819F for ; Sat, 24 Aug 2013 16:58:31 -0700 (PDT) Received: from frog.local ([67.42.198.93]) by wampumpeag.net (8.14.7/8.14.7) with ESMTP id r7ONwR9C022156 for ; Sat, 24 Aug 2013 19:58:27 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <521948A2.1060206@abenaki.wabanaki.net> Date: Sat, 24 Aug 2013 16:58:26 -0700 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> In-Reply-To: <20130824213356.CB42138D63BE@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 24 Aug 2013 23:58:38 -0000 On 8/24/13 2:33 PM, Mark Andrews wrote: > If registrars were to lose acceditation if they didn't add support > for a record within 3 years of it being allocated you would see a > big difference. The word you're looking for is "accreditation", and it comes with a five year contract, at least w.r.t. ICANN and its contractual parties, so introducing an automatic, and unilateral breach condition would be necessary to satisfy your ... hypothetical. From dhc2@dcrocker.net Sat Aug 24 17:30:14 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 C0C1011E81B6 for ; Sat, 24 Aug 2013 17:30:14 -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 5bQrcCnS9MlB for ; Sat, 24 Aug 2013 17:30:09 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BF21111E81C0 for ; Sat, 24 Aug 2013 17:30:09 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7P0U6GZ003405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 24 Aug 2013 17:30:09 -0700 Message-ID: <52194FEF.4@dcrocker.net> Date: Sat, 24 Aug 2013 17:29:35 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 24 Aug 2013 17:30:09 -0700 (PDT) Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 00:30:15 -0000 > You're conflating registrars with DNS providers. Indeed I find myself unclear about the purpose and utility of this rather lengthy thread. Perhaps someone can summarize? For example does it pertain to some sort of long-term effort at DNS enhancement or does it pertain to the document that triggered it, or both or neither? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hallam@gmail.com Sun Aug 25 02:07: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 6D68611E823A; Sun, 25 Aug 2013 02:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=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 Ak59UIajZ960; Sun, 25 Aug 2013 02:07:27 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6A911E8247; Sun, 25 Aug 2013 02:07:24 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id ep20so1610992lab.29 for ; Sun, 25 Aug 2013 02:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GF7O9bDgJGxfSIhbNd69tTabyBQxFp365iaVLctyt/I=; b=xk/QCKc23gjXhsP1SGKmohafuMMt1F+nm9pawUpEUe9c+NqWUxcrC+CGkeC/SEa/2o 3QWE4ek7cOJYnkBfbJ8tpnOduSarwM1YbuPtiWKsVY9q2cqozjlXgeYIrgbN5Y2YCOTA VIeBnW3Oe/mUho6CxZtNKkyRYngODPjiTJg6Ao2U0ucAxWp+GpRFwrYxjKBMWWENHmJ8 8iOJDXnEwGfJ2f6q56GynFEdDYtcJP3vdvjXfOHqubT9/Tqkg4f2nggHCGICUVTfA0df 3QIM6Q++j9gdMDhqjvs59Z3OYMfuUHf2VD6HPC+3MGPSV5O4BvoMSqFqB6QPPieN272U KTWg== MIME-Version: 1.0 X-Received: by 10.112.168.170 with SMTP id zx10mr7265185lbb.0.1377421643352; Sun, 25 Aug 2013 02:07:23 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Sun, 25 Aug 2013 02:07:23 -0700 (PDT) In-Reply-To: <5218f0c0.030a0f0a.103a.fffff6f1SMTPIN_ADDED_BROKEN@mx.google.com> References: <20130823180411.50961.qmail@joyce.lan> <5D4CC1CD-D897-4F46-91A7-02B8176F762A@isi.edu> <5218f0c0.030a0f0a.103a.fffff6f1SMTPIN_ADDED_BROKEN@mx.google.com> Date: Sun, 25 Aug 2013 10:07:23 +0100 Message-ID: From: Phillip Hallam-Baker To: "bmanning@vacation.karoshi.com" Content-Type: multipart/alternative; boundary=001a11c23c88c210c404e4c1f71d Cc: "dnsext@ietf.org" , "ietf@ietf.org list" , manning bill Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 25 Aug 2013 09:07:28 -0000 --001a11c23c88c210c404e4c1f71d Content-Type: text/plain; charset=ISO-8859-1 On Sat, Aug 24, 2013 at 6:43 PM, wrote: > On Sat, Aug 24, 2013 at 08:39:36AM -0400, Phillip Hallam-Baker wrote: > > On Fri, Aug 23, 2013 at 3:46 PM, manning bill wrote: > > > > > > > > the question is not that "nobody" checks type 99, the question > is > > > "is the rate of adoption > > > of type 99 -changing- in relation to type 16? > > > > > > > As John pointed out, support for checking type 99 has decreased and > > continues to decrease rather than increase. So waiting longer is not > going > > to solve the issue. > > that is unclear... we have second hand reports, but only actual > data from very recent DNS logs. did those numbers increase or > decrease? No evidence has been presented. We have statements from people who are involved in the industry concerned and no reason to believe that they are lying. This is not a reasonable objection and it is really not at all surprising that people are getting rude when people are refusing to accept what the WG considers established facts. > > Putting a statement in an RFC does not mean that the world will > > automatically advance towards that particular end state. > > ain't it the truth. -BUT- its still worthwhile documenting the > best technical path and why it was abandoned. The issues wrt > wildcards (thanks), DNSSEC considerations, and code overhead to > demux type 16 vs. the temporary problem of two lookups -IF- type > 99 is not used, plus past guidance from the IAB and the IESG really > need to make it into a document in the RFC cannon. I don't think it was ever about the right technical path. It was about the DNSEXT group not caring to bother to get their DNSSEC infrastructure adopted by the constituencies they needed buy in from then trying to make that effort the problem of the SPF people. > Forcing a WG to adopt a position to suit another constituency is not going > > to lead them to advocate for that position in deployment constituencies. > > Particularly when the original constituency does nothing to advance > > deployment. > > Dorthy Parker said: "You can lead a whore to culture, but you > can't make her think". > Point the bias arrow either way youd like. And as stated > elsewhere, if Yahoo, Google, > Microsoft, AOL, et.al. were simply waiting for the IETF to > settle on a solution, > I'll raise O'Dells law; "The installed base does not matter" > Its a stupid and wrong 'law'. The deployed base is all that matters because before you get to the 'viral marketing' network effects give you the 'chicken and egg problem'. The reason HTTP and the Web took off was because we actually designed it to take off fast. Meanwhile IPv6 and DNSSEC are still in the same state they were 15 years ago, on the cusp of deployment in 5 years time. A large part of the reason has been that the people pushing those initiatives have acted as if deployment was inevitable. I ran simulation studies of adoption to work out how to sell the Web. The companies you cite have no stake in DNSSEC deployment. So why expect them to favor a technical measure designed to facilitate DNSSEC deployment? -- Website: http://hallambaker.com/ --001a11c23c88c210c404e4c1f71d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Aug 24, 2013 at 6:43 PM, <bmanning@vacation.k= aroshi.com> wrote:
On Sat, Aug 24, 2013 at 08= :39:36AM -0400, Phillip Hallam-Baker wrote:
> On Fri, Aug 23, 2013 at 3:46 PM, manning bill <bmanning@isi.edu> wrote:
>
> >
> > =A0 =A0 =A0 =A0 the question is not that "nobody" check= s type 99, the question is
> > "is the rate of adoption
> > =A0 =A0 =A0 =A0 of type 99 -changing- in relation to type 16?
> >
>
> As John pointed out, support for checking type 99 has decreased and > continues to decrease rather than increase. So waiting longer is not g= oing
> to solve the issue.

=A0 =A0 =A0 =A0 that is unclear... =A0we have second hand reports, bu= t only actual
=A0 =A0 =A0 =A0 data from very recent DNS logs. =A0 did those numbers incre= ase or
=A0 =A0 =A0 =A0 decrease? =A0No evidence has been presented.

We have statements from people who are involved in the in= dustry concerned and no reason to believe that they are lying.=A0

This is not a reasonable objection and it is really not at all surpris= ing that people are getting rude when people are refusing to accept what th= e WG considers established facts.

=A0
> Putting a statement in an RFC does not mean that the world will
> automatically advance towards that particular end state.

=A0 =A0 =A0 =A0 ain't it the truth. =A0-BUT- its still worthwhile= documenting the
=A0 =A0 =A0 =A0 best technical path and why it was abandoned. =A0 The issue= s wrt
=A0 =A0 =A0 =A0 wildcards (thanks), DNSSEC considerations, =A0and code over= head to
=A0 =A0 =A0 =A0 demux type 16 =A0vs. =A0the temporary problem of two lookup= s -IF- type
=A0 =A0 =A0 =A0 99 is not used, plus past guidance from the IAB and the IES= G really
=A0 =A0 =A0 =A0 need to make it into a document in the RFC cannon.

I don't think it was ever about the right techn= ical path. It was about the DNSEXT group not caring to bother to get their = DNSSEC infrastructure adopted by the constituencies they needed buy in from= then trying to make that effort the problem of the SPF people.


> Forcing a WG to adopt a position to suit another constituency is not g= oing
> to lead them to advocate for that position in deployment constituencie= s.
> Particularly when the original constituency does nothing to advance > deployment.

=A0 =A0 =A0 =A0 Dorthy Parker said: "You can lead a whore to cul= ture, but you can't make her think".
=A0 =A0 =A0 =A0 Point the bias arrow either way youd like. =A0And as stated= elsewhere, if Yahoo, Google,
=A0 =A0 =A0 =A0 Microsoft, AOL, = et.al. =A0were simply waiting for the IETF to settle on a solution,
=A0 =A0 =A0 =A0 I'll raise O'Dells law; =A0"The installed base= does not matter"

Its a stupid and= wrong 'law'.

The deployed base is all tha= t matters because before you get to the 'viral marketing' network e= ffects give you the 'chicken and egg problem'.

The reason HTTP and the Web took off was because we act= ually designed it to take off fast. Meanwhile IPv6 and DNSSEC are still in = the same state they were 15 years ago, on the cusp of deployment in 5 years= time. A large part of the reason has been that the people pushing those in= itiatives have acted as if deployment was inevitable.

I ran simulation studies of adoption to work out how to= sell the Web.=A0


The comp= anies you cite have no stake in DNSSEC deployment. So why expect them to fa= vor a technical measure designed to facilitate DNSSEC deployment?

--
Website: http://h= allambaker.com/
--001a11c23c88c210c404e4c1f71d-- From mansaxel@besserwisser.org Sun Aug 25 09:27: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 A162521F9D52 for ; Sun, 25 Aug 2013 09:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 Wxa5TrSNU9C1 for ; Sun, 25 Aug 2013 09:27:49 -0700 (PDT) Received: from jaja.besserwisser.org (jaja.besserwisser.org [IPv6:2a01:298:4:0:211:43ff:fe36:1299]) by ietfa.amsl.com (Postfix) with ESMTP id 19CFF21F9D3A for ; Sun, 25 Aug 2013 09:27:49 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 85FB99EEA; Sun, 25 Aug 2013 18:27:47 +0200 (CEST) Date: Sun, 25 Aug 2013 18:27:47 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: John Levine Message-ID: <20130825162747.GA19367@besserwisser.org> References: <5218E528.1080706@isdg.net> <20130824201258.60969.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <20130824201258.60969.qmail@joyce.lan> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 25 Aug 2013 16:27:49 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF Date: S= at, Aug 24, 2013 at 08:12:58PM -0000 Quoting John Levine (johnl@taugh.com): > >> PS: Something like my dns extension proposal should allow providers to= =20 > >> fix the new RR configuration problem once and for all, so I've always= =20 > >> been surprised at the hostile reception to it. > > > >Will it or can it work with Microsoft DNS servers? They are part of=20 > >the world too. >=20 > I don't see why not, if Microsoft wanted to implement it. Which is sort of interesting thing to read when we've heard repetitions ad nauseam that advocate broken design because Microsoft will never implement anything without being forced to by procurement rules. (IMNSHO the DNSSEC "support" in 2008 Server is just there to check the boxes for USGOV procurement rules. I think. Noone reasonably sane runs DNSSEC on that. ) --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I can't decide which WRONG TURN to make first!! I wonder if BOB GUCCIONE has these problems! --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlIaMIMACgkQ02/pMZDM1cXxUACfapf1XY/RJa4mTu1m8ABvFPkB Df4AmQEOvpavxFOzVw/HfVbcFxCuAqp+ =zybA -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From mansaxel@besserwisser.org Sun Aug 25 10:01: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 61FCB21F9CF1 for ; Sun, 25 Aug 2013 10:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 FVtb4wQuLcCb for ; Sun, 25 Aug 2013 10:01:42 -0700 (PDT) Received: from jaja.besserwisser.org (jaja.besserwisser.org [IPv6:2a01:298:4:0:211:43ff:fe36:1299]) by ietfa.amsl.com (Postfix) with ESMTP id D8FE921F9CDF for ; Sun, 25 Aug 2013 10:01:41 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 769C99EEA; Sun, 25 Aug 2013 19:01:39 +0200 (CEST) Date: Sun, 25 Aug 2013 19:01:39 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: dcrocker@bbiw.net Message-ID: <20130825170139.GB19367@besserwisser.org> References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <52194FEF.4@dcrocker.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: <52194FEF.4@dcrocker.net> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 25 Aug 2013 17:01:42 -0000 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF Date: S= at, Aug 24, 2013 at 05:29:35PM -0700 Quoting Dave Crocker (dhc2@dcrocker.ne= t): >=20 > >You're conflating registrars with DNS providers. >=20 >=20 > Indeed I find myself unclear about the purpose and utility of this > rather lengthy thread. >=20 > Perhaps someone can summarize? >=20 > For example does it pertain to some sort of long-term effort at DNS > enhancement or does it pertain to the document that triggered it, or > both or neither? Given,=20 * that we're in DNSEXT,=20 * that there exists a large (according to themselves) body of people/organisations that are unaware/unable of proper DNS=20 operation and standards, Yes. There is, because there must be, a continous effort to channel and guide the lemming population to the proper cliff. The current thread can be viewed as a tactical operation in the overall strategy. The document that trigged this is indeed relevant, because it is an especially clear case of the ignorance that threatens DNS. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Well, here I am in AMERICA.. I LIKE it. I HATE it. I LIKE it. I HATE it. I LIKE it. I HATE it. I LIKE it. I HATE it. I LIKE ... EMOTIONS are SWEEPING over me!! --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlIaOHMACgkQ02/pMZDM1cUdRQCfbaDOndM2eDgHl/ivDKlSElT4 +tcAoKblDnduabmH6sDCArZWyTBFNeKt =SfVG -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd-- From jay@nzrs.net.nz Sun Aug 25 13:30:27 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 43E4C21F9F2B for ; Sun, 25 Aug 2013 13:30:27 -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 FpjBU-SRalLO for ; Sun, 25 Aug 2013 13:30:22 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8B43121F9F21 for ; Sun, 25 Aug 2013 13:30:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 538F34B6DB1; Mon, 26 Aug 2013 08:30:19 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dty7bTCpD0Zh; Mon, 26 Aug 2013 08:30:12 +1200 (NZST) Received: from wintermute.public.internetnz.net.nz (vedra.internetnz.net.nz [202.46.176.54]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 121D24B6D3D; Mon, 26 Aug 2013 08:30:12 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: Date: Mon, 26 Aug 2013 08:06:16 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> To: John R Levine X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 25 Aug 2013 20:30:27 -0000 On 25/08/2013, at 11:43 AM, John R Levine wrote: >> It also tells us if we were to say MUST lookup up SPF then they would = add >> support. >=20 > I salute your wry sense of humor. Sorry John I think Mark is quite right. The position of "we're waiting = for the IETF" can only be interpreted one way - if the IETF mandates the = SPF record lookup then those manufacturers will implement that. As you = and others have pointed out it is most likely a trivial code change = given almost all of the logic is there. They just need a reason to do = it and an IETF mandate is as good a reason as there is. To me this debacle is a failure of will. The will to define and stick = to an architecture. A dose of MUST every now and then in cases like = this would strengthen the IETF not weaken it. Jay >=20 > R's, > John > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From dhc2@dcrocker.net Sun Aug 25 14:09:30 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 DB57A11E80C5 for ; Sun, 25 Aug 2013 14:09:30 -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 V3xrDOXjhcS6 for ; Sun, 25 Aug 2013 14:09:26 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DEF0621F9F8E for ; Sun, 25 Aug 2013 14:09:25 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7PL9L7S031172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Aug 2013 14:09:25 -0700 Message-ID: <521A7261.5080704@dcrocker.net> Date: Sun, 25 Aug 2013 14:08:49 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jay Daley References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> In-Reply-To: <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 25 Aug 2013 14:09:25 -0700 (PDT) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 21:09:31 -0000 On 8/25/2013 1:06 PM, Jay Daley wrote: > To me this debacle is a failure of will. The will to define and stick to an architecture. A dose of MUST every now and then in cases like this would strengthen the IETF not weaken it. I'm sure you have plenty of examples to cite, where such changes in standards language have brought about changes in market behavior? Please do cite them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Sun Aug 25 14:21: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 1414F11E80C5 for ; Sun, 25 Aug 2013 14:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 cO-rHF+HTbHe for ; Sun, 25 Aug 2013 14:21:07 -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 9AE5721F9FCF for ; Sun, 25 Aug 2013 14:21:05 -0700 (PDT) Received: (qmail 24775 invoked from network); 25 Aug 2013 21:21:04 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Aug 2013 21:21:04 -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=521a7540.xn--30v786c.k1308; i=johnl@user.iecc.com; bh=BdZbOaqAb3jkoSreevtqdMpeIE2lDLR4nN/cZJ+cmOY=; b=j4F80V6mVGOkFThavDMfY7YVOm2HeRqOtZBKc24FNtT5C/s7nq5iaXfu97HXat951YAKLmYmoqQdCljjhpf6bhBRh4fjpiJjHC16boTwUbvXyBOOj1jOCfK9V2LOdKVskZxkYiKKjpfDNgC4waFyRRvZWIPf2eUSExj+Lv55n1i2r5amGEyn6i7tw2yIlNveDW1Y8M0NGtziQn3H2pd1c8CMBzyPVxNTqboNdZ8pFlI5pVzxO/LYYVK/hx1SBPOc 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=521a7540.xn--30v786c.k1308; olt=johnl@user.iecc.com; bh=BdZbOaqAb3jkoSreevtqdMpeIE2lDLR4nN/cZJ+cmOY=; b=QsTHqChUb4I1uaejq+Km/NisJkw1cC1dZ1M6jv9zXz8gAB9lbmAcnNknwbLBrp1lB5lUeEqmwx3t3FDBpJ4X+GTm3GCOP+9zibKIiharCtXRwZwm7nRDmziYAJmM46ZIbARK0OYZ9RD6jnaqVYi2Hqr8MUN9hNU3hXP6zsG8XXAKoQjTZ6Wdlf20Krv5gbHkOI6r7ImNnYVSrrkk2tZ+XgMegtNMI259KZ0pI+MgK+19S4IAlCeCs8Tu9gSWv1EX Date: 25 Aug 2013 21:20:42 -0000 Message-ID: <20130825212042.69343.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20130825170139.GB19367@besserwisser.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 25 Aug 2013 21:21:11 -0000 >* that there exists a large (according to themselves) body of > people/organisations that are unaware/unable of proper DNS > operation and standards, Believe it or not, there are some people who understand the DNS perfectly well, but see it as a tool to get work done rather than an arena to score debating points. R's, John From jay@nzrs.net.nz Sun Aug 25 14:23: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 3D58621F92C2 for ; Sun, 25 Aug 2013 14:23:37 -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 K4drqlesyr+L for ; Sun, 25 Aug 2013 14:23:33 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id BB02121F9FFF for ; Sun, 25 Aug 2013 14:23:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id F3D044B6DD5; Mon, 26 Aug 2013 09:23:29 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXmRtkLkWSws; Mon, 26 Aug 2013 09:23:22 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id AB2784B6DCC; Mon, 26 Aug 2013 09:23:22 +1200 (NZST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <521A7261.5080704@dcrocker.net> Date: Mon, 26 Aug 2013 09:23:24 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 25 Aug 2013 21:23:37 -0000 On 26/08/2013, at 9:08 AM, Dave Crocker wrote: > I'm sure you have plenty of examples to cite, where such changes in = standards language have brought about changes in market behavior? Please = do cite them. The only evidence about behaviour that actually matters here was posted = earlier: = http://support.godaddy.com/groups/domains-management-and-services/forum/to= pic/spf-type-99/ = http://features.cpanel.net/responses/ability-to-create-spf-type-99-records= Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From dhc2@dcrocker.net Sun Aug 25 14:44: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 DBFF611E80AD for ; Sun, 25 Aug 2013 14:44:42 -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 2g-n-wSjaDOq for ; Sun, 25 Aug 2013 14:44:35 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CFA7A11E80D3 for ; Sun, 25 Aug 2013 14:44:35 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7PLiMZI031578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Aug 2013 14:44:28 -0700 Message-ID: <521A7A95.9000604@dcrocker.net> Date: Sun, 25 Aug 2013 14:43:49 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jay Daley References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 25 Aug 2013 14:44:31 -0700 (PDT) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 21:44:43 -0000 On 8/25/2013 2:23 PM, Jay Daley wrote: > > On 26/08/2013, at 9:08 AM, Dave Crocker wrote: > >> I'm sure you have plenty of examples to cite, where such changes in standards language have brought about changes in market behavior? Please do cite them. > > The only evidence about behaviour that actually matters here was posted earlier: > > http://support.godaddy.com/groups/domains-management-and-services/forum/topic/spf-type-99/ > http://features.cpanel.net/responses/ability-to-create-spf-type-99-records Jay, Sorry my query wasn't clear enough. I'm not asking about the excuses that a couple of implementers are using, many years after a specification was published -- for why they have not yet implemented a portion of the spec, 7 years after it was published. You are proposing some language changes and you are claiming that the changes will produce much greater implementation. So I am asking when this has occurred in the past, which would therefore provide an empirical basis for believing it likely to happen now. The point behind the query is to solicit some actual evidence that might reasonably counter the 7-year adoption failure of the SPF RR. Evidence, that is, that goes beyond /non-implementation/ excuses. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From andras@dns.net Sun Aug 25 15:27: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 355A611E80D2 for ; Sun, 25 Aug 2013 15:27:13 -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 08x4C8JwH+eR for ; Sun, 25 Aug 2013 15:27:08 -0700 (PDT) Received: from server2.gaon.net (server2.gaon.net [46.4.121.115]) by ietfa.amsl.com (Postfix) with ESMTP id DE01911E80FB for ; Sun, 25 Aug 2013 15:27:06 -0700 (PDT) Received: from server2.gaon.net (localhost [127.0.0.1]) by server2.gaon.net (8.14.3/8.14.3) with ESMTP id r7PMR5xl026595; Sun, 25 Aug 2013 22:27:05 GMT Received: (from asalamon@localhost) by server2.gaon.net (8.14.3/8.14.3/Submit 0.2) id r7PMR5ma026594; Sun, 25 Aug 2013 22:27:05 GMT Date: Sun, 25 Aug 2013 23:28:47 +0100 From: Andras Salamon To: dnsext@ietf.org Message-ID: <20130825222847.GA49656@gaon.net> References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: <521A7261.5080704@dcrocker.net> Sender: andras@gaon.net Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 25 Aug 2013 22:27:13 -0000 On Sun, Aug 25, 2013 at 02:08:49PM -0700, Dave Crocker wrote: >I'm sure you have plenty of examples to cite, where such changes in >standards language have brought about changes in market behavior? I don't know whether there are many examples or not, but ISC and Nominum seem to add new RRtypes to BIND whenever an RFC is published defining them, regardless of who employs the authors of the RFC. Last I checked, variants of BIND ran a large proportion of publicly visible DNS servers on the Internet. So we do have at least an existence proof that there are vendors that proactively respond to standards. Perhaps this is a way to differentiate themselves from other vendors that use "ignore" to complement an "embrace-extend-extinguish" strategy, but I don't really care why -- the fact is examples exist. I agree that the dynamics of "build it and they will come" are not always applicable. But this dynamic is also not always completely inapplicable. -- Andras Salamon andras@dns.net From jay@nzrs.net.nz Sun Aug 25 15:30: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 5DEE711E80F8 for ; Sun, 25 Aug 2013 15:30:46 -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 BUN20rHZtnGi for ; Sun, 25 Aug 2013 15:30:42 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id CA41E11E80D2 for ; Sun, 25 Aug 2013 15:30:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id E3CD84B6E1D; Mon, 26 Aug 2013 10:30:40 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK+ghbyoshpB; Mon, 26 Aug 2013 10:30:33 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 21C7E4B6DFB; Mon, 26 Aug 2013 10:30:33 +1200 (NZST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <521A7A95.9000604@dcrocker.net> Date: Mon, 26 Aug 2013 10:30:35 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <3FBC39B9-C8C9-4BFE-87A3-7C431A08A59C@nzrs.net.nz> References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <521A7A95.9000604@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 25 Aug 2013 22:30:46 -0000 On 26/08/2013, at 9:43 AM, Dave Crocker wrote: > The point behind the query is to solicit some actual evidence that = might reasonably counter the 7-year adoption failure of the SPF RR. = Evidence, that is, that goes beyond /non-implementation/ excuses. Dave, I think you are being unfair to those implementors. Almost all = implementors I know take the approach that they only implement what they = have to implement to make a "minimum viable product". RFC4408 allowed = them to only implement TXT and say "Yes, we support SPF and yes we are = standards compliant". =20 Seven years later and nothing has changed that makes their product any = less viable so there's been no reason for them to change. RFC6686 has = even reduced any future need to change. To me there's been no failure = by implementors and no excuses are necessary because their behaviour has = been *entirely rational*. And I might add, *entirely predictable*. Issue an RFC that requires type 99 and they will be entirely rational = again and ask "Do we want to remain standards compliant and how easy is = it to remain so?". The answer to the second part we know is "trivial". Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From dhc2@dcrocker.net Sun Aug 25 15:42: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 C2CE811E8101 for ; Sun, 25 Aug 2013 15:42:56 -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 qrmAwt8sP6RX for ; Sun, 25 Aug 2013 15:42:51 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CCDC211E80FC for ; Sun, 25 Aug 2013 15:42:51 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7PMgmOh032294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Aug 2013 15:42:51 -0700 Message-ID: <521A8848.80502@dcrocker.net> Date: Sun, 25 Aug 2013 15:42:16 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jay Daley References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <521A7A95.9000604@dcrocker.net> <3FBC39B9-C8C9-4BFE-87A3-7C431A08A59C@nzrs.net.nz> In-Reply-To: <3FBC39B9-C8C9-4BFE-87A3-7C431A08A59C@nzrs.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 25 Aug 2013 15:42:51 -0700 (PDT) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 22:42:56 -0000 On 8/25/2013 3:30 PM, Jay Daley wrote: > > On 26/08/2013, at 9:43 AM, Dave Crocker wrote: >> The point behind the query is to solicit some actual evidence that >> might reasonably counter the 7-year adoption failure of the SPF RR. >> Evidence, that is, that goes beyond /non-implementation/ excuses. > > Dave, I think you are being unfair to those implementors. My unfairness is in pressing you to substantiate the premise for your original assertion. I've explained the request twice. After two iterations, you still have not responded to that. One last time: when has revising a spec altered the further use of features that had so far gained little adoption? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From drc@virtualized.org Sun Aug 25 15:53:00 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 718AC21F9302 for ; Sun, 25 Aug 2013 15:53:00 -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 n0ACSzcHn9oF for ; Sun, 25 Aug 2013 15:52:54 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id 91BC411E8104 for ; Sun, 25 Aug 2013 15:52:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id DD5A787128; Sun, 25 Aug 2013 18:52:51 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 84886-03; Sun, 25 Aug 2013 18:52:51 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id EE8F587127; Sun, 25 Aug 2013 18:52:50 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_DB1C4F30-D606-4BBB-A84B-9B78D62E4720"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: <521A8848.80502@dcrocker.net> Date: Sun, 25 Aug 2013 15:52:39 -0700 Message-Id: <1D8ACC19-9A54-49F5-85C9-363F07BC6701@virtualized.org> References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <521A7A95.9000604@dcrocker.net> <3FBC39B9-C8C9-4BFE-87A3-7C431A08A59C@nzrs.net.nz> <521A8848.80502@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 25 Aug 2013 22:53:00 -0000 --Apple-Mail=_DB1C4F30-D606-4BBB-A84B-9B78D62E4720 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 25, 2013, at 3:42 PM, Dave Crocker wrote: > One last time: when has revising a spec altered the further use of = features that had so far gained little adoption? 3225 revising 2535 and/or 403x replacing 2535? Regards, -drc --Apple-Mail=_DB1C4F30-D606-4BBB-A84B-9B78D62E4720 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSGoq3AAoJEIzZ2DQOJFbKKFQH/i/oeUtbn4BXZLqYfKY8JTC9 zU4d8Zu0dwoXSdxidNiTa7aRamCXpLflNZjeNhpFvagTNSCu3oKRZjQQqc14B5hg +dvpSts7/ONaua/BuNQ0XoGOEwR9Rww4nFTTT2DU281knV+UPlIADBemEqkOedgo iqqbwaGR0zsJDWBe2gQhm2p36Y+0vMXCu6lX85vhjUjke1gTj5JsQ33Y/e51X37b LL2rCkVc1irQMUxr8F2H44nmc5Alc3PJNchaljIY29O2gslAH8FungQH+7ytGNWl Yaib1endDPtXk3hNpMI6++I22X2hXw8biA2WmChTJKGbMrFs5vbrGHM8CyYEwdw= =OY7Q -----END PGP SIGNATURE----- --Apple-Mail=_DB1C4F30-D606-4BBB-A84B-9B78D62E4720-- From ajs@anvilwalrusden.com Sun Aug 25 16:00:27 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 EE5D711E80EA for ; Sun, 25 Aug 2013 16:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 8xc5bIPCS1vM for ; Sun, 25 Aug 2013 16:00:15 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 41DA421F9FCE for ; Sun, 25 Aug 2013 16:00:14 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4D5C98A031 for ; Sun, 25 Aug 2013 23:00:14 +0000 (UTC) Date: Sun, 25 Aug 2013 19:00:12 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130825230012.GG8259@mx1.yitter.info> References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <20130825222847.GA49656@gaon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130825222847.GA49656@gaon.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 25 Aug 2013 23:00:27 -0000 On Sun, Aug 25, 2013 at 11:28:47PM +0100, Andras Salamon wrote: > I don't know whether there are many examples or not, but ISC and > Nominum seem to add new RRtypes to BIND whenever an RFC is published > defining them, regardless of who employs the authors of the RFC. Yes, and virtually every DNS server system actually does in fact cope with TYPE99 records. That is nowise an argument that saying, "Use TYPE99, darnit," will actually change the world. I find myself disagreeing with Dave way more often than not, but on this point I think he's quite right. We have a functioning system that's actually deployed, as far as anyone has argued. It is far from perfect, but it works. Those who think that the spec ought to be changed to reflect some other desired behaviour are responsible to provide evidence that the mere publication of an RFC -- one that recommends against the overwhelming widely-deployed practice in favour of something else -- are indeed responsible to show why that publication would have the requisite effect. Even one example would suffice. Like Dave, I'm having a hard time coming up with one. As I've said before, I'm mighty unhappy about this. But the world is as it is. Rather than fighting old battles, I'd like us to focus on making this never happen again. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From drc@virtualized.org Sun Aug 25 16:21:43 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 99D3211E8108 for ; Sun, 25 Aug 2013 16:21:43 -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 yjK8wZCvgwqm for ; Sun, 25 Aug 2013 16:21:38 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id 78BA011E8106 for ; Sun, 25 Aug 2013 16:21:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id A663D87128; Sun, 25 Aug 2013 19:21:37 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 84886-04; Sun, 25 Aug 2013 19:21:35 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id AAF5387127; Sun, 25 Aug 2013 19:21:34 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3D57EA15-7748-4A4D-AA83-853873C731C0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: <20130825230012.GG8259@mx1.yitter.info> Date: Sun, 25 Aug 2013 16:21:33 -0700 Message-Id: <3880112C-2AC7-433F-B77D-6A5D07365CD9@virtualized.org> References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <20130825222847.GA49656@gaon.net> <20130825230012.GG8259@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 25 Aug 2013 23:21:43 -0000 --Apple-Mail=_3D57EA15-7748-4A4D-AA83-853873C731C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Andrew, On Aug 25, 2013, at 4:00 PM, Andrew Sullivan = wrote: > We have a functioning system that's actually deployed, as far as = anyone has argued. It is far from perfect, but it works. The original version of HTTP was a deployed, functioning system that = despite being far from perfect, worked. The original protocol (the one = without persistent connections) also had unpleasant side effects (see = http://www.ibiblio.org/mdma-release/http-prob.html if you'd like a = refresher). =20 However, instead of saying "deployed systems, no server operator has any = incentive to change, let's just accept the status quo and make sure it = doesn't happen again", the protocol was modified and people have largely = migrated to the new protocol over a large number of years (still = vestiges of the old protocol out there, but definitely a minority). > Even one example would suffice. I suspect this won't matter. People's minds are made up. Regards, -drc --Apple-Mail=_3D57EA15-7748-4A4D-AA83-853873C731C0 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSGpF9AAoJEIzZ2DQOJFbK6aYIALJgYVm3xS03VHm5O9yEb2Fy fJ8FtC6MZ56QLDLs//muqFkNoet+SQRQmeEx1WarfCx2zzMbzrwjkBLyxTL14oYi 9FqV1jSKhTuvucv3a9UVr5ivs8D5ScQ+c1UDa6pbtWtmPWIa29KoLWZZGwMoMPhF ahng1uOzm2A3DA4wAowhVoVX+e7WHYpVnMf4NW19eqqTClqwBOZrDHZmATdda9vC CHA25OBT23RdvZqsNFxi7KtUIvwKJmhV9RRDh7OqSTIahLMNW9nF+dCW/1lI0xXl KS4ZXFLyWtDScjflrwJ7qzFkeL8DwtF7AehgkHNCPY1Nq+Ofu9nj7n7TURaHWUc= =oJut -----END PGP SIGNATURE----- --Apple-Mail=_3D57EA15-7748-4A4D-AA83-853873C731C0-- From ajs@anvilwalrusden.com Sun Aug 25 16:29:14 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 61CCC11E80ED for ; Sun, 25 Aug 2013 16:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 MQmBBJ7ghO0e for ; Sun, 25 Aug 2013 16:29:08 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEE311E80EA for ; Sun, 25 Aug 2013 16:29:08 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 60FFC8A031 for ; Sun, 25 Aug 2013 23:29:03 +0000 (UTC) Date: Sun, 25 Aug 2013 19:29:02 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130825232901.GI8259@mx1.yitter.info> References: <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <521A7A95.9000604@dcrocker.net> <3FBC39B9-C8C9-4BFE-87A3-7C431A08A59C@nzrs.net.nz> <521A8848.80502@dcrocker.net> <1D8ACC19-9A54-49F5-85C9-363F07BC6701@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1D8ACC19-9A54-49F5-85C9-363F07BC6701@virtualized.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 25 Aug 2013 23:29:14 -0000 On Sun, Aug 25, 2013 at 03:52:39PM -0700, David Conrad wrote: > > 3225 revising 2535 and/or 403x replacing 2535? Surely we're not so wedded to the in-band signalling of DNS that we can't distinguish beween management of the DNS itself, and applications using the DNS? I studied the Sophists, too, but I don't think they tell us how to work. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Sun Aug 25 16:46: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 9B53D11E8103 for ; Sun, 25 Aug 2013 16:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 T5N5GAjYJ3QH for ; Sun, 25 Aug 2013 16:46:39 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id D3EA121F9FF9 for ; Sun, 25 Aug 2013 16:46:39 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 67AFE8A031 for ; Sun, 25 Aug 2013 23:46:39 +0000 (UTC) Date: Sun, 25 Aug 2013 19:46:38 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130825234637.GJ8259@mx1.yitter.info> References: <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <20130825222847.GA49656@gaon.net> <20130825230012.GG8259@mx1.yitter.info> <3880112C-2AC7-433F-B77D-6A5D07365CD9@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3880112C-2AC7-433F-B77D-6A5D07365CD9@virtualized.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 25 Aug 2013 23:46:45 -0000 On Sun, Aug 25, 2013 at 04:21:33PM -0700, David Conrad wrote: > > I suspect this won't matter. People's minds are made up. Actually, mine isn't. That's an interesting example. What would be helpful to me is an understanding (and I really don't have any) of why you think the analogy actually shows we ought to move to type-99 instead ot sticking with type-16. As I understand the http/1.0 vs /1.1 trade-off, the 1.0 server suffered latency disadvantages as opposed to 1.1. Therefore, there was an automatic incentive to support 1.1 as soon as possible, even if no client supported it, because for any client that supported it there was an automatic advantage in latency. At the same time, there was an incentive for every client to support 1.1, because if the server did there was a latency advantage. And because of the signalling available by virtue of the header, http sessions could downgrade without starting all over. I'm completely prepared to be corrected on any of this, since I wasn't involved and when it was an issue I was only remotely involved in the effects (i.e. I was an http enthusiast as someone who thought the web was cool, but I was a philosophy student. I thought smarter people than I would fix it, and they did). The proposal in the SPF case doesn't seem to match this. Because DNS is connectionless, we don't have a way to downgrade depending on what the querying agent says it can do. The counter-examples -- DNAME and DNSSEC are the obvious cases -- actually show what a big deal this is. So the transition strategy in this case involves every actor either paying a cost up front with no direct benefit, or else a strategy that prefers the pre-transition state with the desired state a second-best alternative. This seems like a significant difference to me. What did I miss? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc2@dcrocker.net Sun Aug 25 16:48: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 847DF21F8C65 for ; Sun, 25 Aug 2013 16:48:10 -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 WUD6IdYSNgcd for ; Sun, 25 Aug 2013 16:48:05 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 082E021F91CB for ; Sun, 25 Aug 2013 16:48:03 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7PNlxa6000610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Aug 2013 16:48:02 -0700 Message-ID: <521A978F.4010404@dcrocker.net> Date: Sun, 25 Aug 2013 16:47:27 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Conrad References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <521A7A95.9000604@dcrocker.net> <3FBC39B9-C8C9-4BFE-87A3-7C431A08A59C@nzrs.net.nz> <521A8848.80502@dcrocker.net> <1D8ACC19-9A54-49F5-85C9-363F07BC6701@virtualized.org> In-Reply-To: <1D8ACC19-9A54-49F5-85C9-363F07BC6701@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 25 Aug 2013 16:48:02 -0700 (PDT) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 23:48:10 -0000 On 8/25/2013 3:52 PM, David Conrad wrote: > On Aug 25, 2013, at 3:42 PM, Dave Crocker wrote: >> One last time: when has revising a spec altered the further use of features that had so far gained little adoption? > > > 3225 revising 2535 and/or 403x replacing 2535? 1. Given how poor the adoption of DNSSec continues to be, are you sure you want to offer that as an exemplar of success? 2. Given how problematic /any/ adoption of DNSSec was back then and that it only started to gain significant traction after massive additional work and in much more recent years, I guess I don't see how this qualifies as the type of example I was asking for. On 8/25/2013 3:28 PM, Andras Salamon wrote: > ISC and > Nominum seem to add new RRtypes to BIND whenever an RFC is published ... > So we do have at least an existence proof that there are vendors > that proactively respond to standards. Please re-read my query. This wasn't what I was asking about. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From drc@virtualized.org Sun Aug 25 16:50:30 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 2FDE911E8110 for ; Sun, 25 Aug 2013 16:50:30 -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 tiEpS1550sNb for ; Sun, 25 Aug 2013 16:50:24 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id D7C0421F9FE9 for ; Sun, 25 Aug 2013 16:50:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id 2111A87128; Sun, 25 Aug 2013 19:50:23 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 84300-09; Sun, 25 Aug 2013 19:50:22 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id 5F9F887127; Sun, 25 Aug 2013 19:50:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: <20130825232901.GI8259@mx1.yitter.info> Date: Sun, 25 Aug 2013 16:50:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5BF31A35-115B-484C-BD4A-1E09EE7B8AD9@virtualized.org> References: <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <521A7A95.9000604@dcrocker.net> <3FBC39B9-C8C9-4BFE-87A3-7C431A08A59C@nzrs.net.nz> <521A8848.80502@dcrocker.net> <1D8ACC19-9A54-49F5-85C9-363F07BC6701@virtualized.org> <20130825232901.GI8259@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 25 Aug 2013 23:50:30 -0000 Andrew, On Aug 25, 2013, at 4:29 PM, Andrew Sullivan = wrote: > On Sun, Aug 25, 2013 at 03:52:39PM -0700, David Conrad wrote: >>=20 >> 3225 revising 2535 and/or 403x replacing 2535? >=20 > Surely we're not so wedded to the in-band signalling of DNS that we > can't distinguish beween management of the DNS itself, and > applications using the DNS? =20 Err, what? The question posed ("one last time") was: "when has revising a spec altered the further use of features that had = so far gained little adoption?" I was answering that question. The fact that it is specific to features = of the DNS has more to do with what was off the top of my head than = being wedded to "in-band signaling of the DNS" (whatever that means). The point here is that protocols evolve all the time as we learn what's = a good idea and what isn't. You (and others) appear to be arguing that = protocols that get deployed and gain some level of acceptance, even as = "Experimental", are cast in stone and that the IETF must be forbidden = from modifying them unless there is explicit evidence that markets will = _immediately_ seize upon those modifications. I think that view is = broken. Regards, -drc From jay@nzrs.net.nz Sun Aug 25 17:07: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 D021911E810C for ; Sun, 25 Aug 2013 17:07:18 -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 lqYyH2f2B75D for ; Sun, 25 Aug 2013 17:07:14 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 26DB111E80AD for ; Sun, 25 Aug 2013 17:07:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id E87B44B6E6F; Mon, 26 Aug 2013 12:07:03 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6mjmWlIBYJh; Mon, 26 Aug 2013 12:06:56 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id A21BE4B6DE8; Mon, 26 Aug 2013 12:06:56 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <20130825234637.GJ8259@mx1.yitter.info> Date: Mon, 26 Aug 2013 12:07:00 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <20130825222847.GA49656@gaon.net> <20130825230012.GG8259@mx1.yitter.info> <3880112C-2AC7-433F-B77D-6A5D07365CD9@virtualized.org> <20130825234637.GJ8259@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 26 Aug 2013 00:07:19 -0000 On 26/08/2013, at 11:46 AM, Andrew Sullivan = wrote: > [a whole bunch of stuff I've snipped that was well reasoned and = surprisingly succinct for a philosophy student] > ... > So the transition strategy in this case involves every actor > either paying a cost up front with no direct benefit, or else a > strategy that prefers the pre-transition state with the desired state > a second-best alternative. This seems like a significant difference > to me. What did I miss? You almost got it Andrew, it's the answer to the one question - "If we = mandate type 99 then what motivates users at both ends to implement it?" = with due consideration to any difficulties they might encounter. The motivation for implementors would be to stay standards compliant and = there would be few difficulties because the code changes are minor. The motivation for end users would also be to stay standards compliant = and once the implementors support it then there would be little = difficulty. There's a simple, rational, causal chain here - users don't use type 99 because implementors don't support it - implementors don't support type 99 because they don't have to - they don't have to because the RFC says they don't have to Change the root premise and the motivation is there for the rest to flow = through with no real barriers in the way. Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From dhc2@dcrocker.net Sun Aug 25 17:27: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 F0F2411E8118 for ; Sun, 25 Aug 2013 17:27:12 -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=[AWL=0.000, 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 bA07tpGT0ukd for ; Sun, 25 Aug 2013 17:27:08 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 16D2311E810C for ; Sun, 25 Aug 2013 17:27:08 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7Q0R2aU001101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Aug 2013 17:27:06 -0700 Message-ID: <521AA0B6.4030806@dcrocker.net> Date: Sun, 25 Aug 2013 17:26:30 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Conrad References: <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <521A7A95.9000604@dcrocker.net> <3FBC39B9-C8C9-4BFE-87A3-7C431A08A59C@nzrs.net.nz> <521A8848.80502@dcrocker.net> <1D8ACC19-9A54-49F5-85C9-363F07BC6701@virtualized.org> <20130825232901.GI8259@mx1.yitter.info> <5BF31A35-115B-484C-BD4A-1E09EE7B8AD9@virtualized.org> In-Reply-To: <5BF31A35-115B-484C-BD4A-1E09EE7B8AD9@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 25 Aug 2013 17:27:06 -0700 (PDT) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 00:27:13 -0000 On 8/25/2013 4:50 PM, David Conrad wrote: > The point here is that protocols evolve all the time as we learn what's a good idea and what isn't. You (and others) appear to be arguing that protocols that get deployed and gain some level of acceptance, even as "Experimental", are cast in stone and that the IETF must be forbidden from modifying them unless there is explicit evidence that markets will_immediately_ seize upon those modifications. I think that view is broken. That's not the issue here. The issue here is a claim that merely by changing the normative text, a mechanism will get widely implemented, in spite of a) a long track-record of not getting implemented, and b) no incremental value to the implementer. That's not 'learn[ing] what's a good idea'. It's merely an attempt to manipulate through a documentation artifact. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Sun Aug 25 18:12:08 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 3BA2911E8124 for ; Sun, 25 Aug 2013 18:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 AOpuB9b7bMvk for ; Sun, 25 Aug 2013 18:12:04 -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 9D57511E80EF for ; Sun, 25 Aug 2013 18:12:02 -0700 (PDT) Received: (qmail 70338 invoked from network); 26 Aug 2013 01:12:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Aug 2013 01:12:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521aab60.xn--hew.k1308; i=johnl@user.iecc.com; bh=Rte0mEdzlWGI409omVH8G1/mHFxMTek7xMLqfeOYCxM=; b=f64/olw4VOQkYQbOnOYL7SGmUqQmwcWPFv/QGW92VqvJQSU+Khw2Du4PO6buegWSXuvrnyGiLDfuGz9F9v/4eo/yyQy1C/xZaPPh4rqK8mBPRZ6gs/YbmHksnlDodeHHcPlnZ/KedLz/4X3OrG3Rq63TFVVbyn6WED9RbV1I9jtAxOSLU4lXIEZ/XOiNzreOMdum/QrzLPxER3iXZiG0hUvyRUw+D9g8vZ1bRV2wz9fSQskH78bkmkuQPPVJvOWQ 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=521aab60.xn--hew.k1308; olt=johnl@user.iecc.com; bh=Rte0mEdzlWGI409omVH8G1/mHFxMTek7xMLqfeOYCxM=; b=YmLsR3Q3CbQ/ibHu2s4Ed+OgTdf7TM39gZqOF1N0q8myFSxNagAhxHLopTx/snMnILbr2FUvoibduXAm5kVeN2m1mMmsounRqLJBbjEUaHKWuayzpRxnOtojaXSxglc2GDFFZWgA7LaDvD2+s+bfBSbrHs09N3G1jfvrzQmQ038sMpr0uUUx2DmticWNZaul2779rt6oVYbmZGkRXN7MIDAmVOebiBugjYrwJHMvSCLnwjRo0jO3Q0+8fUsnrgNE Date: 26 Aug 2013 01:11:38 -0000 Message-ID: <20130826011138.70037.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <5BF31A35-115B-484C-BD4A-1E09EE7B8AD9@virtualized.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 26 Aug 2013 01:12:08 -0000 >The point here is that protocols evolve all the time as we learn what's a good idea and what isn't. You (and others) appear to be >arguing that protocols that get deployed and gain some level of acceptance, even as "Experimental", are cast in stone and that the >IETF must be forbidden from modifying them unless there is explicit evidence that markets will _immediately_ seize upon those >modifications. I think that view is broken. No, it's the converse. When protocols are deployed and widely accepted, if someone wants to make changes that have NO OPERATIONAL ADVANTAGES WHATSOEVER, it's up to the proponents to explain why the world will adopt them. King Canute and all that. The practical operational advantages of http/1.0 and /1.1 over /0.9 were obvious. The advantages of SPF type 99 over type 16 were purely hypothetical in 2006 and equally hypothetical now. R's, John From ajs@anvilwalrusden.com Sun Aug 25 18:29: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 77AB111E8128 for ; Sun, 25 Aug 2013 18:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 EfSS2ZiC8Xy1 for ; Sun, 25 Aug 2013 18:29:01 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 880CD11E8122 for ; Sun, 25 Aug 2013 18:29:00 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B58BC8A031 for ; Mon, 26 Aug 2013 01:28:58 +0000 (UTC) Date: Sun, 25 Aug 2013 21:28:57 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130826012857.GL8259@mx1.yitter.info> References: <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <20130825222847.GA49656@gaon.net> <20130825230012.GG8259@mx1.yitter.info> <3880112C-2AC7-433F-B77D-6A5D07365CD9@virtualized.org> <20130825234637.GJ8259@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 26 Aug 2013 01:29:12 -0000 On Mon, Aug 26, 2013 at 12:07:00PM +1200, Jay Daley wrote: > The motivation for implementors would be to stay standards compliant and there would be few difficulties because the code changes are minor. > > The motivation for end users would also be to stay standards compliant and once the implementors support it then there would be little difficulty. > That's just not a motivation. There is _no_ business case to conform to any standard unless it's mandated in RFPs. This very fact is what allows the IETF to continue on its merry way despite the desire of Official Bodies to try to legislate the value of pi and other such things. There is no first-, or even any-mover advantage to changing from type-16 to type-99 in the scenario you provide, except for people who are otherwise regulated. > There's a simple, rational, causal chain here > > - users don't use type 99 because implementors don't support it Your "users" chain is wrong. There are _two_ kinds of users, and both ends need to do something before there is any value at all. That's the problem, and why the comparison to http 1.0 vs 1.1 seems to me to be troublesome. More generally, and not aimed at Jay in particular: without trying to come across as impatient or dismissive, I have to say that I'm getting worn out by arguments rehashing exactly the issues that were hashed, mostly by me in the hot seat, on the SPFBIS list. I tried _all_ these arguments, and I conceded in the end because I didn't have a leg to stand on. If people have a new one to present, I'd be delighted to encounter it. But since I'm bearing all the wounds from the SPFBIS battle, it'd be nice if erstwhile supporters of the position I tried, with little help, to defend would at least work through the arguments that were already presented. This isn't religion: I'm as sickend by this use of TXT as anyone. But the world makes us as much as we make the world, and I think the TXT fight _in this case_ is lost. I also think that NATs are a fact of the world, that NAT64/DNS64 is better than NAT-PT, and so on. We've reached sufficient thrust. Do we really want to stand around where the pig is going to land? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From bdickson@verisign.com Sun Aug 25 20:36: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 E66A811E813F for ; Sun, 25 Aug 2013 20:36:53 -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 bgjIX8SHWFf4 for ; Sun, 25 Aug 2013 20:36:49 -0700 (PDT) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id DAA5F11E8138 for ; Sun, 25 Aug 2013 20:36:47 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUhrNTvnJCBQdcbc4ENtV3IFANFuB7V8j@postini.com; Sun, 25 Aug 2013 20:36:49 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r7Q3ajmu001248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 Aug 2013 23:36:45 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Sun, 25 Aug 2013 23:36:41 -0400 From: "Dickson, Brian" To: Andrew Sullivan , "dnsext@ietf.org" Thread-Topic: [dnsext] The state of DNS support, was Deprecating SPF Thread-Index: AQHOoRGivirBe9YSikumprWArcqXUZmlSISAgAFVgwCAABF6gIAAFleAgAAIxwCAAAX3gIAABwIAgAAFsQCAABbmgP//4KSA Date: Mon, 26 Aug 2013 03:36:44 +0000 Message-ID: In-Reply-To: <20130826012857.GL8259@mx1.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 26 Aug 2013 03:36:56 -0000 At the risk of ridicule, and in the interest of potentially useful results: Why not deprecate TXT, or at least abandon the current TXT and introduce a new TXT code point? And, as each iteration gets trashed, move on to the next one? It's not like there is a shortage of type code values, and it is not like the RDATA of TXT is complicated, or in any way is required to be unique. SPF is, after all, exactly the same as TXT except for being different. If SPF want to take over TXT, let them. We can all move to TXT2, until someone ruins it, and then we can introduce TXT3, etc. I realize it is rather silly, but if it works, and it disambiguates things, the fact that it _is_ silly is perhaps not the greatest reason for not doing it. This might provide a small clue to the next group of other-protocol folk, that using TXT instead of asking for their own RRTYPE, is foolish, unwise, and likely to result in having a new RRTYPE lobbed at them in retaliation. :-) (My two cents, late to the discussion.) Brian On 8/25/13 9:28 PM, "Andrew Sullivan" wrote: >On Mon, Aug 26, 2013 at 12:07:00PM +1200, Jay Daley wrote: > >> The motivation for implementors would be to stay standards compliant >>and there would be few difficulties because the code changes are minor. >>=20 >> The motivation for end users would also be to stay standards compliant >>and once the implementors support it then there would be little >>difficulty. >>=20 > >That's just not a motivation. There is _no_ business case to conform >to any standard unless it's mandated in RFPs. This very fact is what >allows the IETF to continue on its merry way despite the desire of >Official Bodies to try to legislate the value of pi and other such >things. There is no first-, or even any-mover advantage to changing >from type-16 to type-99 in the scenario you provide, except for people >who are otherwise regulated. > >> There's a simple, rational, causal chain here >>=20 >> - users don't use type 99 because implementors don't support it > >Your "users" chain is wrong. There are _two_ kinds of users, and both >ends need to do something before there is any value at all. That's >the problem, and why the comparison to http 1.0 vs 1.1 seems to me to >be troublesome. > >More generally, and not aimed at Jay in particular: without trying to >come across as impatient or dismissive, I have to say that I'm getting >worn out by arguments rehashing exactly the issues that were hashed, >mostly by me in the hot seat, on the SPFBIS list. I tried _all_ these >arguments, and I conceded in the end because I didn't have a leg to >stand on. If people have a new one to present, I'd be delighted to >encounter it. But since I'm bearing all the wounds from the SPFBIS >battle, it'd be nice if erstwhile supporters of the position I tried, >with little help, to defend would at least work through the arguments >that were already presented. This isn't religion: I'm as sickend by >this use of TXT as anyone. But the world makes us as much as we make >the world, and I think the TXT fight _in this case_ is lost. I also >think that NATs are a fact of the world, that NAT64/DNS64 is better >than NAT-PT, and so on. We've reached sufficient thrust. Do we >really want to stand around where the pig is going to land? > >Best, > >A > >--=20 >Andrew Sullivan >ajs@anvilwalrusden.com >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext From dhc2@dcrocker.net Sun Aug 25 21:20: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 8FF4411E814C for ; Sun, 25 Aug 2013 21:20:04 -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 7OYsFN+7Sqn2 for ; Sun, 25 Aug 2013 21:19:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9838C21F9CD9 for ; Sun, 25 Aug 2013 21:19:59 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7Q4JsJO006163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Aug 2013 21:19:57 -0700 Message-ID: <521AD749.30502@dcrocker.net> Date: Sun, 25 Aug 2013 21:19:21 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Dickson, Brian" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 25 Aug 2013 21:19:57 -0700 (PDT) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 04:20:04 -0000 On 8/25/2013 8:36 PM, Dickson, Brian wrote: > Why not deprecate TXT, or at least abandon the current TXT and introduce > a new TXT code point? And, as each iteration gets trashed, move on to the > next one? installed base. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mansaxel@besserwisser.org Mon Aug 26 00:40:53 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 AEF9C11E8173 for ; Mon, 26 Aug 2013 00:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 JkuaqhGSBCsc for ; Mon, 26 Aug 2013 00:40:53 -0700 (PDT) Received: from jaja.besserwisser.org (jaja.besserwisser.org [IPv6:2a01:298:4:0:211:43ff:fe36:1299]) by ietfa.amsl.com (Postfix) with ESMTP id CB8AF11E8170 for ; Mon, 26 Aug 2013 00:40:52 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 1CCC7A1D8; Mon, 26 Aug 2013 09:40:51 +0200 (CEST) Date: Mon, 26 Aug 2013 09:40:51 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: John Levine Message-ID: <20130826074050.GF19367@besserwisser.org> References: <20130825170139.GB19367@besserwisser.org> <20130825212042.69343.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gdTfX7fkYsEEjebm" Content-Disposition: inline In-Reply-To: <20130825212042.69343.qmail@joyce.lan> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 26 Aug 2013 07:40:53 -0000 --gdTfX7fkYsEEjebm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF Date: S= un, Aug 25, 2013 at 09:20:42PM -0000 Quoting John Levine (johnl@taugh.com): > >* that there exists a large (according to themselves) body of > > people/organisations that are unaware/unable of proper DNS=20 > > operation and standards, >=20 > Believe it or not, there are some people who understand the DNS > perfectly well, but see it as a tool to get work done rather than an > arena to score debating points. It IS a tool -- like all the other protocols. But just as my spanner is rusty because I left it out by the pool tools that aren't cared for will lose their usefulness. A spanner I can buy again; but the DNS is not a stocked item. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I've got a COUSIN who works in the GARMENT DISTRICT ... --gdTfX7fkYsEEjebm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlIbBoIACgkQ02/pMZDM1cVFSQCfYtIqdemhHcY5GyXDKk3cPDtv r+QAn1NyF0KYdiwuQUNbFjxa3LoAEft5 =eIrv -----END PGP SIGNATURE----- --gdTfX7fkYsEEjebm-- From Ted.Lemon@nominum.com Sun Aug 25 21:31: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 525FD11E8151 for ; Sun, 25 Aug 2013 21:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 xq0CSwSgxtSz for ; Sun, 25 Aug 2013 21:31:00 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id B06BD11E8150 for ; Sun, 25 Aug 2013 21:31:00 -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 DSNKUhraA2+mP/DZuxva3oEMCS1AJ4jiThMS@postini.com; Sun, 25 Aug 2013 21:31:00 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 753B71B82C7 for ; Sun, 25 Aug 2013 21:30:59 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 4252119006D for ; Sun, 25 Aug 2013 21:30:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 25 Aug 2013 21:30:57 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1800\)) From: Ted Lemon In-Reply-To: <20130825222847.GA49656@gaon.net> Date: Mon, 26 Aug 2013 00:30:55 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3D8244E5-A06E-4184-BAF8-F71727AC0523@nominum.com> References: <20130821231334.91165.qmail@joyce.lan> <799C5ED9-5572-4541-8456-E564BAD65751@virtualized.org> <8738pzrvau.fsf@csgate4.strotmann.de> <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <20130825222847.GA49656@gaon.net> To: Andras Salamon X-Mailer: Apple Mail (2.1800) X-Originating-IP: [192.168.1.10] X-Mailman-Approved-At: Mon, 26 Aug 2013 05:52:50 -0700 Cc: "dnsext@" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 26 Aug 2013 04:31:07 -0000 On Aug 25, 2013, at 6:28 PM, Andras Salamon wrote: > I don't know whether there are many examples or not, but ISC and > Nominum seem to add new RRtypes to BIND whenever an RFC is published > defining them, regardless of who employs the authors of the RFC. > Last I checked, variants of BIND ran a large proportion of publicly > visible DNS servers on the Internet. Nominum's DNS servers (we have an authoritative server and a caching = resolver, which are separate products) do not share any code with BIND. = The problem here is not DNS server vendors=97it is consumers of SPF = records. From bmanning@karoshi.com Mon Aug 26 13:15:58 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 9721C21F9E52 for ; Mon, 26 Aug 2013 13:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 lb1p4gX4Nhdh for ; Mon, 26 Aug 2013 13:15:53 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFB821F9DC7 for ; Mon, 26 Aug 2013 13:15:52 -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 r7QKFgdr014425; Mon, 26 Aug 2013 20:15:47 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r7QKFegV014424; Mon, 26 Aug 2013 20:15:40 GMT Date: Mon, 26 Aug 2013 20:15:40 +0000 From: bmanning@vacation.karoshi.com To: dcrocker@bbiw.net Message-ID: <20130826201540.GA14402@vacation.karoshi.com.> References: <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <521A7A95.9000604@dcrocker.net> <3FBC39B9-C8C9-4BFE-87A3-7C431A08A59C@nzrs.net.nz> <521A8848.80502@dcrocker.net> <1D8ACC19-9A54-49F5-85C9-363F07BC6701@virtualized.org> <20130825232901.GI8259@mx1.yitter.info> <5BF31A35-115B-484C-BD4A-1E09EE7B8AD9@virtualized.org> <521AA0B6.4030806@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <521AA0B6.4030806@dcrocker.net> User-Agent: Mutt/1.4.1i Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 26 Aug 2013 20:15:58 -0000 On Sun, Aug 25, 2013 at 05:26:30PM -0700, Dave Crocker wrote: > On 8/25/2013 4:50 PM, David Conrad wrote: > >The point here is that protocols evolve all the time as we learn what's a > >good idea and what isn't. You (and others) appear to be arguing that > >protocols that get deployed and gain some level of acceptance, even as > >"Experimental", are cast in stone and that the IETF must be forbidden from > >modifying them unless there is explicit evidence that markets > >will_immediately_ seize upon those modifications. I think that view is > >broken. > > > That's not the issue here. The issue here is a claim that merely by > changing the normative text, a mechanism will get widely implemented, in > spite of > > a) a long track-record of not getting implemented, and > > b) no incremental value to the implementer. > > That's not 'learn[ing] what's a good idea'. > > It's merely an attempt to manipulate through a documentation artifact. > > d/ > > -- > Dave Crocker Changes in text does have an effect on implementation. See, (for example) The National Technology Transfer and Advancement Act (NTTAA) from about 1995 requires all Government Agencies to use industry consensus standards. /bill From dhc2@dcrocker.net Mon Aug 26 13:18:29 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 EA8BF21F9E89 for ; Mon, 26 Aug 2013 13:18:28 -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=[AWL=0.000, 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 v6pVU1kWVHuw for ; Mon, 26 Aug 2013 13:18:24 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D0D8021F9E5E for ; Mon, 26 Aug 2013 13:18:23 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7QKIK1m021688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Aug 2013 13:18:23 -0700 Message-ID: <521BB80A.2000905@dcrocker.net> Date: Mon, 26 Aug 2013 13:18:18 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: bmanning@vacation.karoshi.com References: <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <521A7A95.9000604@dcrocker.net> <3FBC39B9-C8C9-4BFE-87A3-7C431A08A59C@nzrs.net.nz> <521A8848.80502@dcrocker.net> <1D8ACC19-9A54-49F5-85C9-363F07BC6701@virtualized.org> <20130825232901.GI8259@mx1.yitter.info> <5BF31A35-115B-484C-BD4A-1E09EE7B8AD9@virtualized.org> <521AA0B6.4030806@dcrocker.net> <20130826201540.GA14402@vacation.karoshi.com.> In-Reply-To: <20130826201540.GA14402@vacation.karoshi.com.> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 26 Aug 2013 13:18:23 -0700 (PDT) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 20:18:29 -0000 On 8/26/2013 1:15 PM, bmanning@vacation.karoshi.com wrote: > Changes in text does have an effect on implementation. See, (for example) > The National Technology Transfer and Advancement Act (NTTAA) from about 1995 > requires all Government Agencies to use industry consensus standards. Bill, I wasn't asking an academic question about global, theoretical absolutes. I was asking about IETF experience... with IETF documents. Let's try to stay focused on the issue at hand. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From chip@2bithacker.net Mon Aug 26 13:46: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 6790821F9998 for ; Mon, 26 Aug 2013 13:46:02 -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 A+C+a1Iw7U-l for ; Mon, 26 Aug 2013 13:45:57 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id A471821F9E6A for ; Mon, 26 Aug 2013 13:45:57 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id a11so2079846qen.39 for ; Mon, 26 Aug 2013 13:45:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=LCNWEYLcTiQDbHyEHgEee9enomzBaHCUUCyR/6fxQcI=; b=WITg7z46w9Pz1ll5md3owORsQzNq4cRvMl3Z1n9XFt9MiYo68trUuNvLqnsahNB5Vh E1flLqe7SjmRbMn5dz1nyZIBsMPbAau2nZbQ96rsRilTDX/k5PDYWgGgC3koM/UHiDMq itZThAsLo/XAymP7JbkCl+OpgnnRGxivGy3CX3r1di98Z6Hh0Rx/Jl+eCWA788rdMPjG gc2C8LOPGinW6cws/A1lQflBBnkb2FoMM08UHmRZDaRBll0MaGiax8avcdC7rxpGCurw 6aG267k/bLhb+bw1PwPsjP4Sd0AMVbLtIY7JKvFwH2lfsdvZMxRFfdm/UxB9Of+pFANC lSmA== X-Gm-Message-State: ALoCoQkZYCExsz5aVdAmVh1dCsQVfMsM4KnIdmyFr6vcQ/MOj0q2s8kMv2IbTetinNRBxhp04tVc X-Received: by 10.49.15.66 with SMTP id v2mr5516017qec.73.1377549956065; Mon, 26 Aug 2013 13:45:56 -0700 (PDT) Received: from 2bithacker.net (nat-05-mht.dyndns.com. [216.146.45.244]) by mx.google.com with ESMTPSA id m10sm24398730qae.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 13:45:55 -0700 (PDT) Date: Mon, 26 Aug 2013 16:45:51 -0400 From: Chip Marshall To: dnsext@ietf.org Message-ID: <20130826204551.GC19840@2bithacker.net> References: <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <32389F5D-6B76-4286-BE21-08B71A9598F0@hopcount.ca> <20130824005705.GB5854@mx1.yitter.info> <00B88CDF-B349-4DB0-AF33-BBEA1BA106EA@virtualized.org> <20130824020218.GB5888@mx1.yitter.info> <20130824023657.9777838D42FF@drugs.dv.isc.org> <20130824031754.GC5888@mx1.yitter.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline In-Reply-To: <20130824031754.GC5888@mx1.yitter.info> X-OS: Mac OS X 10.8.4 x86_64 up 31 days User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chip@2bithacker.net List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 20:46:02 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-08-23, Andrew Sullivan sent: > I am an SPF validator. On day 0, there are very few people > publishing SPF-99 records, and many publishing SPF-16 records. > I have a lot of mail volume coming in. What is my incentive to > embrace SPFCheckNG? Please address the latency effects for > large mail operators. I'm not sure I fully understand the latency argument here. Wouldn't you just fire off the SPF-99 and TXT-16 queries asynchronously? Waiting for two answers shouldn't be much longer than waiting for one answer when done in parallel. And long term, wouldn't there be benefits from not having to sift through any other TXT records you receive for the ones that look like SPF records? --=20 Chip Marshall http://2bithacker.net/ --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (Darwin) iEYEARECAAYFAlIbvn8ACgkQnTUxIUPEgZ6c3QCfWaNWAXjrp0J9vo3UwxclXrN9 5fcAn3Sl4s/MRY23n3umsrwO4M7UPrfa =OtDS -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl-- From sm@elandsys.com Mon Aug 26 13:56: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 E58A711E820E for ; Mon, 26 Aug 2013 13:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 waL9UhC9A6DO for ; Mon, 26 Aug 2013 13:56:12 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 132B911E820D for ; Mon, 26 Aug 2013 13:55:59 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7QKtikR028293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Aug 2013 13:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377550555; bh=QPv4vwg7fCWEiQqcff07LMtx2A1OoHWm9F4/+vEN7GU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IsONqKmss3hbrW5GcmlanV7Ab2T71h4orkY8DwYbeavXfSWHZGkzJ+KCbLZ7usCw+ ctdQC9ZPZw7OOnFMzW5IHDTXc+ZD0l2NrBPW4CO3zLBhcaFyzmxD2iYAG3hOlrgkbE U7QoKu4+U0BCPX9EkXeXFMDeUI4ni/KoDXeU8yOo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377550555; i=@elandsys.com; bh=QPv4vwg7fCWEiQqcff07LMtx2A1OoHWm9F4/+vEN7GU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pC1g9VeYCVCn4f8uEiY20dfpc05h/xjOcxVOUW2jaY+Eyy0JyOceyOrqmoIpsNL4o WZPHVzi3iAMrWIj84Z5Pg2WrIZvFGq0bK8VTmxcuqR1aUu2QUWVIPt1E/6hu9bJAi0 XS3J9QwwXGWmsttcKy+0GaDuXEPfDLRefcme1prc= Message-Id: <6.2.5.6.2.20130826135147.0c458768@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 26 Aug 2013 13:53:08 -0700 To: chip@2bithacker.net From: S Moonesamy In-Reply-To: <20130826204551.GC19840@2bithacker.net> References: <5628654950817817361@unknownmsgid> <20130823214123.5D87038D252E@drugs.dv.isc.org> <20130823221016.GX37406@mx1.yitter.info> <32389F5D-6B76-4286-BE21-08B71A9598F0@hopcount.ca> <20130824005705.GB5854@mx1.yitter.info> <00B88CDF-B349-4DB0-AF33-BBEA1BA106EA@virtualized.org> <20130824020218.GB5888@mx1.yitter.info> <20130824023657.9777838D42FF@drugs.dv.isc.org> <20130824031754.GC5888@mx1.yitter.info> <20130826204551.GC19840@2bithacker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 26 Aug 2013 20:56:14 -0000 Hi Chip, At 13:45 26-08-2013, Chip Marshall wrote: >I'm not sure I fully understand the latency argument here. >Wouldn't you just fire off the SPF-99 and TXT-16 queries >asynchronously? Waiting for two answers shouldn't be much longer >than waiting for one answer when done in parallel. See http://www.ietf.org/mail-archive/web/spfbis/current/msg00876.html Regards, S. Moonesamy From johnl@iecc.com Mon Aug 26 14:13: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 A83C111E824A for ; Mon, 26 Aug 2013 14:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 4lklxVDqg0h8 for ; Mon, 26 Aug 2013 14:13:13 -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 15BC611E824D for ; Mon, 26 Aug 2013 14:13:12 -0700 (PDT) Received: (qmail 50901 invoked from network); 26 Aug 2013 21:13:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Aug 2013 21:13:09 -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=521bc4e5.xn--hew.k1308; i=johnl@user.iecc.com; bh=kTzGSgc8sDAEMVxY4dKi6xmXwd/Bq84UM9aJRmDOVx8=; b=d75/ZQoBL883tm8XPCVLJotV+NrWBaey9AmPtDEOue40dIdH/cMY81FgxARAdhLvncGDjxot5BokJsyJIqo3lUIX2h24hvxi05yIKS3C4VOnGfcuey8neBBw8GbSRUwsuDEjsWaQBiOYHOj1E4Iq35ANxAKavk+hKRw0jtru2CNKGPyspqExHp+mVyyfs90tjTjHt2hz84PAvv/xSpYxAC4jkYtSPmarDfAyVy9FZEK6oUg0TH/vGvqRd9y74wTV 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=521bc4e5.xn--hew.k1308; olt=johnl@user.iecc.com; bh=kTzGSgc8sDAEMVxY4dKi6xmXwd/Bq84UM9aJRmDOVx8=; b=E3JKm2MOQJcUEjesdMYoMrzwaAeMqcKXIsOsU1HFv/Hz2X822V6Y/SAhZU6rWSsL1o56UiXbhQUPxigcnPRg7lWBIKCcJz8yIeuw3jaqZKkGIk3QTnqWY7WLH0iMgA0y5l0UzUfLa9zIaVRcWqaINtho4QbvKmeHwSvChy6PW6Rd+xrd2SZ+aC/qjBRzvHFtB+Zedl4lL+rmT6BHtgRNQRrJWonXFhbLCqM7hzXdIb1OTW2LQXbSkSzJlgDdHkYJ Date: 26 Aug 2013 21:12:46 -0000 Message-ID: <20130826211246.82490.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20130826204551.GC19840@2bithacker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF 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, 26 Aug 2013 21:13:17 -0000 >I'm not sure I fully understand the latency argument here. >Wouldn't you just fire off the SPF-99 and TXT-16 queries >asynchronously? Waiting for two answers shouldn't be much longer >than waiting for one answer when done in parallel. If your DNS library permits, sure, you can do them in parallel. But experience has shown that due to cruddy middleboxes or the like, type 99 queries get lost and time out more than you might think. If the type 16 query doesn't give you a usable SPF record, you have to wait for the type 99 query. People who run large mail servers tell me the slowdown is noticable. >And long term, wouldn't there be benefits from not having to sift >through any other TXT records you receive for the ones that look >like SPF records? In a word, no. The SPF rules for handling type 16 and type 99 records were identical: there has to be exactly one record that starts "v=spf1". You have to look at all the records to be sure that there aren't multiple v=spf1 records (which invalidates all of them) and once you're doing that, ignoring the ones that don't have the right prefix is about three lines of code in a multi thousand line library. R's, John From marka@isc.org Mon Aug 26 17:27:34 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 C823611E810B for ; Mon, 26 Aug 2013 17:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_00=-2.599, MANGLED_GOOD=2.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 cTU-GZevLRA4 for ; Mon, 26 Aug 2013 17:27:30 -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 744D411E810A for ; Mon, 26 Aug 2013 17:27:30 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id E08DEC9422; Tue, 27 Aug 2013 00:27:12 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377563245; bh=pa9ByJiMpSna/v9WzhDjHOZkMv1Q2Hk3xX3r2CaksN0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=NBjlDUezFjUmG97x/tjkORAcTTxyxoiAxnabKbl0McIC91n/IR+VZR6cNqUB//x+t 5+hhednLaPJi53kKBIurd+JW0nPSJEFGCWrugG1Uey5/XNXdgG1yLv27o+DZT2x812 OMcrTqgC/ZuuiZv5gbBdRyfVqOxt1JpSBPqUevSc= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 27 Aug 2013 00:27:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0D55516043C; Tue, 27 Aug 2013 00:27:47 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id D3D321602D3; Tue, 27 Aug 2013 00:27:46 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id DA79B38E4C09; Tue, 27 Aug 2013 10:27:06 +1000 (EST) To: "John Levine" From: Mark Andrews References: <20130826011138.70037.qmail@joyce.lan> In-reply-to: Your message of "26 Aug 2013 01:11:38 +0000." <20130826011138.70037.qmail@joyce.lan> Date: Tue, 27 Aug 2013 10:27:06 +1000 Message-Id: <20130827002706.DA79B38E4C09@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 27 Aug 2013 00:27:34 -0000 In message <20130826011138.70037.qmail@joyce.lan>, "John Levine" writes: > >The point here is that protocols evolve all the time as we learn what's a go > od idea and what isn't. You (and others) appear to be > >arguing that protocols that get deployed and gain some level of acceptance, > even as "Experimental", are cast in stone and that the > >IETF must be forbidden from modifying them unless there is explicit evidence > that markets will _immediately_ seize upon those > >modifications. I think that view is broken. > > No, it's the converse. When protocols are deployed and widely > accepted, if someone wants to make changes that have NO OPERATIONAL > ADVANTAGES WHATSOEVER, it's up to the proponents to explain why the > world will adopt them. King Canute and all that. They have a operational advantage especially over the long term or if you consider the overall maintenance of DNS records for a site. This has been demostrated several times. Do you think we would be having this argument if there was not a operational advantage? > The practical operational advantages of http/1.0 and /1.1 over /0.9 > were obvious. The advantages of SPF type 99 over type 16 were purely > hypothetical in 2006 and equally hypothetical now. > > R's, > John > _______________________________________________ > 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 hadriel.kaplan@oracle.com Tue Aug 27 07:25: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 B7A0111E81A8 for ; Tue, 27 Aug 2013 07:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 R7kvVuK9YQVf for ; Tue, 27 Aug 2013 07:25:42 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB3811E8199 for ; Tue, 27 Aug 2013 07:25:41 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7REPcF9008802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Aug 2013 14:25:39 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7REPatu019708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 14:25:37 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7REPanG004986; Tue, 27 Aug 2013 14:25:36 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Aug 2013 07:25:36 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Tue, 27 Aug 2013 10:25:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Dickson, Brian" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "dnsext@ietf.org" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 27 Aug 2013 14:25:48 -0000 Well if we're going to risk being ridiculed, I'll go all-in. :) At one time I had thought along the same lines - not to deprecate TXT, = but rather to just say: "let's go pre-allocate a dozen new RR Types, and = tell DNS servers to implement them, with undefined-text-content, and we = give them random acronym names, and future IETF mechanisms can go use = them on a first-come-first-served basis; and those future IETF specs can = figure out a backronym expansion for the acronyms, and define what the = text-content formatting is, etc." But from reading the problems SPF listed in RFC 6686 and the emails from = SPFBIS folks, I don't think that would solve the problem, even if by = some miracle all DNS servers on the planet supported the new RRs. = There're just too many other DNS-related-things involved. (DNS servers = and registries, and their provisioning interfaces, and DNS = resolvers/caches, firewalls, CGN middleboxes, client libraries and their = APIs...) So here's the to-be-ridiculed part... I suggest a new strategy: let the wookie win. Instead of denying their = existence, accept that there will be more folks who want to deploy new = DNS-using applications quickly and without waiting for the entire = Internet of DNS-related-things to change. It's going to happen whether = we want it to or not. So we might as well try to fix whatever problems = we envision it will cause, and provide guidance of how to use TXT the = best way. Right now RFC 5507 only warns folks against it, but I don't = see a "if you are going to use TXT anyway, then do it this way" type = thing. Nor do I see an IANA registry of prefix names, nor an RFC = describing a general solution to the wildcarding problem when prefixing. = I think those things are possible, maybe. We can require abstinence or we can give out condoms. Which one do you = think is more likely to prevent spread of disease? -hadriel On Aug 25, 2013, at 11:36 PM, "Dickson, Brian" = wrote: > At the risk of ridicule, and in the interest of potentially useful = results: >=20 > Why not deprecate TXT, or at least abandon the current TXT and = introduce > a new TXT code point? And, as each iteration gets trashed, move on to = the > next one? >=20 > It's not like there is a shortage of type code values, and it is not = like > the RDATA of TXT is complicated, or in any way is required to be = unique. > SPF is, after all, exactly the same as TXT except for being different. >=20 > If SPF want to take over TXT, let them. We can all move to TXT2, until > someone ruins it, and then we can introduce TXT3, etc. >=20 > I realize it is rather silly, but if it works, and it disambiguates = things, > the fact that it _is_ silly is perhaps not the greatest reason for not > doing it. >=20 > This might provide a small clue to the next group of other-protocol = folk, > that using TXT instead of asking for their own RRTYPE, is foolish, = unwise, > and likely to result in having a new RRTYPE lobbed at them in = retaliation. > :-) >=20 > (My two cents, late to the discussion.) >=20 > Brian >=20 From nweaver@icsi.berkeley.edu Tue Aug 27 07:44: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 9826411E819B for ; Tue, 27 Aug 2013 07:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6] 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 yNNTaxwK4X5m for ; Tue, 27 Aug 2013 07:44:35 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id F23EB11E8199 for ; Tue, 27 Aug 2013 07:44:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E4D092C401C; Tue, 27 Aug 2013 07:44:21 -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 utyEruMHZx6r; Tue, 27 Aug 2013 07:44:21 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 77CF02C4017; Tue, 27 Aug 2013 07:44:21 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_14FFEEC3-7568-421D-93F5-F0E9BAF58BE3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Nicholas Weaver In-Reply-To: Date: Tue, 27 Aug 2013 07:44:21 -0700 Message-Id: <0CF9372A-84E5-49B3-849D-0ACBEDA2AF5C@icsi.berkeley.edu> References: To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 27 Aug 2013 14:44:39 -0000 --Apple-Mail=_14FFEEC3-7568-421D-93F5-F0E9BAF58BE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 27, 2013, at 7:25 AM, Hadriel Kaplan = wrote: > But from reading the problems SPF listed in RFC 6686 and the emails = from SPFBIS folks, I don't think that would solve the problem, even if = by some miracle all DNS servers on the planet supported the new RRs. = There're just too many other DNS-related-things involved. (DNS servers = and registries, and their provisioning interfaces, and DNS = resolvers/caches, firewalls, CGN middleboxes, client libraries and their = APIs...) Fortunately, for MOST such boxes, they do actually handle unknown = resource records right (we've been testing that with Netalyzr for almost = forever, with type 169 on transport, and 1169 on probes to configured = recursive resolvers). Namely because the protocol is actually designed = right in that respect: its actually easier to handle ALL types in a = generic manner after special casing the FEW types that allow name = compression. Thus it really is that the major problem is provisioning, not transport, = of unknown DNS types. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_14FFEEC3-7568-421D-93F5-F0E9BAF58BE3 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----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSHLtFAAoJEG2B1w+SDi/uE4EQALNKOpp2jZ1L5ZWMJupgaCb2 7xT/qyVupu5HSqvZoRGL9XqFF53fqUYn51Y3UN4Rus6cPcDlTzejGi6Dffuyfump f2L6A5vUsXQd1aIjXgh8vyad5YwZ+5VVHRJThRRRHbo2++vED0dDif4OwxdBphAS LOufGA8s7yehErj0ULHALuWRHmOCXKb8IIjRp4ZY0deK6EYm+qsh8omXGjG2QnrW fMmTvMIk4nKM+C9wCwOjhs64iPLFlBYAolj4BCLO41tD4IxfvShaddl3hClFWrmG U+oohBXY8daW0EA89bmSIJFO+mDyZDWP/fh5Abb93fXWXLTBSSfDEzZ9HJ4oTor+ MjBeKvqprQvITuaQIu9cMGj6uA4707pWdhUQR3K07x+hRZzStITsEdO8wY7ncU/J Sh0x/deWh4riT24VdsZT/KOLToL9EuX/5DUwyWY8h8HgQdiYVGIqDg/WIYmyYNNv XhJr73PsA7VYxvwjDB4ZBakofNS2ORIodIJN55WS7vCDqt8cbbigUv6nG+SNr0aD kGjv9HUuZUY+HAjxYo8AL0agWDY/VY1pVqHZylvm7H0YTuakJ2XFL7tfOqf2GAwG Z39GAU8icx9pOyLz7kA/NBAzzNrwrjBINQpYWNIl9ETBZzB8fKk4mE1E0d1yKbnp pdoDxkThtaNZx76Y8NHZ =OgqB -----END PGP SIGNATURE----- --Apple-Mail=_14FFEEC3-7568-421D-93F5-F0E9BAF58BE3-- From mansaxel@besserwisser.org Tue Aug 27 08:10: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 374D611E81A6 for ; Tue, 27 Aug 2013 08:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 zZvcyEKoe4S3 for ; Tue, 27 Aug 2013 08:10:45 -0700 (PDT) Received: from jaja.besserwisser.org (jaja.besserwisser.org [IPv6:2a01:298:4:0:211:43ff:fe36:1299]) by ietfa.amsl.com (Postfix) with ESMTP id AB87711E819D for ; Tue, 27 Aug 2013 08:10:45 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 9262E9EEA; Tue, 27 Aug 2013 17:10:42 +0200 (CEST) Date: Tue, 27 Aug 2013 17:10:42 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Nicholas Weaver Message-ID: <20130827151042.GI19367@besserwisser.org> References: <0CF9372A-84E5-49B3-849D-0ACBEDA2AF5C@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="N8NGGaQn1mzfvaPg" Content-Disposition: inline In-Reply-To: <0CF9372A-84E5-49B3-849D-0ACBEDA2AF5C@icsi.berkeley.edu> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 27 Aug 2013 15:10:46 -0000 --N8NGGaQn1mzfvaPg Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF Date: T= ue, Aug 27, 2013 at 07:44:21AM -0700 Quoting Nicholas Weaver (nweaver@icsi.= berkeley.edu): >=20 > On Aug 27, 2013, at 7:25 AM, Hadriel Kaplan w= rote: >=20 > > But from reading the problems SPF listed in RFC 6686 and the emails fro= m SPFBIS folks, I don't think that would solve the problem, even if by some= miracle all DNS servers on the planet supported the new RRs. There're jus= t too many other DNS-related-things involved. (DNS servers and registries, = and their provisioning interfaces, and DNS resolvers/caches, firewalls, CGN= middleboxes, client libraries and their APIs...) >=20 > Fortunately, for MOST such boxes, they do actually handle unknown resourc= e records right (we've been testing that with Netalyzr for almost forever, = with type 169 on transport, and 1169 on probes to configured recursive reso= lvers). Namely because the protocol is actually designed right in that res= pect: its actually easier to handle ALL types in a generic manner after spe= cial casing the FEW types that allow name compression. >=20 > Thus it really is that the major problem is provisioning, not transport, = of unknown DNS types. This is indeed interesting data that "complicates" the IMNSHO sweeping statements of 6686. The provisioning problem remains, but the infrastructure is not as broken as stated. Or?=20 --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 =2E.. I think I'd better go back to my DESK and toy with a few common MISAPPREHENSIONS ... --N8NGGaQn1mzfvaPg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlIcwXIACgkQ02/pMZDM1cW5awCgqBaqSBobkEQtuufB7g3jKxl7 JMAAnjG8bQgifRWmQAZ3XYCUHzxx1mO3 =vshl -----END PGP SIGNATURE----- --N8NGGaQn1mzfvaPg-- From marka@isc.org Tue Aug 27 08:24: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 8CD3A11E8313 for ; Tue, 27 Aug 2013 08:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] 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 TcfpO-IkTeWs for ; Tue, 27 Aug 2013 08:24:29 -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 511AB11E81AC for ; Tue, 27 Aug 2013 08:24:29 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 6750EC9496; Tue, 27 Aug 2013 15:24:13 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377617066; bh=PaWtEBXpHphkPJJnSrat/xs92Gr7ae0nn/228Ol3WjI=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Z0ZCxOZFqUjNlaEgrcWd9BG4g9f210Ke6eAuN21buM99xlDNSQAGmkmv6nVZmZD+c zrnkUzP5Bmi/oGFcaRAGc4Yi15KTbKYdNw/HPIm3gP8ZZmtOQIjS1qlV3k9nvwssss Uh2+p6r55TP65tLJMTLsMUIMCu+9hfANG+hmz5EI= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 27 Aug 2013 15:24:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 42E3D160459; Tue, 27 Aug 2013 15:24:50 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id D2C8016043C; Tue, 27 Aug 2013 15:24:49 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7F52338EB205; Wed, 28 Aug 2013 01:23:59 +1000 (EST) To: Hadriel Kaplan From: Mark Andrews References: In-reply-to: Your message of "Tue, 27 Aug 2013 10:25:34 -0400." Date: Wed, 28 Aug 2013 01:23:59 +1000 Message-Id: <20130827152359.7F52338EB205@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsext@ietf.org" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 27 Aug 2013 15:24:33 -0000 In message , Hadriel Kaplan wr ites: > > Well if we're going to risk being ridiculed, I'll go all-in. :) > > At one time I had thought along the same lines - not to deprecate TXT, but ra > ther to just say: "let's go pre-allocate a dozen new RR Types, and tell DNS s > ervers to implement them, with undefined-text-content, and we give them rando > m acronym names, and future IETF mechanisms can go use them on a first-come-f > irst-served basis; and those future IETF specs can figure out a backronym exp > ansion for the acronyms, and define what the text-content formatting is, etc. > " > > But from reading the problems SPF listed in RFC 6686 and the emails from SPFB > IS folks, I don't think that would solve the problem, even if by some miracle > all DNS servers on the planet supported the new RRs. There're just too many > other DNS-related-things involved. (DNS servers and registries, and their pr > ovisioning interfaces, and DNS resolvers/caches, firewalls, CGN middleboxes, > client libraries and their APIs...) There are DNS servers that completely support arbitary types. And have for over a decade. Before that they could resolve and cache arbitary types and have done so for over 20 years. About the only one that doesn't is that shipped by Microsoft. There are DNS resolvers that support arbitary types and have been able to for over 20 years. This is basic RFC 1034 functionality. Unfortunately Microsoft failed to read that part of RFC 1034 or failed to understand it when they were developing their resolver code. Most firewalls don't care diddly squat about DNS record types. For those that do blocking unknown types in firewalls does diddly squat for security and just cause problems for everyone. Just turn the DNS checking off. NAT (carrier grade or otherwise) don't care about DNS message content. Then there are provisioning systems which haven't been upgraded since Noah was a boy and you don't have to use anyway. > So here's the to-be-ridiculed part... > I suggest a new strategy: let the wookie win. Instead of denying their exist > ence, accept that there will be more folks who want to deploy new DNS-using a > pplications quickly and without waiting for the entire Internet of DNS-relate > d-things to change. It's going to happen whether we want it to or not. So w > e might as well try to fix whatever problems we envision it will cause, and p > rovide guidance of how to use TXT the best way. Right now RFC 5507 only warn > s folks against it, but I don't see a "if you are going to use TXT anyway, th > en do it this way" type thing. Nor do I see an IANA registry of prefix names > , nor an RFC describing a general solution to the wildcarding problem when pr > efixing. I think those things are possible, maybe. > > We can require abstinence or we can give out condoms. Which one do you think > is more likely to prevent spread of disease? > > -hadriel > > > On Aug 25, 2013, at 11:36 PM, "Dickson, Brian" wrote: > > > At the risk of ridicule, and in the interest of potentially useful results: > > > > Why not deprecate TXT, or at least abandon the current TXT and introduce > > a new TXT code point? And, as each iteration gets trashed, move on to the > > next one? > > > > It's not like there is a shortage of type code values, and it is not like > > the RDATA of TXT is complicated, or in any way is required to be unique. > > SPF is, after all, exactly the same as TXT except for being different. > > > > If SPF want to take over TXT, let them. We can all move to TXT2, until > > someone ruins it, and then we can introduce TXT3, etc. > > > > I realize it is rather silly, but if it works, and it disambiguates things, > > the fact that it _is_ silly is perhaps not the greatest reason for not > > doing it. > > > > This might provide a small clue to the next group of other-protocol folk, > > that using TXT instead of asking for their own RRTYPE, is foolish, unwise, > > and likely to result in having a new RRTYPE lobbed at them in retaliation. > > :-) > > > > (My two cents, late to the discussion.) > > > > Brian > > > > _______________________________________________ > 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 drc@virtualized.org Tue Aug 27 08:43: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 9C0CB21F8449 for ; Tue, 27 Aug 2013 08:43:55 -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 xxk1ylY8MDKY for ; Tue, 27 Aug 2013 08:43:49 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAE611E81A2 for ; Tue, 27 Aug 2013 08:43:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id 87B3D87128; Tue, 27 Aug 2013 11:43:47 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 10158-02; Tue, 27 Aug 2013 11:43:47 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id EEAC187127; Tue, 27 Aug 2013 11:43:46 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1B9239B1-9F7E-4D5E-809B-30D29313E487"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: <0CF9372A-84E5-49B3-849D-0ACBEDA2AF5C@icsi.berkeley.edu> Date: Tue, 27 Aug 2013 08:43:45 -0700 Message-Id: <4D07D4AC-CFE0-475D-ADE7-B28A06EB0467@virtualized.org> References: <0CF9372A-84E5-49B3-849D-0ACBEDA2AF5C@icsi.berkeley.edu> To: Nicholas Weaver X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 27 Aug 2013 15:43:55 -0000 --Apple-Mail=_1B9239B1-9F7E-4D5E-809B-30D29313E487 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 27, 2013, at 7:44 AM, Nicholas Weaver = wrote: > Thus it really is that the major problem is provisioning, not = transport, of unknown DNS types. I suspect one of the problems here is that in the universe of mediocrity = that is the underlying infrastructure upon which applications that use = the DNS rely, you have a bell curve of sorts of what works and what = doesn't. As a result, when you get into arguments about whether a = protocol feature can be used, people can trot out the 5 sigma extremes = and say e.g., "see, doesn't work - we have to use TXT". They're not = necessarily wrong, but it does suggest that the ossification of the DNS = is pretty much complete... Regards, -drc --Apple-Mail=_1B9239B1-9F7E-4D5E-809B-30D29313E487 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----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSHMkxAAoJENV6ebf0/4rXHgMIAJi8SEQla6PW9sQcWNj9x45w UoBVmMD9qwNI1dqIjBxqENAuArNOeB0g0qE0hgSkdzuWkJCrYHkC9F+HlgTYqroG 4UgnHEziMH7Cmgzj0OwH8+0WLI9oOQGq/7qt7c9IWWo7dp+gA7zZdMHs3CpmmvnU DgZ3t/qTTHUdUNZHUUz30RCXVTaEV+jW/UA+xPrcULElUXAmAWMarA/CRFq5j1H1 7RWaokBVf1L/yk0kUj5LuTYYD7WXrbCh62lTHG9Xlvs49ZbdhUhLB9jsp0NxNeo4 QXH/DNW7VkS/F2bnccDdUO/7ZXgp+1yz/TMPNJ4nnMlJeL6pjiDxuGM9watSNLs= =yy8+ -----END PGP SIGNATURE----- --Apple-Mail=_1B9239B1-9F7E-4D5E-809B-30D29313E487-- From hadriel.kaplan@oracle.com Tue Aug 27 08:56:16 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 435F011E8389 for ; Tue, 27 Aug 2013 08:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 wBKBwvtpICpD for ; Tue, 27 Aug 2013 08:56:07 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 598FB21E80F3 for ; Tue, 27 Aug 2013 08:56:06 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7RFu5C8031401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Aug 2013 15:56:05 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RFu3Hg009502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 15:56:04 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7RFu3Gp025646; Tue, 27 Aug 2013 15:56:03 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Aug 2013 08:56:03 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <20130827152359.7F52338EB205@drugs.dv.isc.org> Date: Tue, 27 Aug 2013 11:56:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <53B7710F-773D-4576-A761-8C6D7304A885@oracle.com> References: <20130827152359.7F52338EB205@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "dnsext@ietf.org" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 27 Aug 2013 15:56:16 -0000 On Aug 27, 2013, at 11:23 AM, Mark Andrews wrote: > There are DNS servers that completely support arbitary types. And > have for over a decade. Before that they could resolve and cache > arbitary types and have done so for over 20 years. About the only > one that doesn't is that shipped by Microsoft. >=20 > There are DNS resolvers that support arbitary types and have been > able to for over 20 years. This is basic RFC 1034 functionality. > Unfortunately Microsoft failed to read that part of RFC 1034 or > failed to understand it when they were developing their resolver > code. >=20 > Most firewalls don't care diddly squat about DNS record types. For > those that do blocking unknown types in firewalls does diddly squat > for security and just cause problems for everyone. Just turn the > DNS checking off. >=20 > NAT (carrier grade or otherwise) don't care about DNS message > content.=20 > Then there are provisioning systems which haven't been upgraded > since Noah was a boy and you don't have to use anyway. Actually, I know of at least one CGN that does. But it doesn't really matter... I think you're missing the point. The = point isn't that NONE support unknown RRs, the point is that SOME do = not. Of course a lot of things do support unknown RR types.=20 So if you're a developer of some new thing, and you want everyone, = everywhere, to be able to use your new thing, would you choose to use a = new RR knowing some of your potential users can't use that? Or would = you choose to use something you know works for everyone everywhere? It's a very hard thing to ignore a potential part of your target user = base, or hope to force them to replace equipment or change DNS = registries just to use your new thing. It's a barrier to adoption most = developers would want to avoid, I would think. -hadriel From johnl@iecc.com Tue Aug 27 09:23: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 256CC11E83A3 for ; Tue, 27 Aug 2013 09:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.613 X-Spam-Level: X-Spam-Status: No, score=-102.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 T+wxVcbc-6iI for ; Tue, 27 Aug 2013 09:23:46 -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 9176111E83A1 for ; Tue, 27 Aug 2013 09:23:45 -0700 (PDT) Received: (qmail 76927 invoked from network); 27 Aug 2013 16:23:40 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Aug 2013 16:23:40 -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=521cd28c.xn--btvx9d.k1308; i=johnl@user.iecc.com; bh=S6A3yightTPVesRQNZ+ni/gpYj+s6u/P51uLzHdROvM=; b=NHKNpZ20MuhUXA6BiL++3p0RhPBIXfg1zq2eebX3wHVB13mmq520CaYTRorvvPwNU4V869S7Ow/D6XIYnqFQjHVqiHZZmFw25gs7OEHmTwQ5C1LlzbnQ6K7V4W70AgE7fdJVvYXn/cVmcM8xtrfY4f7J0NQf5a7hds0+f+w1kJpmuNeoGjjgpaR+Ra9M/0IAfhPfGwo2dVGs9yiMEmZJc+GgV9BmBUPOW0Bm9Mnhf34y8uTTFZfTCgxuSDRd4DiM 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=521cd28c.xn--btvx9d.k1308; olt=johnl@user.iecc.com; bh=S6A3yightTPVesRQNZ+ni/gpYj+s6u/P51uLzHdROvM=; b=oc6gnIBJtG15TR3AsCPuxLF2bZ0Uz69y24RvWugJiYll+QxSerlgii2QGR6IaRV/tVPHK81jsFc87tDjmWL1IZAaFg1neBwp77zJPhQ/UJTBLuevBJuhx/Q97HvLt1/J9g2B6SSczK8KyZXDvV+DdxMuuKcqsh1g2bvvO8lUHS3Wf/ZqWiHoumFibqPVkbu00QQnJCYi+Hnj1WM87GdN0WUq1wEotp6fzy4m9sOqjJGX76VlVZB6jRoMZ9kOc1Vb Date: 27 Aug 2013 16:23:16 -0000 Message-ID: <20130827162316.90467.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20130827151042.GI19367@besserwisser.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 27 Aug 2013 16:23:50 -0000 >This is indeed interesting data that "complicates" the IMNSHO >sweeping statements of 6686. The provisioning problem remains, but the >infrastructure is not as broken as stated. I know the guy who wrote 6686 and contributed some of the data. We were entirely aware that DNS servers other than Microsoft's have little trouble with type 99, and the main problems are provisioning software and middleboxes. Why do you assume otherwise? R's, John From jay@nzrs.net.nz Tue Aug 27 21:01:08 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 7C91211E812C for ; Tue, 27 Aug 2013 21:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 iAjrWb0AZu6x for ; Tue, 27 Aug 2013 21:01:04 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id A2F2111E8128 for ; Tue, 27 Aug 2013 21:01:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 7A3E54B7139; Wed, 28 Aug 2013 16:01:00 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU22X6nGyUcd; Wed, 28 Aug 2013 16:00:53 +1200 (NZST) Received: from [192.168.1.230] (121-74-100-115.telstraclear.net [121.74.100.115]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id DAE904B6DED; Wed, 28 Aug 2013 16:00:52 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <20130826012857.GL8259@mx1.yitter.info> Date: Wed, 28 Aug 2013 16:00:51 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <00DB8F30-6BF8-476B-BAA4-5DFD2C96D2C2@nzrs.net.nz> References: <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <20130825222847.GA49656@gaon.net> <20130825230012.GG8259@mx1.yitter.info> <3880112C-2AC7-433F-B77D-6A5D07365CD9@virtualized.org> <20130825234637.GJ8259@mx1.yitter.info> <20130826012857.GL8259@mx1.yitter.info> To: Andrew Sullivan , "dnsext@ietf.org Group" X-Mailer: Apple Mail (2.1508) Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 28 Aug 2013 04:01:08 -0000 On 26/08/2013, at 1:28 PM, Andrew Sullivan = wrote: > This isn't religion: I'm as sickend by > this use of TXT as anyone. But the world makes us as much as we make > the world, and I think the TXT fight _in this case_ is lost. Having thought about this for a few days I've changed my mind and I'm = happy to see SPF(99) go. What clinched it for me was this note from = Andrew above as it helped me realise my issue is with the misuse of TXT = and not the solution of a new type specific to SPF. So let's let it go = and I'm sure with a bit of thought we can find a way to fix the = overloading of TXT and try to sell that as a better migration path for = "v=3Dspf1" in TXT than SPF(99) ever was. =3D We know the issues can be summarised as: 1. The key benefits people find from using TXT are - it is well supported - it is free form so any experimentation is possible and no standards = body engagement is needed 2. The key issues with the use of TXT are - people not using prefixes and so conflating various uses (and as = Hadriel points out, no prefix registry) - the wildcard issue, which I'm going to restate as how to define a = policy at one level that applies to lower levels, is a key reason for = not wanting to use prefixes. =3D So here's an example solution (and I mean an example since I'm sure = there is a lot more to consider): 3. Create a new generic record for free form policy data that must be = prefixed by protocol. For example: _spf .example.com. POL "a:mail.example.com -all" If we provide that one record then anyone can use it for any policy info = without further need to change the DNS. To me that seems much more = utilitarian than a protocol specific RR. =3D A solution for the wildcard issue is a bit more complex, but here's = an example 4. Add an rdata field to the POL record that if set to "*" (asterisk) = applies this policy to the next level _spf.example.com. POL * "a:mail.example.com -all" This record is then used to synthesise the POL record in exactly the = same way that a wildcard is. 5. Or we could add a record under each sub-domain that refers back up a = level: _spf.sub.example.com. POLPTR example.com. Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From doug.mtview@gmail.com Tue Aug 27 22:10:53 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 30AEF11E8136 for ; Tue, 27 Aug 2013 22:10:53 -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 0wAMgLxIYaP2 for ; Tue, 27 Aug 2013 22:10:52 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 88A2811E8128 for ; Tue, 27 Aug 2013 22:10:52 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id p10so5785240pdj.18 for ; Tue, 27 Aug 2013 22:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YDTSOZgtQX4mcJ+YCwKb2FXRrIhQu3sejy7fYpWzFls=; b=b3AqqExTK8VUStafbb4yrgBMWYA4PCGEE67u9DI7c964FyUkCcZtdhuE1ieEFvoVqB Hvjaqw8jq8OMM9GAw4zseA0e4rwtrSNKRep2EucQHehjwC1SeWv+ZNYMixTkrxsLyeoa q9h3UBfvmzg1JStl5wCj2EeeWbACy3No9o2fGSdgEKfhtXLwgdkMJUMvYggP2yMleEng bqgi+uxfLL5MCdJliMHm89sRQFkxpw9+HcKj43GiuCUvUVp6J+kOJVo5iyYMFsVv/sj7 SPuwIMXtz/rE+iyZJk36VEAoAIQr08tZsJg7AG4RKgaV/Fla4iUXtY2cgurmRAqLI0Gt NmhA== X-Received: by 10.66.253.40 with SMTP id zx8mr24779704pac.71.1377666651336; Tue, 27 Aug 2013 22:10:51 -0700 (PDT) Received: from ?IPv6:2601:9:7680:308:c9ed:2849:9330:64b0? ([2601:9:7680:308:c9ed:2849:9330:64b0]) by mx.google.com with ESMTPSA id ef10sm31166006pac.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 22:10:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Douglas Otis In-Reply-To: <00DB8F30-6BF8-476B-BAA4-5DFD2C96D2C2@nzrs.net.nz> Date: Tue, 27 Aug 2013 22:10:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <20130825222847.GA49656@gaon.net> <20130825230012.GG8259@mx1.yitter.info> <3880112C-2AC7-433F-B77D-6A5D07365CD9@virtualized.org> <20130825234637.GJ8259@mx1.yitter.info> <20130826012857.GL8259@mx1.yitter.info> <00DB8F30-6BF8-476B-BAA4-5DFD2C96D2C2@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 28 Aug 2013 05:10:53 -0000 On Aug 27, 2013, at 9:00 PM, Jay Daley wrote: > On 26/08/2013, at 1:28 PM, Andrew Sullivan = wrote: >=20 >> This isn't religion: I'm as sickend by >> this use of TXT as anyone. But the world makes us as much as we make >> the world, and I think the TXT fight _in this case_ is lost. >=20 > Having thought about this for a few days I've changed my mind and I'm = happy to see SPF(99) go. What clinched it for me was this note from = Andrew above as it helped me realise my issue is with the misuse of TXT = and not the solution of a new type specific to SPF. So let's let it go = and I'm sure with a bit of thought we can find a way to fix the = overloading of TXT and try to sell that as a better migration path for = "v=3Dspf1" in TXT than SPF(99) ever was. Dear Jay, The current SPF specification may require receivers to emit as many as = 222 DNS transactions in an effort to aggregate required data. In = contrast, a well considered APL scheme should offer the needed data = within one RRset transaction in binary form to support a store and = forward protocol. > =3D We know the issues can be summarised as: >=20 > 1. The key benefits people find from using TXT are > - it is well supported > - it is free form so any experimentation is possible and no standards = body engagement is needed Running complex scripts just above DNS is a security risk, especially = when it represents experimentation where support is often limited a few = advocates.=20 > 2. The key issues with the use of TXT are > - people not using prefixes and so conflating various uses (and as = Hadriel points out, no prefix registry) > - the wildcard issue, which I'm going to restate as how to define a = policy at one level that applies to lower levels, is a key reason for = not wanting to use prefixes. A prefix approach kills wildcard schemes. Since overwhelming use of SPF = establishes outbound address ranges for an email domain, TXT represents = a remarkably inefficient approach. Even the policy "all" is largely = ignored. DNS was never intended to offer heavily formatted textual data = in the manner of HTTP. Bulky data requires a reliable transport that = introduce significant delay. This would be silly since that is what is = expected of the message transport. In other words, bulk data is being = carried by the wrong transport. > =3D So here's an example solution (and I mean an example since I'm = sure there is a lot more to consider): >=20 > 3. Create a new generic record for free form policy data that must be = prefixed by protocol. For example: >=20 > _spf .example.com. POL "a:mail.example.com -all" Why? If POL is an alias for TXT, this disrupts _dmarc, _adsp, _atps that = convey concise and small amounts of data at a prefix. > If we provide that one record then anyone can use it for any policy = info without further need to change the DNS. To me that seems much more = utilitarian than a protocol specific RR. >=20 > =3D A solution for the wildcard issue is a bit more complex, but = here's an example >=20 > 4. Add an rdata field to the POL record that if set to "*" (asterisk) = applies this policy to the next level >=20 > _spf.example.com. POL * "a:mail.example.com -all" Already being done as an "alignment" flag in other policy records. > This record is then used to synthesise the POL record in exactly the = same way that a wildcard is. >=20 > 5. Or we could add a record under each sub-domain that refers back up = a level: >=20 > _spf.sub.example.com. POLPTR example.com. sub.example.com could offer authoritative policy for sub.example.com? = atps offers authorization for a list of domains using a hash label list. = Both small and fast.=20 Regards, Douglas Otis From yaojk@cnnic.cn Wed Aug 28 01:07: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 9F52B11E815C for ; Wed, 28 Aug 2013 01:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.934 X-Spam-Level: X-Spam-Status: No, score=-99.934 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 ERNiMfw5Ep2E for ; Wed, 28 Aug 2013 01:07:39 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 2920C11E815F for ; Wed, 28 Aug 2013 01:07:38 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO healthyao-think) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 28 Aug 2013 16:07:35 +0800 Date: Wed, 28 Aug 2013 16:07:36 +0800 From: "Jiankang Yao" To: "Douglas Otis" , "Jay Daley" References: <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <20130825222847.GA49656@gaon.net> <20130825230012.GG8259@mx1.yitter.info> <3880112C-2AC7-433F-B77D-6A5D07365CD9@virtualized.org> <20130825234637.GJ8259@mx1.yitter.info> <20130826012857.GL8259@mx1.yitter.info> <00DB8F30-6BF8-476B-BAA4-5DFD2C96D2C2@nzrs.net.nz>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2013082816073222666410@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart543865816146_=----" Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: yaojk List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 08:07:44 -0000 This is a multi-part message in MIME format. ------=_001_NextPart543865816146_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCkZyb206IERvdWdsYXMgT3Rpcw0KRGF0ZTogMjAxMy0wOC0yOCAxMzoxMA0KVG86IEpheSBE YWxleQ0KQ0M6IGRuc2V4dEBpZXRmLm9yZyBHcm91cA0KU3ViamVjdDogUmU6IFtkbnNleHRdIFRo ZSBzdGF0ZSBvZiBETlMgc3VwcG9ydCwgd2FzIERlcHJlY2F0aW5nIFNQRg0KDQoNCj5EZWFyIEph eSwNCg0KPlRoZSBjdXJyZW50IFNQRiBzcGVjaWZpY2F0aW9uIG1heSByZXF1aXJlIHJlY2VpdmVy cyB0byBlbWl0IGFzIG1hbnkgYXMgMjIyIEROUyB0cmFuc2FjdGlvbnMgaW4gYW4gZWZmb3J0IHRv IGFnZ3JlZ2F0ZSByZXF1aXJlZCBkYXRhLiAgSW4gY29udHJhc3QsIGEgd2VsbCBjb25zaWRlcmVk IEFQTCBzY2hlbWUgc2hvdWxkIG9mZmVyIHRoZSBuZWVkZWQgZGF0YSB3aXRoaW4gb25lIFJSc2V0 IHRyYW5zYWN0aW9uIGluIGJpbmFyeSBmb3JtIHRvIHN1cHBvcnQgYSBzdG9yZSBhbmQgZm9yd2Fy ZCBwcm90b2NvbC4NCj4NCj4NCg0KMjIyIEROUyB0cmFuc2FjdGlvbnMgPw0KDQphbnkgZXhhbXBs ZSBhYm91dCBpdD8= ------=_001_NextPart543865816146_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
 
Date: 2013-08-28 13:10
To: Jay Daley
Subject: Re: [dnsext] The state of DNS support, was Depre= cating=20 SPF
 
 
>Dear Jay,
 
>The current SPF specification may requir= e receivers to emit as many as 222 = ;DNS transactions in an effort to aggregate&= nbsp;required data.  In contrast, a well&nbs= p;considered APL scheme should offer the nee= ded data within one RRset transaction in&nbs= p;binary form to support a store and fo= rward protocol.
>
>
 
222 DNS transactions ?
 
any example about it?
 
 
 
------=_001_NextPart543865816146_=------ From jay@nzrs.net.nz Wed Aug 28 01:09: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 0A8A911E8160 for ; Wed, 28 Aug 2013 01:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 hRO2xaVdswH8 for ; Wed, 28 Aug 2013 01:09:06 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3C311E8164 for ; Wed, 28 Aug 2013 01:09:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 9886D4B704E; Wed, 28 Aug 2013 20:09:05 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4VlYnBWHEno; Wed, 28 Aug 2013 20:08:58 +1200 (NZST) Received: from [192.168.1.230] (121-74-100-115.telstraclear.net [121.74.100.115]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id DC56A4B7036; Wed, 28 Aug 2013 20:08:57 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: Date: Wed, 28 Aug 2013 20:08:57 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <2E767ED7-F7DF-4FF5-A126-D342FF013322@nzrs.net.nz> References: <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <20130825222847.GA49656@gaon.net> <20130825230012.GG8259@mx1.yitter.info> <3880112C-2AC7-433F-B77D-6A5D07365CD9@virtualized.org> <20130825234637.GJ8259@mx1.yitter.info> <20130826012857.GL8259@mx1.yitter.info> <00DB8F30-6BF8-476B-BAA4-5DFD2C96D2C2@nzrs.net.nz> To: Douglas Otis X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 28 Aug 2013 08:09:11 -0000 Hi Douglas On 28/08/2013, at 5:10 PM, Douglas Otis wrote: > The current SPF specification may require receivers to emit as many as = 222 DNS transactions in an effort to aggregate required data. In = contrast, a well considered APL scheme should offer the needed data = within one RRset transaction in binary form to support a store and = forward protocol. >=20 >> =3D We know the issues can be summarised as: >>=20 >> 1. The key benefits people find from using TXT are >> - it is well supported >> - it is free form so any experimentation is possible and no standards = body engagement is needed >=20 > Running complex scripts just above DNS is a security risk, especially = when it represents experimentation where support is often limited a few = advocates.=20 >=20 >> 2. The key issues with the use of TXT are >> - people not using prefixes and so conflating various uses (and as = Hadriel points out, no prefix registry) >> - the wildcard issue, which I'm going to restate as how to define a = policy at one level that applies to lower levels, is a key reason for = not wanting to use prefixes. >=20 > A prefix approach kills wildcard schemes. Since overwhelming use of = SPF establishes outbound address ranges for an email domain, TXT = represents a remarkably inefficient approach. Even the policy "all" is = largely ignored. DNS was never intended to offer heavily formatted = textual data in the manner of HTTP. Bulky data requires a reliable = transport that introduce significant delay. This would be silly since = that is what is expected of the message transport. In other words, bulk = data is being carried by the wrong transport. An interesting point of view, but orthogonal to my proposal. People are = already using TXT in the way you caution against and we aren't going to = stop that except by deprecating TXT. My proposal does not address = whether or not this usage is a good idea but how we tidy split out some = of that usage into a more manageable form. >> =3D So here's an example solution (and I mean an example since I'm = sure there is a lot more to consider): >>=20 >> 3. Create a new generic record for free form policy data that must = be prefixed by protocol. For example: >>=20 >> _spf .example.com. POL "a:mail.example.com -all" >=20 > Why? If POL is an alias for TXT, this disrupts _dmarc, _adsp, _atps = that convey concise and small amounts of data at a prefix. It's not an alias for TXT, it's a semantically different record. = Disruption is prevented by use of a prefix registry. >> If we provide that one record then anyone can use it for any policy = info without further need to change the DNS. To me that seems much more = utilitarian than a protocol specific RR. >>=20 >> =3D A solution for the wildcard issue is a bit more complex, but = here's an example >>=20 >> 4. Add an rdata field to the POL record that if set to "*" = (asterisk) applies this policy to the next level >>=20 >> _spf.example.com. POL * "a:mail.example.com -all" >=20 > Already being done as an "alignment" flag in other policy records. What are those? >> This record is then used to synthesise the POL record in exactly the = same way that a wildcard is. >>=20 >> 5. Or we could add a record under each sub-domain that refers back = up a level: >>=20 >> _spf.sub.example.com. POLPTR example.com. >=20 > sub.example.com could offer authoritative policy for sub.example.com? = atps offers authorization for a list of domains using a hash label = list. Both small and fast.=20 The hashed list of labels is only appropriate in ATPS because a Verifier = has a signature and wants to check the originator of that signature. = That's quite different from this case where the SPF verifier has an = email from sub.example.com and wants to know what policy to apply. It = can't just take a punt that the policy to use is that of example.com and = then construct a hash of that and check to see if it is listed. BTW the irony of ATPS using a TXT record for this hashed label list may = have escaped you. Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From sm@elandsys.com Wed Aug 28 05:53:47 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 5D02F11E8188 for ; Wed, 28 Aug 2013 05:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 MnKTf5yP0Okh for ; Wed, 28 Aug 2013 05:53:46 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1DA11E8187 for ; Wed, 28 Aug 2013 05:53:44 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.239]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7SCrVBL022307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Aug 2013 05:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377694424; bh=rh/VYLpXECskLrfuvuVBK4Mo6UvjjfC5BaCfGAi/egc=; h=Date:To:From:Subject:Cc; b=mTsNtgkSaOuc2259klUi13mpdULY4IH1HEGR0vS1/q3wrQ5lW71Gk7vXm70HFtrpP wguYCe+eaSS0BV9qbMTE/ImFnE/7sigbYSZH1sqlCyk+Q2IEZ7+17lo8nKbrqQ4c8H nNVbpicKRdMNcg25AECSwae/J8/PNcTJbgd+/Zls= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377694424; i=@elandsys.com; bh=rh/VYLpXECskLrfuvuVBK4Mo6UvjjfC5BaCfGAi/egc=; h=Date:To:From:Subject:Cc; b=kBMH+kbY/yfz14g1NeKgHU/f7plLLvKb0iwZQCo0kB4DDFXaMckLils4su47IqyMT +WBDNAzYFJJBTavhdgZ9NgSCP01ufTo3TxfeaGsYzdT0fKRRwwBakE7LkU9qlNQ50G novTZieALRRgJv1w7VkHoVruH4gnD64IGgwuyaZY= Message-Id: <6.2.5.6.2.20130828053243.06ee4650@elandsys.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 28 Aug 2013 05:53:08 -0700 To: dnsext@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ted Lemon Subject: [dnsext] RFC 5507 issues relating to draft-ietf-spfbis-4408bis-19 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, 28 Aug 2013 12:53:47 -0000 Hello, I posted message to the IETF mailing list about RFC 5507 issues relating to draft-ietf-spfbis-4408bis-19 ( http://www.ietf.org/mail-archive/web/ietf/current/msg81885.html ). As a note to Ted Lemon I would appreciate if discussion of the topic on dnsext@ietf.org could be considered as off-topic. Regards, S. Moonesamy From Ted.Lemon@nominum.com Wed Aug 28 06:59:19 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 86F2421F9C47 for ; Wed, 28 Aug 2013 06:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 ATQTzREr0JNF for ; Wed, 28 Aug 2013 06:59:09 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id ED04921F9B53 for ; Wed, 28 Aug 2013 06:59:08 -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 DSNKUh4CLJouELy5HLriixRuSLUWgRQPYQOu@postini.com; Wed, 28 Aug 2013 06:59:08 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 6B8D51B82C4 for ; Wed, 28 Aug 2013 06:59:08 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-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 610FE190070; Wed, 28 Aug 2013 06:59:08 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 28 Aug 2013 06:58:56 -0700 From: Ted Lemon To: S Moonesamy Thread-Topic: RFC 5507 issues relating to draft-ietf-spfbis-4408bis-19 Thread-Index: AQHOo+2jSOhUeawD0kCwrf7/OGTFPZmrGvYA Date: Wed, 28 Aug 2013 13:58:55 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775268D49@mbx-01.win.nominum.com> References: <6.2.5.6.2.20130828053243.06ee4650@elandsys.com> In-Reply-To: <6.2.5.6.2.20130828053243.06ee4650@elandsys.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: <9338C59ABD34BE418F870934B40A95B8@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dnsext] RFC 5507 issues relating to draft-ietf-spfbis-4408bis-19 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, 28 Aug 2013 13:59:19 -0000 On Aug 28, 2013, at 8:53 AM, S Moonesamy wrote: > As a note to Ted Lemon I would appreciate if discussion of the topic on d= nsext@ietf.org could be considered as off-topic. dnsext is a discussion list for a closed working group. If members of the= mailing list wish to participate in an IETF last call, they must do so on = the IETF mailing list, not on the dnsext mailing list. I have been follow= ing all three lists during the IETF last call, and am sure that the points = raised on dnsext were also raised both in the spfbis working group last cal= l and on the IETF mailing list, so I don't think this should be a problem. = If someone on the dnsext mailing list does not agree with this assessment= , they should talk to me about it. From johnl@iecc.com Wed Aug 28 09:12: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 3790611E8221 for ; Wed, 28 Aug 2013 09:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.613 X-Spam-Level: X-Spam-Status: No, score=-102.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 Jx+nrAOjAExn for ; Wed, 28 Aug 2013 09:12: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 6C9E711E81FE for ; Wed, 28 Aug 2013 09:12:49 -0700 (PDT) Received: (qmail 33243 invoked from network); 28 Aug 2013 16:12:48 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Aug 2013 16:12:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521e2180.xn--hew.k1308; i=johnl@user.iecc.com; bh=eM20b9nE9Vz6t8MxXI2HgyisbzIGpUHK6BXgf0YMf10=; b=ixsSDuc0h6yW/5WFe5ox1iUij/kM2yUYdisek+HRtOv4BiT/zPR/zoxKQQwXN2SHmg2vFPGE/8FBIE3Uzrhhqd9eCUJg4gpVJjZ9ZrM3XVC0HvJdOxtDi9vhCvupbkrjMFRqGb+DWeTnOTzpJDqNEpRYv0umVTvZHHvLT7gutgkibe+vvdSHDT/OvPRR4ZamvsVHZ8gVMGDkcqRz/cEO28eEDJsyR0asZaApl90Q9hcieZaQY5B3sl3MdIQyHTT+ 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=521e2180.xn--hew.k1308; olt=johnl@user.iecc.com; bh=eM20b9nE9Vz6t8MxXI2HgyisbzIGpUHK6BXgf0YMf10=; b=Ss9ERvqf7QAJE/VyH7PX6ymwYXIIIqIa+iYUED9/1K8HHQZDkeSiZ/KBibf9Ybo+Kx08fvUkgNLjtvhz1j9r4idoETH4QWHgKEsU9k7khdtTLil3owyf0Dj0Wp4Iof33xZkIKR3tDdRVEYNu8xpCD+oQqxbQYk8kRYCxC/SRJuHMNMxgR5329ht6b5ySq1mV3DckS6HJr+/+uxjri1oMTz2+8xF7KhVaq2X7B3tHUIMkKCo1FmdEqNNDJSjC2Rt7 Date: 28 Aug 2013 16:12:26 -0000 Message-ID: <20130828161226.99262.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <00DB8F30-6BF8-476B-BAA4-5DFD2C96D2C2@nzrs.net.nz> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 28 Aug 2013 16:12:55 -0000 >Having thought about this for a few days I've changed my mind and I'm happy to see SPF(99) go. Whew! >= So here's an example solution (and I mean an example since I'm sure there is a lot more to consider): > >3. Create a new generic record for free form policy data that must be prefixed by protocol. For example: > >_spf .example.com. POL "a:mail.example.com -all" > >If we provide that one record then anyone can use it for any policy info without further need to change the DNS. >To me that seems much more utilitarian than a protocol specific RR. If it's prefixed, what's the advantage over TXT other than it isn't TXT? Once word gets out about it, I'd expect people to load it up with all of the junk that people load into TXT. You can be sure that some bright bulb will use it without a prefix, arguing that's OK because all of the other uses are prefixed so this won't collide. >= A solution for the wildcard issue is a bit more complex, but here's an example > >4. Add an rdata field to the POL record that if set to "*" (asterisk) applies this policy to the next level > >_spf.example.com. POL * "a:mail.example.com -all" > >This record is then used to synthesise the POL record in exactly the same way that a wildcard is. This seems awfully complicated, and would require non-trivial extra code in every authoritative name server. Seems to me that if we could provision new RRTYPEs with less pain, they already do what we want, don't need extra demultiplexing, and has predictable and useful wildcard behavior. Or if you want to open up the guts of the DNS, just make this work: _prefix.*.foo.example. TXT "stuff about foo" I figure it shouldn't take more than a decade to discover all of the weird ways it interacts with NSEC3. R's, John From hadriel.kaplan@oracle.com Wed Aug 28 10:52: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 27A3911E829F for ; Wed, 28 Aug 2013 10:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 E5OwMY3Mp2VP for ; Wed, 28 Aug 2013 10:52:32 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1C76B11E8286 for ; Wed, 28 Aug 2013 10:52:16 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7SHqCCW012005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Aug 2013 17:52:13 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7SHqB5Z023998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Aug 2013 17:52:12 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7SHqBcj023972; Wed, 28 Aug 2013 17:52:11 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Aug 2013 10:52:11 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <00DB8F30-6BF8-476B-BAA4-5DFD2C96D2C2@nzrs.net.nz> Date: Wed, 28 Aug 2013 13:52:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <20130825222847.GA49656@gaon.net> <20130825230012.GG8259@mx1.yitter.info> <3880112C-2AC7-433F-B77D-6A5D07365CD9@virtualized.org> <20130825234637.GJ8259@mx1.yitter.info> <20130826012857.GL8259@mx1.yitter.info> <00DB8F30-6BF8-476B-BAA4-5DFD2C96D2C2@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 28 Aug 2013 17:52:49 -0000 On Aug 28, 2013, at 12:00 AM, Jay Daley wrote: > 3. Create a new generic record for free form policy data that must be = prefixed by protocol. For example: >=20 > _spf .example.com. POL "a:mail.example.com -all" >=20 > If we provide that one record then anyone can use it for any policy = info without further need to change the DNS. To me that seems much more = utilitarian than a protocol specific RR. Isn't that just TXT with a new name? Why not just stick to TXT type-16? > =3D A solution for the wildcard issue is a bit more complex, but = here's an example > 4. Add an rdata field to the POL record that if set to "*" (asterisk) = applies this policy to the next level > _spf.example.com. POL * "a:mail.example.com -all" > This record is then used to synthesise the POL record in exactly the = same way that a wildcard is. > 5. Or we could add a record under each sub-domain that refers back up = a level: > _spf.sub.example.com. POLPTR example.com. That requires DNS server code to change, right? That feels like a high = barrier. Thinking out loud, why couldn't we do this: 1) The IETF asks IANA to create a registry for name tokens, for use as = domain name label prefixes, and "v=3D" in TXT RDATA. 2) We pre-reserve the token "iana", which means we reserved a label = prefix of "_iana", as well as "v=3Diana" as the first chars of the TXT = RDATA. 3) We define an IETF RFC for this new "IANA" application, such that it = is intended for other TXT-using applications to use, for the purpose of = wildcarding and redirection. So future apps don't need to re-do SPF's = redirection stuff, but can instead use this new RFC's ABNF and rules to = get redirection as well as wildcard support. More importantly, it = prevents cluttering of the apex. The specific apps use their own = registered name tokens for app-specific RDATA, but "iana" helps them for = cases as shown below... *.example.com. MX 10 a.example.com *.example.com. TXT "v=3Diana = wildcard=3D_iana.example.com" _qux.example.com TXT "" _foo._iana.example.com. TXT "v=3Dfoo " _bar._iana.example.com. TXT "v=3Dbar " _zoo._iana.example.com. TXT "v=3Diana = redirect=3D_zoo.pwned.example.net" This second "*.example.com" wildcard record is a normal TXT wildcard = record, and thus causes a synthesized TXT RR to be returned for name = queries where no name exists. The returned RR is exactly what it is = today for TXT RRs: the contents of the RDATA shown above. There is NO change to DNS servers or client libraries required = whatsoever. So a client querying for "_qux.example.com" gets back "" as today. But a client querying "_foo.nonameexists.example.com" on the above would = get back "v=3Diana wildcard=3D_iana.example.com". The specific FOO application (not DNS) sees that, and if it supports our = new RFC, knows to generate a new query for the wildcarded-to name, but = with its specific application prefix added in front. So it would now = query "_foo._iana.example.com" and get its rdata content. This would of course cause FOO to do two DNS queries, but only for cases = where a wildcard is used. DNS servers could (optionally) optimize to = reduce it to one answer if they support this new "iana" RFC as well, by = synthesizing the final answer. But if they don't it sill works. The only difference between "wildcard=3D" and "redirect=3D" is that = "wildcard=3D" makes the app prepend its name token prefix again = to the identified target domain-spec, whereas in "redirect=3D" = it does not prepend its name token prefix to the target domain-spec.=20 Why do all that above? To keep too many TXT RRs from cluttering up the = apex, while still letting them have wildcard support. And by reserving = our own "iana" application ABNF and use, we give sanctioned guidance on = how new apps can do this without screwing it up for everyone else, and = let that portion possibly be integrated in DNS servers someday. -hadriel From jay@nzrs.net.nz Wed Aug 28 14:22: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 2EA0321E8054 for ; Wed, 28 Aug 2013 14:22: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 GsDc4xgUtzrZ for ; Wed, 28 Aug 2013 14:22:05 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5BD11E81A3 for ; Wed, 28 Aug 2013 14:22:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 4E31E4B7171; Thu, 29 Aug 2013 09:22:03 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoujZNDSRwTt; Thu, 29 Aug 2013 09:21:55 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id D92CC4B717D; Thu, 29 Aug 2013 09:21:55 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: Date: Thu, 29 Aug 2013 09:09:02 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <4943FDC9-72C3-4E9C-8E5E-C44B7D96323F@nzrs.net.nz> References: <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <20130825222847.GA49656@gaon.net> <20130825230012.GG8259@mx1.yitter.info> <3880112C-2AC7-433F-B77D-6A5D07365CD9@virtualized.org> <20130825234637.GJ8259@mx1.yitter.info> <20130826012857.GL8259@mx1.yitter.info> <00DB8F30-6BF8-476B-BAA4-5DFD2C96D2C2@nzrs.net.nz> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 28 Aug 2013 21:22:19 -0000 Hi Hadriel On 29/08/2013, at 5:52 AM, Hadriel Kaplan = wrote: >=20 > Isn't that just TXT with a new name? Why not just stick to TXT = type-16? > ... > That requires DNS server code to change, right? That feels like a = high barrier. See my answer to John for the answers to those. > Thinking out loud, why couldn't we do this: >=20 > 1) The IETF asks IANA to create a registry for name tokens, for use as = domain name label prefixes, and "v=3D" in TXT RDATA. I really don't think we should be getting into defining the structure of = data inside TXT records. What if someone wants an all binary policy = inside the TXT? (Like the hashed label list already mentioned for = _atps). > 2) We pre-reserve the token "iana", which means we reserved a label = prefix of "_iana", as well as "v=3Diana" as the first chars of the TXT = RDATA. >=20 > 3) We define an IETF RFC for this new "IANA" application, such that it = is intended for other TXT-using applications to use, for the purpose of = wildcarding and redirection. So future apps don't need to re-do SPF's = redirection stuff, but can instead use this new RFC's ABNF and rules to = get redirection as well as wildcard support. More importantly, it = prevents cluttering of the apex. The specific apps use their own = registered name tokens for app-specific RDATA, but "iana" helps them for = cases as shown below... >=20 > *.example.com. MX 10 a.example.com > *.example.com. TXT "v=3Diana = wildcard=3D_iana.example.com" > _qux.example.com TXT "" > _foo._iana.example.com. TXT "v=3Dfoo " > _bar._iana.example.com. TXT "v=3Dbar " > _zoo._iana.example.com. TXT "v=3Diana = redirect=3D_zoo.pwned.example.net" >=20 > This second "*.example.com" wildcard record is a normal TXT wildcard = record, and thus causes a synthesized TXT RR to be returned for name = queries where no name exists. The returned RR is exactly what it is = today for TXT RRs: the contents of the RDATA shown above. >=20 > There is NO change to DNS servers or client libraries required = whatsoever. >=20 > So a client querying for "_qux.example.com" gets back "" as today. >=20 > But a client querying "_foo.nonameexists.example.com" on the above = would get back "v=3Diana wildcard=3D_iana.example.com". >=20 > The specific FOO application (not DNS) sees that, and if it supports = our new RFC, knows to generate a new query for the wildcarded-to name, = but with its specific application prefix added in front. So it would = now query "_foo._iana.example.com" and get its rdata content. >=20 > This would of course cause FOO to do two DNS queries, but only for = cases where a wildcard is used. DNS servers could (optionally) optimize = to reduce it to one answer if they support this new "iana" RFC as well, = by synthesizing the final answer. But if they don't it sill works. >=20 > The only difference between "wildcard=3D" and "redirect=3D" is that = "wildcard=3D" makes the app prepend its name token prefix again = to the identified target domain-spec, whereas in "redirect=3D" = it does not prepend its name token prefix to the target domain-spec.=20 >=20 > Why do all that above? To keep too many TXT RRs from cluttering up = the apex, while still letting them have wildcard support. And by = reserving our own "iana" application ABNF and use, we give sanctioned = guidance on how new apps can do this without screwing it up for everyone = else, and let that portion possibly be integrated in DNS servers = someday. That would certainly be a workable solution fi you ignore my concerns on = defining the structure I mention above. The difference between that and = what I suggested is that you've moved the wildcard into the data and the = processing of the wildcard into the app not the server. However, I = believe we have clear evidence with the very limited uptake of NAPTR = that RRs that define complex processing paths in the client are not the = way forward. cheers Jay >=20 > -hadriel >=20 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From jay@nzrs.net.nz Wed Aug 28 14:22:19 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 2DB2311E811F for ; Wed, 28 Aug 2013 14:22:19 -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 e4tJISPmTbhu for ; Wed, 28 Aug 2013 14:22:05 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7A34F11E8197 for ; Wed, 28 Aug 2013 14:22:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 98B5A4B7184; Thu, 29 Aug 2013 09:22:02 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ8Hts2TPjNx; Thu, 29 Aug 2013 09:21:55 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 4B6A94B7171; Thu, 29 Aug 2013 09:21:55 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jay Daley In-Reply-To: <20130828161226.99262.qmail@joyce.lan> Date: Thu, 29 Aug 2013 09:00:08 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130828161226.99262.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1508) Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 28 Aug 2013 21:22:19 -0000 Hi John On 29/08/2013, at 4:12 AM, "John Levine" wrote: >> 3. Create a new generic record for free form policy data that must = be prefixed by protocol. For example: >>=20 >> _spf .example.com. POL "a:mail.example.com -all" >>=20 >> If we provide that one record then anyone can use it for any policy = info without further need to change the DNS. >> To me that seems much more utilitarian than a protocol specific RR. >=20 > If it's prefixed, what's the advantage over TXT other than it isn't > TXT? Once word gets out about it, I'd expect people to load it up > with all of the junk that people load into TXT. =20 That's the whole point. People are already loading up TXT with lots of = stuff, we can't stop that, but we can tidy it up, make it more = manageable and reduce unnecessary data being transferred. Adding this = is only going to help. > You can be sure that > some bright bulb will use it without a prefix, arguing that's OK > because all of the other uses are prefixed so this won't collide. Not in an RFC they won't as we can control that. Perhaps in practice = yes but they can omit prefixes on SRV records and that didn't stop that = RR. Would you be happier if we renamed the record for PREfixed TeXT ~ = PRETXT ? >> =3D A solution for the wildcard issue is a bit more complex, but = here's an example >>=20 >> 4. Add an rdata field to the POL record that if set to "*" = (asterisk) applies this policy to the next level >>=20 >> _spf.example.com. POL * "a:mail.example.com -all" >>=20 >> This record is then used to synthesise the POL record in exactly the = same way that a wildcard is. >=20 > This seems awfully complicated, and would require non-trivial extra > code in every authoritative name server. This is *exactly* the same as existing wildcard support but with a = different syntax and a prefix. So not that complicated. Not trivial = no, but worth the pain. It's also a mechanism that has possible use in = other new RRs. > Seems to me that if we could provision new RRTYPEs with less pain, > they already do what we want, don't need extra demultiplexing, and > has predictable and useful wildcard behavior. =20 Correct me if I'm wrong, but every DNS implementation already supports = wildcarding. > Or if you want to open up the guts of the DNS, just make this work: >=20 > _prefix.*.foo.example. TXT "stuff about foo" That's silly as you know. But what I do think we should open up is whether wildcarding is enough. = As we know the point is to save people from the pain and waste of having = to mirror RRs all over the place and the inherent dangers of missing one = out. But wildcarding only flows down and stops at the zone cut. = Perhaps we need to consider either a mechanism that doesn't stop at the = zone cut (which radically changes server design) or a flow up mechanism. cheers Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From ajs@anvilwalrusden.com Wed Aug 28 14:31: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 E7A9021F9C88 for ; Wed, 28 Aug 2013 14:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 eRAbKHbLQRyQ for ; Wed, 28 Aug 2013 14:31:51 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id F020221F9D5F for ; Wed, 28 Aug 2013 14:31:50 -0700 (PDT) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 0ED518A031 for ; Wed, 28 Aug 2013 21:31:43 +0000 (UTC) Date: Wed, 28 Aug 2013 17:31:41 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130828213141.GF52572@mx1.yitter.info> References: <20130828161226.99262.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 28 Aug 2013 21:31:57 -0000 >From the peanut gallery: On Thu, Aug 29, 2013 at 09:00:08AM +1200, Jay Daley wrote: > > stops at the zone cut. Perhaps we need to consider either a > mechanism that doesn't stop at the zone cut (which radically changes > server design) or a flow up mechanism. Ted Lemon asked, when we shut down the DNSEXT WG, how long it'd be before a new one started up. I pooh poohed this, but the above sure sounds to me like "DNSng" and "BoF fodder". No, I am not willing to chair the BoF. But I'll show up if someone organizes it. A -- Andrew Sullivan ajs@anvilwalrusden.com From Ted.Lemon@nominum.com Wed Aug 28 15:23: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 23BB511E80D1 for ; Wed, 28 Aug 2013 15:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 JREbqryTlkar for ; Wed, 28 Aug 2013 15:23:00 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id AC50F21E8082 for ; Wed, 28 Aug 2013 15:23:00 -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 DSNKUh54RBj5y1rYEojhnhs23V2IzyjWJR9s@postini.com; Wed, 28 Aug 2013 15:23:00 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 570351B82D5 for ; Wed, 28 Aug 2013 15:23:00 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 4EA75190070; Wed, 28 Aug 2013 15:23:00 -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; Wed, 28 Aug 2013 15:23:00 -0700 From: Ted Lemon To: Andrew Sullivan Thread-Topic: [dnsext] The state of DNS support, was Deprecating SPF Thread-Index: AQHOoRGidFAdItSRuEG856mTCSAqjJmles6AgAFVgwCAABF6gIAAFliAgAAIxwCAAAX3gIAABwIAgAAFsQCAABblgIADTxuAgADMZwCAAFBiAIAACNCAgAAOVwA= Date: Wed, 28 Aug 2013 22:22:59 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077526A31C@mbx-01.win.nominum.com> References: <20130828161226.99262.qmail@joyce.lan> <20130828213141.GF52572@mx1.yitter.info> In-Reply-To: <20130828213141.GF52572@mx1.yitter.info> 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: <32390523F342C54582FFE77F0D34D0B1@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 28 Aug 2013 22:23:16 -0000 On Aug 28, 2013, at 5:31 PM, Andrew Sullivan wrote= : > Ted Lemon asked, when we shut down the DNSEXT WG, how long it'd be > before a new one started up. I pooh poohed this, but the above sure > sounds to me like "DNSng" and "BoF fodder". :) From hadriel.kaplan@oracle.com Thu Aug 29 06:50:19 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 47E1E21F8546 for ; Thu, 29 Aug 2013 06:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 8dLvrFuOTtAj for ; Thu, 29 Aug 2013 06:50:11 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 43D1021F853A for ; Thu, 29 Aug 2013 06:50:11 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7TDo8v9026398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Aug 2013 13:50:09 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TDo74F020585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Aug 2013 13:50:08 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TDo7A2008377; Thu, 29 Aug 2013 13:50:07 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Aug 2013 06:50:06 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <20130828213141.GF52572@mx1.yitter.info> Date: Thu, 29 Aug 2013 09:50:07 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <20130828161226.99262.qmail@joyce.lan> <20130828213141.GF52572@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: dnsext@ietf.org Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 29 Aug 2013 13:50:19 -0000 On Aug 28, 2013, at 5:31 PM, Andrew Sullivan wrote: > From the peanut gallery: > > On Thu, Aug 29, 2013 at 09:00:08AM +1200, Jay Daley wrote: >> >> stops at the zone cut. Perhaps we need to consider either a >> mechanism that doesn't stop at the zone cut (which radically changes >> server design) or a flow up mechanism. > > Ted Lemon asked, when we shut down the DNSEXT WG, how long it'd be > before a new one started up. I pooh poohed this, but the above sure > sounds to me like "DNSng" and "BoF fodder". DNS Non-Extensions = DNSNEXT -hadriel From hadriel.kaplan@oracle.com Thu Aug 29 07:32:00 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 30A8521F9EE5 for ; Thu, 29 Aug 2013 07:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 G5rXYDmdBgjs for ; Thu, 29 Aug 2013 07:31:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id C24A521F970E for ; Thu, 29 Aug 2013 07:31:50 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7TEVdXP015003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Aug 2013 14:31:39 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TEVcTe001237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Aug 2013 14:31:39 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TEVcrS022878; Thu, 29 Aug 2013 14:31:38 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Aug 2013 07:31:38 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <4943FDC9-72C3-4E9C-8E5E-C44B7D96323F@nzrs.net.nz> Date: Thu, 29 Aug 2013 10:31:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130824213356.CB42138D63BE@drugs.dv.isc.org> <7793A67C-E0D8-4B30-8943-64E04A5FA11E@nzrs.net.nz> <521A7261.5080704@dcrocker.net> <20130825222847.GA49656@gaon.net> <20130825230012.GG8259@mx1.yitter.info> <3880112C-2AC7-433F-B77D-6A5D07365CD9@virtualized.org> <20130825234637.GJ8259@mx1.yitter.info> <20130826012857.GL8259@mx1.yitter.info> <00DB8F30-6BF8-476B-BAA4-5DFD2C96D2C2@nzrs.net.nz> <4943FDC9-72C3-4E9C-8E5E-C44B7D96323F@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] The state of DNS support, was Deprecating SPF 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, 29 Aug 2013 14:32:01 -0000 On Aug 28, 2013, at 5:09 PM, Jay Daley wrote: >> Thinking out loud, why couldn't we do this: >>=20 >> 1) The IETF asks IANA to create a registry for name tokens, for use = as domain name label prefixes, and "v=3D" in TXT RDATA. >=20 > I really don't think we should be getting into defining the structure = of data inside TXT records. What if someone wants an all binary policy = inside the TXT? (Like the hashed label list already mentioned for = _atps). If someone doesn't want to follow a new RFC, then they don't. That's up = to them. It's no worse than without the RFC. If they want to follow = it, they get the benefits it provides. Even binary-rdata folks could = follow this new RFC though... "v=3Diana " is just a sequence of octets = after all. :) > That would certainly be a workable solution fi you ignore my concerns = on defining the structure I mention above. The difference between that = and what I suggested is that you've moved the wildcard into the data and = the processing of the wildcard into the app not the server. However, I = believe we have clear evidence with the very limited uptake of NAPTR = that RRs that define complex processing paths in the client are not the = way forward. Yes, complex processing =3D bad. NAPTR is complex, and it's motivating = use-cases aren't as popular to begin with. (Although as an aside, in my = particular world NAPTR gets used a lot) I don't think this would be as complex though. And if an app doesn't = need the redirection portion, they don't implement it. If they do need = it, the SPF-style processing for it seems like a pretty simple one, and = that's all I'm proposing for redirection. The wildcarding portion is a = bit more tricky, in the sense that a newly defined application can't = know whether it needs wildcard support or not really, afaict; so if the = app clients don't implement it then folks will continue to fill the apex = with app-specific records. But that's true no matter what we do. At = least by defining a way for it to work, we make it possible to do it in = a better "standard" way, and it's possible for the DNS server folks to = eventually implement support for it too and avoid double-queries. The major advantage of keeping with TXT over a new POL RR is there's no = new RR required. Getting a new RR usable everywhere on the planet seems = to be a big challenge. And it's not under the app-developer's control = to affect that type of change, or timeframe for it. -hadriel