Designing a Resilient DNS Architecture Part 1: Namespace Views

For most enterprise networks, there are typically four or more jobs for DNS servers. Many DNS administrators don’t realize it, but it’s generally best to separate each of these onto separate sets of servers rather than having one server providing more than one of these services. This is the first post in a series of articles that will delve into what these different roles are and why they should be kept separate.

The series will cover the following topics related to DNS server roles:

Part 1: Namespace Views
Part 2: Authority versus Recursion
Part 3: Internal Recursion versus Recursing the Internet
Part 4: Bringing it All Together

Part 1: What is a namespace? What are views?

A namespace, for the sake of this discussion, is the entire DNS (Domain Name System) as visible to a particular client or set of clients. A view of the namespace typically starts with the Internet namespace and then grafts on zero or more private domains.

These private domains fall into three categories:

a) Child of a public domain
b) Duplicate of a public domain
c) Something arbitrary under a fake TLD, such as .corp or .lan.

Let’s examine each option in turn.

a) Child of a Public Domain This option is the best choice from a technical perspective, as shall become clear. However, it’s often the last one chosen by admins because of the resulting length – users don’t like repetitive typing. It’s this same thinking that gave us NetBIOS, WINS, and the modern version of this, the GlobalNames zone. It also gives us the super-long search order, another bane of domain admins in large enterprises.

The advantages are:

1. There’s only one namespace tree to maintain. This means all data could theoretically be hosted on a single set of servers. In practice, this is rare, because of the desire to shield internal name servers from externally-sourced traffic, but it could be done.
2. DNSSEC configuration is simpler. (More on this in Part 3 of this series.)
3. Common data can be hosted in the public parent domain and still accessed by internal users.

b) Duplicate of a Public Domain This choice is the most common. For example, the name “example.com” might be used privately as well as publicly. Unfortunately, this method restricts how the authoritative data can be served. It forces maintenance of two separate copies of the same zone – public and private – which means that all of the common data between the two copies must typically be maintained twice. There are tricks that have been employed to make this easier, but it’s generally a headache.

c) A Child of a Fake TLD This choice is the most onerous, because the list of public TLDs changes. For example, consider the case of .corp: This TLD is currently being considered as a future public TLD. But several well known enterprises are currently using domains ending in .corp as private domains, on the assumption that such a name would never become public. Queue the Active Directory renaming…

Serving Public and Private Views

Whichever method is chosen, it’s common practice to segregate public and private data into multiple views. This does not necessarily mean multiple “view” statements in a BIND configuration file; it also applies to use of separate sets of servers for internal and external data. In fact, there are many reasons not to serve multiple views from one server:

1. It’s too easy to make mistakes. Here are some examples:

o    Data that should be in both views is not entered in both. o    Public data is entered in the private view, or vice versa. o    The view selection criteria are entered incorrectly, showing the public view to some internal users or (worse) the private view to outsiders. o    The view statement syntax contains errors, causing all views to fail at some future time when the name server is restarted.

2. Hardware, especially virtual hardware, is cheap.
3. An architecture designed for the workload and the data of today may not scale to the needs of tomorrow.
4. Documenting the configuration for use by the next generation of maintainers is often left too late, with the result that a new administrator inherits a confusing mess.

There are valid use cases for multiple views on a single server, where the business need outweighs the considerations above, but these are few and far between.

Stay tuned for Designing a Resilient Adaptive DNS Architecture Part 2: Authority vs. Recursion.