<pbaker(_at_)verisign(_dot_)com>
Witholding functionality in the hope it will drive deployment
is a very very bad strategy.
I won't say it. It's too easy.
We're caught between a rock and a hard place over this. On one side we don't
want to break existing functionality in DNS (ahem*s*te-f*nd*r*ahem) but on
another we can't wait for bureaucracy to catch up (ahem*dnssec*ahem).
I'm going to ignore the wildcard matter because I agree that wildcard abuse
is a problem and I'd be happy to avoid them altogether. But the motivation
to use TXT came from an existing RFC (albeit experimental and possibly bad
design) and a way to tell the difference between records we're looking for vs
records we're not looking for. Sure a query for TXT could return more than
one TXT record but only one record, in theory, contains the property we'd be
looking for. Consider:
$ORIGIN example.com.
@ TXT "property of example.com incorporated"
@ TXT "antispamproperty=foo,bar,baz"
@ TXT "otherprotocolproperty=something,else,entirely"
Go ahead DNS people: cringe. I feel your pain.
A straight TXT query would return all of these records of course. It'd be
easy to tell the difference. At least I'd hope something parsing this could
tell the difference.
Now that was the theory. DNS purists have a problem with this, but there are
apparently other applications that could have a problem with this or the DNS
people wouldn't have moaned so loudly. I'm not interested in what those
problems are because enough people have moaned loudly that I'll accept that
it's a problem.
With this in mind, I'd be glad to invent something that represents
"antispamproperty=foo,bar,baz" and ask DNS vendors to support arbitrary
record types as that's apparently easier than asking the DNS WG to tolerate
record type abuse. Even in the Microsoft camp where I make my money, I'll
swap a client's MSDNS with BIND 9 in a heartbeat [1] to support this if M$
ignores my plea to support it. Something like this should not stop us from
avoiding the record overloading problem and it sure shouldn't stop us from
storing sender authentication info.
[1] BIND 9 supports Active Directory because it supports dynamic DNS updates.
All I'd have to do is change the AD-integrated zones to standard zones,
install BIND 9 for NT and tell it to use the zones MSDNS exported. Stubborn
vendor's DNS replaced and new record types supported with little pain.
--
PGP key (0x0AFA039E):
<http://www.pan-am.ca/consulting(_at_)pan-am(_dot_)ca(_dot_)asc>
What's a PGP Key? See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET. <http://vmyths.com/rant.cfm?id=401&page=4>