1. maximum hubris: do it all the perl way, use modules, and as portable as anybody could wish. But see next rule.
2. maximum impatience: get it done. That means, if you are familiar with nslookup or dig, stick to them, parse their output - hey, there's nothing bad calling an external program specialized for the task. Mark code that needs (or could need) a revision in a transition towards the goal of the previous rule.
3. maximum laziness: let others do the job. Grab appropriate modules for all tasks. How do you know they are appropriate? Eeek, you have to read their documentation, how bad. For maximum laziness, look at the modules' dependencies. Loading Net::DNS means loading 37 modules. While most are core, some have to be installed (and updated eventually!). Umm... work. But that's how it goes - to be lazy, you need time to spend.

So, contradictions. These can be put in-line looking at other constraints. How much time have you got? You need to get familiar with perl, and with the modules. To get familiar with Net::DNS you need not read the 37 manual pages for the 37 modules loaded, but the main ones of the module. At the end, having read all of them is a big win. But just now?

Then, Is portability required, and to what extent? Are you willing to upgrade / improve your script? Remember, as Aristotle says - and I agree - makeshifts last the longest, and you might write stinkin' crap instead of loading "a module or two" (heh.. 37 to INF :-) which sits around as a symbolic link: "that's the guy that wrote me! blame him!"

As for using awk, grep, sed, ksh etc from inside perl - if you don't know how to do your tasks without them in pure perl, come back with the specific issue and ask; but using them from inside perl is mostly...silly :-)

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}