DekGenius.com
I l@ve RuBoard Previous Section Next Section

10.10 A Nonrecursive Name Server

By default, BIND resolvers send recursive queries, and by default BIND name servers do the work required to answer them. (If you don't remember how recursion works, look in Chapter 2 ) In the process of finding the answers to recursive queries, the name server builds up a cache of nonauthoritative information from other zones.

In some situations, it's undesirable for name servers to do the extra work required to answer a recursive query or to build up a cache of data. The root name servers are an example of one of these situations. The root name servers are so busy that they can't expend the extra effort necessary to find the answers to recursive queries. Instead, they send a response based only on the authoritative data they have. The response may contain the answer, but it more likely contains a referral to other name servers. And since the root servers do not support recursive queries, they don't build up a cache of nonauthoritative data, which is good because their caches would be huge.[7]

[7] Note that a root name server doesn't normally receive recursive queries unless a name server's administrator configured it to use a root server as a forwarder, a host's administrator configured its resolver to use the root server as a name server, or a user pointed nslookup at the root server. All of these happen more often than you'd expect, though.

You can induce a BIND name server to run in nonrecursive mode with the following conf file statement:

options {
	recursion no;
};

On a BIND 4.9 server, that's the directive:

options no-recursion

Now the server will respond to recursive queries as if they were nonrecursive.

In conjunction with recursion no, there is one more configuration option necessary if you want to prevent your name server from building a cache:

options {
	fetch-glue no;
};

Or, on BIND 4.9:

options no-fetch-glue

This stops the server from fetching missing glue when constructing the additional data section of a response. BIND 9 name servers don't fetch glue, so the fetch-glue substatement is obsolete in BIND 9.

If you choose to make one of your servers nonrecursive, don't list that name server in any host's resolv.conf file. While you can make your name server nonrecursive, there is no corresponding option to make your resolver work with a nonrecursive name server.[8] If your name server needs to continue to serve one or more resolvers, you can use the allow-recursion substatement, available in BIND 8.2.1 and later (including BIND 9). allow-recursion takes an address match list as an argument; any queriers that match can send recursive queries, but everyone else is treated as if recursion were off:

[8] In general. Of course, programs designed to send nonrecursive queries, or programs that can be configured to send nonrecursive queries, like nslookup, will still work.

options {
	allow-recursion { 192.253.254/24; };  // Only resolvers on the FX
                                          // subnet should be sending
                                          // recursive queries
};

allow-recursion's default is to provide recursion to any IP address.

Also, don't list a nonrecursive name server as a forwarder. When a name server is using another server as a forwarder, it forwards recursive queries to the forwarder. Use allow-recursion to permit just authorized name servers to use your forwarder instead.

You can list a nonrecursive name server as one of the servers authoritative for your zone data (i.e., you can tell a parent name server to refer queries about your zone to this server). This works because name servers send nonrecursive queries between themselves.

    I l@ve RuBoard Previous Section Next Section