At 01:47 AM 9/6/2004, Bill McQuillan wrote:
On Sun, 2004-09-05, Mark wrote:
> If we require an underscored _marid prefix to prevent potential collisions
> with existing namespace, are we then not dealing with a circular reasoning
> here?
> I mean, if the underscore prefix is not widely deployed because few DNS
> providers support it, then choosing an underscored prefix to avoid
collision
> leads to having to make world-wide changes to providers' User
Interfaces, so
> that the _marid prefic can be widely deployed; after which time you
lost the
> advantage again of not running the risk of collision.
I believe the reason for the underscore is that it is, in fact, NOT a
valid *hostname* character, but it IS valid in a domain name. It seems to
be a common, but incorrect, belief that DNS is only for hostnames.
So let me get this straight.
Folks are worried about the companies some people outsource their DNS to
(instead of running their own servers) not handling _marid or _foo or
whatever the tag would be. But folks are not worried about updating name
server software to support a new RR type and getting that software
deployed, and are not worried about getting MTA software updated to handle
new a new capability and get that deployed.
Am I the only one who thinks this is looney? If SPF or SenderID become
accepted, then people will update MTA software to make it work. They will
update DNS server software to make it work. And if outsourced DNS providers
wish to remain competitive, they'll add capabilities to their GUIs. Let the
market handle it.
It sure seems like folks are getting hung up over what's probably the
EASIEST thing to deal with, that being finding a DNS outsourcer (if you
even need one) that'll publish the records you request.
Let's get back to deciding what's right at the protocol level, and leave
the business decisions of web-interfaced DNS providers out of the discussion.
I, for one, would like to hear more on the technical merits of using _spf
or _marid or _foo vs. not using it.