http://www.dimensional.com/~mfuhr/perldns/
Although the module isn't available yet, there are a few manpages that
show what you'll be able to do. The Net::DNS and Net::DNS::Resolver
manpages have some code fragments as examples.
I originally called the module DNS but my current choice is Net::DNS,
which seems more consistent with the modules for other protocols such
as Net::FTP, Net::SMTP, etc. I'm open to other suggestions.
I'd appreciate any feedback on the info I've provided so far. Thanks.
--
Michael Fuhr
http://www.dimensional.com/~mfuhr/
Bravo. One sees queries after such a thing at least once a month. I've
been meaning to write one for a long time, but I never seem to get
around to it.
> I'd appreciate any feedback on the info I've provided so far.
Several times I've wanted a resolver interface which would let me do
queries in the background while I went on with other tasks. (Eg, an
implementation in which the library would let me know which fds it
wanted to listen to and write on and I'd stuff them into my main
select() and I'd call back to the resolver appropriately). This
functionality is a pretty big task, of course, but perhaps if it's not
too late and you can keep it in mind from the early stages it won't be
out of reach.
--
Roderick Schertler
rode...@gate.net
Roderick Schertler <rode...@gate.net> writes:
I just had to ask, didn't I :-) I'll keep that in mind, but don't
expect to see it in the early versions of the module. I suppose a
forked child could wait on a query while the parent went about its
business, then write the response back to the parent via a pipe.
This could be implemented on top of the resolver module, thus
requiring few if any changes to that module. I'll have to give it
some more thought.
Thanks for the input.
Sounds really good! I don't know why someone didn't think of this one
sooner. I can't wait for it to be done...
--
------------------------------------------------------------------
Rob Perelman ro...@eciti.com http://www.eciti.com/robp
San Diego Rocks sdr...@eciti.com http://www.eciti.com/sdrocks
------------------------------------------------------------------
In article <5c1jej$j...@nova.dimensional.com>,
Michael Fuhr <mf...@dimensional.com> wrote:
>I've been working on a general interface to the DNS resolver,
>allowing the programmer to look up any record type instead of
>just A (gethostbyname) and PTR (gethostbyaddr). I hope to have
>it finished by the end of Jan 1997; in the meantime, there's
>some info about it at:
>
> http://www.dimensional.com/~mfuhr/perldns/
>
>Although the module isn't available yet, there are a few manpages that
>show what you'll be able to do. The Net::DNS and Net::DNS::Resolver
>manpages have some code fragments as examples.
>
>I originally called the module DNS but my current choice is Net::DNS,
>which seems more consistent with the modules for other protocols such
>as Net::FTP, Net::SMTP, etc. I'm open to other suggestions.
>
>I'd appreciate any feedback on the info I've provided so far. Thanks.
- - You should look at Roland Schemer's lbnamed code. It implements a DNS
server in perl. It is available via
http://www-leland.stanford.edu/~schemers/dist/lb.tar
- - It includes a DNS.pm , but it should probably be renamed to Net::DNS.
My one quibble about the Net stuff is that it does not distinguish between
server and client code for the various protocols.
- - Booker C. Bense : bbe...@stanford.edu
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMuZf4QD83u1ILnWNAQEO5gP6AwtdtAH6blWmz87/fVEBOejOq86BR1LB
0e5A5hU00YrB0VfzJbUlzHleysF5sKSPBF/B1dNfhD2IoxCVmxS9oBY6ShbJo4a1
VdRt5Avp1boRClQEMiUAONoXifhIKXb282lvQ1FlPCIImWLQe4LC8nMYjiDz0Ldz
8L4PiFq6+rs=
=VlPB
-----END PGP SIGNATURE-----
bbense+comp.lang.perl.modules.@shred.stanford.edu writes:
>- - You should look at Roland Schemer's lbnamed code. It implements a DNS
>server in perl. It is available via
>
> http://www-leland.stanford.edu/~schemers/dist/lb.tar
Thanks - I'll take a look at it.
>- - It includes a DNS.pm , but it should probably be renamed to Net::DNS.
>My one quibble about the Net stuff is that it does not distinguish between
>server and client code for the various protocols.
With my module there'll be nothing in Net::DNS itself - that just
serves as a top-level abstraction. The classes are:
Net::DNS::Resolver - the client side of a DNS request
Net::DNS::Packet - DNS packet
Net::DNS::Header - header section of a DNS packet
Net::DNS::Question - question section of a DNS packet
Net::DNS::RR - base class for resource record types
The answer, authority, and additional sections of a DNS packet
will be lists of Net::DNS::RR objects.
With this setup, one could add a Net::DNS::Nameserver class to
take a server role.
> Several times I've wanted a resolver interface which would let me do
> queries in the background while I went on with other tasks. (Eg, an
> implementation in which the library would let me know which fds it
> wanted to listen to and write on and I'd stuff them into my main
> select() and I'd call back to the resolver appropriately).
I have this almost completely written, although the method I use (forking
off a separate process to do the DNS calls and exchanging information
across a Unix domain socket) isn't ideal. The "server" is written in C;
the client library will be both C and Perl.
I don't have anything completed to the point where I can show it to
anyone, but just in case someone else was considering embarking on a
similar project, this is a heads-up.
--
Russ Allbery (r...@cs.stanford.edu) <URL:http://www.eyrie.org/~eagle/>