Cover V11, I04

Figure 1
Figure 2
Figure 3
Figure 4
Figure 5


Name Services: Another View

Ron McCarty

In the November 1999 issue of Sys Admin, I covered "Domain Name System Design Considerations" ( 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:
The installation instructions covered are for Solaris 2.6. Open source development tools were used, including GNU gcc compiler version 3.0.3 with the binutils version 2.11.2 and GNU make version 3.79.1.

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
and execute the following commands:

make install
mkdir /var/run
mkdir /var/named
The name server will need to know how to reach the root name servers, so download the named.root file from and place it in the /var/named directory and named.root.

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 "" {
                type master;
                file "localhost.rev";
which can be tested by firing up named with:

/usr/local/bin/named &
Check /var/adm/messages if named does not start up. (You can ignore the messages about the in the /var/adm/messages for now.) To be sure the name server is resolving correctly, the nslookup command can be used by pointing the nslookup command to the new server:

Default Server:
> server
Default Server:


Non-authoritative answer:
The "Non-authoritative answer" reports that the name server requested and received an answer. The "Non-authoritative" means the server is not configured to serve the domain directly.

The dig command can also be used:

dig @

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

;                 IN      A

;; ANSWER SECTION:          259086  IN      A

;; AUTHORITY SECTION:              259086  IN      NS              259086  IN      NS

;; Query time: 2 msec
;; WHEN: Sun Jan 20 21:55:26 2002
;; MSG SIZE  rcvd: 86
Now that I've shown that the server operates, let's configure it as the split DNS server as shown in Figure 5. Remove everything in the /etc/resolv.conf and put only this view in:

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

                zone "" {
                type master;
                file "";
After restarting named (using -HUP), the split DNS server should be serving up the extranet views as well. To create an extranet view of the DNS, add the following to the top of the file:

view "extranet" {
        match-clients {; };
        recursion no;

        zone "" {
                type master;
                file "";
and restart named.

In this particular case, we're allowing the clients from the partners extranet to query the name server. Queries from the 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.


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.


BIND 9.2.0 Administrator Manual:

BIND FAQ: DNS Resources Directory:

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 ( 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: