Name Services: Another View

Ron McCarty

In the November 1999 issue of Sys Admin, I covered "Domain Name System Design Considerations" (http://www.sysadminmag.com/documents/s=1172/sam9911f/sam9911f.htm). This month, I will cover several name server topologies as well as the BIND 9.2.0 new view feature that will add another tool to your name server tool chest.

Prior to BIND version 8, name servers were identified by their roles as either "primary" or "secondary". The primary server contained the actual zone databases, and the secondary servers pulled the zones from the primary. With version 8 of BIND, the terminology changed to "master" and "slave". Regardless of the terminology, it is important to realize that the client is not aware of a name server's role within a particular domain.

In addition to the basic topology shown in Figure 1, systems administrators can take advantage of the fact that clients (and name servers acting as clients in recursive mode) are not aware of the server technology to solve networking issues or requirements. For example, an organization may want to take advantage of its ISP's name services setting on a very high-speed network connection, but may also want to maintain a control zone without answering requests from external clients.

Figure 2 shows a topology that supports this business requirement. With the hidden master, the ISP's slave servers are registered with the registrar as authoritative, but the corporate name server is not registered with the registrar as an authoritative name server. The ISP name servers are configured to pull the zones from the hidden primary. This topology takes advantage of the ISP's high-speed connection, keeps client requests off the WAN connection to the ISP, and allows the organization to limit incoming DNS to only the slave servers, thus providing additional security to the organization.

DNS efficiency can be improved in a similar fashion. Systems administrators needing to provide remote domain name services often need to consider the impact of name services on WAN connections prior to simply pointing all clients to a centralized name server across the WAN link. Through the use of an internal non-registered slave, as shown in Figure 3, remote clients can resolve names locally without the request crossing the WAN link. Since the remote non-registered slave is not entered as a name server in the zone, there is no chance other clients outside the remote site will query the name server. This topology works because the remote clients are configured to point to the un-registered slave. This un-registered happens to be configured as a slave so that it considers itself authoritative and will return responses to the client's queries.

While the above two examples take advantage of the client's lack of knowledge of the server topology, a common requirement for DNS is to provide external users of the domain with a limited external view of the domain that typically includes only WWW, FTP, and mail servers. This is done to keep hackers from mapping out the internal zone and is often accomplished by separating the external and internal zone onto two name services, as shown in Figure 4. This method is very effective from a security perspective. However, with the creation of extranets, many organizations want to share name services with partners that not only include public services, but also services within the extranet, as shown in Figure 5. BIND version 9.2 allows a single server to provide split DNS through views as shown in the figure. A BIND view allows a query to be answered based upon the source address of the client. Before looking at the specifics, I'll discuss installing BIND 9.2.0.

BIND Installation

BIND is available at the Internet Software Consortium at:

http://www.isc.org/products/BIND/bind9.html

After downloading the BIND source tarball, unzip and untar the distribution to the appropriate source directory. I used /usr/local/src/bind-9.2.0/. Move into the directory with:

cd /usr/local/src/bind-9.2.0

./configure
make
make install
mkdir /var/run
mkdir /var/named

In regard the views mentioned previously, I will cover the /etc/named.conf configuration as opposed to emphasizing the contents of the zone files. Test zone files are required for the following examples. (The sidebar "Important DNS Files" covers the other files.) The following configuration of /etc/named.conf is needed to create an internal view for all clients that will act as a cache-only name server:

view "internal" {
        match-clients { any; };

                zone "." {
                type hint;
                file "named.root";
                };

                zone "0.0.127.in-addr.arpa" {
                type master;
                file "localhost.rev";
                };
        };

/usr/local/bin/named &

nslookup
Default Server:  any.mcwrite.net
Address:  192.168.1.5
> server 192.168.1.252
Default Server:  sunny.mcwrite.net
Address:  192.168.1.252

>www.samag.com.
Server:  sunny.mcwrite.net
Address:  192.168.1.252

Non-authoritative answer:
Name:    www.samag.com
Address:  66.35.216.85

The dig command can also be used:

dig @192.168.1.252 www.samag.com.

; <<>> DiG 9.2.0 <<>> @192.168.1.252 www.samag.com.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47099
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;www.samag.com.                 IN      A

;; ANSWER SECTION:
www.samag.com.          259086  IN      A       66.35.216.85

;; AUTHORITY SECTION:
samag.com.              259086  IN      NS      gw.ddj.com.
samag.com.              259086  IN      NS      ads.ddj.com.

;; Query time: 2 msec
;; SERVER: 192.168.1.252#53(192.168.1.252)
;; WHEN: Sun Jan 20 21:55:26 2002
;; MSG SIZE  rcvd: 86

view "external" {
        match-clients { any; };

                zone "mcwrite.net" {
                type master;
                file "mcwrite.net.ext";
                };
        };

view "extranet" {
        match-clients { 192.168.2.0/24; };
        recursion no;

        zone "mcwrite.net" {
                type master;
                file "mcwrite.net.extranet";
                };
                   };

In this particular case, we're allowing the clients from the partners extranet to query the name server. Queries from the 192.168.2.0/24 would probably be a name server that will make the requests for internal clients, or special application servers that are aware of the specific name server.

Views could also prove very useful on managing internal networks to keep users from arbitrarily picking DNS servers outside of their LANs. Now that an internal view has been created, a view for the extranet must be created. Figure 5 shows the external view that can be added to the last /etc/resolv.conf.

Summary

DNS has proven itself as the name server protocol of choice both on the Internet and within corporate networks. Although the protocols are aged and proven, there continue to be improvements, such as BIND's new view feature, that can help administrators solve common networking problems.

Resources

BIND 9.2.0 Administrator Manual: http://www.nominum.com/resources/documentation/Bv9ARM.pdf

BIND FAQ: http://www.nominum.com/resources/faqs/bind-faqs.html DNS Resources Directory: http://www.dns.net/dnsrd/

Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. He works for Sonus Networks as a senior systems engineer on a customer team responsible for a major telecommunications carrier. Ron is the co-author of New Rider's Linux Routing (http://www.linuxroutingbook.com/). 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: ronald.mccarty@gte.net.