The saga continues

triv on 2002-06-24T17:27:02

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.


Win2K DNS bug

dws on 2002-06-24T19:54:08

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.