Category list

Chapter 7. The DNS Tool Chest

The Internet

Maintenance Tools

Quality Control

The Internet

I'm risking sounding trite, but the Web—and Internet in general—is an important tool. It's especially important for DNS. The newsgroups and mailing lists mentioned in Chapter 15, "Compiling and Maintaining BIND," are excellent places to learn of, and about, DNS and the tools people use. If you don't have time to read them everyday, they are still an excellent resource if accessed through a service such as the Usenet archive at deja.com, which has a searchable archive of news. If in doubt, search there first. The URL is http://www.deja.com/usenet.

Web sites do, of course, exist that are dedicated to DNS. One of the best known is the DNS Resources Directory at http://www.dns.net/dnsrd/. It is really the only URL you'll ever need when it comes to DNS. A separate, very extensive , Tools to Manage DNS page is also available there.

Internet-Based Tools

Getting someone else's view of your domain can be useful, especially if you are experiencing complaints from outside your organization about things not working, and you can't figure out why from the inside.

ZoneCheck

ZoneCheck is a Web-based tool used by the French NIC to enable their clients to check whether the zones they want to register are available. You can use this prior to registration, and periodically thereafter. It is at http://www.nic.fr/zonecheck/english.html. You also will find the source code there.

DigIt

DigIt is a Web interface to dig provided by Men&Mice. It enables you to see how your domain resolves from the outside, using the nameserver at Men&Mice if you want. Its URL is http://us.mirror.menandmice.com/cgi-bin/DoDig.

Internet Query Tools

This very diverse service is provided by Demon Internet. It lets you check almost anything you can think of, including whois lookups. You can find it at http://www.demon.net/external/ntools.shtml.

Maintenance Tools

A large class of the tools called maintenance tools helps you maintain zone files in various ways. The following are some of them.

h2n

h2n is a popular tool; it's a Perl script written by Cricket Liu, one of the authors of the O'Reilly book DNS and BIND. h2n formats a /etc/ hosts style file into DNS zone files and a BIND 4 or 8 configuration file. The software is available from the O'Reilly FTP site, but the most updated version is included in the BIND 8 contrib bundle in the directory nutshell . It's a simple, yet effective tool. Consider this /etc/hosts file:

195.0.166.251   lookfar.linpro.no
195.0.166.130   rcp.linpro.no   rcp
195.0.166.200   nfsd.linpro.no  nfsd
195.0.166.201   false.linpro.no false
195.0.166.2     mail.linpro.no  mail
195.0.166.140   lpd.linpro.no   lpd

In addition, consider this simple command: h2n -v 8 -d linpro.no -n 195.0.166 . From it, you get several files:

`named.boot`	Named in the style of BIND 4, but containing BIND 8 `named.conf` syntax
`db.127.0.0`	The reverse lookup file for the 127.0.0 network
`db.linpro`	The forward file for the linpro.no domain
`db.195.0.166`	The reverse lookup file for the 195.0.166 network

The following is the db.linpro file it produced:

@ IN  SOA lookfar.linpro.no. root.lookfar.linpro.no. (
          2 10800 3600 604800 86400 )
  IN  NS  lookfar.linpro.no.

localhost            IN  A     127.0.0.1
lpd                  IN  A     195.0.166.140
lpd                  IN  MX    10 lpd.linpro.no.
mail                 IN  A     195.0.166.2
mail                 IN  MX    10 mail.linpro.no.
false                IN  A     195.0.166.201
false                IN  MX    10 false.linpro.no.
nfsd                 IN  A     195.0.166.200
nfsd                 IN  MX    10 nfsd.linpro.no.
rcp                  IN  A     195.0.166.130
rcp                  IN  MX    10 rcp.linpro.no.
lookfar              IN  A     195.0.166.251
lookfar              IN  MX    10 lookfar.linpro.no.

Either these files can be used as starting points for maintaining your DNS or the entire maintenance of your DNS can be based on h2n. Each time h2n is run, it rewrites the files, all the while maintaining the SOA record sequence number in the correct manner. That, however, is the only thing saved from the zone files; any changes you might have made to them are lost. If you maintain a hosts file in NIS (the name service formerly known as YP), h2n can be used to trivially generate zone files from it. h2n has a rich set of options, making it powerful enough to be used for almost anything.

As you might have noticed, each host in the previous zone file is its own mail server. You can suppress all MX records with the -M option, and you can add MX records with the -m option.

If you feel more comfortable with the hosts format, or simply like the idea of maintaining just one file instead of all the files BIND needs to work—and h2n is powerful enough for you—this is a good tool. In addition, it is written in Perl and therefore is easy to hack if you know how to program.

Webmin

Webmin is a GUI UNIX administration tool. It can do a lot of things, among which is DNS management. Plus, it can work with both BIND 4 and 8. Webmin has not even reached version 1 as I write this; it's at 0.80 and is already spoken well of on the Net. Its home page is at http://www.webmin.com/webmin/. Figures 7.1 and 7.2 show a browser-based interface, to named.conf , and all the zone files you manage, letting you add, delete, and alter zones and records. It supports setting all types of parameters, globally and per zone as BIND allows. Additionally, it can use https , as well as http, as a transport.

Figure 7.1. Webmins BIND 8 interface.

graphics/07fig01.gif

mkrdns

mkrdns takes care of writing reverse zone files for you. Given a named.conf file and a set of forward zones, written by you, it will write the appropriate reverse zone files. You must have the files for all the forward zones that use the given reverse zones to be able to do this, but the advantage is that one source of errors is eliminated—your reverse zones will match your forward ones. One reverse zone can correspond to several forward zones, and mkrdns needs all of them to be available locally. If you're not the master for the zones, you should make reverse maps to enable you to at least be a slave. However, you can very easily just enter slave zone entries in named.conf to gather the necessary data.

Figure 7.2. Editing penguin.bv A records and the reverse zone.

graphics/07fig02.gif

You can leave mkrdns directives embedded in your named.conf file, hiding them from BIND as comments. The map directive enables mkrdns to support classless reverse zones. The serialt directive, on the other hand, controls which kind of serial numbers you use. In other words, it controls whether you use a serial number in the YYYYMMDDNN date format, which is traditional, or whether you simply use a number. Handling it as a number enables you to make more than 100 changes in a day, and this is, perhaps, why BIND's dynamic zones are maintained with a numerical serial number as well. The serial number format can be global or zone by zone.

The skip directive instructs mkrdns to ignore certain records when generating the reverse zone. This enables you to create multiple A records for one address, but to have only one PTR record for the same address, as expected. It also enables you to ignore addresses whose reverse zone you're not responsible for. mkrdns also entirely skips zones named with the skipzone directive, because you do not maintain the reverse zones for the addresses used in that forward zone.