The last time the SPF folks investigated where to place their TXT
record, it was determined that a non-trivial number of web-based DNS
administration systems (registrars, DNS providers, etc.) could not
handle the underscore. Some can not deal with adding TXT records, and
most do not allow you to add arbitrary RRs.
There is a difference of context though. An independent group does not
have the same leverage here. It is much easier to get these companies
to respond if the changes are endorsed by a credible party such
as the major vendors, major ISPs, the maintainers of the code or a
I agree with Phillip here. I think that in the context of an IETF
proposal, we can get these fixed, but there ARE problems that need to
be fixed. Last fall, when it looked like SPF deployment would be
going a lot slower, it was decided that using an underscore would
be too much of a hurdle for rapid adoption. It was also determined
that the usage of TXT records is low enough that there wasn't a need
to place them in a subdomain in order to keep the DNS queries under
The other piece of context that has changed here is that we are now in
a standards process and I don't think that the naked TXT record is
going to be credible, it is not a defensible position by any stretch.
I think if there is an insistence on DNS binary encoding and waiting
for a full proposal before any deployment is possible that we should
just close the group now and stop wasting everybody's time.
If the _prefix convention is used the deployment situation is at best no
worse than for a new RR. The risk of collision is no different, there
is no need to upgrade the legacy base.
A new RR with a TXT string representation provides meaningless
compatibility with a legacy architecture, adds no value, requires
use to wait for the servers to be upgraded and is generally bogus
but could be acceptable if done quickly.
The only real risk is that DNSEXT does not 'get it'. I'll start taking
that group seriously once they tell me that they are going to fix
DNSSEC, but certainly not before.