Domain Name System Design Considerations

Ron McCarty

Welcome to Sys Admin's new monthly networking column. In this column, I will be covering network design issues that are important in today's network-centric organizations. The opinions expressed here are mine, and suggestions are based on my own experience. Thus, I'll be interested in hearing about alternate solutions to problems discussed here. Such alternatives, and any suggestions for future columns, may be addressed to me at: mccarty@my-own-domain.to. DNS design is this month's topic.

Domain Name System (DNS) was the Internet's answer to global naming. It is the standard name system required for Internet access and is often the choice of internal naming systems. Despite its widespread use, very little consideration is given to designing proper name systems. GUI configuration tools and current firewall technology can help almost anyone deploy a relatively secure DNS system; however, poorly designed DNS systems will not grow with the organization.

Like many small networks, the Internet originally used a central file with a complete listing of all hosts within the network maintained by a central authority/server. This method does not scale well due to intensive maintenance requirements. Unfortunately, unlike the Internet, many small networks do not identify these shortcomings during growth and fail to move to a system that will grow with the company. Within organizations that try to maintain host tables on more than a few centrally managed hosts, problem growth seems to match the growth of the network and host entries. Additionally, name resolution failure is often reported as a general network connectivity problem, so other resources are wasted on accurately identifying the problem and tracking down the approriate administrator to correct it. A quick survey of your central server's /etc/hosts files will tell you whether you have a system that is destined to cause heartburn.

DNS, as opposed to maintaining hosts tables, gives the flexibility of central or distributed management (through delegation of subdomains) as well as proven protocols, and a client server model that will scale to meet any organizations need. As opposed to creating and maintaining host tables on new hosts during installation, the host (client) is configured to use DNS by pointing the resolver (the client portion of DNS) to your name servers; name resolution for the new host can then be forgotten. With a host table, the table of the new host would have to be maintained either manually or through a custom script that the administrator would update to push to the new host.

Unfortunately, migrating from a host table to a name server is often challenged with many reasons for not implementing a server. Typically, valid technical reasons quickly overrun flawed logic. However, one argument that may seem reasonable is the argument that a host can still talk to other hosts by names despite a DNS outage if local host files are used. Although it is a good idea to maintain a table of important local addresses in the host table (if the host supports DNS and a host table) in order to quickly reach specific critical hosts during an outage, the maintenance required to maintain many hosts will never cost the organization less than the few outages a correctly designed name system will provide.

Building the Pieces: System Integration and Interoperability

Generally, Berkeley Internet Name Domain (BIND), is the name server of choice on UNIX systems and because of the popularity of UNIX for Internet hosts, is a favorite among ISPs. BIND is currently maintained by the Internet Software Consortium:

http://www.isc.org/view.cgi?/products/BIND/index.phtml

and its source code is available. I will not cover BIND configuration; however, a good starting place for BIND is the comp.protocols.dns.bind newsgroup. Any mention of BIND should also mention the O'Reilly book, DNS and Bind by Paul Albitz and Cricket Liu (O'Reilly and Associates).

BIND is also available for Windows NT. Besides the freely available version of BIND, there are other systems based upon the BIND code as well as independently developed systems. Interoperability is a given since any vendor will quickly find itself not selling its product if it cannot operate with other systems on the Internet.

Although DNS is the standard on the Internet, Microsoft decided early on to integrate WINs into its systems; therefore, WINs integration is important for many organization's internal naming services. DHCP integration is also an often-sought feature.

MetaIP, recently purchased by CheckPoint:

http://www.metaip.checkpoint.com/products/metaip.cfm

will integrate with the Windows Internet Naming Service (WIN) and DHCP. Additionally, Microsoft's own DNS server provided with Windows NT 4 Server integrates with its WIN. However, new large-scale integration of WINs support should be considered carefully. NT supports DNS, and Microsoft's LDAP-based active directory services will be based upon DNS. Although WINs will be around for a while, its life is limited as Microsoft moves to DNS. Before you flame me on WINs, please check out Microsoft's own statement concerning WINs at:

http://www.microsoft.com/NTServer/nts/deployment/migration/ \ 
  nt4tont 5/4_PlanningTheDNS.asp

In addition to integration with other systems, GUI support might be a necessity for DNS admins, especially in organizations with large internal DNS structure with subdomains delegated to business units or regions. BIND's configuration file is relatively straightforward and much easier to maintain than other server daemons such as Sendmail and inn; however, it may intimidate a remote user that is responsible for a subdomain you have delegated to his site.

MetaIP, mentioned above, uses a Java client, so it can be managed using Netscape or Internet Explorer. Microsoft's DNS manager, not surprisingly, provides a GUI manager for Windows. Cisco, well known for its enterprise routers and switches, offers GUI management as well as DHCP management with its Cisco Network Registrar (CNR). CNR:

http://www.cisco.com/warp/public/cc/cisco/mkt/enm/cap/cnr/index.shtml

has replaced Cisco's simply named DNS/DHCP Manager.

Building It Stable

DNS is a distributed system: responsibility for your domain is delegated to you and all queries for your domain are pointed to name servers you've chosen. These name servers are listed in the root servers (top level) of your domain. Since these name servers are distributed throughout the planet (Internet), it is highly unlikely that a root server outage will affect your domain. The following type of redundancy should be used for your DNS servers: a minimum of two name servers should be chosen, and the two name servers should not share a common failure point. This is very important for your external (external and internal DNS will be discussed later) name services since a new delegation can take days and cannot be relied on during a disaster recovery. Many ISPs offer name services; however, their services should not be relied on solely, nor should they be your only secondary. A major telecom outage experienced at the ISP telco will likely disconnect the ISPs primary and backup connection to the Internet.

The total number of name servers is limited by the UDP protocol payload -- when a query is made to one of the root name servers, it replies with a list of name servers for the domain via one UDP packet. Depending on the host name length, anything over nine entries should be watched. There are very few organizations in the world that need this many name-registered name servers.

Many systems administrators and managers are surprised to learn that mail delivery fails when name servers for the domain are unavailable -- they expect the sending mail server (mail transport agent) to queue the message for later delivery as it would do if the mail server were unavailable. This is not the case. The sending mail server tries to determine the receiver's mail server by querying for the mail exchange (MX) record through its name server for the users' domain (or subdomain or host) for delivery. Since the mail server receives a negative response, it stops delivery attempts and returns an error message to the user. However, had a name server been reachable and the mail server were down, the sending mail server would have queued the message for later delivery.

Placement of your DNS servers should also be carefully planned. Placement of an external DNS server at an ISP or complete outsourcing of the DNS services can be considered by many small and mid-sized organizations. One advantage of outsourcing the services is the ISP's expertise -- it is not uncommon for ISPs to manage thousands of domains for their customers. The ISP's security and reputation should be investigated. Most ISPs will provide references, and ISPs will typically react very quickly to security advisories. Outsourcing is, of course, an option for a large organization, too. It is usually just not practical because internal DNS requirements require continual DNS maintenance and the few external tasks can be easily managed by the same administrators.

Performance on ISP's name services will typically be excellent. Although they serve up many domains, their backbone connection will typically compensate for any other shortcomings unless the server is simply oversubscribed.

Outsourcing the service will not guarantee a sound, distributed system. ISPs that have a large Web-hosting clientele may not make the appropriate effort not to have a common failure point. However, by clearly stating your needs, you'll likely get the distribution needed as well as extra servers with the ISP's global partners.

Cache-only name servers can be strategically placed within your internal networks to keep unneeded traffic off backbones or expensive WAN links. The maintenance of an additional box, plus the capital expense of the system, should simply be weighed against the reduced traffic. This is very important for departments with a large headcount that are crossing backbones for name resolution.

Building it Secure

I've mentioned internal and external name services several times. For a sound security model, your organization requires internal and external name services (split DNS). The external name servers will contain only the information necessary to communicate with your “public” servers such as email, Web, ftp, and your public IP addresses. Giving anyone on the Internet any more information is simply foolish, because the information can be used for security and social attacks.

Security advisories and recommended patches must be taken seriously for internal and external name servers. Depending on the security topology deployed, a cracked internal name server may be a larger loss to the organization than a cracked external server, because it is not uncommon to run DNS services on servers that provide other services. CERT advisories:

http://www.cert.org/

and security-focus.com:

http://www.securityfocus.com/

are two good sources of information. Also, subscribe to your vendor's security list.

BIND, because of its popularity, is often a target for security hacking. This same popularity ensures very quick fixes to any known security problems. Another good practice is to limit zone transfers to secondary/slave name servers. Allowing anyone to transfer and analyze (internal or external) zone can create a good network map of the organization, which can be exploited.

A hidden primary topology might also be worth considering. With this topology, your primary name server is not registered as a name server, rather, all the registered name servers pull the zone either from the unregistered primary or one of the registered name servers. This further narrows the hole you must punch into the DMZ area of your network.

Besides the aforementioned host and protocol security, network security must be considered when placing any external servers. Current firewall technology likely supports the needs of any organization. Unfortunately, this current technology is often used to bypass sound security practice by placing external services within the internal network by proxying the connection or network address translation. Should such a name server be cracked, the intruder has access to the internal network; whereas, a name server placed behind a choke point and in front of the firewall or on a dedicated segment off the firewall, does not provide a direct connection to the internal network. The firewall must still be broken or bypassed to receive internal access.

Building DNS to Fit

A properly designed DNS structure will scale to meet your organization's needs, and by the distributed nature of DNS, your choice of product will not limit scaling except in very large organizations with few name servers and little delegation of subdomains. Plan delegations of subdomains in advance.

DNS policy should be well understood by all involved. Delegating a subdomain and deploying a server to a regional office will improve performance for the regional office for resolving subdomain queries and caching other hits. This may not be manageable if the policy does not allow the central DNS admin to manage the service, and there is no one on site to maintain it.

Be creative with your design and policy but do not go overboard. Overseas WAN links can be very expensive, so placing a secondary server in an overseas location that otherwise would not justify a name server may save the company valuable bandwidth.

Advanced Topics

Building DNS right or fixing a broken deployment will not always solve all your needs. Topics that are often presented to DNS admins include load sharing and balancing:

http://www.isc.org/view.cgi?/products/BIND/docs/bind-load-bal.phtml

via DNS or even via hardware such as Cisco's distributed director:

http://www.cisco.com/warp/public/cc/cisco/mkt/scale/distr/index.shtml

and clustering solutions, such as those provided by Sun:

http://www.sun.com/software/white-papers/wp-clusters/

and Microsoft:

http://www.microsoft.com/NTServer/ntserverenterprise/techdetails/ \ 

  overview/NTSEE.asp

Additionally, with the shortage of IP addresses, many organizations, especially within Europe are no longer receiving large numbers of IP addresses (often smaller than a /24 network). This requires CIDR delegation of the address space as described in RFC 2317 or not having the space delegated and having it maintained by your ISP. Dynamic DNS, as covered in RFC 2136, will also become very important to next generation implementations.

A posting to comp.protocols.dns.bind will often get you started in the right direction on specific questions or vendor solutions. Always keep your needs and good design in mind when seeking assistance. Do it right the first time.

About the Author

Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ronald McCarty started his network career as network administrator at the Schwaebisch Gmuend campus. Ronald McCarty currently works for Software Spectrum, Inc. as a network engineer in the IT&S Network Services Project's team. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia. Ron can be reached at: mccarty@my-own-domain.to.