12. Reading BIND Debugging Output

Contents:
Debugging Levels
Turning On Debugging
Reading Debugging Output
The Resolver Search Algorithm and Negative Caching
Tools

"O Tiger-lily!" said Alice, addressing herself to one that was waving gracefully about in the wind, "I wish you could talk!"

"We can talk," said the Tiger-lily, "when there's anybody worth talking to."

One of the tools in your troubleshooting toolchest is the name server's debugging output. As long as your name server has been compiled with DEBUG defined, you can get query-by-query reports of its internal operation. The messages you get are often quite cryptic; they were meant for someone who has the source code to follow. We'll explain some of the debugging output in this chapter. Our goal is to cover enough for you to follow what the name server is doing; we aren't trying to supply an exhaustive compilation of debugging messages.

As you read through the explanations here, think back to material covered in earlier chapters. Seeing this information again, in another context, should help you understand more fully how a name server works.

12.1 Debugging Levels

The amount of information the name server provides depends on the debugging level. The lower the debugging level, the less information you get. Higher debugging levels give you more information, but they also fill up your disk faster. After you've read a lot of debugging output, you'll develop a feel for how much information you'll need to solve any particular problem. Of course, if you can easily recreate the problem, you can start at level 1 and increase the debugging level until you have enough information. For the most basic problem - why a name can't be looked up - level 1 will often suffice, so you should start there.

12.1.1 What Information Is at Each Level?

Here is a list of the information that each debugging level will give. The debugging information is cumulative; for example, level 2 includes all level 1's debugging information. The data are divided into the following basic areas: starting up, updating the database, processing queries, and maintaining zones. We won't cover updating the name server's internal database - problems always occur elsewhere. However, what the name server adds or deletes from its internal database can be a problem, as you'll see in Chapter 13, Troubleshooting DNS and BIND .

Level 1: The information at this level is necessarily brief. Name servers can process lots of queries, which can create lots of debugging output. Since the output is condensed, you can collect data over long periods. Use this debugging level for basic startup information and for watching query transactions. You'll see some errors logged at this level, including syntax errors and DNS packet formatting errors. This level will also show referrals.
Level 2: Level 2 provides lots of useful stuff: it lists the IP addresses of remote name servers that are used during a lookup, along with their round trip time values; it calls out bad responses; and it tags a response as to which type of query it is answering, a SYSTEM (sysquery) or a USER query. When you are tracking down a problem with a secondary server loading a zone, this level shows you the zone values - serial number, refresh time, retry time, expire time, and time left - as the secondary checks if it is up-to-date with its master.
Level 3: Level 3 debugging becomes much more verbose because it generates lots of messages about updating the name server database. Make sure you have enough disk space if you are going to collect debugging output at level 3 or above. At level 3, you'll also see: duplicate queries called out, system queries generated (sysquery), the names of the remote name servers used during a lookup, and the number of addresses found for each server.
Level 4: Use level 4 debugging when you want to see the query and response packets received by the name server. This level also shows the credibility level for cached data.
Level 5: There are a variety of messages at level 5, but none of them are particularly useful for general debugging. This level includes some error messages, for example, when a malloc() fails, and a message when the name server gives up on a query.
Level 6: Level 6 shows you the response sent to the original query.
Level 7: Level 7 shows you a few configuration and parsing messages.
Level 8: There is no significant debugging information at this level.
Level 9: There is no significant debugging information at this level.
Level 10: Use level 10 debugging when you want to see the query and response packets sent by the name server. The format of these packets is the same format used in level 4. You wouldn't use this level very often, since you can see the name server response packet with nslookup .
Level 11: There are only a couple of debugging messages at this level, and they are in seldom-traversed code.

With BIND 8, you can configure the name server to print out the debug level with the debug message. Just turn on the logging option print-severity as explained in Section 7.5, " BIND 8 Logging" .

Keep in mind that this is debugging information - it was used by the authors of BIND to debug the code, so it is not as readable as you might like. You can use it, too, to figure out why the name server isn't doing what you think it should be doing, or just to learn how the name server operates - but don't expect nicely designed, carefully formatted output.