IETF Logo Mail Archive

Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE

David Conrad <drc@virtualized.org> Fri, 26 April 2013 06:05 UTC

Return-Path: <drc@virtualized.org>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8987A21F97C7; Thu, 25 Apr 2013 23:05:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Quedfh9U5ke; Thu, 25 Apr 2013 23:05:23 -0700 (PDT)
Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8BD21F97AF; Thu, 25 Apr 2013 23:05:23 -0700 (PDT)
Received: from [10.0.1.2] (unknown [12.6.90.3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id B944E17166; Fri, 26 Apr 2013 06:05:22 +0000 (UTC)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: David Conrad <drc@virtualized.org>
In-Reply-To: <CAL0qLwYzKnfRArQAVD1M=ccnV079j-D9PHDaB-tLaUwG4vm_BQ@mail.gmail.com>
Date: Fri, 26 Apr 2013 01:05:22 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org>
References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <BB8C643A-FC46-4B2F-B677-F1B7CAB0E79F@frobbit.se> <alpine.BSF.2.00.1304251030380.65043@joyce.lan> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <CAL0qLwYzKnfRArQAVD1M=ccnV079j-D9PHDaB-tLaUwG4vm_BQ@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
X-Mailer: Apple Mail (2.1503)
Cc: spfbis@ietf.org, "dnsext@ietf.org Group" <dnsext@ietf.org>
Subject: Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2013 06:05:23 -0000

Murray,

On Apr 25, 2013, at 10:29 PM, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
> I think this continues to trivialize exactly what it means to migrate the enormous deployed base of SPF in the manner you're pushing.

Out of curiosity, what do folks who follow SPF think the current "enormous deployed base" is compared to the future deployed base?

> At least half of the reason we landed here is because of an environment that was basically hostile to doing it right in the first place. 

Well, deprecating the SPF RR will certainly teach the DNSEXT/IESG/IETF community a good lesson.  (Seriously?)

> So how much energy are the DNS experts going to put into cleaning up their house while demanding the mail people clean up theirs? 

So, this is about revenge because it used to be hard to get RRtypes? 

> The deployed SPF base probably won't give a damn if the IETF suddenly releases an RFC that exclaims "Everybody migrate to type 99!" 

Yep.  This gets into projections about the future.  If SPF has topped out, it simply doesn't matter.  If SPF is going to continue to grow, then it probably does matter.

> From the perspective of large and small operators around the world, what's out there is working now, and messing with it is asking for pain; engineers' time to switch and debug costs a lot of money, so they have no incentive whatsoever to comply with a proposed change to "fix" a service that is philosophically broken but operationally just fine.

The point is that it isn't just fine.  It does have operational impacts, from potentially increased fragmentation/fallback to TCP to increased complexity in TXT RR parsers that have to distinguish between the myriad of crap that's residing at the zone apex TXT RR, etc.  Of course, most of these negative impacts are hidden to the folks who are putting the TXT RRs in the zone, so it's all good, right?

> Thus, I maintain that we take our licks on this one and just take steps to ensure that nobody follows this path again.


And how do you propose that exactly, particularly given the precedent set by SPFBIS?

Regards,
-drc

v2.23.0 | Report a Bug | By Email