In message <20130819214139.gb19...@mx1.yitter.info>, Andrew Sullivan writes: > I'm not going to copy the spfbis WG list on this, because this is part > of the IETF last call. No hat. > > On Mon, Aug 19, 2013 at 02:04:10PM -0700, Murray S. Kucherawy wrote: > > On Mon, Aug 19, 2013 at 1:59 PM, Dave Crocker <d...@dcrocker.net> wrote: > > > > From earlier exchanges about this concern, the assertion that I recall is > > > that 7 years is not long enough, to determine whether a feature will be > > > adopted. > > > What is the premise for seven years being "not long enough"? And what does > > constitute "long enough"? And upon what is that last answer based? > > I have two observations about this. First, EDNS0, which is of > significantly greater benefit to DNS operators than the mere addition > of an RRTYPE, took well over 10 years to get widespread adoption. > Second, we all know where IPv6 adoption stands today, and that has > certainly been around longer than 7 years. So I think it _is_ fair to > say that adoption of features in core infrastructure takes a very long > time, and if one wants to add such features one has to be prepared to > wait. > > But, second, I think all of that is irrelevant anyway. The plain fact > is that, once 4408 offered more than one way to publish a record, the > easiest publication approach was going to prevail. That's the > approach that uses a TXT record.
Except you are trying to unring a bell. The SPF type exists and is supported in nameservers, resolver libraries and in SPF specific libraries. Support is integrated into SMTP servers. Basically it is all there. Deployment is happening. More and more SMTP servers are making SPF requests before TXT requests. There was no rush to migrate to the new type. Suddenly there is a "oh we have not moved fast enough" so we need to abandon the migration for lots of really spurious reasons. * RFC 4408 allows to publish records that might not be read by a client. This isn't actually bad. At some point you have to drop support for legacy users. RFC 4408 *allows* this to happen. The worst that happens is a forgery isn't detected but we don't guarentee to stop all forgeries. * SPF and TXT records may get out of sync. If we really need to do something about this we can request that nameserver vendors keep these records in sync but in reality the SPF record will be the one that get used more and more and TXT record will not be looked up at all if we just let the migration continue. * SPF lookups fail or are slow. So do TXT lookups. Most of these are due to misconfigured nameservers that return the wrong SOA record as they are configured to server a parent zone rather than the delegated zone or load balancers which are not RFC 1034 compliant as they don't respond to anything other than a limited set of types. * Nameservers don't support SPF. Most currently shipping nameservers do support SPF and have for years. Some OS vendors are slow to pickup new nameservers which doesn't help. Of those that don't support SPF moving from experimental to standard will/should help with getting the support added. * Resolver libraries don't support SPF lookups. Such libraries are not RFC 1034 compliant as support for lookups of unknown types is a explictly listed requirement. Most resolver libraries are capable of looking up unknown types though they can only present them as a blob of data. * Registrars don't support type SPF records. Shop around there are those that do. TXT was described as legacy in RFC 4408. The spf specific libraries look for SPF first then TXT if a SPF RR is not present which is exactly what you would expect when TXT is described as legacy. You also have a problem that "SPF record" means two things if we stop the migration. The TXT record with "v=spf1" at the start and the type SPF record that is deprecated. There are other problems like undoing all the changes to support type SPF. You need to modify all the servers that now support SPF to warn / fail to load if they see a SPF record in a zone. Note it doesn't help that companies charge extra to support SPF over TXT as you well know. RFC 4408 treated the SPF type as a foot note. All the examples were done using TXT not SPF with the exception of the single example showing identical TXT and SPF records. When all the examples are done with TXT how do you expect people to know that they should be using type SPF? Lots of people were not aware of the SPF type. Named now warns when both TXT and SPF versions of SPF records are not present and it could be made into a failure unless the test is explicitly downgraded to a warning or disabled. The code could also be extended to enforce consistancy between the two types of records when present. I'm willing to write the code for named. Mark > Best, > > A > > -- > Andrew Sullivan > a...@anvilwalrusden.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
