For many IT organizations, the holidays provide a welcome respite from the constant chaos of the rest of the year. (Not so if you work in retail, of course.) Many employees are on vacation, so the office is quiet and there are fewer interruptions. Corporate policy may rule out major configuration changes, but there's time to attend to long-deferred maintenance and documentation.

While it's tempting to use the newfound hours in your work day to brush up on solitaire, why not carpe the diem and tune your DNS architecture and management processes? There's probably lots you can do to improve the reliability and security of your DNS infrastructure. The little things you can do now; the major changes may need to wait until early next year. For now, tack these onto your list of New Year's resolutions.

Here's a list of six best practices to consider when evaluating your DNS infrastructure and management:

1. Use forwarders, but sparingly.

Most corporate DNS architectures rely on forwarders. Some use of forwarders is inevitable: It's a bad idea to expose all of your internal name servers directly to the Internet, so you funnel queries for Internet domain names through a smaller group of forwarders.

However, many companies create Byzantine name-resolution architectures in which one name server forwards to another, which in turn forwards to another. These designs are almost unavoidably brittle: The failure of any forwarder in the chain slows or breaks name resolution. Even during normal operation, the forwarders handle a disproportionate share of the resolution load, and resolution paths are needlessly inefficient.

Most modern name servers, support "conditional forwarding," which allows you to forward (or not forward) queries based on the domain name being looked up. Using conditional forwarding, you can forward only those queries that need to be forwarded -- namely those in the Internet's namespace. Queries for internal domain names can -- and should -- be resolved internally, using iterative name resolution.

2. Don't place all your eggs in one basket.

When implementing forwarding, it's tempting to use your external authoritative name servers as forwarders, too. They already have Internet connectivity, after all. And most name server implementations are capable of processing both recursive and nonrecursive queries simultaneously. But splitting the two functions -- authoritative name servers and forwarders -- between two sets of name servers has pronounced advantages.

First, you can more effectively secure each set of name servers. On the authoritative-only name servers, you can disable recursion. This helps the name servers resist denial-of-service attacks, since a BIND name server's capacity for processing nonrecursive queries dwarfs its capacity for handling recursive queries. Authoritative-only name servers also don't cache, so you won't need to worry about your server's data segment growing out of control, or about cache poisoning.

You can configure the recursive name servers to deny name service to all but authorized query-makers. This should make it difficult for hackers to attack the name server without the collusion of one of your users.

This separation also helps compartmentalize breaches and failures of name servers. If a hacker finds a vulnerability in the query processing code in BIND, he may be able to crash your authoritative name servers, but he won't be able to compromise your recursive name servers, which won't accept his queries.

3. Use hidden primary masters.

A hidden primary master name server is one that doesn't appear in the NS records for its zones and doesn't serve any resolvers. So, what good is it? Its only responsibility is to serve zone transfers to slave name servers. (Well, it also sends them Notify messages and handles their refresh queries, and it may process dynamic updates, too.)

Running a hidden primary master gives you flexibility in its administration. A primary master that handles queries from resolvers and other name servers can't be brought down for long without causing query timeouts. But if a hidden primary takes a few minutes to reload a large zone, there's no adverse effect. If you muff a configuration change and the name server won't start, you'll have the full expiration interval of your zones to fix the problem.

4. Call for backup.

Despite your best efforts, your name servers will sometimes go down. They may crash. They may become overloaded and stop processing queries. If your resolvers only know about one name server and it's down or unresponsive, their queries will fail and your users will get angry. So configure your resolvers with a backup name server in their configurations so that if the first fails, they'll move on.

5. Keep watch over your flock.

Like I said, sometimes your name servers will go down. If you're not monitoring them, you may not find out right away. Someone else may have to tell you. Like your boss.

If you set up a system to monitor your name servers, you'll be the first to know. Any respectable monitor should check not only that your name servers are responding, but also that they're authoritative for the zones assigned to them. The free mon software includes a DNS service monitor.

You can also monitor the operation of your name servers by collecting their syslog output on a single loghost and using tools such as swatch to alert you when a name server logs a significant message. This would enable you to detect a slave name server's repeated failures to transfer a zone, for example.

6. Test modified configurations and zone data before putting them into production.

Errors you inadvertently introduce will cause outages: Syntax errors in zone data files will prevent the name server from loading the zone, while syntax errors in a name server's configuration file may keep the name server from starting.

After modifying zone data, you can use named-checkzone (a standard part of BIND 9) to check for syntax errors. If you don't have named-checkzone available, you can configure a new named process, listening on a nonstandard port, to load (and thereby test) the zone data file. (Just look in the name server's syslog output for errors.) Similarly, you can use named-checkconf or a new named process to check a named.conf file for errors.

Cricket Liu is an expert on the Domain Name System and co-author of O'Reilly & Associates' Nutshell Handbooks on DNS, including DNS and BIND. He is also vice president, architecture, at Infoblox, a provider of network identity products and services. At Infoblox, he helps guide the development of product strategy and service offerings and serves as a liaison between Infoblox and the technical community.