Subject: [dnsext] Obsoleting SPF RRTYPE

From: S Moonesamy <[email-masked]>
Date: Tue, 23 Apr 2013 15:03:45 -0700

Hello,

Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE:

   'IANA is requested to add an annotation to the SPF RRTYPE saying
    "(OBSOLETE - use TXT)" in the DNS Parameters registry.'

Is the annotation in the DNS Parameters registry correct?

Regards,
S. Moonesamy (as document shepherd)

---

From: David Conrad <[email-masked]>
Date: Wed, 24 Apr 2013 17:12:07 -0700

Hi,

> Is the annotation in the DNS Parameters registry correct?

It is in keeping with past practice, e.g., see the notations for MD, MF, A6, and the MAILA RRtypes at http://www.iana.org/assignments/dns-parameters/dns-parameters.xml.

I personally believe deprecating the SPF RR is the wrong way to go, but I'm guessing that discussion has already been had.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Apr 2013 10:28:47 +1000

In message <[email-masked]>, David Conrad
 writes:
> It is in keeping with past practice, e.g., see the notations for MD, MF, A6, 
> and the MAILA RRtypes at http://www.iana.org/assignments/dns-parameters/dns-p
> arameters.xml.
> 
> I personally believe deprecating the SPF RR is the wrong way to go, but I'm g
> uessing that discussion has already been had.
> 
> Regards,
> -drc

Personally, I agree with you.  TXT to SPF transition was always
going to be a slow transition.  libspf2 took ages to come out but
it is out now and looks for SPF records first.  Waiting less than
is single hardware deprecation cycle before stating that the
transition is not working wasn't a good faith effort.  The introduction
of MX records to 10 or more years before you could reliably have
MX only (no A records) domains.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 25 Apr 2013 01:33:17 -0000

>> I personally believe deprecating the SPF RR is the wrong way to go, but I'm
>> guessing that discussion has already been had.

Yes, it has.  Did you miss RFC 6686?

Once again, the huge practical barriers to deploying new RRTYPEs made
the SPF RR dead on arrival.

R's,
John

---

From: David Conrad <[email-masked]>
Date: Wed, 24 Apr 2013 19:34:22 -0700

John,

> Yes, it has.  Did you miss RFC 6686?

I've read it.  Didn't strike me as particularly persuasive towards deprecating the SPF RR, but that's probably just me.

> Once again, the huge practical barriers to deploying new RRTYPEs made the SPF RR dead on arrival.

Yes, the ossification of the DNS makes introducing new things challenging however as Mark pointed out, software was beginning to do the right thing and there actually are web interfaces out there that let folks enter SPF records (I use one). My reading of 6686 would suggest that SPF has greater penetration than either DNSSEC or IPv6 which both face the practical barriers you mention, yet I'd argue deploying DNSSEC and IPv6 are the right thing to do.

In any event, I suppose that's what last call is for.

Regards,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Apr 2013 11:39:17 +0900

David Conrad wrote:

> My reading of 6686 would suggest that SPF has greater
> penetration than either DNSSEC or IPv6 which both face the
> practical barriers you mention,

Good point.

> yet I'd argue deploying DNSSEC and IPv6 are the right thing to do.

It is not.

Because of so high noise level here attempting to deploy DNSSEC,
we fail to join a lot of discussions on the real works.

						Masataka Ohta

---

From: "John R Levine" <[email-masked]>
Date: 24 Apr 2013 23:09:46 -0400

> In any event, I suppose that's what last call is for.

It's in WGLC now.  Feel free to let the WG know how you feel.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: David Conrad <[email-masked]>
Date: Wed, 24 Apr 2013 21:37:43 -0700

> It's in WGLC now.  Feel free to let the WG know how you feel.

Thanks for the kind invitation.

Actually, I'm more intrigued as to the view of the folks on DNSEXT on this issue (I have no illusions that I'd be able to sway anyone related to spfbis -- minds appear to be quite made up based on the private messages I've received): 

Draft-ietf-spfbis-4408bis-14 and RFC 6686 would appear to suggest that the use of new RRtypes is so fraught with "practical" and operational issues that for all intents and purposes, the definition of Internet-wide RRtypes is a lost cause even if draft-levine-dnsextlang is finished (I have a bit of skepticism that the same folks who can't implement support for SPF RRs are going to implement draft-levine-dnsextlang, but that may just be me).  An implication of this  would appear to be that definition of new RRs should be constrained to "consenting adults" (e.g., EUI48/68). Is there some other takeaway from the "failure" of the SPF RR?

Thanks,
-drc

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 25 Apr 2013 09:51:47 +0200

> I personally believe deprecating the SPF RR is the wrong way to go, but I'm guessing that discussion has already been had.

Overloading the TXT record has always been a Really Bad Idea. I'm with
drc here. While the draft probably is formally proper, it advocates the
worng decision and I cannot support it.

OTOH, mixing up routing layer with application layer and gilding some
IP addresses in favour of others is another Really Bad Idea; I'd rather
throw the entire business of supposedly Good and Bad addresses out the
window and start looking at the in-band data instead; ie. DKIM or similar.

While removing SPF can be seen as in support of above, I'm pretty certain
that it in practice just will continue as usual, in TXT records. Better 
then that we get to keep TXT records for free-form data. 

Regards, 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I want you to organize my PASTRY trays ... my TEA-TINS are gleaming in
formation like a ROW of DRUM MAJORETTES -- please don't be FURIOUS with me --

---

From: Douglas Otis <[email-masked]>
Date: Thu, 25 Apr 2013 02:15:23 -0700

> then that we get to keep TXT records for free-form data.

Dear Måns,

Obsoleting SPF RR is not enough.  All macros should be deprecated as well.  tools.ietf.org/html/rfc3123 predates this poorly conceived scheme.

SPF was poorly conceived starting out as 2KB TXT XML encoded resource records in DNS where many expect direct use of TXT resource records permits wildcard replication.  This scheme also expects receivers to combine email-address local-parts with SPF domains to query other resource record sets.  SPF may induce high query overheads flooding caches with up to 100 transactions derived from email-address local-parts that normally vary in spam campaigns to also support DDoS attacks leveraging receiver's attempt to verify service authorizations.
(10 mechanisms x 10 (PTRs or As or AAAAs))  Permitting PTRs can also lead to connection resource exhaustion. The macro expansion can also leverage DNS name compression to further increase network amplifications against some unseen domain while spamming entirely different domains.

The macro scheme was not intended to validate EHLOs or provide NDN authorizations and inappropriately exposes aspects of message handling.  The review of SPF use also neglects whether major providers process these macros, many whom assure they do not.  Verifying the ELHO is seldom supported, where authorization permits by bulk sender's to dodge accountability.  Without genuine domain authentication SMTP is not safe.    

A safe and effective alternative is needed to safely provide a basis for assessing and reacting to abusive behavior.  XMPP offers examples of StartTLS used in a highly scalable fashion that can leverage OCSP and self published DANE Certs needed to support IPv6.  

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 25 Apr 2013 05:58:56 -0400

No hat.  Especially this time.

On Wed, Apr 24, 2013 at 09:37:43PM -0700, David Conrad wrote:
> 
> implication of this would appear to be that definition of new RRs
> should be constrained to "consenting adults" (e.g., EUI48/68). Is
> there some other takeaway from the "failure" of the SPF RR?

One obvious one is, "Don't have two mechanisms to achieve the same
goal."  Given that SPF has the TXT record and that there is zero hope
of getting rid of that use, the SPF RRTYPE was just a vain hope.  

And indeed, as DKIM and other such uses show, the underscore-label
extension is a permanent part of the DNS landscape and we should
expect applications to depend on that as often as on new RRTYPEs,
regardless of any advice to the contrary.  It's rather unfortunate
that SPF didn't use that, but it didn't.

Best,

A  

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Apr 2013 11:13:29 +0000

On Apr 25, 2013, at 12:37 AM, David Conrad <[email-masked]> wrote:
> I have no illusions that I'd be able to sway anyone related to spfbis -- minds appear to be quite made up based on the private messages I've received

Then perhaps we should all tromp on this in IETF last call.   I certainly agree with your take on this: the idea that a document would advocate the use of a TXT record because promulgating SPF records is "too hard" is just broken.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Apr 2013 21:18:04 +0900

Andrew Sullivan wrote:

> goal."

It means anything to be implemented by TXT can not have its own
RR.

> Given that SPF has the TXT record and that there is zero hope

"there is zero hope of getting rid of that use"?

Why?

Some reasoning, please.

> regardless of any advice to the contrary.

Where is the advice not to have underscore-label extensions
with SRV?

The problem of underscore-label extensions is that the
underscore-labels is not assured to be unique (RFC1034
imposes no restriction to use underscore-label for any
purpose) and can have conflicts to other applications.

Thus, an application specific underscore-label extension is
just fine if and only if it is tied with applications' own
specific RR type to prevent ambiguities on meaning of the label.

That is, having application specific RRs is MUST, even if you
use underscore-labels.

						Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 25 Apr 2013 08:34:30 -0400

Dear colleagues,

First, no hat, but just for context: I am co-chair of the moribund
dnsext and also of spfbis.  Glancing at another hat, I am acutely
aware of recommendations the IAB has historically made about the use
and extension of the DNS, and I mostly agree with those observations.
To emphasise, however, I am speaking here in an individual capacity.

This conversation should probably move to spfbis@ if we're going to
have it out, but I want to make sure that people who haven't been
following that WG have the appropriate context.

> Then perhaps we should all tromp on this in IETF last call.   I certainly agree with your take on this: the idea that a document would advocate the use of a TXT record because promulgating SPF reco…

I'm not sure whether Ted is offering advice above to a still-active WG
of which he is the shepherd, or participating as an individual, but in
any case I'd like to point out that the documents in question (one of
which is already an RFC) don't advocate new use of TXT because another
type is "too hard".  There's actually an interoperability problem, and
there's a simple fact of deployment.  The IETF has not had notable
success when it pretends to be King Canute, and I think "tromping on
this" would be an example of such behaviour.

First, it is worth noting three things about the co-existing SPF and TXT
records described in RFC 4408.  The first is that a server using SPF
MUST publish at least one of them.  The second is that a client using
SPF MUST query for at least one of them.  The third is that there was
never any specification of interdependency between these records. 

The consequence of those three things is that there's a basic interop
problem in RFC 4408: if a server only publishes SPF records and a
client only looks up TXT records (or conversely), they both implement
the protocol as specified and yet the communication fails.  So, this
is broken.

Now, SPFBIS was chartered to move SPF from experimental to the
standards track, on the not-implausible premises that it's a widely
deployed technology and, indeed, 4408 was never really an experiment
anyway.  To fix the interop problem above, we have three options:

    1.  Specify that clients query first SPF, and then query TXT if
    SPF returned NODATA.

    2.  Specify that clients first query TXT, and then SPF if TXT
    returned either NODATA or a TXT record that wasn't an SPF record.

    3.  Deprecate one of the types.

We rejected (1) (in consultation with DNSOP) on the grounds that the
evidence showed overwhelmingly that deployed systems used TXT in
preference to SPF.  A number of systems (including, full disclosure,
one of the services that my employer, Dyn, offers) to this day only
support SPF using TXT records.  So, (1) would result in an increase of
query traffic with little, if any, benefit.

We rejected (2) on the grounds that, since nearly every system we
looked at (and all the systems that didn't appear to be operated by
DNS nerds) published a TXT record for SPF (and maybe also published an
SPF record), the SPF type lookup would just never happen.  Ditching
the additional lookup logic leads to a simpler specification and
simpler implementations, at no apparent cost.  Moreover, if everyone
migrated to type SPF, (2) would be bad in the same way (1) is, only
worse because of the additional complexity caused by having to examine
every TXT record at an owner name prior to falling through.

This led us to (3).  Of course, in (3), we could either deprecate the
SPF type or the use of TXT for this purpose.  But the deployed base
has clearly spoken: TXT is the overwhelming preference, and almost
everyone who publishes an SPF record also publishes a TXT SPF record.
Deprecating the TXT use would mean that the actual deployed software
would never stop using 4408 as its specification, because of the
massive backward compatibility problem that would arise.

I am very, very unhappy about this fact, but it is a fact of the
world, and I think the IETF just makes itself look ridiculous if it
attempts to make the rest of the world work the way we would like.
There is no question that it is architecturally lousy that we're using
TXT records for this.  The underscore-label convention, as much as it
gives me hives, offers a way for future innovations to avoid trouncing
all over the TXT record at an owner name, so I don't think SPF
functions as any kind of precedent.  And I, as much as anyone, am
extremely keen to promote the idea that new RRTYPEs are often a good
idea.  But we are just not in a position to try to tell the Internet
not to use TXT in this particular case, and I think we're dreaming in
Technicolor if we suppose that we could.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 25 Apr 2013 09:21:39 -0400

Andrew Sullivan writes:
> [...]

In the near term.  It is unclear what the effect would be long term.

I know that, as an implementer, if I had a spec that was unambiguous
about the intended behaviour of SPF-then-TXT that I would endeavour to
make my software be part of the evolution that moved things in the
right direction.  (I currently work on a widely deployed auth server,
not a resolver, and that server supports the SPF record.)

I will not pretend to prognosticate, however, on whether similar
action by other developers would be widespread enough to eventually
noticeably mitigate the extra query hit.  I don't think anyone else
can convincingly make the case that they really know how it would work
out, either.

As an operator, both for a large organization and also one whose
personal DNS server sits behind a pretty small pipe, to me that extra
hit is hardly a worse situation than AAAA-then-A.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Apr 2013 06:33:10 -0700

> Is the annotation in the DNS Parameters registry correct?

Yes, it is correct.

Isn't it amazing that the DNSEXT WG can't answer a simple question without turning it into a lecture about How Things Would Be Done If We Were Kings and Queens? (Actually, no one even bothered to answer the question...)

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 25 Apr 2013 10:04:51 -0400

> hit is hardly a worse situation than AAAA-then-A.

No hat.

It was partly the never-ending complaints about that very situation
that led me to believe that the extra traffic would be a bad thing.

But, with my moderator hat on, if people want to argue about this,
however, the correct place to do it is on the spfbis list, please.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 25 Apr 2013 16:08:57 +0200

>> Once again, the huge practical barriers to deploying new RRTYPEs made the SPF RR dead on arrival.

John, I completely disagree, as you know, with this statement. What killed SPF RR was the introduction of the TXT cludge for SPF.

> Yes, the ossification of the DNS makes introducing new things challenging however as Mark pointed out, software was beginning to do the right thing and there actually are web interfaces out there t…

We do deploy IPv6 and DNSSEC with new RR types. Having that in TXT would have made things not just a little bit messier.

   Patrik

---

From: "John R Levine" <[email-masked]>
Date: 25 Apr 2013 10:44:52 -0400

> John, I completely disagree, as you know, with this statement. What 
> killed SPF RR was the introduction of the TXT kludge for SPF.

You're confusing cause and effect.  For one thing, back in 2004-2005 
getting a new RR type allocated was so painful that it wasn't worth the 
effort when they were trying out SPF.  I realize this problem has been 
somewhat alleviated.

The much more serious reason is that the provisioning systems to let 
system managers install type 99 records into their DNS did not exist, and 
for the most part still do not exist.  I know a lot of the people who did 
early SPF installations and they uniformly reported that even getting the 
provisioning software to support TXT records that have been around since 
the dawn of the DNS was painful, and there would have been no hope for a 
new and exotic record type.  Since their goal was to make SPF actually 
work, they used a kludge.  It's the same reason DKIM uses TXT records.

>> Yes, the ossification of the DNS makes introducing new things 
>> challenging however as Mark pointed out, software was beginning to do 
>> the right thing and there actually are web interfaces out there that 
>> let folks enter SPF records (I use one).

Wow, and it's only taken eight fripping years.  Perhaps if we wait another 
century the provisioning systems will catch up.  If the DNS crowd spent 
half the effort addressing the provisioning problem that you do trying to 
deny that it exists, it'd have been fixed years ago.  My dnsextlang 
proposal is one approach, but surely not the only one.

In any event, the SPF draft is in WGLC.  Feel free to read the extensive 
discussion in the list archives and let them know how you feel.

R's,
John

PS: The system that lets you enter SPF records wouldn't be Godaddy, would 
it?  If so, create an SPF record, then do a dig and try to find it.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 25 Apr 2013 17:03:55 +0200

On 25 apr 2013, at 16:44, John R Levine <[email-masked]> wrote:

> In any event, the SPF draft is in WGLC.  Feel free to read the extensive discussion in the list archives and let them know how you feel.

They know how i feel. We in IETF do believe in rough consensus. I am this time on the rough side.

That does not imply I am quiet in other places, and I am as many others nervous over the implications.

   Patrik

---

From: "John R Levine" <[email-masked]>
Date: 25 Apr 2013 11:05:12 -0400

> That does not imply I am quiet in other places, and I am as many others nervous over the implications.

That we have a large and unaddressed problem of cruddy provisioning 
software?  I entirely agree.

Regards,

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 25 Apr 2013 17:42:35 +0200

> That does not imply I am quiet in other places, and I am as many others nervous over the implications.

This is a slippery slope. One record overload is not bad, but it sort
of opens the floodgates for systematic overloading. DNSEXT and DNSOP
certainly need to get involved; because this is way bigger than just SPF.

And IMNSHO spfbis is out of scope prescribing TXT records, just because
of this contagiousness.

For the record: I think that the spfbis draft is unfit for publication
as RFC unless TXT records are deprectaed as only carrier of data.
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
... I want FORTY-TWO TRYNEL FLOATATION SYSTEMS installed within
SIX AND A HALF HOURS!!!

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Apr 2013 16:01:52 +0000

> They know how i feel. We in IETF do believe in rough consensus. I am this time on the rough side.

It seems to be the case that there are rather a lot of people on the dnsext mailing list who are on the rough side of the consensus here.   That suggests that perhaps the consensus isn't in the direction that we are presuming it is.

---

From: "John Levine" <[email-masked]>
Date: 25 Apr 2013 16:16:30 -0000

>In the near term.  It is unclear what the effect would be long term.

There are at least several hundred thousand mail systems publishing
TXT SPF records, and presumably a similar number checking them.

Their SPF deployment works fine.  It is absurd to claim that TXT SPF
records will ever stop working.  Why should they change?  What's the
justification for spending money on software that provides them no
benefits?

I published type 99 records for a while and can report from direct
experience that they did, indeed, provide no benefit whatsoever, and a
certain amount of hassle due to other systems whose type 99 code
turned out to be buggy.

R's,
John

PS: Nobody's arguing that SPF is a well designed protocol, but its
installed base is undeniable.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Apr 2013 09:21:41 -0700

> It seems to be the case that there are rather a lot of people on the dnsext mailing list who are on the rough side of the consensus here.   That suggests that perhaps the consensus isn't in the dir…

Are you saying that the people on the DNSEXT mailing list read the document that is in WG LC in the other WG? If so, please re-read the comments above. It is pretty clear most did not. Helping form consensus means more than voicing an uninformed reaction on an unrelated mailing list: it takes work and concern for everybody else who is doing work.

--Paul Hoffman

---

From: Jim Reid <[email-masked]>
Date: Thu, 25 Apr 2013 17:26:35 +0100

On 25 Apr 2013, at 13:18, Masataka Ohta <[email-masked]> wrote:

> Andrew Sullivan wrote:
> 
>> One obvious one is, "Don't have two mechanisms to achieve the same goal."
> 
> It means anything to be implemented by TXT can not have its own RR.

If anything it means the opposite: please don't use a TXT record when a unique RRtype could be used instead. Or at the very mininum it means choose between one or the other, not both.

> "there is zero hope of getting rid of that use"? Why?

Once stuff has been deployed, there's almost no chance of un-deploying it. If you think all the mail software using SPF will switch from TXT records to SPF records (or vice versa), feel free to document how to make that happen.

> Where is the advice not to have underscore-label extensions with SRV?

I think you've misunderstood. Of course there's no such advice. [SRV records explicitly use underscores in certain labels so their domain names avoid clashing with host names (which can't contain underscores). An SRV record of sip.udp.example.com would be bad if there already was an A or MX record (say) for that hostname.] Others have adopted this practice/convention: some SPF users it seems. RFC5507 discusses the sort of things to consider when planning to add suffixes or prefixes to domain names.

> purpose) and can have conflicts to other applications.

All domain names are by definition unique. Whether they contain underscores or not. Anyone inserting an underscore somewhere in an existing domain name creates a new domain name that might already exist. So what?

---

From: Warren Kumari <[email-masked]>
Date: Thu, 25 Apr 2013 12:31:09 -0400

[-spfbis, because this bit is just DNS ] 

> certainly need to get involved; because this is way bigger than just SPF.

There were a set of (protracted) discussions in DANE on having our own RR type or overloading TXT.

There were a number of arguments on each side, but much of it boiled down to:
a: web based provisioning systems suck, and some middle boxes dinkle with unknown RR types, so use TXT.

b: overloading TXT is inelegant and required custom and complex parsers. Also, some of the data we want to carry is binary, and so you'd have to b64 (or something) encode it (not insurmountable, but annoying).

As always there were fairly strong views (and each side had folk who were, or believed that they were,  DNS experts), but the consensus ended up being a dedicated RR type.
As an aside, the RR type allocation process was painless and quick.

An easily accessible document describing the implications of choosing an RR type over funky TXT records, and how to evaluate these would be useful.
Added brownie points if the document also describes how to do discovery / naming. TLSA settled on the _port._protcol.host.example.com "standard",  but much time was spent on this discussion (and if tree-walking could be performed, and if so how, etc.)
Yes, everyone's needs are different, but being able say "Some DNS wonks have already thought about this, go read RFC $foo before commenting please" would have been nice.

W

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

--
Some people are like Slinkies......Not really good for anything but they still bring a smile to your face when you push them down the stairs.

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Apr 2013 21:42:03 -0700

Hi David,
At 17:12 24-04-2013, David Conrad wrote:
>It is in keeping with past practice, e.g., see the notations for MD, 
>MF, A6, and the MAILA RRtypes at 
>http://www.iana.org/assignments/dns-parameters/dns-parameters.xml.

Based on the current discussion a similar approach may be followed 
for the SPF RRTYPE.    Please note that this is in my view a IANA 
Considerations (administrative) issue.

>I personally believe deprecating the SPF RR is the wrong way to go, 
>but I'm guessing that discussion has already been had.

Yes, the thread is at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html 
The results of the discussion is documented in RFC 6686.

Regards,
S. Moonesamy

---

From: Dotzero <[email-masked]>
Date: Thu, 25 Apr 2013 12:26:51 -0400

> And IMNSHO spfbis is out of scope prescribing TXT records, just because

It is not so much that SPFbis is prescribing practice as it is
updating to describe practice and avoid potential problems that have
been identified with having both TXT and type 99 records (without a
lot of verbage to address hypothetical future use).

> as RFC unless TXT records are deprectaed as only carrier of data.

Would you be any happier if the WG left type 99 records and in a coy
manner made it clear that usage is overwhelmingly TXT based with
little likelyhood of type 99 gathering any meaningful traction? I'm
sure that if the issues surrounding adoption of new RR types were
resolved we would not be having this discussion - but they haven't
been resolved.

Mike

---

From: Joe Abley <[email-masked]>
Date: Thu, 25 Apr 2013 12:52:13 -0400

> An easily accessible document describing the implications of choosing an RR type over funky TXT records, and how to evaluate these would be useful.

http://tools.ietf.org/html/rfc5507#section-5

> Added brownie points if the document also describes how to do discovery / naming.

http://tools.ietf.org/html/rfc5507#section-3.2

> TLSA settled on the _port._protcol.host.example.com "standard",  but much time was spent on this discussion (and if tree-walking could be performed, and if so how, etc.)

http://tools.ietf.org/html/rfc5507

Joe

---

From: Joe Abley <[email-masked]>
Date: Thu, 25 Apr 2013 12:54:20 -0400

On 2013-04-25, at 10:44, John R Levine <[email-masked]> wrote:

> The much more serious reason is that the provisioning systems to let system managers install type 99 records into their DNS did not exist, and for the most part still do not exist.  I know a lot of the people who did early SPF installations and they uniformly reported that even getting the provisioning software to support TXT records that have been around since the dawn of the DNS was painful, and there would have been no hope for a new and exotic record type.

Wait; support for the SPF RRType would have involved changes in provisioning systems, so instead the decision was to use TXT RRTypes which involved changes in provisioning systems?

Awesome. :-)

Joe

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Apr 2013 09:58:54 -0700

On 04/25/2013 12:51 AM, Måns Nilsson wrote:
|
| OTOH, mixing up routing layer with application layer and gilding some
| IP addresses in favour of others is another Really Bad Idea; I'd rather
| throw the entire business of supposedly Good and Bad addresses out the
| window and start looking at the in-band data instead; ie. DKIM or similar.

Måns,

SPF has one important benefit that DKIM cannot, reduction of
joe-jobbing. I used to get backscatter at the rate of at least 2-3 per
day, with peaks of 10-20. After adding an SPF record with the hard-fail
option that's down to a couple per month.

Doug

---

From: Warren Kumari <[email-masked]>
Date: Thu, 25 Apr 2013 13:08:10 -0400

> http://tools.ietf.org/html/rfc5507#section-5

Doh.

> http://tools.ietf.org/html/rfc5507#section-3.2

Doh, doh.

> http://tools.ietf.org/html/rfc5507

Yup, you are right -- I forgotten this document… Well, actually I hadn't forgotten it, I just remembered it as being more "Please don't just stuff random crap in the DNS", then some motherhood and apple-pie stuff. Maybe I'm confusing it with something else? Whatever the case, oops.

Oh, someone also pointed out (off-list) that my message sounded like I was saying SPFbis is doing the wrong thing here. That was not my intent (I personally think that TXT is less elegant than a dedicated record, but a: they *appear* to have throughout this through, b: I have only skimmed their documents, but there are chats and graphs, and c: I have not been following the WG) -- my intent was instead to say that a document like, er, rfc5507 would be useful :-P

Blushes and wanders off-stage,
W

--
"Have you got any previous convictions?"

"Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned--"
-- Terry Pratchett

---

From: Pete Resnick <[email-masked]>
Date: Thu, 25 Apr 2013 12:34:19 -0500

> as RFC unless TXT records are deprectaed as only carrier of data.

SPFBIS AD hat on for this:

We are *long* past this discussion. This discussion should have happened 
at SPFBIS *chartering* time, as it is crystal clear from the charter 
that existing features currently in use in SPF are not going away. 
Indeed, the TXT record was specifically mentioned in the charter.

I certainly have the same heartburn as everyone else about having used 
TXT in this manner, but that ship has long sailed. This is running and 
interoperable code and it is being documented on the standards track. 
Unless you think there is a piece of information I missed in my 
assessment that we had consensus to go forward with this work in the 
first place, you are going to have a hard time convincing me that this 
is not in the rough part of the consensus now.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "John R Levine" <[email-masked]>
Date: 25 Apr 2013 13:59:04 -0400

> Wait; support for the SPF RRType would have involved changes in provisioning systems, so instead the decision was to use TXT RRTypes which involved changes in provisioning systems?

Sheesh.  The changes were a lot less, and were a lot easier to explain 
since everyone with even the most cursory familiarity with DNS knows 
what TXT records are.

Meow,
John

---

From: Warren Kumari <[email-masked]>
Date: Thu, 25 Apr 2013 14:03:06 -0400

On Apr 25, 2013, at 1:34 PM, Pete Resnick <[email-masked]> wrote:

> We are *long* past this discussion. This discussion should have happened at SPFBIS *chartering* time, as it is crystal clear from the charter that existing features currently in use in SPF are not going away. Indeed, the TXT record was specifically mentioned in the charter.
> 
> I certainly have the same heartburn as everyone else about having used TXT in this manner, but that ship has long sailed. This is running and interoperable code and it is being documented on the standards track. Unless you think there is a piece of information I missed in my assessment that we had consensus to go forward with this work in the first place, you are going to have a hard time convincing me that this is not in the rough part of the consensus now.

I would also recommend that folk actually go and read RFC6686 [0] - I know that having actual measurements interferes with one's ability to have a fun little rant, but, if you do, maybe you can avoid looking silly (like I did with the RFC5507 discussion :-)).

Maybe stuffing stuff in a TXT record was a poor decision. Maybe it wasn't. There are heaps more SPF in TXT than SPF in SPF, kvetcing won't change that, and I'm sure we can find something else more fun to kvetch about...

W

[0]: Yes, I know finding the documents can be hard. Here is a link: http://tools.ietf.org/html/rfc6686

--
"When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie."
-- Terry Pratchett

---

From: Warren Kumari <[email-masked]>
Date: Thu, 25 Apr 2013 14:16:17 -0400

[ Whee, replying to my own message. Always a good sign…] 
On Apr 25, 2013, at 2:03 PM, Warren Kumari <[email-masked]> wrote:

> Maybe stuffing stuff in a TXT record was a poor decision. Maybe it wasn't. There are heaps more SPF in TXT than SPF in SPF, kvetcing won't change that, and I'm sure we can find something else more fun to kvetch about…
> 

Ever have one of those days when you just wake up ornery? Those are probably the days when you shouldn't be responding to mail (or interacting with people at all) :-P

W

-- 
A. No
Q. Is it sensible to top-post?

---

From: David Conrad <[email-masked]>
Date: Thu, 25 Apr 2013 13:19:45 -0500

Andrew,

> following that WG have the appropriate context.

Thanks.  As mentioned, it would seem minds are made up so I'm not sure whether it's worth the effort to wade in there.  However...

> There's actually an interoperability problem, and there's a simple fact of deployment.  

There is and will always be an interoperability problem and a 'simple' fact of deployment.

In my view, the issue relevant to DNSEXT ("moribund" or not) is the implication of the SPFBIS approach on the specification of new DNS RRtypes. I do not believe the issues faced in SPF deployment are unique and I imagine there will be protocols in the future that follow the same steps, i.e., put info in the DNS using TXT during initial experimental phases because it's easy/simple/doesn't require any approvals/documentation/interaction with others and then come back later and try to do "the right thing" when the protocol "works".

As I try to be pragmatic, I personally don't get hives about the underscore-label convention. I don't think it is an ideal choice, but it does get around broken DPI firewalls/policy that reject unknown RR types. (of course, SPFBIS doesn't even do this). However, I believe the implication of the SPFBIS decision is to cement this approach for future DNS protocol enhancements.

This should probably be made clear to RRtype expert reviewers and (if it doesn't already exist -- quick review of the IANA registries suggests that it doesn't) a registry should probably be created to avoid collisions on underscore labels.  Of course, I wouldn't put it past DPI firewall and/or 'security' policy makers to start filtering underscore labels but so it goes.  Hmm.  I wonder how many of the DNS User Interfaces out there disallow underscores in labels... 

Regards,
-drc

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Apr 2013 18:21:45 +0000

> It seems to be the case that there are rather a lot of people on the dnsext mailing list who are on the rough side of the consensus here.   That suggests that perhaps the consensus isn't in the dir…

There have been a number of rather stiff comments sent to me privately about this statement, particularly with respect to the fact that as AD, I might have some influence on the consensus call on the SPF document.   One person said that I should be very clear about whether I am wearing my AD hat when I make comments like this, which I think is a valid point, and that further, I probably shouldn't make statements like this at all, which I am not sure is a valid point; neither am I sure it is not.

So to be clear here, the document in question is not a DNSEXT document, and I am not responsible area director for the working group in which the document has been considered.

Someone proposed that I might be threatening to use my influence as one member of the IESG to influence the outcome of the consensus call on this document.   To be clear, I was not threatening to do that, and it hadn't occurred to me that someone would think I was threatening to do that. I do understand why someone might have been concerned that I was threatening to do that, and I apologize for having given that impression.

As to what I did mean here, what I meant is that I think this is a matter that DNSEXT people are clearly interested in, and there are a lot of DNSEXT people who think deprecating the SPF record in favor of the TXT record is exactly the wrong thing to do, including me with my AD hat off.

With my AD hat on, I actually have no clue how to resolve this question.   I've been in working groups where another working group has dogpiled on an issue.   It's certainly appropriate for people who do not agree with the deprecation of the spf record to participate in the spfbis last call, although you ought to read the document and review the history first.

However, there is also an IETF last call, and the purpose of the IETF last call, as I understand it, is to evaluate whether a document that a working group has produced actually has consensus within the IETF.   As far as I understand it, it is entirely in scope for participants on the dnsext mailing list to speak up at the IETF last call and say "hey, this is a really bad idea, here's why."

It's my understanding that the responsible AD for the working group whose document got pushback in IETF last call is supposed to evaluate consensus on that document; that would be Pete Resnick, not me, so you don't have to worry about my corrupt influence on that process.

I don't think IETF last calls often fail to produce consensus, but it did happen recently with the MIF DHCP Default Route option.   Like this document, the DHCP Default Route option was in the MIF charter, which had been through IETF last call.   But when the document itself went though IETF last call, there was substantial pushback.   As a result of this, the document did not advance.

It might be worth considering another related case.   Years ago, the DHC working group proposed a new RRtype, the DHCID RRtype.   At the time, existing DHCP servers were using TXT records to record identifiers on names so that they could tell whether or not it was safe to do a DNS Update on that name on behalf of a client that was claiming the name.   We wrote up a single, thorough document explaining how to do it, brought it to DNSEXT, and got the rotten tomato treatment.

Eventually we broke the document up into three pieces, published one as a DNSEXT (or was it DNSIND?) document, one I think as a DNSOP document, and one as a DHC document.   At the time of publication, and for many years after, 100% of implementations used the TXT record, not DHCID.

I do not know what the prevalence of DHCID in the field is at this point.   I don't actually care.  The standard says the right thing.   If existing implementations do something different, that's okay, as long as it works.   Eventually the implementations will get fixed.   I think this is the right outcome for DHCID.   It's not exactly analogous to the situation with SPF, though, where the text record is actually documented in RFC4408.

I think you can make an argument for letting this go, or for trying to argue the point.   I honestly don't know what the right move is—this debate really should have happened when the spfbis charter was last called.   Perhaps we should take this as a lesson to follow the IETF mailing list more closely—I certainly didn't notice this when it went by, and I wish I had.   This kind of ships-passing-in-the-night problem happens a lot in the IETF, and I've never seen a good proposal for how to solve it.

---

From: Pete Resnick <[email-masked]>
Date: Thu, 25 Apr 2013 13:53:44 -0500

Ted and I spoke a bit about this offline, but just to follow up on a 
couple of points:

> However, there is also an IETF last call, and the purpose of the IETF last call, as I understand it, is to evaluate whether a document that a working group has produced actually has consensus withi…

It is certainly acceptable to reply to the IETF Last Call, but it is 
also important to keep in mind what the valid issues to raise are. I 
intend to make sure that we stay on topic during Last Call, and I will 
attempt to put appropriate reminders in the Last Call announcement 
itself. In particular, rehashing issues that ought to have been decided 
at charter time, or during the Last Call of RFC 6686, are unlikely to be 
allowed to go on for very long without a clear accounting of new 
information that has come to light since then.

> It's my understanding that the responsible AD for the working group whose document got pushback in IETF last call is supposed to evaluate consensus on that document; that would be Pete Resnick, not…

I think it reasonably likely that I can avoid being corrupted by Ted. ;-)

> Perhaps we should take this as a lesson to follow the IETF mailing list more closely—I certainly didn't notice this when it went by, and I wish I had.   This kind of ships-passing-in-the-night problem happens a lot in the IETF, and I've never seen a good proposal for how to solve it.
>    

We have been on a long steady drift away from actually doing cross area 
work (and note that I didn't say "review"; that comes too late) and have 
become rather silo-ed, and we also seem to have forgotten how to get 
broad consensus. I've been working on the latter (see <some random 
I-D>), and I believe the IESG is starting to think about the former. I 
am more hopeful than I used to be.

pr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Apr 2013 19:07:52 +0000

On Apr 25, 2013, at 2:53 PM, Pete Resnick <[email-masked]> wrote:
> In particular, rehashing issues that ought to have been decided at charter time, or during the Last Call of RFC 6686, are unlikely to be allowed to go on for very long without a clear accounting of new information that has come to light since then.

So, I'm looking at the charter, and I see nothing in the charter about deprecating SPF.   Indeed, I see this, which I think forbids deprecating SPF:

> Specifically out-of-scope for this working group: 
> [...]
> * Removal of existing features that are in current use. 

This doesn't seem to be subject to a lot of interpretation.

---

From: Pete Resnick <[email-masked]>
Date: Thu, 25 Apr 2013 14:14:50 -0500

> This doesn't seem to be subject to a lot of interpretation.

Indeed, and this was a topic of some serious discussion at the time that 
6686 was being worked on, and I'll suggest, as some others have, that 
you read that document to see why the decision was made. (Indeed, this 
particular charter item was the topic of a rather contentious appeal to 
the AD that went a different way for a different topic.)

And I'd suggest that this is no longer an interesting topic of 
conversation for DNSEXT.

pr

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 25 Apr 2013 21:59:56 +0200

On 25 apr 2013, at 20:03, Warren Kumari <[email-masked]> wrote:

> Maybe stuffing stuff in a TXT record was a poor decision.

What I tried to explain in RFC5507 was that the real pain(*) is when you in an RRSet get back more data than what you want, so that you have to parse the blob of data you get and do whatever you want to do.

The selector of what you want can only be in one of the owner, class or type, and we know the class is sort of not usable, so you are stuck with type and owner. If now owner is TXT on everything,...

The rest is left as an exercise for the reader.

   Patrik

(*) Experience from too extensive use of NAPTR records in various solutions, and the reason I came up with the URI RRType.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 25 Apr 2013 22:02:06 +0200

> The selector of what you want can only be in one of the owner, class or type, and we know the class is sort of not usable, so you are stuck with type and owner. If now owner is TXT on everything,...

Sigh...if now TYPE is TXT on everything...of course...

   Patrik -- going to bed now

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Apr 2013 13:54:39 -0700

> Indeed, the TXT record was specifically mentioned in the charter.

As Ted pointed out, that seems not to be the case.

Meanwhile, some of us have spoken long and loud about how deprecating 
the SPF record is the wrong path, which includes before, during, and 
after spfbis was chartered. Those concerns have consistently been 
shouted down, as you are doing now.

The way forward is simple, spfbis should specify that compliant senders 
MUST publish the SPF record, and compliant receivers MUST query for it 
first. Then down the road at some point we can deprecate TXT for this 
purpose. If that had been done in the beginning we would be celebrating 
the deprecation of the TXT record right about now, instead of having 
another round of contentious arguments about doing it the right way in 
the first place.

Everyone knows the history of how hard it was to get new RRtypes off the 
ground at the time SPF first came into being. A lot of lessons were 
learned from that, and the situation is much better now. Everyone also 
understands that the problem of upgrading 3rd party and/or web-based 
provisioning systems to accommodate new records is still a problem. But 
that problem doesn't get better by ignoring it.

In short, the proponents of SPF (which by the way, I like and use) 
should be focusing on doing the right thing here, instead of the 
expedient thing.

Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Apr 2013 14:09:47 -0700

On Thu, Apr 25, 2013 at 1:54 PM, Doug Barton <[email-masked]> wrote:

> purpose. If that had been done in the beginning we would be celebrating the
> deprecation of the TXT record right about now, instead of having another
> round of contentious arguments about doing it the right way in the first
> place.
>
>
I fail to see how the word "simple" can be legitimately applied here given
the breadth of the deployed base of SPF that's using TXT.  It may be the
right thing to do, but I don't think that's a mountain that's easy to
move.  Certainly it's easy to talk about it though.

> ground at the time SPF first came into being. A lot of lessons were learned
> from that, and the situation is much better now. Everyone also understands
> that the problem of upgrading 3rd party and/or web-based provisioning
> systems to accommodate new records is still a problem. But that problem
> doesn't get better by ignoring it.
>
> In short, the proponents of SPF (which by the way, I like and use) should
> be focusing on doing the right thing here, instead of the expedient thing.
>

I think that same history gives rise to another way forward.  When SPF came
into being, the RRtype issue prevented the right thing from happening.  It
was made worse by late insertion of a sloppy transition mechanism.  It's
much too late to fix that now, but we can take steps to prevent it from
happening with future protocols. Thus: Take our licks and leave this one
alone, but do good work on improving process and provisioning so that it
can't happen again.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 25 Apr 2013 21:38:23 -0000

>option that's down to a couple per month.

Gee, on a bad day I used to get 300,000, mostly from parts of the
world where SPF still isn't very widely used.  (Yes. that's the right
number of zeros.)  Now it's down to an insignificant 250 or so, mostly
because the spammer who used to forge my address in all his spam has
gone on to other stuff.

Look, we all understand why glomming everything into TXT records is
not ideal.  If we were defining SPf from scratch, and the time to get
new rrtypes into provisioning systems were measured in months rather
than decades, we'd likely have done something else.  But we aren't,
and it's not.

R's,
John

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Apr 2013 14:39:48 -0700

On 04/25/2013 02:09 PM, Murray S. Kucherawy wrote:
> On Thu, Apr 25, 2013 at 1:54 PM, Doug Barton <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     The way forward is simple, spfbis should specify that compliant
>     senders MUST publish the SPF record, and compliant receivers MUST
>     query for it first. Then down the road at some point we can
>     deprecate TXT for this purpose. If that had been done in the
>     beginning we would be celebrating the deprecation of the TXT record
>     right about now, instead of having another round of contentious
>     arguments about doing it the right way in the first place.
>
>
> I fail to see how the word "simple" can be legitimately applied here
> given the breadth of the deployed base of SPF that's using TXT.

I didn't say "Don't query for TXT records any more." I definitely didn't 
say, "Let's throw out SPF altogether." I said "change it to go the right 
way around in the first place." Obviously the transition will take time 
(as I also pointed out), but that doesn't mean that we shouldn't start 
doing it the right way now.

And really, it IS simple. Tomorrow all the extant software that deals 
with SPF gets updated to query for SPF first. The next day all the docs 
for publishing SPF records tell people to publish both. Ok, tomorrow and 
the next day are probably not realistic, but how about next week? Or 
next month? This isn't brain surgery, it really is a very simple change. 
And sure it's going to take time to implement, time to upgrade the 
installed base, and time for the pendulum to swing from TXT being 
queried nearly universally to SPF instead. But it's a minimal amount of 
effort, and the time is going to pass anyway.

There is simply no reason not to do this right, and to start doing it 
right now.

> It may
> be the right thing to do, but I don't think that's a mountain that's
> easy to move.  Certainly it's easy to talk about it though.

We in the DNS world have a ton of experience with the long tail of an 
installed base that doesn't upgrade often. Maybe that's the difference 
in perspective that makes this look like an "easy" problem to us.

>     Everyone knows the history of how hard it was to get new RRtypes off
>     the ground at the time SPF first came into being. A lot of lessons
>     were learned from that, and the situation is much better now.
>     Everyone also understands that the problem of upgrading 3rd party
>     and/or web-based provisioning systems to accommodate new records is
>     still a problem. But that problem doesn't get better by ignoring it.
>
> I think that same history gives rise to another way forward.  When SPF
> came into being, the RRtype issue prevented the right thing from
> happening.

I would argue that the situation at the time made doing the right thing 
more difficult than using the TXT record, not that it made it 
impossible. But I will agree to disagree on that point. :)

> It was made worse by late insertion of a sloppy transition
> mechanism.  It's much too late to fix that now

But it's not. That's the point. I realize that the course of action 
where we throw up our hands and say to ourselves, "better luck next 
time, hopefully this will become a lesson learned" is wildly attractive. 
But it's bad to do that. Bad for SPF, bad for the DNS in general, and 
bad for the Internet as a whole. And most importantly, it would be 
choosing to do the wrong thing when there is no reason not to do the 
right thing.

Doug

---

From: Hector Santos <[email-masked]>
Date: Thu, 25 Apr 2013 17:57:08 -0400

I believe the right engineering design choice in MARID was made.  The 
problem was the DNS Servers have not caught up with the very least of 
having a passthru concept with unnamed query types.  It is was clearly 
known what the issues were in MARID, a migration path was provided with 
the protocol and we fully expected the DNS servers will eventually catch 
up and support unnamed types. [1]  It was a long term migration path 
issue as Doug Barton pointed out.

I still believe having a specific record is the right thing and path. 
Eliminating it will only encourage more TXT-based protocols.  The 
question is whether the DNS servers will support it or at the very least 
a passthru.

I suggest to keep it and to relax the requirements, and basically have 
developers keep it as an software design option, i.e. don't forget about 
it, comment it out, compiler directives, etc.  It would be their choice 
to immediately support the ideal migration path that is currently 
described in 4408 (although I have a small issue with the parallel call 
idea, but that's a different issue), or leave the code ready but disable 
it for a TXT only query.  Lets think ahead here now (again), not later 
and begin to encourage DNS server developers/vendors, DNS Managerment 
Software folks, etc, to support unnamed types processing. [1]

--
HLS

[1] http://tools.ietf.org/html/rfc3597

n 4/25/2013 5:09 PM, Murray S. Kucherawy wrote:
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>

---

From: Pete Resnick <[email-masked]>
Date: Thu, 25 Apr 2013 17:41:18 -0500

> As Ted pointed out, that seems not to be the case.

Ted and I just had a discussion about this offline, and just as Ted did, 
you have misread what I wrote. I responded to Måns's suggestion that 
spfbis can not "prescribe TXT records". And I responded that existing 
features currently in use in SPF (of which the use of TXT is such a 
feature) are out of charter to remove. And they are.

The removal of the feature to use RR 99 was an option open to the WG if 
they determined that it was not on the forbidden list of "features 
currently in use". RFC 6686 and the discussion leading up to it document 
why it is, for all intents and purposes, unused.

> shouted down, as you are doing now.

A few things on this point:

1. There is no doubt that the removal of the feature to use RR 99 
engendered a protracted and contentious discussion. However, it was not 
specifically discussed before or during chartering as far as I can tell. 
I've looked through the IETF list, the IESG list, the DNSEXT list, and 
the SPFBIS list and I see nothing on this topic discussed prior to 
chartering. And importantly, I see not a single message from you in 
particular on this topic prior to this, and only a few messages in 
September of last year on any SPF topic.  So I'm not clear on what you 
mean by "some of us" having "spoken long and loud" about this topic 
before or during SPFBIS being chartered.

2. There is also no doubt that during the long discussion in February of 
last year on the SPFBIS list, many folks expressed the view that the 
feature ought not be removed, including by at least one chair of the WG. 
(In fact, that argument drove some of the research that ended up in RFC 
6686.) However, in the end, a consensus call was made that, although 
there were some outstanding objections, those concerns were sufficiently 
addressed *by reasoned technical argument* and that the consensus (with 
some roughness) was that the feature was to be removed. Though there may 
have been shouting at times, there was no "shouting down".

3. I do not intend, and hope I have not, "shouted down" any argument 
here. However, there is now a long record on this argument and how the 
consensus call was made. Though the chairs and I will review all 
discussion that comes out during Last Call (or now), it really is only 
polite for (if not incumbent on) those who might still have objections 
to do some research to see if their particular argument was not 
addressed in that lengthy discussion. My claim in my earlier message was 
(and remains) that it's going to take identifying some piece of 
information that was missed during that discussion to convince me that 
the consensus call was not correct. As I've said elsewhere, number of 
people saying something is not how consensus is judged; it's whether the 
issue itself was properly addressed. (See draft-resnick-on-consensus-02 
for my musings on that.) Coming to consensus is hard work, and it 
shouldn't just be hard work for chairs and ADs; participants have to do 
their part too.

In particular:

> query for it first. Then down the road at some point we can deprecate 
> TXT for this purpose.

This is *not* a new argument. It was one that was discussed at length on 
the SPFBIS list at the end of last February. If you think we missed 
something (and I'd really ask you to read through the discussion of 
issue #9 on the list), I'd encourage you to make that case. But simply 
saying, "MUST publish/MUST query/later deprecate TXT" is not a 
sufficient technical argument given all that has been discussed to date.

> should be focusing on doing the right thing here, instead of the 

If, after reading the discussion, you think SPFBIS was being superficial 
in its treatment of this topic and can identify an argument that was 
missed, fine. But your presumption that this was done simply for 
expedience is at the very least premature.

pr

---

From: David Conrad <[email-masked]>
Date: Thu, 25 Apr 2013 17:46:18 -0500

Paul,

> Isn't it amazing that the DNSEXT WG can't answer a simple question without turning it into a lecture about How Things Would Be Done If We Were Kings and Queens? (Actually, no one even bothered to a…

Err, might want to step down off that high horse: might be causing cerebral hypoxia. :)

In my response that seems to have touched off this thread, I stated: 

"It is in keeping with past practice, e.g., see the notations for MD, MF, A6, and the MAILA RRtypes at http://www.iana.org/assignments/dns-parameters/dns-parameters.xml."

I'd also point out some inconsistencies in the registry (e.g., NXT should probably say "OBSOLETE - use NSEC") and sillinesses (e.g., what's the point of replicating the RR type's name as the meaning?) but that's probably something for a different thread.

Regards,
-drc

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Apr 2013 16:28:50 -0700

> feature) are out of charter to remove. And they are.

... and for the Nth repetition, I did not propose to remove the TXT 
record at this time.

> why it is, for all intents and purposes, unused.

Yep, been there, done that. It was a bad decision then, and it's still a 
bad decision now. I realize that it's incredibly unpopular to bluntly 
call bad decisions "bad decisions," but not doing so doesn't make them 
any less bad. And, to make matters worse, not doing so has led to a 
non-trivial number of those bad decisions becoming de facto standards. 
This has at least 2 very bad side effects ... first, we have to live 
with the bad de facto standards; but more importantly we are providing 
encouragement to people who wish to make similar bad decisions down the 
road.

The argument in 6686 boils down to, "We made a series of bad decisions, 
which have led to a bad result. We now want to codify that bad result 
instead of cleaning up our mess." I don't agree with that in principle, 
and I don't agree with that in regards to this particular case.

Further, while cleaning up the SPF mess would require nothing more than 
a marginal amount of extra work now, plus the passage of time, there is 
no reason not to actually clean up the mess.

> chartering.

https://www.ietf.org/mail-archive/web/ietf/current/msg72024.html is 
where the thread starts. There is another parallel thread an a related 
topic around that same time.

> And importantly, I see not a single message from you in
> particular on this topic prior to this,

https://www.ietf.org/mail-archive/web/ietf/current/msg72085.html

> and only a few messages in

With respect, you clearly haven't been paying attention. That thread on 
ietf@ (and the one you referenced on dnsext) took me about 2 minutes to 
find. Admittedly, the ietf@ thread wasn't specifically about SPF, but it 
was about the same exact topic, at the time that the spfbis charter was 
being developed, so one would think that interested parties would have 
wanted to pay attention.

The topic has been raised numerous times since day 1 of SPF, and the DNS 
folk who have said "the SPF RRtype should be the first (if not only) 
choice" have been consistently ignored.

Meanwhile, who said what when isn't the interesting part of the 
discussion. The questions are simple:

1. What is the right thing to do?
2. Can we do it?

We know the answer to 1, and the answer to 2 is yes. So why are we 
spending all of this time trying to find reasons not to do the right 
thing? If as much energy had gone into fixing the problem as has gone 
into justifying not fixing the problem, the problem would be fixed by 
now. :)

> some roughness) was that the feature was to be removed.

Yes, I know the history. It was a bad decision. The great thing about 
life, especially life in the IETF, is that bad decisions can be revisited.

> Though there may

Others see the problem differently, but let's not quibble on that point.

> issue #9 on the list), I'd encourage you to make that case.

I'll give that a go, sure.

> But simply

But what if all of the previous discussion was wrong? Simply saying "we 
have discussed this extensively" doesn't refute sound technical 
arguments either. :)

> expedience is at the very least premature.

While I didn't follow the spfbis group, I have followed SPF from the 
time before it was even a topic at the IETF. Given what I know of the 
history I stand by my assertion, but would be overjoyed to be proven wrong.

Doug

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Apr 2013 17:15:43 -0700

On 04/25/2013 03:41 PM, Pete Resnick wrote:
> and I'd really ask you to read through the discussion of issue #9 on the
> list

Ok, so I've read through those threads, and the antecedents. I saw the 
following:

1. Some reports of people who wrote code to use the new RRtype early on, 
and had problems, so they stopped.

2. A report that Perl's "Mail::SPF (which is used by Spamassassin) 
checks for Type SPF first by default."

3. Several folks pointing out the valid DNS protocol based reasons why 
overloading TXT is bad, and new RRtypes for new features are good.

4. Lots of messages along the lines of, "We've always used TXT for this, 
so we should keep using it." These arguments all seem focused around the 
concept that having 2 ways to do the same thing is kind of a pain, so 
let's just use the one that is most popular.

5. Some fairly persuasive technical arguments from Andrew Sullivan that 
putting SPF records into your zone is a good idea. Particularly this:
https://www.ietf.org/mail-archive/web/spfbis/current/msg00544.html

#1 was an expected result in the days prior to 3597 (2003), but should 
be little to no trouble now.

#2 Speaks in favor of my proposal.

#3 (Arguably one of the only "reasoned technical arguments" in the 
bunch) seems to have been ignored by the majority of list members.

#4 Is not a "reasoned technical argument."

#5 Is also a "reasoned technical argument," which was not only ignored, 
but twisted on its ear by at least one list member.

It's also worth pointing out that a non-zero number of list members were 
ready (eager?) to shut down the SPF record prior to their being any 
actual discussion of it.

So I stand by my original proposal. We should do the right thing here, 
not the expedient thing. And the fact that a significant piece of 
software is already doing that, and clearly it works, is a pretty big 
point in favor.

Further, there were no "reasoned technical arguments" in that thread 
against doing what I proposed. As I mentioned in #4 above there was some 
whinging about having 2 ways to do the lookup, but as I pointed out 
previously if the switch had been flipped to do the SPF lookup first at 
some reasonable time post-3597, we'd be celebrating the deprecation of 
the TXT record right about now.

And further than _that_, Andrew and a few other list members pointed out 
that with a theoretical v=spf3 on the horizon, that would be a perfect 
time to say "Use the SPF record only, don't use TXT at all." Of course 
that whole line of thought was shot down with the same, "But we've 
always used TXT" argument. Which is unfortunate because I think that 
would have been an excellent compromise position, which has valid 
technical grounds.

Doug

---

From: S Moonesamy <[email-masked]>
Date: Thu, 25 Apr 2013 17:22:25 -0700

Hi Doug,
At 16:28 25-04-2013, Doug Barton wrote:
>Yep, been there, done that. It was a bad decision then, and it's 
>still a bad decision now. I realize that it's incredibly unpopular 
>to bluntly call bad decisions "bad decisions," but not doing so 
>doesn't make them any less bad. And, to make matters worse,

I am ok if anyone says that it a bad decision.  The thread for the 
discussion started at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html

>The argument in 6686 boils down to, "We made a series of bad 
>decisions, which have led to a bad result. We now want to codify 
>that bad result instead of cleaning up our mess." I don't agree with 
>that in principle, and I don't agree with that in regards to this 
>particular case.

I was the document shepherd for RFC 6686.  There wasn't any comments 
during the Last Call.

>where the thread starts. There is another parallel thread an a 
>related topic around that same time.

I read the messages on that thread around the time they were posted.

>https://www.ietf.org/mail-archive/web/ietf/current/msg72085.html

I also read those messages.

>The topic has been raised numerous times since day 1 of SPF, and the 
>DNS folk who have said "the SPF RRtype should be the first (if not 
>only) choice" have been consistently ignored.

I have to respectfully mention that I read all the messages that were 
posted to the SPFBIS mailing list.  I cannot take into consideration 
comments posted to ietf@ if they are not part of the Last Call.

>But what if all of the previous discussion was wrong? Simply saying 
>"we have discussed this extensively" doesn't refute sound technical 
>arguments either. :)

If all the previous discussions were wrong I hope that the future 
discussions will be right. :-)

>time before it was

You missed 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01440.html :-)

At 17:15 25-04-2013, Doug Barton wrote:
>5. Some fairly persuasive technical arguments from Andrew Sullivan 
>that putting SPF records into your zone is a good idea. Particularly this:

[snip]

>#5 Is also a "reasoned technical argument," which was not only 
>ignored, but twisted on its ear by at least one list member.

The SPFBIS WG Chairs are the persons making the determination for 
discussions within the working group.  I happen to be one of the 
SPFBIS WG co-chairs and the other co-chair is Andrew Sullivan.  I 
didn't ignore his comments.  I didn't ask Andrew Sullivan whether he 
ignored his comments.  If I misunderstood or misinterpreted his 
comments he would likely talk to me about that.  That makes it 
unlikely that any twisting would reach my ears. :-)

Regards,
S. Moonesamy

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Apr 2013 18:30:43 -0700

Note, I'm going to push back on some of the things you say below, but I 
don't want the main point I'm trying to make to get lost:

1. It's not too late to do the right thing,
2. So we should do that.

Arguing about how we got here is fun and all, but not germane to the 
really important bit.

On 04/25/2013 05:22 PM, S Moonesamy wrote:
>> Yep, been there, done that. It was a bad decision then, and it's still
>> a bad decision now. I realize that it's incredibly unpopular to
>> bluntly call bad decisions "bad decisions," but not doing so doesn't
>> make them any less bad. And, to make matters worse,
>
>> decisions, which have led to a bad result. We now want to codify that
>> bad result instead of cleaning up our mess." I don't agree with that
>> in principle, and I don't agree with that in regards to this
>> particular case.
>

There are only so many times that people can say "this is a bad idea," 
then get ignored, and then have enthusiasm to come back and say the same 
thing again. I didn't follow the pre-publication of 6686, as I had other 
things to do at the time. However the volume of previous discussion over 
the last 8+ years should have been sufficient to render the idea of 
deprecating the SPF RRtype a non-starter. The fact that the draft got 
written in the first place said a lot about the chances of any 
objections being considered.

> comments posted to ietf@ if they are not part of the Last Call.

I have to respectfully point out that a) there is a wider world beyond 
spfbis, and b) the reasoned technical arguments that were presented on 
the list (not to mention the running code) should have been sufficient 
to push the group in the direction of preferring the SPF RRtype with an 
eye toward deprecating TXT in the future.

I don't know why, specifically, that didn't happen; but I also don't care.

What I want to see happen is that we do the right thing now.

> discussions will be right. :-)

Voila! :)

> discussions within the working group.  I happen to be one of the SPFBIS
> WG co-chairs and the other co-chair is Andrew Sullivan.  I didn't ignore
> his comments.  I didn't ask Andrew Sullivan whether he ignored his
> comments.  If I misunderstood or misinterpreted his comments he would
> likely talk to me about that.  That makes it unlikely that any twisting
> would reach my ears. :-)

It wasn't any of your messages I was referring to.

Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Apr 2013 20:29:14 -0700

On Thu, Apr 25, 2013 at 4:28 PM, Doug Barton <[email-masked]> wrote:

> bad decision now. I realize that it's incredibly unpopular to bluntly call
> bad decisions "bad decisions," but not doing so doesn't make them any less
> bad. And, to make matters worse, not doing so has led to a non-trivial
> number of those bad decisions becoming de facto standards. This has at
> least 2 very bad side effects ... first, we have to live with the bad de
> facto standards; but more importantly we are providing encouragement to
> people who wish to make similar bad decisions down the road.
>
> instead of cleaning up our mess." I don't agree with that in principle, and
> I don't agree with that in regards to this particular case.
>
> Further, while cleaning up the SPF mess would require nothing more than a
> marginal amount of extra work now, plus the passage of time, there is no
> reason not to actually clean up the mess.

I think this continues to trivialize exactly what it means to migrate the
enormous deployed base of SPF in the manner you're pushing. I fully agree
with your premise that it should've been "done right" in the beginning and
I lament that it was not, but I don't agree that fixing this now is worth
moving a mountain, especially when I don't believe the people saying that
here will be among the people doing even a fraction of the moving.

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.  The rules
for getting new RRtypes have been improved -- I think we all agree on that
-- but, as you already conceded, there's still a large deployed base of
faulty firewalls and DNS tools out there that don't exactly make use of
uncommon RRtypes easy.  So how much energy are the DNS experts going to put
into cleaning up their house while demanding the mail people clean up
theirs?  I would even go so far as to say that the DNS part has to happen
first, before any cleanup on the email side is practical to consider.

The deployed SPF base probably won't give a damn if the IETF suddenly
releases an RFC that exclaims "Everybody migrate to type 99!"  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.

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

-MSK

---

From: David Conrad <[email-masked]>
Date: Fri, 26 Apr 2013 00:39:59 -0500

John,

On Apr 25, 2013, at 9:44 AM, John R Levine <[email-masked]> wrote:
> The much more serious reason is that the provisioning systems to let system managers install type 99 records into their DNS did not exist, and for the most part still do not exist.  

Standard chicken-or-egg problem endemic to trying to deploy anything new.

I actually find this situation a bit amusing.  Not being a follower of these things, I actually honestly didn't know that TXT RRs was the preferred method to do SPF when I set up SPF on my server about a year ago.  The user interface I was using (CloudFlare) supported SPF and it actually didn't occur to me to use TXT. It wasn't until an unrelated problem showed up that someone who follows the IETF SPF stuff laughed at me and said I should be using TXT RRs instead of SPF RRs.   

> I know a lot of the people who did early SPF installations and they uniformly reported that even getting the provisioning software to support TXT records that have been around since the dawn of the DNS was painful, and there would have been no hope for a new and exotic record type.  Since their goal was to make SPF actually work, they used a kludge.  It's the same reason DKIM uses TXT records.

So I believe the question here isn't really related to the horrible bogosities of the past (that I think we can all cite evidence for) but what should be the future.  I'm reminded of the (perhaps apocryphal) story of the guy who wrote make(1) deciding that having whitespace significant in Makefiles was a mistake, but the installed base was too large to fix it -- the installed base at the time being 20 developers. 

I guess it depends on what the view of the future of SPF actually is.  If the assumption is that SPF is at or near its peak and SPF usage will dwindle over time, then it doesn't actually matter whether TXT or SPF RRs are used.  However, if the assumption is that SPF will see increased deployment over time, eventually dwarfing the number of deployments currently, then I personally believe the approach proposed in the SPFBIS draft is simply broken. IMHO, YMMV. 

Not being tuned in to the world in which SPF matters all that much (as evidenced by my apparently silly use of the SPF RR), I have no idea what the assumptions are regarding future use of SPF.

>>> Yes, the ossification of the DNS makes introducing new things challenging however as Mark pointed out, software was beginning to do the right thing and there actually are web interfaces out there that let folks enter SPF records (I use one).
> Wow, and it's only taken eight fripping years.  Perhaps if we wait another century the provisioning systems will catch up.  

As I said, standard chicken-or-egg.  Why should a provisioning system bother implementing anything other than TXT if no one is asking for anything other than TXT?  Why should anyone ask for their provisioning system to support anything other than TXT since using TXT appears to work?

Of course, using TXT has all sorts of downsides, but few if any of those are apparent the the person who puts TXT into their DNS editor.  The fact that folks are implementing SPF RR support now (as evidenced by Mark's comments and my experiences) might suggest that the migration curve is trending in the right direction and the SPFBIS decision might have been wrong.

> If the DNS crowd spent half the effort addressing the provisioning problem that you do trying to deny that it exists, it'd have been fixed years ago.  My dnsextlang proposal is one approach, but surely not the only one.

Sorry, when folks can't figure out how to implement an editor that by definition is identical to the editor used for the TXT RR, I have a bit of skepticism that they'll implement anything like dnsextlang.  However, with that said, I fully support moving forward with dnsextlang.

> PS: The system that lets you enter SPF records wouldn't be Godaddy, would it?

Nope. CloudFlare.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Fri, 26 Apr 2013 01:05:22 -0500

Murray,

On Apr 25, 2013, at 10:29 PM, "Murray S. Kucherawy" <[email-masked]> 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

---

From: Noel David Torres Taño <[email-masked]>
Date: Fri, 26 Apr 2013 07:21:49 +0100

On Jueves, 25 de abril de 2013 12:13:29 Ted Lemon wrote:
> > I have no illusions that I'd be able to sway anyone related to spfbis --
> > minds appear to be quite made up based on the private messages I've
> > received
> 
> Then perhaps we should all tromp on this in IETF last call.   I certainly
> agree with your take on this: the idea that a document would advocate the
> use of a TXT record because promulgating SPF records is "too hard" is just
> broken.
> 
I agree with this. Tha main idea with TXT records is to keep data aimed to 
humans, not to machines. In fac, a machine should never request a TXT Query on 
its own.

Regards
Noel
er Envite
-------------------------
A: Because it breaks the logical flow of discussion.
Q: Why is top posting bad?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Apr 2013 23:30:13 -0700

On Thu, Apr 25, 2013 at 11:05 PM, David Conrad <[email-masked]> wrote:

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

Did I really come across as that petty?

No, what I'm saying is that the way things were ten years ago pushed the
SPF community to the place it's in now, ugly as it is.  SPF, in the
interim, has become very widely deployed.  Suddenly now we have a few
voices from the ivory tower asserting that the same community needs to go
out and re-do things the way they should have been done in the first place,
now that we finally have a somewhat more reasonable perspective, even
though some of the vestiges of ten years ago are in fact still around.  My
reaction to that is "You can't be serious."  That doesn't sound like
revenge at all to me, just pragmatism.

> 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.
>

I think it's much closer to the former.

> 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.
>

Someone else (Joe, I think) has already referred to other RFCs that talk
about things like IAB advice about how [not] to put application data into
the DNS.  Seems to me this is a perfectly good subject for another such
project.  One may counter that by saying nobody will pay attention to such
a document, but I submit that it's our primary mechanism for making sure
mistakes aren't re-made, so that's the tool we have to use or not use.

If we do the opposite and somehow compel SPFBIS to favour type 99 over TXT,
then I still think we'll be shouting that to an audience that will think
we're nuts and simply go about their business.

-MSK

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Apr 2013 16:52:21 +1000

> here will be among the people doing even a fraction of the moving.

The installed base of SPF is miniscule.  As for moving it, you
really only need to update a couple MTA's to use the SPF libraries
that look for SPF first and let time pass.

If you want a hurry on one could add code to nameservers and zone
signers to detected TXT style spf records and add SPF records if
they are missing.

> for getting new RRtypes have been improved --

The rules were dead simple at the time, just nobody in the SPF camp
was willing to try to go down that route.  I know they were simple
because I used them at the time for another type.

> I think we all agree on that

The DNS had deployed support for UNKNOWN RR types at the time.  Most
resolvers have been able to lookup unknown types since RFC 1034 was
published.  For most resolvers it was simply a matter of using 99
rather than a symbolic name.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 26 Apr 2013 01:28:14 -0700

Hi Doug,
At 18:30 25-04-2013, Doug Barton wrote:
>Note, I'm going to push back on some of the things you say below, 
>but I don't want the main point I'm trying to make to get lost:
>

I'll comment below.

>There are only so many times that people can say "this is a bad 
>idea," then get ignored, and then have enthusiasm to come back and 
>say the same thing again. I didn't follow the

Ok.

>  pre-publication of 6686, as I had other things to do at the time. 
> However the volume of previous discussion over the last 8+ years 
> should have been sufficient to render the idea of deprecating the 
> SPF RRtype a non-starter. The fact that the draft got written in 
> the first place said a lot about the chances of any objections 
> being considered.

When the work started nobody knew what to do.  The following comment 
was made around a year ago:

   "the IESG would simply like to see the SPF *and* Sender-ID 
experiments wrapped
    up, and presumes that the charter is correct and the outcome of 
the experiment
    leads one to conclude that SPF should get advanced to Proposed Standard and
    Sender-ID should not".

In easy terms, it would be good to have a conclusion to those 
experiments.  There was an assumption, i.e. SPF would get 
advanced.  My guess (not technically sound) was that there was a 
higher chance of that happening (e.g. see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00355.html 
).  There is a short discussion predating Issue #9 
(see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00329.html 
).  Philip Gladstone provided some data (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00354.html 
).  Issue #9 was opened based on the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00361.html 
draft-kucherawy-spfbis-experiment was posted after that (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00405.html 
).  There were comments mentioning the ietf@ discussion ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00789.html ).

Anyway, the working group decision about the protocol aspect was made 
based on the analysis.  The question of whether to obsolete the SPF 
RRTYPE or not is an administrative issue.  That is why it is in the 
IANA Considerations Section of draft-ietf-spfbis-4408bis-14.  I am ok 
with whatever the IETF decides about that.

There are several intermingled issues.  If I understood correctly the 
main issue is which DNS RR to use to publish SPF information in the 
DNS.  I suggest discussing about that during the Last Call for 
draft-ietf-spfbis-4408bis.

>I have to respectfully point out that a) there is a wider world 
>beyond spfbis, and b) the reasoned technical arguments that were 
>presented on the list (not to mention the running code) should have 
>been sufficient to push the group in the direction of preferring the 
>SPF RRtype with an eye toward deprecating TXT in the future.

I am aware of that. :-)  There isn't much I can do about it.  My task 
was to give due consideration to all the arguments that were 
presented on this mailing list.  Technical arguments are obviously 
more compelling.

If there are any new arguments which have been missed please let me 
know as I can include them in my write-up.  If the argument is solely 
"do the right thing" I will decline including it in the write-up as 
it is, in my individual opinion, non-technical.  I cannot comment on 
what arguments should be provided as I will then be biasing the outcome.

Regards,
S. Moonesamy

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 13:41:33 +0000

[This is really long, because I've spent a lot of time thinking about this and reading the discussion; the tl;dr is that I don't intend to contest the obsoleting of the SPF RRtype any further, but <ad hat off>would not fault others for doing so</>, and <ad hat on>I think there are lessons to be learned about how the process went this time</>, which, if you are interested in that, might be a good reason to continue reading.]

On Apr 25, 2013, at 8:22 PM, S Moonesamy <[email-masked]> wrote:
> I am ok if anyone says that it a bad decision.  The thread for the discussion started at http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html

<no hat>

I undertook the exercise of reading this thread, and it looks like there was some very interesting data collection work done.   I didn't find a point at which a consensus was determined; I presume that happened later, on some other thread.

> I was the document shepherd for RFC 6686.  There wasn't any comments during the Last Call.

FWIW, and I do not intend this as a criticism of what you did, I just went back to the datatracker and looked at the text of the IETF last call.   There is nothing at all in this text that would indicate that the document said anything at all about the continued use of the SPF DNS RRtype.   I've also read the document, and even reading the conclusion of the document, there's very little there that would suggest to me that the spfbis working group was about to deprecate the use of the SPF DNS RRtype.

Of course someone who was already involved in the discussion on the mailing list would know this, but there's no reason to think that anyone reading the dnsext mailing list would have felt it was their duty to review this particular document during the IETF last call, and if they had reviewed it, they might still have remained innocent of any understanding that spfbis intended to deprecate the SPF RRtype in favor of the TXT record.

> If there are any new arguments which have been missed please let me know as I can include them in my write-up.  If the argument is solely "do the right thing" I will decline including it in the write-up as it is, in my individual opinion, non-technical.  I cannot comment on what arguments should be provided as I will then be biasing the outcome.

<still no hat>
It seems to me that the argument in favor of deprecating SPF is that nobody is publishing SPF records, despite widespread support in software.   This results in unnecessary traffic, the elimination of which would have minimal impact.

On the other side, here are the arguments that I understand to have been made:

1. TXT records are not specific to SPF, thus we can't assume that any given TXT record is an SPF record.
Rejoinder: doesn't seem to be an issue in practice—no other TXT records are needed on the names to which SPF TXT records are typically attached.

2. Because TXT records aren't specific to SPF, a query for TXT records may return an unexpectedly large result set, requiring fallback to TCP.
Rejoinder: doesn't seem to be an issue in practice.

3. Using TXT records is a bad idea.
Rejoinder: this isn't really a technical argument; if there is a technical argument in here, it should be stated explicitly, but this argument per se will be ignored.

4. Using TXT records sets a bad precedent.
Rejoinder: the horse is already out of the barn.

I think there's one possible benefit to be considered for using TXT records for SPF: it gets in the way of other uses of TXT records, and acts as a sound technical argument against adoption of TXT records on bare names in future protocols.

Speaking entirely with my AD hat off, and merely as an armchair quarterback, I don't think it's fair to say that the consensus call in spfbis on what was to become RFC6686 and the IETF consensus call on that document, taken together, represent IETF consensus.   I don't think the rejoinders to arguments 1 and 2 are very convincing, although they seem to have carried the day in the spfbis working group, and I understand why.

The reason I reacted the way I did when drc brought this up is that it was a surprise to me that spfbis was eliminating the SPF record from the specification.   It is not surprising that it was a surprise—the process that was followed, which I think was followed correctly and with the best intentions, did not really have much chance of bringing this decision to my attention while it was being discussed in spfbis.

Having reviewed the discussion in spfbis, and argued with this at length with Pete, I am remarkably ambivalent about it.   I don't like the decision the spfbis working group has made.  I don't agree with the decision.  I understand why you made it, and don't fault you for having made it.   It's probably not worth my personal time to dispute it.

I would rather work to hasten the demise of SMTP and all the anti-spam kludges that rode in on it.

<ad hat on>
So, what do I think could have gone better here?   First, it would have been very helpful if the abstract for RFC 6686 had said that the reason the research was being done was to answer the question "should we continue supporting the SPF RRtype, or drop it?"   Authors of drafts that are trying to address issues like this might want to think carefully about how they write abstracts, since it's only the abstract that gets shown in the IETF last call message.   If your abstract doesn't attract the people who ought to be reading the document, it's going to be hard later to argue that the document had a clear IETF consensus, even though it nominally has consensus.

It may be that using the document abstract in the last call announcement is not sufficient—if authors phrased the abstract the way I've suggested, it might be the wrong thing for the document once it's published.   I don't know the answer to this—it might also be the right thing.

I think it's clear that early in this discussion, all present, including the responsible AD, were aware that it was going to be contentious.   I think if a message like the one drc sent to the mailing list yesterday had gone out in February of 2012, you would have gotten the exact same response.   This probably would have created additional hassle on the spfbis mailing list as a bunch of dnsext people dogpiled there, but we wouldn't be having _this_ conversation _now_, so it actually would have been better, despite the short-term hassle.

Andrew did raise this issue to the dnsop working group; he didn't mention raising it on dnsext.   I don't remember seeing it on the dnsop mailing list, and I'm not finding it in the archive; I don't see it in the minutes either.   This doesn't mean it isn't there; it just means that it didn't stand out the way drc's message did.   This ought to be a valuable lesson for working group chairs; if you know something is going to be contentious, rip the bandaid off—don't be quiet about it.   Make sure the people who you know are going to kick up a fuss do it at the right time.   I know Andrew didn't intend to not rip off this bandaid, so I'm not sure how this failed to happen, but it's something to think about.

The responsible AD also knew this was going to be contentious (I think!).   I don't know if he talked this over with Ralph (who was then the responsible AD for dnsext) or not.   If he did, that was the right thing to do, and it's worth considering why it didn't work.   If he didn't, this might be a lesson to remember for the future.   Same thing should have happened with the responsible AD for dnsop; I don't know who that was.

Of course, ADs don't always know that what's being raised in the working group is going to be contentious in other areas.   Working group chairs need to be proactive about this.   ADs can definitely be a resource in spreading the word, though, whether they do it on their own or at the request of working group chairs.   And of course working group chairs may not always know that something will be contentious, but there's nothing we can do about that case other than live with the late surprise.
</hat>

I hasten to emphasize that I don't really know what went wrong here.   It may be that even if all the remedies I've discussed above had happened, we'd still be having a big kerfuffle about this on the dnsext mailing list.   My motivation for suggesting that more could have been done is simply my experience as a participant: I really think I would have participated in the discussion about this if I'd realized it was happening last February.  I get the impression from several other participants in the discussion now that they weren't aware of it either.   I don't have a sense of whether the discussion would have come out differently if we'd participated.

<hat>
As for how to participate now, the right thing to do for people who feel they were left out of the discussion before is to read the draft, read the historical discussion (to which pointers have already been given) and then participate constructively on the spfbis working group mailing list.

"Tromping" on this in IETF last call would not be constructive given that it has not passed a working group last call.  I'm sorry for having suggested that—I understood the document to have already passed WGLC, and stupidly didn't go check to see if my impression was correct.
</hat>

And, by the way, internet dating is quite a lucrative industry, so it's probably a bad example of a hopeless task.   :)

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 14:00:58 +0000

> Speaking entirely with my AD hat off, and merely as an armchair quarterback, I don't think it's fair to say that the consensus call in spfbis on what was to become RFC6686 and the IETF consensus ca…

Argh.   I can't say anything right, apparently.   What I mean here is that the consensus call in the working group and the subsequent consensus call on the IETF mailing list do not mean that the IETF definitely has consensus to deprecate the SPF RRtype.   They do mean that the IETF had consensus to publish the document.   Sorry for putting that so badly.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 26 Apr 2013 07:52:29 -0700

On Fri, Apr 26, 2013 at 6:41 AM, Ted Lemon <[email-masked]> wrote:

> FWIW, and I do not intend this as a criticism of what you did, I just went
> back to the datatracker and looked at the text of the IETF last call.
> There is nothing at all in this text that would indicate that the document
> said anything at all about the continued use of the SPF DNS RRtype.   I've
> also read the document, and even reading the conclusion of the document,
> there's very little there that would suggest to me that the spfbis working
> group was about to deprecate the use of the SPF DNS RRtype.
>

RFC6686 never set out to make a conclusion about the RRtype question, but
rather to determine which of the four protocols MARID discussed appear to
have enough traction to warrant advancement along the standards track, thus
concluding "the experiment".  Accordingly, the abstract for that document
doesn't say anything about this matter.

In the process of collecting data to answer that question, we realized that
the numbers also highlight the non-use of type 99 by both senders and
receivers.  We were very careful in our wording of RFC6686 to point out
that type 99, though supported both in protocol and software, is actually
not very useful, and said nothing at all about what we planned to do with
it.  RFC6686 provides supporting evidence for what the main spfbis draft is
doing, but does not itself introduce those actions.

I don't think there was process breakage here.

>
> It seems to me that the argument in favor of deprecating SPF is that
> nobody is publishing SPF records, despite widespread support in software.
> This results in unnecessary traffic, the elimination of which would have
> minimal impact.
>

That's not the complete argument I and others have been making.  Widespread
support in DNS software and SPF libraries exists, but there are also
existing components of the infrastructure that interfere with either
publication or handling of type 99 queries and replies, long after the type
was assigned.  RFC6686 calls this out.  The rejoinder we're hearing to this
is merely the gainsay of that position despite both anecdotal and empirical
evidence to the contrary.

On the other side, here are the arguments that I understand to have been
> made:
> Rejoinder: doesn't seem to be an issue in practice—no other TXT records
> are needed on the names to which SPF TXT records are typically attached.
>

Moreover, parsing TXT records is not hard, nor is answering the question
"Does this one start with the string 'v=spf1'?".  We saw one case in our
survey of a zone that had 37 TXT records at the same query point; SPF code
is able to pull out the applicable one just fine.

>
> 2. Because TXT records aren't specific to SPF, a query for TXT records may
> return an unexpectedly large result set, requiring fallback to TCP.

That's not correct; there are still packet filters out there configured by
default to disallow TCP over port 53.  We discovered this during the
RFC6686 surveys.

-MSK

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 26 Apr 2013 08:02:58 -0700

On Apr 26, 2013, at 7:52 AM, Murray S. Kucherawy <[email-masked]> wrote:
> That's not correct; there are still packet filters out there configured by default to disallow TCP over port 53.  We discovered this during the RFC6686 surveys.

This is pretty rare but not nonexistent.

If anyone cares, we have some names that test resolver->authority path for truncation, and client->resolver path for proper truncation support.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 15:13:16 +0000

On Apr 26, 2013, at 10:52 AM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:
RFC6686 never set out to make a conclusion about the RRtype question, but rather to determine which of the four protocols MARID discussed appear to have enough traction to warrant advancement along the standards track, thus concluding "the experiment".  Accordingly, the abstract for that document doesn't say anything about this matter.

In the process of collecting data to answer that question, we realized that the numbers also highlight the non-use of type 99 by both senders and receivers.  We were very careful in our wording of RFC6686 to point out that type 99, though supported both in protocol and software, is actually not very useful, and said nothing at all about what we planned to do with it.  RFC6686 provides supporting evidence for what the main spfbis draft is doing, but does not itself introduce those actions.

Okay, fair enough.   Please do note that I didn't say that there was process breakage—I said the process seemed to have been followed correctly, but produced a less than perfect outcome.

The sense in which I mean that with respect to RFC 6686 is that several people have mentioned the IETF last call on RFC 6686 as if it means that the IETF now has an opinion on whether to deprecate SPF.   It sounds like we both agree that it does not, so this wouldn't be an example of process breakage.   However, if people came to the conclusion that it did mean that, it's worth talking about.

That's not the complete argument I and others have been making.  Widespread support in DNS software and SPF libraries exists, but there are also existing components of the infrastructure that interfere with either publication or handling of type 99 queries and replies, long after the type was assigned.  RFC6686 calls this out.  The rejoinder we're hearing to this is merely the gainsay of that position despite both anecdotal and empirical evidence to the contrary.

OK.   But presumably these parts of the internet are going to start really seriously breaking as IPv6 and DNSSEC deployment increase.   So this doesn't _seem_ like a long-term concern.   What am I missing?

Moreover, parsing TXT records is not hard, nor is answering the question "Does this one start with the string 'v=spf1'?".

Sure, and a base-64 encoded string will never have an equals sign in that position, so we don't have to worry too much about a random collision.

  We saw one case in our survey of a zone that had 37 TXT records at the same query point; SPF code is able to pull out the applicable one just fine.

These two points taken together seem like a pretty strong argument in favor of _not_ deprecating the SPF record; in this case, only the SPF record would have made it back to the MTA.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 26 Apr 2013 08:16:55 -0700

> Sure, and a base-64 encoded string will never have an equals sign in that position, so we don't have to worry too much about a random collision.

Yeah, we don't.  

IF the string is random, thats a 1 in 2^36 chance.  Yawn.

And if the string is "malicious" and deliberately constructed to be a bad record starting with v=spf1, it only screws up the domain owner's SPF record, so who gives a flying fig?  The domain owner can correct it, be done with it, and move on.

> These two points taken together seem like a pretty strong argument in favor of _not_ deprecating the SPF record; in this case, only the SPF record would have made it back to the MTA.

If you want DNSSEC, you got to fix THAT problem anyway.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 15:32:00 +0000

> And if the string is "malicious" and deliberately constructed to be a bad record starting with v=spf1, it only screws up the domain owner's SPF record, so who gives a flying fig?  The domain owner…

Right.

> If you want DNSSEC, you got to fix THAT problem anyway.

This is a non-sequitur.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 26 Apr 2013 12:53:28 -0400

> FWIW, and I do not intend this as a criticism of what you did, I just went back
> to the datatracker and looked at the text of the IETF last call.   There is nothing
> at all in this text that would indicate that the document said anything at all about
> the continued use of the SPF DNS RRtype.   I've also read the document, and
> even reading the conclusion of the document, there's very little there that would
> suggest to me that the spfbis working group was about to deprecate the use of
> the SPF DNS RRtype.

As Murray's already responded, the intent of the document that became
RFC 6686 was simply to report on the SPF/Sender-ID experiment.  That
document never meant to recommend a specific course, and didn't -- so
any cross-area review of that document wouldn't have been likely to
raise this discussion, and no text in that document relating to this
issue would have been appropriate.

That said, there is a general need for chairs, shepherds, and
responsible ADs to be aware of these sorts of things.
Chairs/shepherds need to make sure something about them gets put into
shepherd writeups, at least, and ideally gets sent out to relevant
lists earlier.  Best I can tell, there *was* a discussion of this
earlier, but it didn't get this level of attention.

It would also be good for ADs to put things into the last call
notices, pointing out things that participants in other areas might
want to look at.  We don't have a habit of doing that, and we should.
Even something like, "This specification involves aspects of
[technology X] and [technology Y]; experts in those technologies
should pay particular attention and provide reviews and comments,"
might make a big difference.

> Rejoinder: doesn't seem to be an issue in practice—no other TXT records are
> needed on the names to which SPF TXT records are typically attached.

Right: the underscore-prefix technique has been vetted before, and as
far as I can tell this issue and its variants are settled.

> Rejoinder: this isn't really a technical argument; if there is a technical argument
> in here, it should be stated explicitly, but this argument per se will be ignored.

Actually, I don't agree that it's not a technical argument.  The
second part of that sentence is operative, and I want to drill down on
that: if there's a technical argument in here, let's tease out what it
is.

We really have two issues that really seem to matter here:

1. Should we be working on a transition to type=99 only, rather than
deprecating type=99?

2. Claim (quoting Måns here): overloading TXT is bad.

(1) is being adequately argued back and forth; I want to focus on (2):

Why, specifically, is it bad to use TXT records in an "_spf."
subdomain for this purpose?  What harm does it cause, specifically.
Let's bring that out clearly, and have that part of the discussion,
realizing that some possible arguments already have answers:

- It's not hard to parse these; there are many parsers out there that
work, and there are many text-based protocols that work.

- The "_spf." subdomain eliminates the issue of multi-use collisions
-- DKIM queries, for example, will go to "_dkim." subdomains, and
won't see SPF records in the responses.

What other issues does the use of TXT records in this context cause,
which would make it clear that migration away from them in SPF is
important to avoid damage to the Internet, or at least to the DNS
system?

Barry

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Apr 2013 03:08:56 +1000

In message <[email-masked]>, Barry Leiba writes:
> > FWIW, and I do not intend this as a criticism of what you did, I just wen=
> t back
> > to the datatracker and looked at the text of the IETF last call.   There =
> is nothing
> > at all in this text that would indicate that the document said anything a=
> t all about
> > the continued use of the SPF DNS RRtype.   I've also read the document, a=
> nd
> > even reading the conclusion of the document, there's very little there th=
> at would
> > suggest to me that the spfbis working group was about to deprecate the us=
> e of
> > the SPF DNS RRtype.
> 
> > On the other side, here are the arguments that I understand to have been =
> made:
> >
> > 1. TXT records are not specific to SPF, thus we can't assume that any giv=
> en TXT
> > record is an SPF record.
> >
> > Rejoinder: doesn't seem to be an issue in practice=97no other TXT records=
>  are
> > Rejoinder: this isn't really a technical argument; if there is a technica=
> l argument
> > in here, it should be stated explicitly, but this argument per se will be=
>  ignored.
> 
> 1. Should we be working on a transition to type=3D99 only, rather than
> deprecating type=3D99?
> 
> 2. Claim (quoting M=E5ns here): overloading TXT is bad.
> 

Wrong question.  The correct question is "is the use of _spf bad?".

Using a prefix constrains where the solution can be used.  It won't
work with wildcards.  It won't work for all domains.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 26 Apr 2013 10:09:49 -0700

Hi Ted,
At 06:41 26-04-2013, Ted Lemon wrote:
>[This is really long, because I've spent a lot 
>of time thinking about this and reading the 
>discussion; the tl;dr is that I don't intend to 
>contest the obsoleting of the SPF RRtype any 
>further, but <ad hat off>would not fault others 
>for doing so</>, and <ad hat on>I think there 
>are lessons to be learned about how the process 
>went this time</>, which, if you are interested 
>in that, might be a good reason to continue reading.]

I'll comment nelow.

>I undertook the exercise of reading this thread, 
>and it looks like there was some very 
>interesting data collection work done.   I 
>didn't find a point at which a consensus was 
>determined; I presume that happened later, on some other thread.

There are actually several threads about the 
issue of which RRTYPE to use.  The discussions 
also occurred on unrelated threads.  There was an 
intermediate conclusion (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00594.html 
) which was followed by an objection (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00658.html 
).  The SPFBIS WG Chairs posted a message after 
that ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00692.html 
) which I'll quote partially:

   "There appears to be a wide variety of opinion about Issue #9. Moreover,
    the discussion has revealed an 
interoperability concern in the existing RFC."

There was the IETF 83 session (see Item C in the 
minutes) after that where the SPFBIS Chairs stated the following:

   "The conclusion reached by the Chair was that the document will
    say SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99."

For what it is worth I edited the minutes by 
listening to the audio recording.  Two drafts of 
the minutes were posted to the SPFBIS mailing 
list (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01369.html 
and 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01419.html 
).  As there wasn't any objection I considered the issue as resolved.

>FWIW, and I do not intend this as a criticism of 
>what you did, I just went back to the 
>datatracker and looked at the text of the IETF 
>last call.   There is nothing at all in

Let's not worry about that and focus on understanding what happened. :-)

>  this text that would indicate that the 
> document said anything at all about the 
> continued use of the SPF DNS RRtype.   I've 
> also read the document, and even reading the 
> conclusion of the document, there's very little 
> there that would suggest to me that the spfbis 
> working group was about to deprecate the use of the SPF DNS RRtype.

Here's an extract from the write-up:

  "The discussions about the RRTYPE 99 DNS Resource Record were controversial.
   The issue was resolved.  There was consensus that Sender ID re-use of
   SPF DNS Resource Records does not have to be called out in the document."

I'll highlight one of the points from Section 6 of RFC 6686:

  "2.  The absence of significant adoption of the RRTYPE 99 DNS Resource
        Record suggests that it has not attracted enough support to be
        useful."

There is some background information about the 
RRTYPE in Appendix A of RFC 6686.

I agree that the document or even the write-up 
may not be clear.  I left it to Pete Resnick to 
translate for the IESG. :-)  I'll describe the 
working group climate as unfriendly.  It was 
surprising that was even consensus.

>Of course someone who was already involved in 
>the discussion on the mailing list would know 
>this, but there's no reason to think that anyone 
>reading the dnsext mailing list would have felt 
>it was their duty to review this particular 
>document during the IETF last call, and if they 
>had reviewed it, they might still have remained 
>innocent of any understanding that spfbis 
>intended to deprecate the SPF RRtype in favor of the TXT record.

I expected some people from DNSEXT to raise an 
issue during the Last Call.  There was some text 
in it which was like asking for trouble.  I'll 
refrain from commenting about DNSEXT reviews.

>It seems to me that the argument in favor of 
>deprecating SPF is that nobody is publishing SPF 
>records, despite widespread support in 
>software.   This results in unnecessary traffic, 
>the elimination of which would have minimal impact.

Yes.

>1. TXT records are not specific to SPF, thus we 
>can't assume that any given TXT record is an SPF record.
>Rejoinder: doesn't seem to be an issue in 
>practice—no other TXT records are needed on the 
>names to which SPF TXT records are typically attached.

Yes.

>2. Because TXT records aren't specific to SPF, a 
>query for TXT records may return an unexpectedly 
>large result set, requiring fallback to TCP.

Yes.

>Rejoinder: this isn't really a technical 
>argument; if there is a technical argument in 
>here, it should be stated explicitly, but this argument per se will be ignored.

Probably. :-)

>Rejoinder: the horse is already out of the barn.

I don't know about this one.

>Speaking entirely with my AD hat off, and merely 
>as an armchair quarterback, I don't think it's 
>fair to say that the consensus call in spfbis on 
>what was to become RFC6686 and the IETF 
>consensus call on that document, taken together, 
>represent IETF consensus.   I don't think the 
>rejoinders to arguments 1 and 2 are very 
>convincing, although they seem to have carried 
>the day in the spfbis working group, and I understand why.

It's debatable.  I would have to read the 
detailed arguments to form an opinion.

>Having reviewed the discussion in spfbis, and 
>argued with this at length with Pete, I am 
>remarkably ambivalent about it.   I don't like 
>the decision the spfbis working group has 
>made.  I don't agree with the decision.  I 
>understand why you made it, and don't fault you 
>for having made it.   It's probably not worth my personal time to dispute it.

At the end of the day a decision has to be 
taken.  It may not be the right decision.  There 
are safeguards in the process if that is the 
case.  I don't mind if anyone disputes the 
decision.  There has been an appeal (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html 
).  It's part of the work.

>I would rather work to hasten the demise of SMTP 
>and all the anti-spam kludges that rode in on it.

:-)

><ad hat on>
>So, what do I think could have gone better 
>here?   First, it would have been very helpful 
>if the abstract for RFC 6686 had said that the 
>reason the research was being done was to answer 
>the question "should we continue supporting the 
>SPF RRtype, or drop it?"   Authors of drafts 
>that are trying to address issues like this 
>might want to think carefully about how they 
>write abstracts, since it's only the abstract 
>that gets shown in the IETF last call 
>message.   If your abstract doesn't attract the 
>people who ought to be reading the document, 
>it's going to be hard later to argue that the 
>document had a clear IETF consensus, even though it nominally has consensus.

That sounds like a good idea.

>It may be that using the document abstract in 
>the last call announcement is not sufficient—if 
>authors phrased the abstract the way I've 
>suggested, it might be the wrong thing for the 
>document once it's published.   I don't know the 
>answer to this—it might also be the right thing.

In the write-up I am supposed to mention whether 
a draft requires review from a particular or from broader perspective.

>I think it's clear that early in this 
>discussion, all present, including the 
>responsible AD, were aware that it was going to 
>be contentious.   I think if a message like the 
>one drc sent to the mailing list yesterday had 
>gone out in February of 2012, you would have 
>gotten the exact same response.   This probably 
>would have created additional hassle on the 
>spfbis mailing list as a bunch of dnsext people 
>dogpiled there, but we wouldn't be having _this_ 
>conversation _now_, so it actually would have 
>been better, despite the short-term hassle.

With hindsight I'll say that it would have been good to have the discussion.

>I hasten to emphasize that I don't really know 
>what went wrong here.   It may be that even if 
>all the remedies I've discussed above had 
>happened, we'd still be having a big kerfuffle 
>about this on the dnsext mailing list.   My 
>motivation for suggesting that more could have 
>been done is simply my experience as a 
>participant: I really think I would have 
>participated in the discussion about this if I'd 
>realized it was happening last February.  I get 
>the impression from several other participants 
>in the discussion now that they weren't aware of 
>it either.   I don't have a sense of whether the 
>discussion would have come out differently if we'd participated.

The discussion would have been more 
controversial.  As a rough guess I would say that 
the Last Call did not work as expected.  Some of 
the reasons for that are mentioned in the (quoted) text above.

>And, by the way, internet dating is quite a 
>lucrative industry, so it's probably a bad example of a hopeless task.   :)

I might ask the Responsible AD to recharter this 
working group to work on that task. :-)

Regards,
S. Moonesamy

---

From: Hector Santos <[email-masked]>
Date: Fri, 26 Apr 2013 13:09:01 -0400

On 4/26/2013 9:02 AM, Scott Kitterman wrote:
>
> Since there wasn't the same screaming about DKIM, I wonder if this issue is
> really about the RR type at all or if it's really about the design decision on
> where to place the record?  It seems that SPF is not being penalized in some
> form for having gone to the trouble of getting the type assignment and giving
> it a go.
>

In my view, the DKIM decision was entirely based on the fact SPF was 
getting a huge traction and adoption as a TXT solution.  So why not for 
DKIM? It worked for SPF!

We should also note the mindset were among the same authors for 
protocols that are now entirely TXT:

    SPF    - 99/TXT, Levine against SPF, Murray wasn't around MARID
    DKIM   - TXT only, Murray authored
    VBR    - TXT only, Levine authored
    DMARK  - TXT only, and now a new I-D by Murray
    SPFBIS - TXT only, Murray started SPFBIS.

So we don't have too much "diversity" on the design.

SPF goal is still the same design goal for SPF type. The problem are the 
DNS servers. Getting Microsoft DNS servers to support unnamed RRTYPE 
processing at the very least will immediately change the course of the 
RRTYPE needs in the right direction.

Its a different problem in the same way AUTH-RES isn't ready for prime 
time with SPF - an errata is needed and people need to change their 
Received-SPF reporting.  In the mean time, in the name of across the 
board coding and single-sourcing, you support both even if the AUTH-RES 
support needs to be done with a kludge comment field.   Its the same 
with DMARC design pressures, it "works" better when MTA does the SPF 
processing at the 5322 Payload level (DATA state) or you accept the 
message then do the above tests and it may bounce or perhaps, hopefully 
not, discard:

             SPF FAIL POLICY === DKIM/ADSP DISCARD POLICY

Ideally, if we are going to stick with TXT based solutions and to better 
support integrated systems (ones that may support all of the above, it 
will be at least 4 DNS TXT queries), then we explore a direct solution 
of a single call to return all the sender information one may need 
about, including the message owner and copyright holder domain.

--
HLS

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 26 Apr 2013 20:00:52 +0200

> work with wildcards.  It won't work for all domains.

There CAN be a zone cut between the SPF record and the MX, which in turn might have impact on trust related to DNSSEC.

I have no idea on the implications, but I do not see it being examined.

   Patrik

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 18:42:06 +0000

Yes.

> realizing that some possible arguments already have answers:

I think it's mostly harmless, but it's not what 4408bis does.

---

From: Doug Barton <[email-masked]>
Date: Fri, 26 Apr 2013 12:31:37 -0700

On 04/25/2013 11:30 PM, Murray S. Kucherawy wrote:
> On Thu, Apr 25, 2013 at 11:05 PM, David Conrad <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>      > So how much energy are the DNS experts going to put into cleaning
>     up their house while demanding the mail people clean up theirs?
>

Uncharitable interpretation of the current situation could come to that 
conclusion.

> No, what I'm saying is that the way things were ten years ago

As I (and others) have said many times, things were rough at the time 
SPF came to bloom. However, and this is really important to understand, 
it's not 10 years ago anymore.

I'm not being petty when I say that. It really is important to 
understand, the time is going to pass anyway. In the time period between 
then and now a LOT of things have happened in the DNS world, and the 
situation is dramatically different now than it was.

What is even more important to understand is that 10 years from now 10 
more years will have passed. We have a chance now to set in motion 
events that will continue to improve the situation, so that 10 years 
from now we can look back and laugh at the SPF TXT record, and have joy 
that things are so much better. Or, we can spend 10 more years with the 
same silly kludge, and not have made any progress at all. Either way, 
the next 10 years are going to pass.

> pushed the
> interim, has become very widely deployed.

And some of the software that handles SPF has already switched to 
querying SPF/99 first. There is no reason that the rest could not do 
that as well. Then by the time that the next version of SPF is released, 
it can be all SPF/99, and no TXT. Eventually the TXT record will die out 
altogether.

As I have mentioned previously, in the DNS world we have a LOT of 
experience dealing with issues EXACTLY like this. We know how it works, 
we know what long tails look like, and we know that as problems go it's 
a pretty easy problem to deal with.

> Suddenly now we have a few
> voices from the ivory tower asserting that the same community needs to
> go out and re-do things the way they should have been done in the first
> place, now that we finally have a somewhat more reasonable perspective,
> even though some of the vestiges of ten years ago are in fact still
> around.  My reaction to that is "You can't be serious."  That doesn't
> sound like revenge at all to me, just pragmatism.

Um, it's not "suddenly." The advice to do it right in the first place 
has been offered repeatedly, since the very beginning. That's why the 
code point was assigned in the first place.

There is no doubt that in the early days, prior to the widespread 
deployment of 3597, querying for SPF/99 could cause problems. But we're 
not in that world anymore. Thank DNSSEC and IPv6 for shaking things 
loose. There is currently no TECHNICAL reason that the change cannot be 
made NOW to query SPF/99 first. The only argument you (and others) have 
put forward so far is, "We have been using TXT, it works, so we want to 
keep using it." I understand why that course of action is attractive, 
but it's bad. And the right thing isn't hard to do.

>     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.
>
> about things like IAB advice about how [not] to put application data
> into the DNS.  Seems to me this is a perfectly good subject for another
> such project.  One may counter that by saying nobody will pay attention
> to such a document, but I submit that it's our primary mechanism for
> making sure mistakes aren't re-made, so that's the tool we have to use
> or not use.

But this mistake isn't carved in stone. It CAN be fixed. And the 
solution isn't difficult. Some minor changes are made to software, some 
docs are updated, and then time passes and the old way becomes obsolete.

> If we do the opposite and somehow compel SPFBIS to favour type 99 over
> TXT, then I still think we'll be shouting that to an audience that will
> think we're nuts and simply go about their business.

If that happens (and I personally don't think it will), it's not the 
IETF's problem. We don't (traditionally) write specs to accommodate the 
worst behavior we see in implementations. We write specs to describe how 
it should be done right, and do our best to support people who want to 
write software that does it right.

And I should emphasize again, "Mail::SPF (which is used by Spamassassin) 
checks for Type SPF first by default." So there is already a non-trivial 
implementation that is doing it right. The number of other 
implementations that need to be updated is not very large. Another case 
mentioned in the spfbis thread on "issue #9" was the python lib for spf, 
which already has the code to query SPF/99. It would be a 30 minute job 
to update that to query 99 first.

So if I'm missing some TECHNICAL reasons why this proposal isn't 
feasible, please enlighten me. But all I've seen so far is, "We don't 
want to do it," which I don't find particularly compelling.

Doug

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Apr 2013 13:43:51 -0700

> Is the annotation in the DNS Parameters registry correct?

Dear DNSEXT,

For all of the really interesting side discussions that have developed 
since SM sent this initial query, I believe there have not been any 
responses that answered the question that was asked.

DNSEXT was asked to provide expert review of this specific bit of text. 
  The text is intended to be comparable to the way that some other, 
similar situations have already been handled.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: David Conrad <[email-masked]>
Date: Fri, 26 Apr 2013 15:55:01 -0500

Dave,

As I pointed out to Paul Hoffman, the message I sent that I believe started this thread said:

Regards,
-drc

On Apr 26, 2013, at 3:43 PM, Dave Crocker <[email-masked]> wrote:

> For all of the really interesting side discussions that have developed since SM sent this initial query, I believe there have not been any responses that answered the question that was asked.
> 
> DNSEXT was asked to provide expert review of this specific bit of text.  The text is intended to be comparable to the way that some other, similar situations have already been handled.
> 
> d/
> -- 
> Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Apr 2013 14:03:52 -0700

On 4/26/2013 1:55 PM, David Conrad wrote:
> "It is in keeping with past practice, e.g., see the notations for MD,

ahh.  right.  thanks!

d/

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2013 21:49:56 -0000

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

This may come as a surprise, but this isn't all about you.  

The spfbis group is cleaning up a protocol that is in use at hundreds
of thousands of mail systems all over the world including most,
probably all, of the largest ones.  For all its warts, SPF works fine
as is, and they have no incentive to change.  Hence the narrow charter
of the group only to clean up the existing spec, not to extend or
change it.

I go to a industry meetings like MAAWG with all of the large mail
operators, and I can assure you that if the IETF were so silly as to
publish an spfbis that demanded a switch to type 99, the large mail
systems would say, wow, that was dumb, I guess we'll be looking for
mail standards somewhere else.

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

Provide the tools and processes so that people can use new RRTYPEs in
new designs.  (Insert usual point about provisioning.)

Don't shoot yourself in the foot by demanding that we break one that's
a decade old and likely in wider use than 95% of all of the other IETF
protocols.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 26 Apr 2013 14:58:59 -0700

On Fri, Apr 26, 2013 at 12:31 PM, Doug Barton <[email-masked]> wrote:

> As I (and others) have said many times, things were rough at the time SPF
> came to bloom. However, and this is really important to understand, it's
> not 10 years ago anymore.
>

I am keenly aware of the date.  What I am also keenly aware of, as I (and
others) have said many times, is that SPF set off in a specific direction
based on the situation ten years ago and has continued in that direction
all this time.  Now, with the situation "at home"
largely-but-not-completely improved, there are a few people now exclaiming
that it went in the wrong direction, and that needs to be fixed.

It's very easy to make that assertion when one ignores questions of
momentum and inertia.

I'm not being petty when I say that. It really is important to understand,
> the time is going to pass anyway. In the time period between then and now a
> LOT of things have happened in the DNS world, and the situation is
> dramatically different now than it was.
>

Nobody's arguing that point.

> more years will have passed. We have a chance now to set in motion events
> that will continue to improve the situation, so that 10 years from now we
> can look back and laugh at the SPF TXT record, and have joy that things are
> so much better. Or, we can spend 10 more years with the same silly kludge,
> and not have made any progress at all. Either way, the next 10 years are
> going to pass.

Sure.  Is that a good use of engineering resources?  This is where we
appear to differ.  I claim, given current data, that it is not.

>
> And some of the software that handles SPF has already switched to querying
> SPF/99 first. There is no reason that the rest could not do that as well.

I agree with the first sentence, but not the second.

> experience dealing with issues EXACTLY like this. We know how it works, we
> know what long tails look like, and we know that as problems go it's a
> pretty easy problem to deal with.
>

This situation touches more than just DNS code.  You appear to be convinced
that the path to overcoming inertia in the DNS world is the same, or maybe
even harder, than it is in other environments like email.  I am not a
believer.

>
> Um, it's not "suddenly." The advice to do it right in the first place has
> been offered repeatedly, since the very beginning. That's why the code
> point was assigned in the first place.
>

Um, it is "suddenly", or have you a copy of the spfbis archive that's
different from the one I have?

> deployment of 3597, querying for SPF/99 could cause problems. But we're not
> in that world anymore. Thank DNSSEC and IPv6 for shaking things loose.
> There is currently no TECHNICAL reason that the change cannot be made NOW
> to query SPF/99 first. The only argument you (and others) have put forward
> so far is, "We have been using TXT, it works, so we want to keep using it."
> I understand why that course of action is attractive, but it's bad. And the
> right thing isn't hard to do.
>

I'm sorry, but that is not the only argument I (and others) have put
forward so far.  If this conversation is going to be selective in that
manner, then I think I'm done here.

-MSK

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Apr 2013 08:45:53 +1000

> a decade old and likely in wider use than 95% of all of the other IETF
 
As far as I can see no one is asking anyone to break SPF.  All they
are asking is to let it continue down the path towards all type
SPF.  The DNS people know that will take years before people will
feel comfortable with using SPF only.  MX only domains took years
as well before people were confident to use them.

Instead of going for deprecation ask nameserver vendors to add
automatic insertion of type SPF if there is no SPF RRset (SHOULD
level).  This will help sites that are unintentionally breaking the
SHOULD publish both records.

Note most of the sites that described how to do SPF failed to mention
that you are supposed to publish both which where generally written
by people trying to promote SPF.

e.g.
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

That includes sites written by people in the SPF working group who
should have known better.

When every example is a single TXT record it is hardly suprising
that type SPF was not being published often.

Conspiracy theorists would say that it was a deliberate attempt to
undermine type SPF.

---

From: Noel David Torres Taño <[email-masked]>
Date: Sat, 27 Apr 2013 02:43:40 +0100

> It's very easy to make that assertion when one ignores questions of
I'm physicist, so I understand momentum and inertia quite well. I thus can 
assure you that even the minimal force can stop and revert even the fastest 
movement of the heaviest celestial body. It's just a matter of how much time 
you apply that force.

Here, the momentum and inertia are the deployed base of TXT spf records. Most 
of them being v1, but the small force of spf 2 changed that movement and the 
body curved the trajectory from "use TXT v1" to "use TXT v1 and 2". Now, if we 
recommend SPF over TXT for spf (that's the minimal force) and give enought 
time, we'll see how TXT loses positions from almost unique to dominant, then 
to majority, then to coexistent, then to minority, then to historic, then to 
almost unused. It is just a matter of time, and if we start today better than 
tomorrow, well gain the same 1 day at the end of the process.

Physics is so simple!

Of course, greater forces like deprecating TXT too early can broke things, in 
the same way you can receive an egg with your hands (small force) but you'll 
break it if your receive it with a hockey stick.

So I suggest we do the right thing, which is not deprecating TXT, but exerting 
the small force: recommending SPF over TXT, and increasing slowly the force of 
the recommendation through SPF 3, 4 and so on.

Of course, it may be that we'll never reach SPF 4, but it can also be that an 
asteroid impacts us before IPv6 gets deployed completely, and we work towards 
that as well.
> > the time is going to pass anyway. In the time period between then and now
> > a LOT of things have happened in the DNS world, and the situation is

Better if is is not dramatical ;)
> > can look back and laugh at the SPF TXT record, and have joy that things
> > are so much better. Or, we can spend 10 more years with the same silly
> > kludge, and not have made any progress at all. Either way, the next 10
> > years are going to pass.
> 

Reality is addict to do bad use of resources. The amount of engineering used 
to clone Minix just to make it free was (with then-current data) a complete 
waste, but The Universe (whatever that means) converted that waste of 
engineering resources into modern linux.
> > that as well.

I do not believe, I know. There is nothing that can not be moved. Moreover, 
there is nothing that can not be moved with the minimal force over its current 
friction limit. We just need to pass that limit. The friction, in this case, 
is those Windows and Providers unwilling to change. As the novel Momo teaches, 
they should be moved the last, once the remainder of the "society" is working 
the way you want. Do not try to "speak with Momo" too early.

Regards

Noel Torres
er Envite

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Apr 2013 13:24:48 -0700

Dear DNSEXT,

d/

---

From: Hector Santos <[email-masked]>
Date: Thu, 25 Apr 2013 13:52:34 -0400

In my view, since I was the one who posted and asked questions about 
this very issue in IETF and DNSOP to get a feel about the unnamed RRTYPE 
and rfc3597 "Handling of Unknown DNS Resource Record (RR) Types", the 
current status quo, nine years later, what most preferred, I don't 
believe there was a consensus when you include the inputs from the other 
list to just stay with TXT. My concern was whether an RFC will be 
"sanctioned" as a proposed standard for what most experts believe, 
including myself, is a KLUDGE solution and not ideal in large scale and 
worst as more and more protocols are written using a TXT only solutions, 
its all limited.

What I felt is that some were some key folks who were now more accepting 
of a TXT based record and possibly because DNS servers have failed to 
keep up with this need (support RFC3597 or something like it).  That was 
the expectation in my view and we expected a long term migration to 
occur too.

I would support keeping the RRTYPE. I believe it is be less of a cost 
issue - implementators don't have to "UPGRADE/KEEP UP" to BIS by 
removing RRTYPE overhead.   By making it obsolete, you automatically 
make all SPF implementators "out of date."

Anyway, I am not too sure if everyone will like this outside the SPF BIS 
group. I didn't get that feel. Only a selective few (key cogs) that are 
part of this work has began to show an acceptance to it.  So if that 
matters, what is what I was trying to feel in IETF and DNSOP - who else 
agreed with that from an endorsement standpoint.

--
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 11:09:17 -0400

> default to disallow TCP over port 53.  We discovered this during the

And, in the event a domain needs enough other TXT data that an SPF record 
would cause it to spill over into TCP, it's trivially solvable.  For 
example.com:

example.com.     3600    IN      TXT     "v=spf1 redirect=_spf.example.com"
_spf.example.com. 3600   IN      TXT     "v=spf1 [record content] -all"

It needn't ever be more impact than that.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 17:58:02 -0400

Thanks.  Having looked at that, I think that the text in the original question 
from sm is OK (modulo we don't redesign things - please keep that in a 
different subthread).

Scott K

On Friday, April 26, 2013 03:55:01 PM David Conrad wrote:
> "It is in keeping with past practice, e.g., see the notations for MD, MF,
> A6, and the MAILA RRtypes at
> http://www.iana.org/assignments/dns-parameters/dns-parameters.xml."
> 
> Regards,
> -drc
> 
> > The text is intended to be comparable to the way that some other, similar
> > situations have already been handled.
> > 
> > d/
>

---

From: Hector Santos <[email-masked]>
Date: Sun, 28 Apr 2013 09:48:33 -0400

I would like to suggest before eliminating (deprecating) SPF RRTYPE, in 
SPFBIS, the SPFBIS/DNS key cogs find out from the DNS vendors (or 
whoever manages/codes the main infrastructure DNS servers) why they are 
not supporting unnamed type processing?  Are they even aware of this 
need?  I believe BIND supports it, but not Microsoft DNS server.  How 
about others?  Are they all/mostly based on Bind source code?

I tried to find out last March 2012 in the Microsoft Windows Server Tech 
Forum [1] if Microsoft DNS v5.0 supported RFC3597 [2] or unnamed type 
processing, and it wasn't known or I just didn't reach the right folks. 
It was surprising that not even Ace Fakey was not aware of this need.

--
HLS

[1] 
http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/5841e884-db22-42a1-8530-615a375662cc/

[2] http://tools.ietf.org/html/rfc3597

On 4/28/2013 9:07 AM, Hector Santos wrote:
> But this isn't a complex problem. It is a simple solution.  The goal is
> for the docs to described what DEVELOPERS need to do, or should do, to
> prepare for the "Future."
>
> o Select method of SPF lookups
>     (_) SPF RRTYPE only
>     (*) TXT RRTYPE only
>     (_) BOTH (SPF/TXT)
>
> Protocol Options are always part of the design game.
>
> The only real problem, is that we currently do not have any control over
> this future (DNS Servers supporting unnamed type processing).  There is
> seriously a lack of communications going on. Where are these DNS
> vendors? Who are the key folks who have some "control" over this future?
>
>
> On 4/28/2013 8:18 AM, Andrew Sullivan wrote:
>> No hat.
>>
>> On Sat, Apr 27, 2013 at 10:29:40PM -0400, Stuart Gathman wrote:
>>
>>> I will be implementing this myself in the next week or so.  Should
>>> be very simple.
>>
>> I believe it was Mencken who said, "For every complex problem there is
>> an answer that is clear, simple, and wrong."
>>
>> Best,
>>
>> A
>>
>

---

From: David Conrad <[email-masked]>
Date: Sun, 28 Apr 2013 18:57:58 -0500

[Apologies for delays, travel distractions]

John,

> This may come as a surprise, but this isn't all about you.  

Damn.  Burst my bubble.  But I'd note that this isn't all about you or the other participants of SPFBIS either. It's actually about the future.

> For all its warts, SPF works fine

Err, SPFBIS _does_ change the spec.  It is proposing to deprecate the RR specifically created for SPF and state that compliant implementations only use TXT.

> new designs.  (Insert usual point about provisioning.)

While I know you'd like to use this to drive dnsextlang (something I support), given the SPF RR semantics are identical to TXT RRs and the complexity associated with implementing (minimal) support for SPF is changing code to emit "99" instead of "16", I have a bit of skepticism that better tools/processes are actually the driving force here.

> a decade old and likely in wider use than 95% of all of the other IETF

Strawman. Can you point to any message "demanding that we break" _anything_? Similarly, can you point to anyone who claims using TXT is the best choice as opposed to the pragmatic choice?  What I believe people (including myself) are saying is that the abandonment of a migration away from TXT is simply the wrong way to go and that a better approach would be to continue to encourage migration to SPF (with backwards compatibility, of course), even if it will take time. 

In any event, DNSEXT is the wrong venue to discuss the SPFBIS strategy. I suppose the right course of action is to write up a draft entitled "TXT Considered Harmful" or somesuch.

Regards,
-drc

---

From: "John R Levine" <[email-masked]>
Date: 28 Apr 2013 20:34:00 -0400

> Strawman. Can you point to any message "demanding that we break" _anything_?

Yes.  Read the spfbis list archives for details.

> Similarly, can you point to anyone who claims using TXT is 
>the best choice as opposed to the pragmatic choice?

No.  But engineers make pragmatic choices.

Regards,

---

From: Doug Barton <[email-masked]>
Date: Sun, 28 Apr 2013 17:52:16 -0700

> Yes.  Read the spfbis list archives for details.

I did, and didn't find anything that said that changing to querying SPF 
first would break anything _now_. If you're going to make the argument 
that it does, be explicit. The fact that at various times in the past, 
especially pre-3597, there were problems doesn't factor in.

>> Similarly, can you point to anyone who claims using TXT is the best
>> choice as opposed to the pragmatic choice?
>

And in this case doing the right thing is easy, so absent any concrete 
reasons not to ...

Doug

---

From: "John Levine" <[email-masked]>
Date: 29 Apr 2013 01:32:05 -0000

>first would break anything _now_.

It's there, read it again.

R's,
John

---

From: Doug Barton <[email-masked]>
Date: Sun, 28 Apr 2013 18:34:14 -0700

> It's there, read it again.

Sorry, I've spent way too much time on this already, and I've given a 
thorough analysis of what I did and didn't find in the archives. If you 
have an argument to make, make it. If not, admit that you're just not 
willing to do the work necessary to make the change.

Doug

---

From: Havard Eidnes <[email-masked]>
Date: Mon, 29 Apr 2013 13:46:58 +0200 (CEST)

> [...] I suppose the right course of action is to write up a
> draft entitled "TXT Considered Harmful" or somesuch.

Isn't that what RFC 5507 is all about?  Quoting from the
conclusion part:

  Given the various issues described in this note, we believe that:

   o  there is no magic solution that allows a completely painless
      addition of new data to the DNS, but

   o  on the whole, the best solution is still to use the DNS Resource
      Record Type mechanism designed for precisely this purpose,
      whenever possible, and

   o  of all the alternate solutions, the "obvious" approach of using
      TXT Resource Records for arbitrary names is almost certainly the
      worst, especially for the two reasons outlined above (lack of
      semantics and its implementations, and size leading to the need to
      use TCP).

which seems pretty clear-cut to me.

Regards,

- Håvard

---

From: Edward Lewis <[email-masked]>
Date: Mon, 29 Apr 2013 10:49:32 -0400

On Apr 25, 2013, at 0:37, David Conrad wrote:
> 
> Actually, I'm more intrigued as to the view of the folks on DNSEXT on this issue.

I'm tired of hearing about it.

The only concern is that pushing more data into TXT records is that, if more than one application does this and involves the same name, we are increasing the number of large RRsets pushed around.  Why this is only tiring and not a really big problem is - we have other large RRsets already and it takes a name and application collision.  One application using TXT instead of BLAH makes no difference.  The number of bytes is the same.  Only when BLAH and URGH combine themselves into *a* TXT is there bloat (for both applications).  And bloat is only a problem in the general sense when reflection/amplification is an issue.

It's not so much a DNS *protocol/architectural" or "operations* issue.  It's more of a matter for applications (to avoid bloat) and for anti-abuse techniques (to avoid amplification).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: Jim Reid <[email-masked]>
Date: Mon, 29 Apr 2013 16:19:21 +0100

On 29 Apr 2013, at 15:49, Edward Lewis <[email-masked]> wrote:

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

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

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

---

From: David Conrad <[email-masked]>
Date: Mon, 29 Apr 2013 20:22:27 -0700

Ed,

> I'm tired of hearing about it.

Sorry to hear that.

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

Well, no. That's not the only concern:

1) it moves the mechanism to uniquify a DNS response out of the DNS library and into the application, forcing every protocol-specific library or application to have to deal with uniquifying the response in their own unique (and undoubtedly in some cases fascinating) way;

2) given individual RR order within an RRset is not guaranteed, it significantly complicates TXT RDATA parsing logic for any application that cares about TXT RRs;

3) It means you've reduced the amount of usable space in the RDATA since you have to have some unique string in the RDATA to key off of; and

4) because other protocols may use TXT at the same (unfortunately common) ownername, it becomes more probable that the size of the response will go over the 512 limit resulting in fragmentation or fallback to TCP increases, which imposes potential load and reachability issues, not just for SPF but for any other protocol that is using TXT at that ownername

> It's not so much a DNS *protocol/architectural" or "operations* issue.  It's more of a matter for applications (to avoid bloat) and for anti-abuse techniques (to avoid amplification).

While I agree that bloat/amplification is an issue, SPFBIS's decision impacts any future protocol that might use TXT at the same ownername as SPF.  The implication to DNSEXT is obviously that we should discourage TXT at the same ownernames as SPF uses (if not generally), but I figure that's already sort of been done. Unfortunately, I suspect "pragmatists" won't listen to such advice and then you get all of the above fun.

That's why I said "I personally believe deprecating the SPF RR is the wrong way to go".

Regards,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 30 Apr 2013 06:42:26 +0200

> 4) because other protocols may use TXT at the same (unfortunately common) ownername, it becomes more probable that the size of the response will go over the 512 limit resulting in fragmentation or…

As I have written before:

5) As multiple different usages of RR in DNS use the same owner and class, separation of the records in the query/response must be done via prefix on the owner. This implies multiple records can end up on different sides of a zone cut where a DNSSEC administrative boundary is located. For example, the MX might be signed, but the TXT for the same domain, but with a prefix, might be unsigned. The security implications of such differences in DNSSEC implications (key rollower etc) has not been investigated. I believe it is a weakness, or rather, it is a strength that all records that are "similar" can have the same owner and because of that be in the same zone.

It was not a coincidence I took the initiative to write RFC 5507. I am _really_ concerned over use of TXT the way it is done by the SPF "solution".

   Patrik