In message <20130820022209.ga56...@mx1.yitter.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: ma...@isc.org
