Gear up for New Year's DNS resolutions

Computerworld - 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