Quality Control


Quality control tools are tools that will help you ensure that your zone data and DNS service are healthy and consistent. You should use some of them regularly to check certain things. For example, you should use dnswalk alone or DOC combined with nslint to check both your delegations and zone contents.

dnswalk

dnswalk, a Perl program that has been around a while, walks through your zone(s), looking at its contents and checking those contents. It also performs several sanity and consistency checks on your domain and subdomains. A version of dnswalk resides in the BIND contrib directory. That version does have some problems, though. Fortunately, another version is available, which can be found at http://sourceforge.net/project/?group_id=1103. Its homepage is at http://www.visi.com/~barr/dnswalk/. dnswalk is a complete rewrite using the Net::DNS Perl module instead of various command-line tools, which gives it a robust base for future development.

The following is an example:

 $ ./dnswalk -rFl linpro.no. Checking linpro.no. Getting zone transfer of linpro.no. from smp.linpro.no...done. SOA=smp.linpro.no       contact=hostmaster.linpro.no BAD: linpro.no NS ns1.xtn.net: lame NS delegation WARN: loghost.linpro.no CNAME pot.linpro.no: unknown host WARN: covehold.frs.linpro.no A 193.212.244.37: no PTR record Checking ddns.linpro.no BAD: ddns.linpro.no has only one authoritative nameserver Getting zone transfer of ddns.linpro.no from smp.linpro.no...done. SOA=smp.linpro.no       contact=hostmaster.linpro.no WARN: mangellan.ddns.linpro.no A 192.168.55.200: no PTR record 0 failures, 3 warnings, 2 errors. 

In the first warning, pot refers to the Norwegian civil surveillance organization, Politiets ÅkningsTjeneste. Linpro obviously hasn't bothered to do more than enter a joke CNAME record for loghost. Someone also forgot to enter a reverse record for covehold.frs.linpro.no. But, worst of all, only one nameserver is available for our ddns experiment ddns.linpro.no and no reverse exists for mangellan, either.

The -F (fascist checking) switch is particularly useful, because it checks whether your A and PTR records match up. If you maintain your zones by hand, as many people do, having a software tool check for you is very beneficial. Another switch, the -l switch, enables lame delegation checking, which detects servers that are listed as authoritative but are not answering as if they are. In the Linpro example, ns1.xtn.net is such a server. The -r switch simply turns on recursion, causing subdomains of Linpro to be checked, in this case, it's ddns.linpro.no.

The original dnswalk was written alongside RFC 1912, "Common DNS Operational and Configuration Errors," and checks for the errors mentioned there.

DOC

DOC (Domain Obscenity Control) is another tool that interrogates the DNS, looking for problems. It is a collection of csh and awk scripts distributed in the BIND contrib bundle in contrib/doc to be exact. A more current version might be available at the FTP site (ftp://ftp.his.com/pub/brad/dns/>,) but you should also check the DNS Resource Directory Web site mentioned earlier in this chapter.

The following is an example:

 $ doc -v linpro.no Doc-2.1.4: doc -v linpro.no Doc-2.1.4: Starting test of linpro.no.   parent is no. Doc-2.1.4: Test date - Sat Aug  5 11:08:18 CEST 2000 soa @ifi.uio.no. for no. has serial: 2000080461 soa @nac.no. for no. has serial: 2000080461 soa @nn.uninett.no. for no. has serial: 2000080461 soa @ns.eu.net. for no. has serial: 2000080461 soa @ns.uu.net. for no. has serial: 2000080360 WARNING: Found 2 unique SOA serial #'s for no. Found 3 NS and 3 glue records for linpro.no. @ifi.uio.no. (AUTH) Found 3 NS and 3 glue records for linpro.no. @nac.no. (non-AUTH) Found 3 NS and 3 glue records for linpro.no. @nn.uninett.no. (non-AUTH) Found 3 NS and 3 glue records for linpro.no. @ns.eu.net. (non-AUTH) Found 3 NS and 3 glue records for linpro.no. @ns.uu.net. (non-AUTH) DNServers for no.    === 1 were also authoritatve for linpro.no.    === 4 were non-authoritative for linpro.no. Servers for no. (not also authoritative for linpro.no.)    === agree on NS records for linpro.no. NS lists for linpro.no. from all no. servers are identical    === (both authoritative and non-authoritative for linpro.no.) NS list summary for linpro.no. from parent (no.) servers   == ifi.uio.no. ns1.xtn.net. smp.linpro.no. soa @ifi.uio.no. for linpro.no. serial: 2000080401 soa @ns1.xtn.net. for linpro.no. serial: 2000080401 ERROR: non-authoritative SOA for linpro.no. from ns1.xtn.net. soa @smp.linpro.no. for linpro.no. serial: 2000080401 SOA serial #'s agree for linpro.no. WARN: SOA records differ for linpro.no. from authoritative servers Authoritative domain (linpro.no.) servers agree on NS for linpro.no. NS list from linpro.no. authoritative servers matches list from   === all parent (no.) servers Checking 1 potential addresses for hosts at linpro.no.   == 195.0.166.3 in-addr PTR record found for 195.0.166.3 Summary:    ERRORS found for linpro.no. (count: 1)    WARNINGS issued for linpro.no. (count: 2) Done testing linpro.no.  Sat Aug  5 11:08:26 CEST 2000 

As the previous example shows, DOC does not perform the same checks as dnswalk. DOC also does not come with a published RFC like dnswalk does; however, DOC does come with a draft RFC, as well as a man page that describes the tests DOC implements. DOC checks the structure of your domains, the delegations, the SOA records, and the NS and A records. It does not verify the zone contents beyond that. If you plan to use it, it should be combined with a tool that checks zone contents, such as nslint.

nslint

The traditional C programmer's tool lint is described thus in the Solaris man page: "lint detects features of C program files which are likely to be bugs, nonportable, or wasteful." nslint, on the other hand, checks your zone files. You can find a copy in the BIND contrib directory, but the home site (ftp://ftp.ee.lbl.gov/) is likely to contain a newer version. nslint is written in C and comes with a GNU automatic configure script, so it is very easy to compile. In addition, nslint reads your /etc/named.conf file and finds all the domains it defines and then checks your zone files. Similar to its C equivalent it is very picky. See the following example:

 $ nslint nslint: /var/named/pz/penguin.bv:22 "ns" target missing trailing dot:         ns.emperor nslint: /var/named/pz/penguin.bv:24 "a" name missing trailing dot:         ns.emperor nslint: /var/named/pz/192.168.56:20 bad ttl nslint: /var/named/pz/192.168.56:22 bad ttl nslint: missing "ptr": ns.penguin.bv. -> 192.168.55.2 nslint: missing "ptr": ns.emperor.penguin.bv. -> 192.168.56.3 nslint: missing "ptr": penguin.bv. -> 192.168.55.3 nslint: name referenced without other records: mail.herring.bv. nslint: missing "a": localhost. -> 127.0.0.1 nslint: missing "ptr": localhost.penguin.bv. -> 127.0.0.1 nslint: 127.0.0.1 in use by localhost.penguin.bv. and localhost. nslint: 192.168.55.2 in use by mail.penguin.bv. and ns.penguin.bv. nslint: 192.168.55.3 in use by www.penguin.bv. and penguin.bv. 

In this example, nslint complains about valid constructs, but not without reason: Some of the valid constructs I've used in the Penguin zone files are, in some ways, risky and should perhaps be avoided. nslint is a very useful tool, but it is also a strict master. The upside is that tools such as dnswalk probably will not find anything to complain about if you verify your zones with nslint. But, if you use it, you should change your zone style to suit it, not you especially if several people are maintaining the zone files using nslint, or dnswalk.

All the bad ttl messages stem from the fact that the nslint version I tested does not understand the new 1D, 1H, and so on, on syntax that BIND supports.

nsping

nsping is a more system- and network-oriented tool. It sends DNS query packets to a server, measures how long it takes to get an answer, and determines whether the answer arrives at all. In this way, it is very much like the ordinary network ping tool. If you run FreeBSD, you will find nsping in the ports collection, but it is also available as source code from http://www.entract.com/-tqbf/nsping.tar.gz. However, running FreeBSD and getting it from the ports collection is your best bet for getting it running. The following is an example:

 $ nsping -h www.world-online.no ns000.world-online.no NSPING ns000.world-online.no (213.142.64.170): Hostname         "www.world-online.no", Type = "IN A" + [  0 ]   204 bytes from 213.142.64.170:   9.304 ms [   0.000 san-avg ] + [  1 ]   204 bytes from 213.142.64.170:  11.241 ms [  10.273 san-avg ] + [  2 ]   204 bytes from 213.142.64.170:   9.880 ms [  10.142 san-avg ] + [  3 ]   204 bytes from 213.142.64.170:   9.922 ms [  10.087 san-avg ] + [  4 ]   204 bytes from 213.142.64.170:   9.924 ms [  10.054 san-avg ] + [  5 ]   204 bytes from 213.142.64.170:   9.916 ms [  10.031 san-avg ] + [  6 ]   204 bytes from 213.142.64.170:  10.286 ms [  10.068 san-avg ] + [  7 ]   204 bytes from 213.142.64.170:   9.924 ms [  10.050 san-avg ] ^C Total Sent: [  8 ] Total Received: [  8 ] Missed: [  0 ] Lagged [  0 ] Ave/Max/Min:   10.050 /   11.241 /    9.304 

If packet loss occurs, you might be experiencing a network or server (or BIND) problem. This is useful to know because such things are usually hidden by retransmission strategies in the resolver library and recursive servers.

Software such as top, trafshow, and netstat show you your resource usage and pinpoint resource hogs. If no problems occur on the server or with its network interfaces, you can check the network with the usual ping tool. However, if that shows problems, you should alert the network administrator(s). But, if no problems show up, you can lean back and feel happy and confident about your DNS installation and how it works for your clients.

My thanks to Anders Nordby of WorldOnline for help with nsping.



The Concise Guide to DNS and BIND
The Concise Guide to DNS and BIND
ISBN: 0789722739
EAN: 2147483647
Year: 1999
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net