Re: [dnsext] Deprecating SPF

Phillip Hallam-Baker <> Tue, 20 August 2013 20:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE7A211E829B for <>; Tue, 20 Aug 2013 13:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.446
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n0MLa+uFQxbs for <>; Tue, 20 Aug 2013 13:23:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22c]) by (Postfix) with ESMTP id BCAA511E829A for <>; Tue, 20 Aug 2013 13:23:57 -0700 (PDT)
Received: by 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;; 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 with SMTP id j10mr2852259wjn.41.1377030235520; Tue, 20 Aug 2013 13:23:55 -0700 (PDT)
Received: by with HTTP; Tue, 20 Aug 2013 13:23:55 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
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: "" <>
Subject: Re: [dnsext] Deprecating SPF
X-Mailman-Version: 2.1.12
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

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 <>wrote:

> On Tue, Aug 20, 2013 at 1:16 PM, Michael Sinatra <
>> wrote:
>> 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?
> 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.
> --
> Website: