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:
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.
On 20 Jan 1997 22:16:03 -0700, mf...@dimensional.com (Michael Fuhr) said:
> 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).
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 <roder...@gate.net> writes: >On 20 Jan 1997 22:16:03 -0700, mf...@dimensional.com (Michael Fuhr) said: >> 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.
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.
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:
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 r...@eciti.com http://www.eciti.com/robp San Diego Rocks sdro...@eciti.com http://www.eciti.com/sdrocks ------------------------------------------------------------------
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:
>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
- - 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.
bbense+comp.lang.perl.modul...@shred.stanford.edu writes: >- - You should look at Roland Schemer's lbnamed code. It implements a DNS >server in perl. It is available via
>- - 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.
Roderick Schertler <roder...@gate.net> writes: > 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.
|
