In message <20130820022209(_dot_)GA56138(_at_)mx1(_dot_)yitter(_dot_)info>,
Andrew Sullivan writes:
Again, I'm not the shepherd on this, but I was involved in the
consensus call in the WG when we determined that the WG wanted to
deprecate use of RRTYPE 99. (Note that this "deprecation" means just
that users of SPF stop publishing that record. There's nothing in the
draft to remove the RRTYPE, as that would be absurd.)
Recommending that people not publish RRTYPE 99 does not address the
problem. You need to forceable stop people using RRTYPE 99 or you
need to continue the migration by deploying more software that looks
up type SPF then type TXT if SPF is not available.
Those are the only solutions to the so called problem of publishers
and checkers not interoperating with each other.
On Tue, Aug 20, 2013 at 11:27:25AM +1000, Mark Andrews wrote:
Deployment is happening. More and more SMTP servers
are making SPF requests before TXT requests.
I think those are the two central premises that are up for dispute.
RFC 6686 made the determination about the former claim, and therefore
that premise is not up for debate: deployment appears not to be
happening. If people wish to argue with the conclusions of RFC 6686,
that's fine, but it seems that one at least needs to write an
anti-6686 document in that case. The draft currently up for last call
is relying on the conclusions of RFC 6686 as a premise, and is not
itself arguing whether RRTYPE 99 deployment is or is not happening.
When you only do a point measurement and don't have any long term
trends the data is meaning less. Lots of zones were setup pre RFC
4408 with no campain to transition them to RFC 4408 status. Similarly
it takes several years for new support to make its way into production.
You have to write the libraries. You have to integrate the new
libraries into the servers. You have to get those servers deployed
which is often only done on hardware replacement.
The fact that SPF processors are making SPF queries before TXT queries
is in fact part of the reasoning for why RRTYPE 99 ought to be
deprecated. If many clients make a query and only a tiny number of
zones have that type published (or are likely ever to publish the
type), it's simply wasteful to continue using that type. If this
seems a familiar line of argument, it's because it's one you see in
the spfbis list archives when this issue was decided by the WG.
So the solution is to educate. The long term goal is to get to
type 99 only. The complaints about delays could be removed with
draft-wkumari-dnsop-hammer and addressing the bigger problem of
broken nameservers draft-andrews-dns-no-response-issue or have TLD
operators actually do what was requested of them in RFC 1034 and
periodically CHECK delegations which would address some of
misconfiguration issues.
Note it doesn't help that companies charge extra to support SPF
over TXT as you well know.
I'm not sure whether that's supposed to be a swipe at my employer, but
just so we're clear: Dyn (my employer) supports the SPF RRTYPE in its
enterprise-focussed offerings. There's no extra charge.
There is a extra charge over basic support which support A, AAAA,
CNAME, MX, TXT, SRV, NS, LOC, PTR compared to the premium product
which supports A, AAAA, CERT, CNAME, DHCID, DNAME, DNSKEY, DS,
IPSECKEY, KEY, KX, LOC, MX, NAPTR, NS, NSAP, PTR, PX, RP, SOA, SPF,
SRV, SSHFP, TXT.
http://dyn.com/dns/dns-comparison/
The front end for the basic DNS service (many people know this as
DynDNS or Dyn's Standard DNS or other such trade names) is intended to
be simple and self-service. It's cheap, and the margins don't allow
us to provide a lot of personalized support. Dyn found that people
who were good candidate customers for that self-service system knew
how to do things with TXT, did not know about or care about the SPF
type, and were confused by having two types for one purpose. For
practical purposes, it was necessary to support SPF over TXT (since
some clients didn't check the SPF type). So, one type it was, and TXT
at that. This all happened long before I worked at Dyn, but I assure
you that the commercial pressure for adding TYPE 99 support to the
basic platform (actually, it's just the front end) is just as
non-existent today as it was when that decision was made.
So rather than do what RFC 4408 said to do and support the SHOULD Dyn
made it impossible for the non enterprise customer to do RFC 4408
properly.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org