Fwd: [ietf-dkim] New Issue: Use of XPTR records in SSP
steve at blighty.com
Tue Apr 17 22:03:13 PDT 2007
(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
>>> 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
>> 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
>> heard that some Microsoft products may have problems with new RR
>> 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
> 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
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
would deploy sooner (and the protocol support later).
> I think that the reality is that unless a new RR type is the only
> solution to a pressing problem, the internet will just route around
> roadblock and solve the problem another way.
The alternative phrasing is that if you cobble together some pseudo-
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
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.
More information about the ietf-dkim