DNS on Campus

Since 1993, the Campus's primary name servers have been

128.32.136.9
128.32.206.9
128.32.136.12
128.32.206.12

These are the IP addresses one should use in the DNS configuration of campus hosts. The name servers were two machines each with two interfaces on two different networks. For many years this was considered suitable reliability and redundancy.

Since May 2000 CNS has taken several steps to improve performance and reliability of campus name service. These steps include creating a set of distributed on-campus name servers, establishing an off-site name server that we operate, and separating the functions of caching and authoritative name servers.

Distributed On-Campus Nameservers

The original two name servers were both located in Evans Hall. This created a critical single point of failure. But because name servers are known by their IP addresses in workstation configurations all over campus and registered with the Internet root name servers, it is difficult to simply re-address, move or add to them.

The solution involves the concept of 'Anycast'. Multiple distributed name servers are situated throughout the campus, any of which can answer DNS queries. Each server answers to the four well-known IP addresses. The campus routing protocol (OSPF) is configured to route queries to the nearest well-known name server IP address.

This resulted in increased reliability and redundancy. The task of responding to DNS requests are now shared among several name servers. Nameserver upgrade and maintenance can take place without impacting DNS on campus. Most importantly if a single name server should fail, there is near instant fail-over to the next-nearest server.

Offsite Master Nameserver

For many years, CNS has made agreements with Hostmasters at other institutions to provide name service for our domains. These other name servers are registered with the Internet root name servers and can provide DNS service for our domains. However, they must pull our DNS data from our name servers. If the master name servers here on campus are down or isolated from the Internet, eventually the data in these remote name servers will expire.

Recently CNS established an agreement with New York University (NYU) to house a name server that we operate at their facilty. We provide the same service to NYU. The particular nature of our partnership with NYU provides us with more than mere redundancy. Because we are able to configure the server at NYU as a DNS master server, we will be able to make changes to our DNS database even if the entire campus DNS or network infrastructure fails or becomes isolated from the rest of the world. The most significant application of this capability is in the areas of disaster recovery and business resumption. For example, CNS staff will be working with Public Affairs personnel to establish procedures to use the DNS system to redirect traffic for the main Berkeley website (www.berkeley.edu) to the campus's off-site emergency website (emergency.berkeley.edu) in the event of a campus-wide emergency or other mishap.

Caching vs. Authoritative Nameservers

DNS servers typically have two functions: to provide authoritative data to other name servers (authority function) and to provide recursive record lookups for clients and cache those records to minimize load on the network and on other name servers (caching function.) The recursive lookup simply means that if the name server you query does not know the answer it will query the root name servers for the appropriate authoritative nameserver, then send it your query and return the answer to you. It is these answers that are kept in a name server's cache.

In the past, it was common for DNS servers to combine those functions; the same server would provide caching services to all of its clients, while providing authority records for its domain. However, in recent years, it has been strongly recommended that these functions be separated onto separate servers, one set for caching and another set for authority. This is for several reasons:

1. Security: Nameservers that do recursive lookups are inherently subject to cache poisoning, where an attacker attempts to fool the DNS server into trusting data from a rogue name server. By separating the recursive-caching function and the authority function, recursion can be turned off on the authoritative server, thereby making cache poisoning nearly impossible on the authoritative servers. The caching server can be configured to ignore queries from off-site clients or from netblocks that should not use our name servers, reducing its risk of cache poisoning. Further, caching servers may be more vulnerable to certain denial of service attacks.
2. Efficiency: Since authoritative-only servers do not perform recursive queries on behalf of clients nor maintain large and growing cache data sets in memory, authoritative data may be served more efficiently on authoritative-only servers.
3. Load sharing: As are all servers and network functions, name servers are busier nowadays. It makes sense to share the load by distributing functions across servers.

For more information on this topic see, Running An Authoritative-Only BIND Nameserver, ISC's Technical Note Series.

CNS completed this transition in late 2003. The authority function is provided by a set of name servers that also employ 'Anycast' to provide resiliency and redundancy.