13.5 The Resolver Search Algorithm and Negative Caching (BIND 9)

Here's what a BIND 9.1.0 name server's debugging output looks like when looking up foo.bartwice:

Sep 18 15:45:42.944 client cujo.horror.movie.edu#1044: query: foo.bar A
Sep 18 15:45:42.945 createfetch: foo.bar. A
Sep 18 15:45:42.945 createfetch: . NS
Sep 18 15:45:43.425 client cujo.horror.movie.edu#1044: query: foo.bar.horror.movie.edu A
Sep 18 15:45:43.425 createfetch: foo.bar.horror.movie.edu. A

This output is more subtle and succinct than BIND 8's, but you can get the information you need from it. The first line, at 15:45:42.944, shows the initial query for foo.bar 's address arriving from the client cujo.horror.movie.edu (remember, we ran this through our magic IP-to-name filter, which we'll introduce next). The next two lines show the name server dispatching two tasks (createfetch) to look up foo.bar : the first is the actual task to look up foo.bar 's address, while the second is a subsidiary task to look up NS records for the root zone, necessary to complete the foo.bar lookup. Once the name server has current NS records for the root, it queries a root name server for foo.bar 's address and gets a response indicating that no top-level domain called bar exists. Unfortunately, you don't see that.

The line at 15:45:43.425 shows cujo.horror.movie.edu applying the search list, looking up foo.bar.horror.movie.edu. This causes the name server to dispatch a task (createfetch) to look up that domain name.

When we look up foo.baragain we see:

Sep 18 15:45:46.557 client cujo.horror.movie.edu#1044: query: foo.bar A
Sep 18 15:45:46.558 client cujo.horror.movie.edu#1044: query: foo.bar.horror.movie.edu A

Notice the absence of createfetch entries? That's because our name server has the negative answers cached.