Providing Crucial Network Services W/ Solaris 9 OS

Posted on
Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

Many modern organizations rely on computer networks to run core business functions. The network can be considered a foundation stone in business operations. Keeping the network running is crucial to the continuing success of the organization. The Solaris 9 OS can be used as the platform to provide many crucial network services.

The Domain Name System
One service fundamental to many networks, and to the Internet, is the Domain Name System (DNS). Whenever you type the name of a Web site in a Web browser, it is DNS that is responsible for translating the name of the Web site to the numeric IP address that the computer actually uses to contact the Web server and obtain the information you asked for by supplying the name of the Web site. The DNS functions as a distributed database, with each organization responsible for providing accurate DNS records to the rest of the Internet.

The DNS allows customers, clients, partners and suppliers to contact an organization’s computers. Without functioning and accurate DNS information, an organization will lose network connectivity with these groups, which may have significant impact on operations. Providing and maintaining an organization’s public DNS information can be an important component of a network administrator’s job role.

Any organization that makes DNS information available to the Internet is required to follow certain rules. One rule is that the organization’s DNS information must be available from a minimum of two DNS servers that are connected to the Internet. An organization may choose to connect all of its public DNS servers using the same connection to the Internet. This approach, while it does meet the requirements of connecting to the Internet, runs the risk that, if the single network connection fails, the organization’s DNS information is no longer available to anyone who wishes to access the organization’s public information. A better solution may be to have the DNS servers each connected to the Internet using a different network link. In a large organization with multiple locations, this may be achievable through the organization’s own Internet connections. For a small organization, which may only use one Internet link, an alternative approach may be required.

The DNS divides the Internet into areas known as “name spaces.” A master DNS server and one or more slave DNS servers are configured for each part of the DNS name space. The master DNS server is the location where the original source information is stored. Secondary DNS servers contain copies of the DNS information obtained from the master server. Secondary servers contact the master server on a regular basis to obtain updates. Anyone who wants to contain the computers that have their information stored in the DNS server should be able to contact the master DNS server or any of the slave DNS servers to obtain the information that they are looking for.

Being a master DNS server or a slave DNS server is not a function of a system. A single system can be both a master and a slave DNS server for different areas of the name space. The function of being a master DNS server or a slave DNS server is defined individually for each area of the DNS name space for which a server will supply answers to requests. This granularity of functionality is what allows a smaller organization to implement a master DNS server using its own Internet link and use the same system to provide slave DNS servers for other small organizations. Implementing such arrangements on a reciprocal basis allows several small organizations to meet the requirements of DNS servers for connecting to the Internet while introducing redundancy in the connection of the DNS servers to the Internet and requires that each organization maintain only a single system.

Configuring a Solaris 9 System as a DNS Server
Many systems acting as DNS servers use an implementation of the Berkeley Internet Name Daemon (BIND), and the Solaris 9 OS is no exception to this. The Solaris 9 OS contains the in.named daemon, which is an implementation of the Berkeley Internet Name Daemon (BIND). The exact version of BIND varies depending on which release of the Solaris 9 OS you are running, but it will be an implementation of BIND version 8.

A Solaris 9 system will configure itself as a DNS server when the system boots if the file /etc/named.conf is present. The /etc/named.conf file is the BIND Configuration file and defines everything about the DNS server running on the system on which it is found. The /etc/named.conf file includes information about which areas of the DNS name space a DNS server is responsible for, which are called “zone.” It also defines whether the DNS server is a master or a slave server for each zone, and typically defines where the files are located that contain the DNS information for each zone. There may also be information that defines where the DNS server should go to obtain information about the other areas of the DNS name space that it does not know about.

The location of the files containing the DNS information is defined in an options section in the /etc/named.conf file. For example:

options {
directory “/var/named”;

The files that contain information about individual areas of the DNS name space are called zone files. Two zone files exist on a DNS server for an area of the DNS name space the server is responsible for. One zone file is the forward zone file, and the other is the reverse zone file. The DNS service is responsible for taking host names and supplying the IP address for the system, but it is also responsible for supplying the host name of the host, which has a particular IP address. The forward zone file is responsible for the information used to translate host names to IP addresses. The reverse zone file is responsible for the information used to translate IP addresses to host names. Forward and reverse zone files are defined in zone sections in the /etc/named.conf file. For example:

zone “” in {
type master;
file “”;
zone “” in {
type master;
file “mydomain.revzone”;

The value contained in the quotes after the zone keyword forms the origin for each zone file. The two zone files are located in the directory specified by the directory keyword in the options section. The two files follow a similar format, but contain some important differences. Both files begin with a Start of Authority (SOA) record. The SOA record defines some important information about the zone file. A typical SOA record may look like this:

@ IN SOA (
1 ; Serial Number
10800 ; Refresh (3 hours)
3600 ; Retry (1 hour)
604800 ; Expire (1 week)
86400 ) ; Minimum TTL (1 day)

The “at” symbol (@) is a placeholder for the origin defined in the /etc/named.conf file. The two fields following the SOA keyword define the nameserver and DNS administrator e-mail address for the domain. Note that the e-mail address for the DNS administrator does not contain the @ symbol because of its use as a placeholder for the origin. Instead, the first dot is automatically replaced to turn the argument in to an e-mail address. The e-mail address is followed by a list of five values enclosed in braces. (Note that a semi-colon in a zone file designates the remainder of the line as a comment.)

The first of the five values is the serial number of the zone file. This value can be considered to be a version number. Each time the zone file is changed, this number must be increased. The serial number is the value that a slave DNS server uses to determine whether or not it needs to update its information about a zone from the master server. In simple terms, if the serial number of the slave’s

Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone


Posted in Archive|