DnsCluster: A networking tool for automatic domain zone updating

Transcription

1 DnsCluster: A networking tool for automatic domain zone updating Charalambos Alatas and Constantinos S. Hilas * Dept. of Informatics and Communications Technological Educational Institute of Serres Serres, Greece * chilas@teiser.gr Abstract The Domain Name System can be considered as one of the most important services in the core of the Internet. It translates names that are meaningful to humans into numerical IP addresses. The most commonly used DNS server on the Internet is BIND. In this paper we present a client server application that is designed to cope with the problem of exchanging BIND information between a primary DNS Server and its secondary servers in large and/or different networks. I. INTRODUCTION The Domain Name System (DNS) is a hierarchical naming system for computers, services, or any resource that is connected to the Internet. It associates various kind of information with domain names that are assigned to appliances and/or services. Its main contribution to the Internet semantics is that it translates humanly meaningful domain names to the numerical identifiers (IP addresses) that are associated with networking equipment locating and addressing. The DNS, also, makes it possible to assign names to groups of Internet users, independent of their physical location. This is the feature that permits Internet contact information (like hyperlinks and addresses) to remain consistent and constant even if the current Internet routing arrangements change or the participant uses a mobile device [1]. The Domain Name System (DNS) is maintained by a distributed database system, which uses the client-server model. The nodes of this database are the name servers. This is the largest and most distributed database currently on the planet, with the amazing feature of being updated and administered by millions of network administrators worldwide. DNS allows local administration of the segments on the overall database. Each domain or sub-domain has one or more authoritative DNS servers that publish information about that domain and any domains subordinate to it. The top of the hierarchy is served by the root nameservers, i.e. the servers that should be queried when looking up (resolving) a top-level domain name (TLD). Thus, data in each segment of the network (actually in each segment of the database) are available across the entire network through a client-server scheme consisting of name servers and resolvers. The most commonly used DNS server on the Internet, especially on Unix-like systems, is BIND (Berkeley Internet Name Domain or "named"). The BIND server allows a standard way of naming the different types of objects and resources that exist in distributed network environments, and provides operations for storing and retrieving information about these objects. BIND servers collectively manage a hierarchical name space that is partitioned into domains reflecting administrative entities [2]. Despite its wide use, BIND has been the target of some criticism as regards three of its features: configuration procedure, zone support and security. When configuring BIND one should always include all higher level domain labels in each domain name. BIND does not offer a store and retrieve mechanism for zone data, especially when communicating with secondary name servers. Last, BIND like many other popular Internet services has got no embedded security, though current implementations take care of this problem. In this paper we present a client server application that cooperates with Bind and adds automatic zone synchronization. We have named this application DnsCluster because it was primarily designed to cope with the problem of exchanging BIND information between a primary DNS Server and its secondary servers in large networks. DnsCluster is actually a plugin tool that cooperates with Bind and delivers a rock solid, load balancing, fault tolerant solution for serving the Domain Name System. The application was conceived three years ago when two or more Web Hosting Servers were demanding an all-in-one solution for managing their domains. The main concept was the development of an application that would be able to synchronize zones between different installations of the nameserver daemon. DnsCluster can be used from the smallest installation to the big enterprise DNS clustering system. It complies with the RCF-1591 and does not imply any new limitations. It is no exaggeration to state that the BIND nameserver is a great daemon for serving the Domain Name System, a statement

2 supported by its widespread use. DnsCluster respects all of its features and simply adds an extra one. The present paper proceeds as follows. In the next chapter the DNS operation is briefly discussed along with several applications that are responsible for exchanging domain zone information between primary and secondary nameservers. In Chapter III the features and the development of the DnsCluster application are discussed. Three common DNS server cluster configurations are presented in Chapter IV and the role of DnsCluster within them is presented. In the last chapter conclusions are drawn. II. DNS OPERATION AND COMMERCIAL PRODUCTS A. How DNS works The basic operation of DNS that allows a domain name to direct customers to a web site is depicted in Fig 1. The figure describes basic steps that are followed when a web browser attempts to view pages on a web site. The DNS system needs to determine which primary name server contains the requested domain name. So, the following procedure is followed. 1. The local name server contacts the root domain name server maintained by several Internet root server authorities. The local name server has already been contacted by the web browser, which is not shown in the figure. One may assume it is hosted in the same machine. 2. The root domain name server returns the IP address of the primary name server responsible for the requested domain name. 3. The local name server contacts the primary name server. 4. The primary name server holds the IP address information for the domain name in a database and satisfies the request from the local name server. 5. If the primary name server is unavailable, the local name server contacts the secondary name server that satisfies the request from the local name server. The local name server replies to the Web browser with the IP address for the requested domain name. It is common to contact directly the secondary name server and not the primary. 6. Using this IP address, the web browser contacts the web server. 7. Last, the web server (target machine) sends the web page to the web browser. In cases of large domains, one may maintain several secondary name servers. And to make things more complex, the secondary name servers may be geographically dispersed. DnsCluster application is responsible to always keep the secondary name servers updated with information served by the primary name server. B. Prior Work and Commercial Solutions DnsCluster is not the only solution around. Several applications are available that try to cope with the challenge. WHM/CPanel has developed a plugin, namely the cpanel DNS Only, that works quite similar to the way that the DnsCluster does. The major difference is that the WHM/CPanel's solution requires a dedicated and fresh installed server system to be installed on and may only cooperate with other WHM/CPanel installations [3]. On the contrary, DnsCluster can cooperate in virtually any hosting control panel environment using BIND nameserver. Figure 1. Basic DNS Operation Microsoft provides a redundant system that relies on Active Directory Services. Using a Primary Domain controller and a Secondary/Slave Domain Controller one can easily build a fault tolerant system that replicates every zone from the Primary Domain Controller to the Slave Domain Controller. The drawback of Microsoft's approach is that it only works when these two systems are in the same subnet. Moreover, it can be used with only two nameservers and in simple network topologies [4]. As already mentioned the most popular DNS server is the BIND. Every bind nameserver can be setup to query another nameserver and cache the results given. This solution provides load balancing but no fault tolerance features are available because if the primary nameserver fail then the other nameservers are not able to reach and query each other. Also, cache is only stored in memory which renders it unusable in case of a secondary server reboot. Bind cannot handle zones synchronization between servers and there is no plugin doing so. Bind can only transfer zone data and keep them up-to-date but every zone must be explicitly declared in the named.conf file. So there must be a mechanism for syncronizing the zone records in the named.conf file because bind is not doing this. DnsCluster handles exactly this situation with safety and reliability without adding any extra limitations to bind. III. DESCRIPTION OF THE DNSCLUSTER APPLICATION A. Basic Operations The DnsCluster implementation follows the classic client server paradigm. Thus, it consists of two distinct programs. The DnsCluster is the server side application/ daemon and the DnsNode which runs on the client side (and is also a daemon). The concept is to monitor for zone changes (added or deleted) and serve these changes to the DnsNode clients. When DnsCluster starts running, it reads the zones file and uses the zones found to build a set of active zones. Then it starts building a log. This log contains and describes every change that DnsCluster will find in the named.conf file. DnsCluster will serve these changes to all DnsNode instances.

3 This is done by means of appropriate commands executed at the DnsNode side. On the client's site, DnsNode polls, in preset time intervals, a DnsCluster installation (or more) for changes. DnsNode accepts the commands an associated DnsCluster sends to it and executes them one by one to reproduce the zones file. The server side of the program keeps track of every client connected to it. Thus, the next time a DnsNode daemon will communicate, DnsCluster will send only the new log commands (update). The application s operation is very simple. It complies with all the standards that a POSIX compliant system needs to work as a daemon [5]. DnsCluster has minimum memory footprint and requests less that a second of CPU time per day. It has also several security features embedded in its design. B. A closer look to the program DnsCluster periodically monitors the BIND nameserver for changes and when a change occurs the program logs it. DnsNode, the client side daemon, communicates with the server, DnsCluster, and queries it for newly added or deleted zones records (Fig 2). Figure 2. Diagram of basic DnsCluster and DnsNode functions and communication The communication takes place via a secure SSL channel. DnsCluster must accept the Certification Authority (CA) that provided DnsNode's certificate. Otherwise communication stops. Adding to SSL channels, DnsNode validates all received data by means of SHA1 Hashes. Traffic burden is not an issue since DnsCluster can transfer up to 1,000 domain zones with as little as 100kbytes of traffic. Also, thanks to its great feature of keeping account of changes, DnsCluster generates even less traffic in the internet. DnsNode also notifies the Bind nameserver for changes. The rndc (remote name daemon control) provided with every installation of BIND nameserver is used to notify BIND that changes are present in the zones file. Rndc is a tool that controls Bind nameserver and it can do some very useful things like triggering named.conf to re-read the configuration file and reload all zones from scratch or refresh a particular zone from its master nameserver. C. Important Features DnsCluster instances communicate with each other only through SSL channels. DnsCluster and DnsNode authenticate each other by means of the machine's IP address and appropriate digital certificates. If an invalid certificate is presented to the application then communication is canceled and terminated. DnsCluster works seamlessly and transparently for very long periods, just listening for changes. When a change in the zones file happens then the distribution mechanism is triggered to update all the DnsNode clients with the new changes. Changes are propagated throughout the cluster in a few minutes. Both may run for very long periods without crunching the resources of the host machine. They also provide great stability with a rustworthy memory management. DnsCluster consumes 6 MBytes of memory to operate and DnsNode consumes at most 3 MBytes to serve as much as 1,000 domain zones. These numbers confirm that DnsCluster can run in very small installations providing great performance and a rock solid stability. DnsCluster incorporates an incremental zone logging system so every DnsNode gets only the new data. Every time a host authenticates itself in order to receive the new zone records or to delete old ones, the logging system records the last command sent to the client. So, the next time the same client connects, DnsCluster will send only the changes from the previous state. DnsCluster also incorporates mechanisms to track client reboots in order to resubmit the entire zone list and thus avoid having consistency problems. D. Security Issues There are no known security issues concerning DnsCluster and DnsNode. ACE Wrappers, [6], is used for the communication which provides great stability in the client server communication. Three authentication methods are used to authenticate each connected client. First, every client must have a security certificate issued by a CA known and accepted by the DnsCluster application. Because the communication is two way, SSL encrypted DnsCluster must also provide an SSL certificate from a known and accepted CA to the DnsNode. Second, DnsCluster must validate the IP address of the connected client against the list of known members of the cluster. If this is not the case then the connection is terminated.

4 Third, DnsCluster authenticates the client via a digital signature. Every client must have its own. Every IP address in the cluster (i.e. every machine) is binded to a different signature. If any of these security checks fail then the communication is terminated immediately. One may consider this validation procedure extreme but there it is not limiting the functionality of the application and it is offering a more than adequate level of security. Running the service with root privileges is also not needed. DnsCluster may run with named or another user's uid. Also, DnsNode does not need root rights but it needs to be run with at least named uid so it can gain access to the rndc binary. E. DnsCluster development process The DnsCluster application was totally developed with open source / free software tools. The Eclipse platform with CDT was used as the editor to develop the application. Eclipse has a powerful interface to develop applications using most programming languages [7]. The communication interface was developed with ACE Wrappers [6]. ACE makes socket programming a simple and straightforward procedure. Moreover, ACE supports SSL which is a very good reason to use the Wrappers. The application was compiled with the free GNU/Gcc compiler with static libraries to make deployment a simple procedure. Valgrind was used to troubleshoot all the issues concerning memory leakages and problems in the code [8]. IV. CASE STUDIES DNS cluster topologies may differ from installation to installation. The simplest installation used in rather small web hosting environments is depicted in Fig 3. information between the primary and the secondary nameserver. Figure 4. A more complex topology (arrows show the flow of information between DnsCluster and DnsNode) In Fig. 4 a more realistic, though more complex, configuration is depicted. Here, the host machine is the web server, with a Bind instance that is only responsible to transfer the zones to the DNSnode servers. The DnsCluster and the DnsNode cooperate to transfer zone information to the slave nameserver who is the actual server of domain names to the rest of the network. The most common web hosting environment is shown in Fig 5. Here many web servers exist, each serving different domain zones. Usually only two (or three) nameservers are used to serve the zones of all the hosting servers. Web servers synchronize their zones with all the DnsNode servers in the cluster. Figure 3. A simple primary - secondary DNS topology A host machine, usually the same that hosts the web server, is hosting the master nameserver. The DnsCluster application is installed on the same host. DnsNode is running on the machine that hosts the secondary (slave) nameserver. DnsCluster is responsible for synchronizing zone related Figure 5. A topology with several WEB servers. Each one serves different zones (arrows show the flow of zone related information). DnsNode servers are serving all the zones together. This configuration provides an extra benefit. If the network connection between a web server and a secondary nameserver is lost then this secondary nameserver may learn domain zone changes by querying its primary nameserver (dotted arrow in Fig 5). Using multiple A records, Heartbeat and other familiar

5 clustering techniques one can achieve maximum fault tolerance and load balancing. V. CONCLUSIONS In this paper a client server application is presented that copes with the problem of exchanging BIND information between a primary DNS Server and its secondary servers in large domains. We have named this application DnsCluster. It is a plugin tool that can cooperate with Bind nameserver and deliver a rock solid, load balancing, fault tolerant solution for serving the Domain Name System. DnsCluster has been designed and developed to be used in diverse Web Hosting environments and may server different hosting control panels simultaneously. It has been tested in real networks and has proved to be a stable and lightweight application. Extra features are added daily and statistics are collected in order to help us enhance its features. REFERENCES [1] Mockapetris, P. RFC1035: Domain Names - Implementation and Specification. November, [2] Douglas Brian Terry, Mark Painter, David W. Riggle and Songnian Zhou, The Berkeley Internet Name Domain Server, Proceedings USENIX Summer Conference, Salt Lake City, Utah, June 1984, pp [3] cpanel Inc, [4] Microsoft TechNet, Designing DNS Zones, [5] POSIX FAQ Ver 1.12, [6] Douglas C. Schmidt and Stephen D. Huston. C++ Network Programming, Volume 1: Mastering Complexity with ACE and Patterns, Addison-Wesley, Boston, [7] Eclipse. [8] Julian Seward and Nicholas Nethercote. Using Valgrind to detect undefined value errors with bit-precision. Proceedings of the USENIX'05 Annual Technical Conference, Anaheim, California, USA, April 2005.