ietf-mxcomp
[Top] [All Lists]

RE: suggested new RRtype experiment

2004-05-20 16:24:42

This is in general not possible on Windows, since, depending on
configuration, the DNS APIs don't actually speak UDP off of the host in
question but rather do remote procedure calls RPCs to remote systems
(usually firewalls) to do the work for them. There is no reasonable way
in an application to detect this configuration, let alone work around
it.

A new RR type really is a show stopper. Please believe me on this; I've
looked long and hard over the last year+ at alternatives, and there
isn't one.


-----Original Message-----
From: Eric A. Hall [mailto:ehall(_at_)ehsco(_dot_)com]
Sent: Thursday, May 20, 2004 3:59 PM
To: Yakov Shafranovich
Cc: Bob Atkinson; IETF MARID WG
Subject: Re: suggested new RRtype experiment


On 5/20/2004 3:02 PM, Yakov Shafranovich wrote:

So let me get this straight: if MARID defines a new RR type, Windows
will not be able to support it?

People have been dealing with resolver limitations for years and not
just
for Windows. In the usual case, they deal with it by embedding their
own
resolver into the app that does whatever heavy lifting is needed,
while
passing simple calls you can to the native APIs. Even implementors of
the
mail-submission and -retrieval SRV records
[draft-hall-mail-srv-01.txt]
have run into this problem because SRV is not supported in earlier
versions of the Windows resolver (or in many of the resolvers on
several
other platforms for that matter).

Is bundling a resolver lib into your app show-stopping? I mean, that's
really the test for how important this work is: either its more
important
than the work required to build a resolver function, or it isn't.

The server part of the problem is a bit more fuzzy but is less
difficult
than the client side.

--
Eric A. Hall
http://www.ehsco.com/
Internet Core Protocols
http://www.oreilly.com/catalog/coreprot/