Subject: [dnsext] SPF - case study for process fail or...?

From: Shane Kerr <[email-masked]>
Date: Fri, 7 Sep 2012 11:30:56 +0200

All,

Someone pointed out on another mailing list that the SPF RR type is
being deprecated. I checked it out, and sure enough, RFC 4408-bis
requires TXT records, and recommends not including the SPF RR type.

The rationale is in RFC 6686:

http://tools.ietf.org/html/rfc6686#appendix-A

I can't see any real answer to the concerns about firewalls and other
software.

--
Shane

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 7 Sep 2012 11:46:19 +0200

> I can't see any real answer to the concerns about firewalls and other

If we can not deploy new things, together with people giving up like this, is not a very positive view of the future.

   Patrik

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 7 Sep 2012 05:23:40 -0700

> I can't see any real answer to the concerns about firewalls and other

There are many obstacles for DNSSEC and other DNS enhancements.  Firewalls blocking novel RRTYPEs (without, eg, blocking DNSSEC in general) is generally not one of them, or way way way down in the list.

The server side does have a fault, not making it easy to SPECIFY novel types, but once a novel type is queried for, it tends to work reliably through the whole path to the client.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 7 Sep 2012 10:28:45 -0400

> If we can not deploy new things, together with people giving up like this, is not a very positive view of the future.

Maybe.

I'm co-chair of SPFBIS, and I wasn't able to marshal good arguments
for keeping the RRTYPE.  But I note that there's something special
about this case: the original protocol offered _two_ ways to achieve
the functionality.  It used both TXT and SPF.

This actually created an interoperation issue.  Those publishing an
SPF record could use TXT or SPF or both.  Those looking up an SPF
record could ask for TXT or SPF or both.  The arragement in RFC 4408,
then, makes it possible for a publisher to offer the record and a
client to request the record, and for the record still not to be
received (pub uses SPF, client asks for TXT, record isn't seen).

This meant that we had do do _something_ about the state of affairs,
and given the almost complete lack of use of type 99, ditching it
seemed to make sense.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 08 Sep 2012 02:05:59 +1000

In message <[email-masked]>, Nicholas Weaver writes:
> There are many obstacles for DNSSEC and other DNS enhancements.  Firewalls blocking novel RRTYPEs (without, eg, blocking DNSSE
> C in general) is generally not one of them, or way way way down in the list.
> 
> The server side does have a fault, not making it easy to SPECIFY novel types, but once a novel type is queried for, it tends t
> o work reliably through the whole path to the client.

And the analysis is fault as there is a 3.2/3.4/4.8% deployment
rates of the SPF record in participating sites.  Why would you need
a web tool to change TXT to SPF as the rdata is syntactically
identical?  Alexa domains list is problematical for any type other
than A, additionally depending upon the methodology used to check
you can get significantly different failure rate as that list
contains a higher than normal percentage of DNS load balancers.

Seeing few queries for SPF record when there are TXT records present
does not indicate anything about SPF record support in clients as
there is no need to try SPF if TXT is present.

Lack of code could also be a contributing factor libspf2 took until
October 2008 to add type SPF lookups.

https://github.com/shevek/libspf2/blame/master/src/libspf2/spf_server.c

We shipped BIND 9.4.0 in Feb 2007 and it included SPF support.

RFC 4408 April 2006

TXT was already well established for SPF before we could convince
any to go down the SPF path.

You can't rush a migration from one record type to another see A
to MX which took much, much longer that SPF was given before defeat
was called.

I actually expect to see SPF queries to rise as the early mover
machines get replaced with modern hardware and with that have a
software refresh.

There is a lot of inertia in the DNS but it does move and moves
faster if you don't start with a migration.

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

---

From: Doug Barton <[email-masked]>
Date: Fri, 07 Sep 2012 12:47:06 -0700

> If we can not deploy new things, together with people giving up like this, is not a very positive view of the future.

This was discussed on ietf@ a while ago. The consensus I read from that
discussion (possibly because I agreed with it) was that the fail for SPF
was allowing 2 provisioning methods, instead of just using the new
RRTYPE from day 1. This is a similar problem to the Header: vs X-Header:
issue.

Doug

---

From: "John Levine" <[email-masked]>
Date: 7 Sep 2012 23:00:09 -0000

>RRTYPE from day 1. This is a similar problem to the Header: vs X-Header: issue.

It's true that we wouldn't be having this discussion if SPF required
type 99 records, since nobody would have deployed it and it would have
disappeared without a trace.

The problem is that it's too hard for people to use new record types,
in particular because the provisioning systems that most people use do
not have any practical way to add new RR types for people who aren't
DNS weenies.  Often there's no way to add them even if you are a DNS
weenie.  (Helpful hint: if you were about to argue that it's not hard
to add new RR types, don't bother.  In the real world, it is.)

Perhaps this would be a good time to take another look at
draft-levine-dnsextlang-02.txt.  It's hardly a magic bullet, but as
far as I'm aware it's the first attempt in a long time, perhaps ever,
to address the provisioning problem.

R's,
John

---

From: Michael Sinatra <[email-masked]>
Date: Fri, 07 Sep 2012 17:35:55 -0700

> and given the almost complete lack of use of type 99, ditching it

I am sure this was discussed in SPFBIS, but I am wondering why they 
couldn't have gone the route of MX (vs. A) from the perspective of the 
queryer: First ask for the SPF record, and if it doesn't exist, ask for 
the TXT record.  In this situation, you only have to change the 
specification of the software doing the lookups; SPF publishers can 
still have the flexibility to use either record.  Principle of least 
change, etc...

michael

---

From: Mark Andrews <[email-masked]>
Date: Sat, 08 Sep 2012 11:55:12 +1000

> to add new RR types, don't bother.  In the real world, it is.)

Which is a fault of the provisioning system not the DNS.  Lots of
povisioning systems don't even support the set of RR types in RFC
1034.  The DNS has a standard method that allows the introduction
of arbitary records that does not require provisioning systems to
change anything when a new type is introduced (RFC 3597).  It may
not be the most elegant but it works.

> to address the provisioning problem.

As for draft-levine-dnsextlang-02.txt there was nothing stopping
anyone implementing something like this in the past.   Standardising
this does run the risk of forcing new records to match what is
describeable in that language.

You need to base32hex without padding.

For the record our DHCP product has a similar system and it still
needs extending occasionally to support new DHCP option codes.  We
also get called "to heavy" in part because we are extensible like
this.

Mark

---

From: Doug Barton <[email-masked]>
Date: Fri, 07 Sep 2012 20:10:53 -0700

> disappeared without a trace.

All of the new record types deployed in the last several years
(particularly DNSSEC-related ones) give us a lot more hope than that.

I realize that you have a draft you'd like to get published, but
repeating the same oft-refuted arguments won't help that effort.

-- 

    I am only one, but I am one.  I cannot do everything, but I can do
    something.  And I will not let what I cannot do interfere with what
    I can do.
			-- Edward Everett Hale, (1822 - 1909)

---

From: SM <[email-masked]>
Date: Sat, 08 Sep 2012 00:47:26 -0700

Hi Doug,
>RRTYPE from day 1. This is a similar problem to the Header: vs X-Header:

I thought so too at first.  There are a few issues DNS-wise which 
didn't make sense.  I read the relevant mailing list archive and 
found a possible explanation for the two provisioning methods and 
some other issues.  It was one of these decisions which was _the_ 
alternative at the time.  With hindsight, I might say that using only 
the RRTYPE from day 1 would have been better.

I wouldn't call it process failure.  It was a different time, the DNS 
environment was different and the work wasn't easy.

Regards,
-sm

---

From: "John R Levine" <[email-masked]>
Date: 9 Sep 2012 10:20:58 -0400

> Which is a fault of the provisioning system not the DNS.

Right.  And as long as provisioning systems don't support new RR types, 
they're not going to get deployed in in the real world.

I'm getting the impression that I'm the only one here who thinks that it 
might be a good idea to try and solve that problem.  That's sad.

R's,
John

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 09 Sep 2012 13:52:00 -0400

> might be a good idea to try and solve that problem.  That's sad.

I think that people here feel powerless to address that problem :-(
but your draft will hopefully empower them.

	Olafur
ps: remember to add the int64 type to the next version.

---

From: Edward Lewis <[email-masked]>
Date: Sun, 9 Sep 2012 15:29:36 -0400

>Which is a fault of the provisioning system not the DNS.

I think this is a case of barking up the wrong tree.

I don't have a complete history, but I once had a real close seat to 
the action leading up to this.  By that I mean I was part of an 
interim MARID WG meeting in June of 2004 where the situation came to 
a boil.

At that point in time, the SPF effort had been under way for quite 
awhile.  The prototype code written by a group of people relied on 
the use of the TXT record because (and this I don't know) they either 
couldn't get a RR type allocated or they failed to ask for one.  At 
that time in IETF history it was very difficult to get a new RR type 
allocated, I do know that, and the document that is now RFC 5057 was 
just emerging as a response to what was happening and I was asked to 
go to the meeting to argue its points.

The MARID WG was trying to publish a document including the use of 
the TXT record.  When the message was delivered that this was not 
good for the DNS an all out IETF-brawl raged.  The story was that the 
group had gone to great lengths the develop, deploy, use, document 
multiple independent implementations to get to the point where they 
could publish and qualify for a RR type (which is what it took then). 
They were right - the red-tape of the time encouraged overloading the 
TXT record and discouraged "the right way to go."

To compromise the WG was granted a new type and allowed to go forward 
with a specification allowing TXT or SPF.  On the DNS end, a more 
liberal process was put in place to get new types allocated - the 
template system we have in place now.  And until now, that was the 
end of the story for me.

The rest of this are observations I'll throw on the table.

The forward-looking plan to accommodate backwards compatibility seems 
to have allowed the "problem" to fester.  With "problem" being 
defined as overloading the TXT record.  Looking on the bright side, 
this is a "problem" only for the DNS, not for anyone else - which is 
why no one else seems to have cared to fix this "problem."

Provisioning systems?  No, they are not the issue.  Even if it were 
easier to put the SPF record into the DNS, this doesn't address the 
security filters that are fairly DNS ignorant.  That problem sits in 
a whole 'nuther bin.

Longer back in time there was a decision (from the Security Area AD 
in the 90's, Jeffery Schiller) to not approach security as a cohesive 
problem, I recall Schiller's talk at Danvers (IETF 32) including the 
analogy of "eggs in one basket."  He (it may have been a committee 
decision, but he was the head then) wanted security to be tackled 
protocol by protocol.  This seemed like a good idea at the time, sort 
of a "defense in depth" approach (which I think was a strong theme). 
Now, with 20/400 hindsight, it seems that this forward-looking plan 
has backfired.

We know that the DNS protocol, relying as it does on UDP, is a 
security nightmare.  Even if we DNSSEC it, that won't stop DDoS, for 
example.  So what has happened while the DNS has tried to take care 
of itself, other protocols and operators have but protections in 
place against the DNS.  By limiting the DNS to only what they 
understand it to be doing, they feel they are protected.  The result 
is shackles have been placed on DNS, preventing innovation within the 
protocol from having the desired impact.

This long story is to say that it isn't provisioning.  It's the 
dynamics of how applications are deployed and the (old-time) red tape 
choking them and the nature of the DNS to be a threat to the rest of 
the network that are bigger problems here.

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

2012...time to reuse those 1984 calendars!

---

From: "John R Levine" <[email-masked]>
Date: 9 Sep 2012 16:42:33 -0400

> At that point in time, the SPF effort had been under way for quite awhile. 
> The prototype code written by a group of people relied on the use of the TXT 
> record because (and this I don't know) they either couldn't get a RR type 
> allocated or they failed to ask for one.

SPF was basically a done deal by the time it got anywhere near the IETF. 
They used the text record because it let them get their work done.  If 
they had asked, we would probably have told them to use a TXT record with 
a prefix.

When we did DKIM, which was an IETF effort to smoosh together two somewhat 
incompatible predecessors, we used TXT records with a prefix.  Partly that 
was because one of the predecessors used them, but mostly it was because 
we knew that in practice, if DKIM required that people provision a new RR, 
it would have no chance of widespread deployment.

> This long story is to say that it isn't provisioning.  It's the dynamics of 
> how applications are deployed and the (old-time) red tape choking them and 
> the nature of the DNS to be a threat to the rest of the network that are 
> bigger problems here.

Provisioning may not be the only issue, but it's serious enough that 
untill we make provisioning orders of magnitude easier, there's no point 
in fixing anything else.

DNSSEC, which seems to be the poster child for how easy it allegedly is to 
add new RRs, is finally succeeding despite needing new RRs and upgrades to 
every bit of DNS software, only because there's no other plausible 
approach to fixing the problem.

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

---

From: Edward Lewis <[email-masked]>
Date: Sun, 9 Sep 2012 18:32:31 -0400

At 16:42 -0400 9/9/12, John R Levine wrote:

>add new RRs, is finally succeeding despite needing new RRs and upgrades
>to every bit of DNS software, only because there's no other plausible

And not just because there's no other way, there was a concerted, 
funded effort to *make sure* it happened.

DNSSEC came out of the lab in 1998.  There was immediate concern by 
powers that be that DNSSEC wasn't easily picked up, so a new funded 
effort began which fostered the workshops that followed (1999-2004 or 
so) and the new rounds of RFCs.  And once that all happened and 
DNSSEC didn't, more and more work was done to make it so, eventually.

Entropy is hard to fight.

(And, I don't mean to say provisioning is not a problem.  It's not 
the important one in the SPF case.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Doug Barton <[email-masked]>
Date: Sun, 09 Sep 2012 15:38:29 -0700

On 9/9/2012 12:29 PM, Edward Lewis wrote:
> The MARID WG was trying to publish a document including the use of the
> TXT record.  When the message was delivered that this was not good for
> the DNS an all out IETF-brawl raged.  The story was that the group had
> gone to great lengths the develop, deploy, use, document multiple
> independent implementations to get to the point where they could publish
> and qualify for a RR type (which is what it took then). They were right
> - the red-tape of the time encouraged overloading the TXT record and
> discouraged "the right way to go."

Not only is that my recollection, it matches the recounted history
dragged up recently on ietf@.

> template system we have in place now.

And this is where the mistake was made. Once they got the new RR type
they should have dropped the TXT record. What's arguable is whether or
not the ramifications of that choice were foreseeable.

However, rather than beating the dead SPF horse what I'm eager for is
that we learn the lessons from that experience, and not repeat them.

Doug

--

---

From: Mark Andrews <[email-masked]>
Date: Mon, 10 Sep 2012 09:14:56 +1000

> interim MARID WG meeting in June of 2004 where the situation came to 

By June 2004 we already had private types available in the DNS (RFC
2929) because I was already using them.  The private version of DLV
(65323) was committed to named's tree in March 2004.

commit 50105afc551903541608b11851d73278b23579a3
Author: Mark Andrews <[email-masked]>
Date:   Wed Mar 10 02:19:58 2004 +0000

    1589.   [func]          DNSSEC lookaside validation.
    
    enable-dnssec -> dnssec-enable

I had also started the process of getting a formally allocated type
for DLV.  I prototyped with a private type then moved to a formally
allocated type.
 
> could publish and qualify for a RR type (which is what it took then). 

There was NEVER a time were you required have even a *single*
implementation to get a new RR allocated.  It helped if you had a
implementation but it was not required.

> TXT record and discouraged "the right way to go."

The red tape had basically gone by then, but not the perception of
red tape.  The bar to get a new type was extremely low.  DLV (32769)
got allocated under the rules that were in existance at that time
and DLV was a very controversial type as people though it was a end
run around the working group and various email about its progress
were not sent so I was left waiting when I shouldn't have been.

An experimental type was a no brainer under the rules that were in
place but no one was willing to do that.  You just needed to meet
"Specification Required".

      Specification Required - Values and their meaning must be
           documented in an RFC or other permanent and readily available
           reference, in sufficient detail so that interoperability
           between independent implementations is possible.

> template system we have in place now.  And until now, that was the 

People complained about a system without even trying to use the
system.

---

From: Edward Lewis <[email-masked]>
Date: Sun, 9 Sep 2012 19:34:43 -0400

>            between independent implementations is possible.

I think this is an unfair criticism of the folks involved.  Not 
everyone is well steeped in the DNS RFCs.  Sorry, but that's true. 
We, who are on namedroppers day in and day out live and breath this 
stuff.  But not others.

If you think the rules were a no brainer in 2004...ask yourself why 
so many changes were made in the wake of the MARID WG issues?  (They 
may not have been the only ones with this problem.)  Private types 
were known and dismissed because they only added fuel to the failure.

The group that pioneered SPF did the right thing.  Wrote code, 
deployed, tested, then documented.  That's the IETF way, or it once 
was.  They got screwed for doing that.  Whether it was a private type 
ot TXT record, trying to redeploy with SPF is the same burden.

Note I say this as the person back then trying to convince them to 
change from TXT to SPF.  Maybe it was the Stockholm Syndrome 
(http://en.wikipedia.org/wiki/Stockholm_syndrome) but I have become 
sympathetic to the plight (...to overdramatize this.)

---

From: Mark Andrews <[email-masked]>
Date: Mon, 10 Sep 2012 10:00:45 +1000

> We, who are on namedroppers day in and day out live and breath this

They got told the rules had changed but they refused to listen.

> were known and dismissed because they only added fuel to the failure.

Because there was a perception that there was a problem.   There
was no documented evidence of a problem because no one (apart from
myself as far as I am a aware) attempted to use the system.  It
wasn't worth fighting about this when people decide they needed to
tweak the system again.

> ot TXT record, trying to redeploy with SPF is the same burden.

Which is why there was supposed to be a overlap period.  libspf
NEVER added support for type 99.  libspf2 took 2 years to add support
for type 99 after the RFC was published.  The SPF community failed
here.  Nameservers and associated tool chains shipped with SPF
support before the libraries were updated.  libspf and libspf2 could
have been update the day the type code was allocated as they used
libresolv and the type code is just a integer as far as that library
is concerned.

	#ifndef T_SPF
	#define T_SPF 99
	#endif

---

From: "John R Levine" <[email-masked]>
Date: 9 Sep 2012 20:36:28 -0400

> (And, I don't mean to say provisioning is not a problem.  It's not the 
> important one in the SPF case.)

Having been there at the time, I can say that if it were easy to provision 
new RRs, there would have been some chance that type 99 would catch on. 
Since it wasn't, it was DOA.

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Mon, 10 Sep 2012 13:17:16 +1000

In message <[email-masked]>, "John R Levine" wri
> Since it wasn't, it was DOA.
 
What makes you think having a standardised RR description language
will get any more buy in from the registrars than RFC 3597 has had?

Most nameserver vendors already support RFC 3597, the exception is
Microsoft[1].  This is despite people complaining about the lack of
support for nearly a decade now.

[1] http://social.technet.microsoft.com/Forums/en-US/winserver8gen/thread/6d937082-53a3-470a-8407-ddbe75dbc166

---

From: "John R Levine" <[email-masked]>
Date: 9 Sep 2012 23:43:21 -0400

> will get any more buy in from the registrars than RFC 3597 has had?

Disregarding the detail that no sane person wants to put an SPF record in 
a TLD, the registrars I know (and yes, I know some) have few customers who 
are prepared to deal with stuff like this:

foo	TYPE731         \# 6 abcd (
 		 ef 01 23 45 )

You and I can do it, most people setting up DNS for an organization can't. 
I sure wouldn't want to do it very often.  (I had my DNS provisioning 
stuff do type 99 records for a while, by the simple but effective kludge 
of looking for TXT records that started with v=spf1 and adding matching 
SPF records, but I took them out because too much client software barfed.)

The point of my proposal is that it offers a syntax that is at least 
somewhat possible for normal humans to type, and allows some error 
checking at the time the data are entered, e.g., numeric values are in 
range, domain names are syntactically valid.  I don't care whether people 
do that or someone comes up with something better, but telling people to 
write hex glop suggests an unfamiliarity with normal DNS users.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Mon, 10 Sep 2012 14:11:49 +1000

In message <[email-masked]>, "John R Levine" wri
> SPF records, but I took them out because too much client software barfed.)

So there was client software that looked for SPF records then barfed when
it got them or client software that made ANY queries then barfed because
it had a unknown type in the response or ...
 
> write hex glop suggests an unfamiliarity with normal DNS users.

Hex goop is for "immediate use" until the interface can be upgraded.
It needs to be there because you still have to get someone else to
do something to support new types even if it is updating a configuration
file.

Nothing has stopped developers doing what you are suggesting anytime
in the last 20+ years.  What makes you think they will add support
for it now just because it is a RFC.  It's not like most of the RR
types went beyond a the simple set of primatives you have already?

This is not to say we wouldn't add support to named for this but I
don't think named is the problem here.  We already have a not too
complicated method of adding new types that others have used.

Mark

---

From: "John R Levine" <[email-masked]>
Date: 10 Sep 2012 00:14:59 -0400

> it had a unknown type in the response or ...

Antique BIND libraries, as I recall.

> types went beyond a the simple set of primatives you have already?

Having said "provisioning software" about 100 times already, I give up.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Mon, 10 Sep 2012 14:30:24 +1000

In message <[email-masked]>, "John R Levine" wri
> Having said "provisioning software" about 100 times already, I give up.

Provisioning software has developers.

Deciding whether to do something like this or not has been a obvious
design question for over a decade now.  We thought about whether
to take this route back when we were starting with BIND 9 (1998).
We decided to go the C code route and have seperate files for each
type which had all the type specific code.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 10 Sep 2012 07:59:19 -0400

On Sun, Sep 09, 2012 at 07:34:43PM -0400, Edward Lewis wrote:

> so many changes were made in the wake of the MARID WG issues? 

Also, go read the namedroppers archives, if you can find them, from
that era.  They support what Ed is saying.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 10 Sep 2012 08:03:11 -0400

On Fri, Sep 07, 2012 at 05:35:55PM -0700, Michael Sinatra wrote:
> couldn't have gone the route of MX (vs. A) from the perspective of
> the queryer: First ask for the SPF record, and if it doesn't exist,
> ask for the TXT record.  In this situation, you only have to change
> the specification of the software doing the lookups; SPF publishers
> can still have the flexibility to use either record.  Principle of
> least change, etc...

Maintaining two records in the system is harder, and makes the system
more complicated.  The use of TXT seems to be working, and effectively
nobody is using the SPF type now.  So TXT it is.

If people feel strongly about this, I encourage you to make the
arguments on the spfbis list, _after_ reading the archives of the
discussion from when this was changed.  Be prepared to argue with Dave
Crocker about the DNS.

Best,

A

-- 
Andrew Sullivan
[email-masked]