Subject: [spfbis] Garbage TXT records (more on Issue #9)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 25 Feb 2012 06:55:00 +0000

While running some more query reports about deployed SPF records, I came across a few interesting cases.  My favourite two examples are ut.edu and aaronline.com.  Do a TXT query of both to see what I'm looking at.  The ut.edu one actually triggered truncation in my tests.

So for the sake of discussion, let me toss out this straw man argument:

An SPF client that queries SPF first and actually gets answers is far less likely to need hardening against this kind of junk.   It's thus less likely to break.  Therefore, enabling the isolation of SPF data into its own RRtype is actually beneficial, and so we should keep it and re-emphasize its value.

(Yes, I know it's easy to cycle through a TXT RRset and only extract stuff that starts "v=spf1".  That doesn't mean everyone will get it right.)

For another example, look at zagat.com.  The Google Apps site ownership verification record is one example of how TXT is overloaded for numerous purposes for which SPF clients need to be prepared if they're querying TXT, but would very unlikely be a concern for an SPF RRset.

Again, just a straw man that might end up being useful when considering the merits of the proposal to remove type 99 vs. keeping it.  I don't know that I agree with it.

For that matter, is the fear of unsupported RRtypes that was obviously around six years ago still an issue today?  Could we actually go the other way and slap a SHOULD NOT on TXT records because support is now relatively available?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 25 Feb 2012 02:10:39 -0500

On Saturday, February 25, 2012 06:55:00 AM Murray S. Kucherawy wrote:
> While running some more query reports about deployed SPF records, I came
> across a few interesting cases.  My favourite two examples are ut.edu and
> aaronline.com.  Do a TXT query of both to see what I'm looking at.  The
> ut.edu one actually triggered truncation in my tests.

I got SERVFAIL from aaronline.com.

> An SPF client that queries SPF first and actually gets answers is far less
> likely to need hardening against this kind of junk.   It's thus less likely
> to break.  Therefore, enabling the isolation of SPF data into its own
> RRtype is actually beneficial, and so we should keep it and re-emphasize
> its value.

Contrarywise, an SPF client that queries for TXT under any circumstances needs 
to be prepared to deal with it, so there's still no benefit.

> (Yes, I know it's easy to cycle through a TXT RRset and only extract stuff
> that starts "v=spf1".  That doesn't mean everyone will get it right.)

This isn't a new type of concern and I think it's safe to assume 
implementations can at least pick the right record.  There are other ways that 
things that aren't valid SPF records can get published that would also apply 
to Type SPF (one of my favorites being the ones that have no spaces) so Type 
SPF really doesn't avoid anything.

> For another example, look at zagat.com.  The Google Apps site ownership
> verification record is one example of how TXT is overloaded for numerous
> purposes for which SPF clients need to be prepared if they're querying TXT,
> but would very unlikely be a concern for an SPF RRset.

That doesn't excuse an SPF client from having to do basic input validation on 
Type SPF record and it's trivial to do.

> Again, just a straw man that might end up being useful when considering the
> merits of the proposal to remove type 99 vs. keeping it.  I don't know that
> I agree with it.
> 
> For that matter, is the fear of unsupported RRtypes that was obviously
> around six years ago still an issue today?  Could we actually go the other
> way and slap a SHOULD NOT on TXT records because support is now relatively
> available?

Publishing Type SPF is fine for people that run their own DNS servers.  I'm not 
aware of any commercial host that supports it.

Given the chairs comments on WG scope, I think slapping a SHOULD NOT on 
something because we thing it might be a good idea is out of scope anyway.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 25 Feb 2012 07:54:12 -0000

>An SPF client that queries SPF first and actually gets answers is far
>less likely to need hardening against this kind of junk.

The sanity check for SPF records is identical to that for TXT records,
so why wouldn't you do the same thing either way?  Also, SPF records
offer their own exciting failure modes.  See, for example, the mail on
the dmarc-discuss list a few weeks ago from the guy who insists on
returning NOTIMP in response to type 99 queries, which Yahoo
interpreted as a soft failure it should retry.

>around six years ago still an issue today?

I'm not sure fear is the right word, but there's vast amounts of DNS
provisioning* software that only support a fixed set of RRs, and SPF
inevitably isn't one of them.  Or they only support them via ugly
escape codes.  Here, for example, is the source form of one of my SPF
records:

:taugh.com:99:\072v=spf1\040ip4\07264.57.183.0\05726\040ip6\0722001\072470\0721f07\0721126\072\072\05764\040~all:7200

(That was generated by a perl script, but not all provisioning systems
are run by perl weenies.)

A few months ago I sent a proposal to the dnsext group for a simple
DNS extension language that would make it easier to add new RRs to
both servers and provisioning software, but although a few people
expressed interest, it looks like dnsext will shut down without doing
anything about it.

R's,
John

* - I said provisioning software, not DNS servers

---

From: Hector Santos <[email-masked]>
Date: Sat, 25 Feb 2012 23:22:43 -0500

My Opinion:

Interesting records.

The first one, ut.edu, there is no v=SPF1 "string" that I can see, so 
even though we may view this as "junk", in SPF terms with a proper 
expected parsing, there is no v=SPF1, so no issue here. (Extra comment 
about this below).

The 2nd one, arronline.com, this one had a bunch of v=spf1 strings. 
IMO, the technical question for SPF-BIS is which one should be valid. 
  I would think "software wise" the first one is the one that should 
honor and the logic SHOULD stop to continue looking for any more.

Regarding the ut.edu record, I think the issue here is how TXT records 
are/were used to EXPLORE many different ideas to expose domain 
information.

Look up winserver.com to see the some different ideas were explored.

Regarding the arronline.com and zagat.com, lookup  _dsap.isdg.net and 
see the ideas here exploring the merging of multiple v=dsap1 records 
to deal with different domains and wildcarding.  The old DMP 
experimental LMAP protocol was similar with using multiple strings.

So its all part of the DNS infrastructure concerns debated with using 
TXT records in different ways.  The evidence you provide shows these 
efforts.

In My view:

  using type 99

    PRO: helps with isolating a protocol framework data, less conflicts.
         (Note: CEP (prior to SENDER-ID) had its own namespace).

    PRO: Helps with IETF/DNS community endorsement

    CON: RFC 3597 related issue, higher CON yesteryears, lesser CON today.

  using TXT

    PRO: Helps for multiple protocols to share the same namespace
        (i.e. 1 query vs multiple queries)

    PRO: Probably view as simpler

    CON: Does not helps with IETF endorsement

    CON: More complex, no standard set to separate them except for
         looking for specific start tags

I think a forward looking consideration is the idea of clients having 
to use different query formats for different protocols where perhaps 
maybe there should be all part of a single call.  This will have with 
long term scaling of DNS storage usage.  Does a focus on reliable 
wildcarding helps here?

Perhaps there is a need to propose a BATCH Multiple Query Packet 
concept for DNS that is now emulated using async methods.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Murray S. Kucherawy wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 26 Feb 2012 03:40:08 -0500

>Interesting records.
...
>honor and the logic SHOULD stop to continue looking for any more.
...

Since the order the various strings will be returned varies, that would mean a different result on subsequent queries. That kind of stochastic behavior is something we need to avoid. Under RFC 4408 multiple SPF records like this is a permanent error and that should not change for 4408bis.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sun, 26 Feb 2012 04:36:27 -0500

Scott Kitterman wrote:
> Since the order the various strings will be returned varies, that would mean 
> a different result on subsequent queries. That kind of stochastic behavior is 
> something we need to avoid. Under RFC 4408 multiple SPF records like this is 
> a permanent error and that should not change for 4408bis.

You are referring to 4.5

    If there are two or more records remaining, then check_host() exits
    immediately with the result of "PermError".

Right?  Ok, +1. Bad record.