Hi,
Quoting UDNS:
"Most applications that requires asyncronous DNS processing either implements
their own resolver modules (which, again, is not a trivial task, and sometimes
leads to incompatibilities with other resolver libraries and bugs which are
difficult to find), or uses forked-resolver model, where separate process is
forked just to perform DNS queries, which requires quite some resources,
especially when an application already have some sort of event loop in place
to multiplex I/O. Asyncronous DNS resolver is a must for many nowadays
applications, such as GUI (GUI-application should not stop processing user
interface events while performing DNS queries), high-performance servers (such
as mail servers) using event-loop model (see for example an excellent "The
C10K problem" page at kegel.com describing various methods to handle many
client requests in parallel)."
So you are forewarned it is not a trivial task. :( Then again what do we need?
Reading documentation on most libs reveals that the problems start with the
other stuff, not so much with A_NAME and AAAA_NAME records. But then again,
when that part is not too hard, why not use an available library for that that
is at least good at that?
Thanx,
Jaap
Stephen Fisher wrote:
All very interesting alternatives to adns. I found a few others
searching the Internet. Why is everyone starting but not maintaining an
async dns library? :) I don't like adns because it isn't maintained very
much, but I'm afraid of trying something else and it being less stable.
Maybe this is something we should build into Wireshark since it is such
an important feature? Lots of work I'm sure. What made me think of
this was running across old web pages talking about Netscape and its
built-in(?) async dns resolver ;).
Steve