(Sorry for the duplicate, Scott. I bet you wondered why I mailed
you off-list to agree with you. :) ).
On Apr 17, 2007, at 9:13 PM, Scott Kitterman wrote:
On Tuesday 17 April 2007 23:40, Jim Fenton wrote:
Scott Kitterman wrote:
Additional arguement Con is that a new RR type takes a LONG time to
deploy.
In 2 - 5 years when this new RR type is deployed, whatever
problem it was
trying to solve will likely be solved some other way.
I know this has come up before; I have long been searching for
specifics
on what needs to be updated. Name servers? Resolvers? Caches?
I know
you can do this today with current and recent versions of BIND. I
have
heard that some Microsoft products may have problems with new RR
types,
but real facts have been elusive.
The only recent parallel that I'm aware of if the new RR Type for
SPF. It
will be two years ago in July when the type was assigned. Within a
week of
the assignment a few domains where publishing Type 99 records (and
those of
us that maintain the Python SPF library had Type 99 support
implemented in
about the same amount of time). So, yes. Rapid deployment for
test use is
possible.
That is not the same thing as something that gets deployed for
production use.
The first version of BIND that natively supports Type SPF was just
recently
released.
But there was much less urgency for that as nobody will ever need
to use it. For SPF TXT records are there, and they work today. If the
RR support were needed before the protocol could be deployed the RR
support
would deploy sooner (and the protocol support later).
I think that the reality is that unless a new RR type is the only
possible
solution to a pressing problem, the internet will just route around
the
roadblock and solve the problem another way.
The alternative phrasing is that if you cobble together some pseudo-
syntax
and stuff it in a TXT record "just until you get a real RR" then you'll
have a deployed base of TXT records and never move it all over to
the new RR.
At that point the only thing the new RR adds is the requirement to
do two DNS queries, rather than one, as you'll still need to be checking
TXT forever.
When the issue has come up before the usual problem that's claimed
is not dns servers or resolvers, so much as management software,
web interfaces to manage dns records and so on. I don't really
buy that, but it's something that probably needs to be answered.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html