Using Net::DNS - DNS Checking: An Iterative Approach

Chapter 5. TCP/IP Name Services

5.3. Domain Name Service (DNS)

5.3.2. DNS Checking: An Iterative Approach

5.3.2.3. Using Net::DNS

It may be as fast or faster than calling an external program.

•

It is easier to tweak the parameters of the situation (timeouts, etc.).

The drawbacks of this approach are:

•

It's likely to take longer to write and is more complex than the previous approach.

•

It requires more knowledge external to the direct problem at hand (i.e., you may have to learn how to put DNS packets together by hand, something we did not need to know when we called nslookup).

•

You may have to handle OS−specific issues yourself (hidden in the previous approach by the work already done by the external program's author).

5.3.2.3. Using Net::DNS

As mentioned in Chapter 1, "Introduction", one of Perl's real strengths is the support of a large community of developers who churn out code for others to reuse. If there's something you need to do in Perl that seems universal, chances are good that someone else has already written a module to handle it. In our case, we can make use of Michael Fuhr's excellent Net::DNS module to make our job simpler. For our task, we simply have to create a new DNS resolver object, configure it with the name of the DNS server we wish to use, ask it to send a query, and then use the supplied methods to parse the response:

use Net::DNS;

@servers = qw(nameserver1 nameserver2 nameserver3); # name of the name servers foreach $server (@servers) {

&lookupaddress($hostname,$server); # populates %results }

%inv = reverse %results; # invert the result hash if (scalar(keys %inv) > 1) { # see how many elements it has print "There is a discrepency between DNS servers:\n";

use Data::Dumper;

print Data::Dumper−>Dump([\%results],["results"]),"\n";

}

# only slightly modified from example in the Net::DNS manpage sub lookupaddress{

my($hostname,$server) = @_;

$res = new Net::DNS::Resolver;

$res−>nameservers($server);

$packet = $res−>query($hostname);

if (!$packet) {

warn "Unable to lookup data for $hostname from $server!\n";

return;

}

5.3.2.3. Using Net::DNS 186

# stores the last RR we receive foreach $rr ($packet−>answer) {

$results{$server}=$rr−>address;

} }

The benefits of this approach are:

•

The code is legible again.

•

It is often faster to write.

•

Depending on how the module you use is implemented (is it pure Perl or is it glue to a set of C or C++

library calls?) the code you write using this module may be just as fast as calling an external compiled program.

•

It is potentially portable, depending on how much work the author of the module has done for you.

Any place this module can be installed, your program can run.

•

As in the first approach we looked at, writing code can be quick and easy if someone else has done the behind−the−scenes work for you. You don't have to know how the module works; you just need to know how to use it.

•

Code re−use. You are not reinventing the wheel each time.

The drawbacks of this approach are:

•

You are back in the dependency game. This time you need to make sure this module is available for your program to run. You need to trust that the module writer has done a decent job.

•

There may not be a module to do what you need, or it may not run on the operating system of choice.

More often than not, a pre−written module is my preferred approach. However, any of these approaches will get the job done. TMTOWTDI, so go forth and do it!

5.2. NIS, NIS+, and WINS 5.4. Module Information

for This Chapter

The Five−Minute RCS Tutorial (Perl for System Administration)

5.3.2.3. Using Net::DNS 187

Chapter 5: TCP/IP Name Services

5.4. Module Information for This Chapter

Module CPAN ID Version

Rcs CFRETER 0.09

Net::NIS RIK a2

Data::Dumper (ships with Perl) GSAR 2.101 IO::Socket (ships with Perl) GBARR 1.20

Net::DNS MFUHR 0.12

5.3. Domain Name Service (DNS)

5.5. References for More Information

Chapter 5: TCP/IP Name Services

5.5. References for More Information

DNS and BIND, 3rd Edition, by Paul Albitz and Cricket Liu (O'Reilly, 1998).

RFC849: Suggestions For Improved Host Table Distribution, Mark Crispin, 1983.

RFC881: The Domain Names Plan and Schedule, J. Postel, 1983.

RFC882: Domain Names: Concepts And Facilities, P. Mockapetris, 1983.

RFC1035: Domain Names: Implementation And Specification, P. Mockapetris, 1987.

6. Directory Services

5.4. Module Information for This Chapter 188

5.4. Module Information for This Chapter

Perl for System Administration

The Five−Minute RCS Tutorial (Perl for System Administration)

5.4. Module Information for This Chapter 189

Contents:

What's a Directory?

Finger: A Simple Directory Service The WHOIS Directory Service

LDAP: A Sophisticated Directory Service ADSI (Active Directory Service Interfaces) Module Information for This Chapter References for More Information

The larger the information system, the harder it becomes to find anything in that system or even know what's available. As networks grow and become more complex, they are well served by some sort of directory.

Network users might make use of a directory service to find other users for email and other messaging services. Resources on a network, like printers and network−available disk areas, might be advertised via a directory service. Public−key and certificate infrastructures could use a directory service to distribute information. In this chapter we'll look at how to use Perl to interact with some of the more popular directory services, including Finger, WHOIS, LDAP, and ADSI.

In document The Five Minute RCS Tutorial (Perl for System Administration (Page 193-197)