Subject: SRV resolver API?

From: "John S. Bucy" <[email-masked]>
Date: Mon, 15 Nov 2004 21:35:51 -0500

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]

It seems like the uptake on SRV has been very slow.  As an application
developer, on more than one occassion now, I've wanted to use SRV and
been stymied by the unavailability of resolver implementations.  To my
knowledge, there are only 2 opensource implementations: RULI and adns
which are both GPLed. In any case, there isn't one in libc/libresolv
on any Unix platform that I know of.  The DnsQuery() API in Windows
appears to handle SRV as of Win2K/XP.

I'd like to suggest that part of the problem -- at least on the Unix
side -- is that there isn't a standardized resolver API for SRV.  The
IPv6 effort came up with getaddrinfo() and friends in rfc2553; its
gone into POSIX as well.  Why haven't we standardized a resolver API
for SRV?

john

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Nov 2004 14:43:44 +0000

> appears to handle SRV as of Win2K/XP.

bind8/contrib/srv/ contains arnt gulbrandsen's work in this area, which
while inadequate as the basis for a POSIX API, is adequate for application
work.  it's been in bind8/contrib/ since 1998.

> gone into POSIX as well.  Why haven't we standardized a resolver API

more broadly than that, a full dns client-side api is needed.  we drafted
one a couple of years ago but couldn't find the funding for it.  c and c++
programmers should have the same high level access to the dns protocol that
perl programmers have (through the excellent Net::DNS module).

---

From: [email-masked]
Date: Tue, 16 Nov 2004 10:41:32 -0500

----- Original Message Follows -----
> > side -- is that there isn't a standardized resolver API for SRV. 
> > The IPv6 effort came up with getaddrinfo() and friends in rfc2553;
> > its gone into POSIX as well.  Why haven't we standardized a resolver
> > API for SRV?
> 
> more broadly than that, a full dns client-side api is needed.  we
> drafted one a couple of years ago but couldn't find the funding for
> it.  c and c++ programmers should have the same high level access to
> the dns protocol that perl programmers have (through the excellent
> Net::DNS module).
> 

Paul, is the funding needed for the work to get the standardization
pushed
through the various standards bodies or for the implementation?

Danny

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Nov 2004 16:51:27 +0000

> pushed through the various standards bodies or for the implementation?

depends on which standards body you mean.  the advanced bsd api rfc for
ipv6 seems to have resulted, for the first time ever, in portability of
socket-api applications.  the posix socket api wasn't able to achieve
this in the ipv4 days -- there were way more #ifdef's then than now.

i believe two things.  first, in the power of implementation.  the glibc
project has created a defacto standard that's a superset of ansi/posix,
and the original bsd socket api (by which i intend to include things like
gethostbyname) and the original bsd dns api (by which i mean to include
things like res_query()) have been wildly successful, widely emulated
on non-unix platforms, and generally acceptable.

second, in the danger of the power of implementation.  more reviewers and
more creative minds would have caught a lot of errors and omissions early
on which are still painful today because implementation was so powerful.

while ietf's charter is all about on-the-wire protocols and formats, it
did good work with the advanced bsd api rfc for ipv6, and i think that
doing an advanced dns api rfc would be just as successful.

isc's original funding request to the "bind vendors" on this topic 
included both an openly-developed api, and an open-source implementation
of it.