Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

triv (2745)

triv
  reversethis-{gro.virt} {ta} {lrep.esu}
http://www.triv.org/

I hack perl for dyndns.org, I maintain Net::DNS, I play drums in a band.. I do this, I do that.. yada yada yada...

Journal of triv (2745)

Monday June 24, 2002
12:27 PM

The saga continues

[ #5905 ]

Got activeperl installed on XP under Virtual PC. Installed nmake, installed Net::DNS. Can't reproduce the bug. (The bug being the Net::DNS::Resolver doesn't get the right IP for the local recursive DNS server.)

However, the bug report was for windows 2000. So I install w2k, activeperl, nmake, and Net::DNS. And... I can't reproduce the darn bug!

On the plus side I had an epiphany last night about how Net::DNS::Resolver should be reorganized. Right now it's very monolithic, with lots of the "copy and paste" code reuse methodology.

I don't have the details plained out, I have to wade though the code and figure those out, but here is my plan:

Net::DNS::Resolver keeps the same interface, it's for setting options, building packets to be sent, and getting the results of sending those packets. Interally, it uses Net::DNS::Connection::UDP or Net::DNS::Connection::TCP classes, instead of Net::DNS::Resolver::send_tcp() or Net::DNS::Resolver::send_udp(). To keep the options going back and forth nicely, I'm leaning towards some sort of options object, but that's not in stone.

I'm thinking that Net::DNS::Connection will be a super class of Net::DNS::Connection::UDP and TCP. The super class will be smart and try UDP first, and then use TCP if you run into packet fragmentation. (Or if you're doing a AXFR....)

I currently have Resolver.pm in peices scattered around my home directory. I'm also working on Text::ReflowEmail. But that's a whole other story.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • This might relate, or it might not: There's bug under Win2K (workstation, at least), where Win2K loses track of its primary DNS, and falls back on using the secondary. Our secondary was outside of our firewall. This caused us no end of grief until we identified the problem and worked around it by ensuring that we had an inside-the-firewall secondary that the same answers as the inside-the-firewall primary. I don't know if Microsoft has fixed this yet.