DNS server

=========================== from web ========================

Unix solaris 10 tutorials, training resources

Unix Solaris 10 training for SCSA, SCNA

« Introducing DNS Basics Troubleshooting the DNS Server by Using Basic Utilities » Configuring a DNS Server Published April 17th, 2007 in Configuring and Managing Network Applications.

The DNS server daemon is the /usr/sbin/named process. This daemon provides a service in the SMF. The named daemon is started at boot time only if the /etc/named.conf file exists and the appropriate SMF service is enabled.

The following svcs command is used to determine the status of the DNS-related services:

1. svcs -a | grep dns

disabled Oct_22 svc:/network/dns/client:default disabled Oct_22 svc:/network/dns/server:default

The following svcadm commands enable the DNS naming service and the default client service:

1. svcadm enable svc:/network/dns/server:default
2. svcadm enable svc:/network/dns/client:default
3. svcs -a | grep dns

online 23:02:34 svc:/network/dns/client:default online 23:08:27 svc:/network/dns/server:default

Note: The DNS client service will not start any new processes, but when enabled, checks that the system is configured as a DNS client with an /etc/resolv.conf file. Other services used for managing application and daemons that require DNS, such as LDAP, will have a dependency on the DNS client service to ensure that the system is a DNS client.

When you configure a DNS server, supply the server with the following types of information:

   * The names and addresses of root servers.
   * The information required to resolve all domains for which the server is authoritative. This information consists of name-to-address translations.
   * The information needed to resolve all reverse domains for which the server is authoritative. This information consists of address-to-name translations.
   * The names and addresses of servers for all domains that are one level below the domains being served by this server. This information is sometimes referred to as parenting or delegating.

BIND version 8.x.x and later versions use a new configuration file, /etc/named.conf, that replaced the /etc/named.boot file used in versions 4.9.x and earlier. A BIND version 4.9.x named.boot file can be converted to a named.conf file by running the /usr/sbin/named-bootconf script.

The /etc/named.conf file contains statements that:

   * Indicate the location of the file that includes the root servers
   * Establish the server as a primary, a secondary, or a caching-only server
   * Specify the server’s zones of authority
   * Indicate the location of the server’s data files
   * Apply security selectively for specific zones
   * Define logging specifications
   * Apply options selectively for a set of zones

The named daemon reads the /etc/named.conf file when the daemon is started by the SMF. The configuration file directs the named daemon either to other servers or to local data files for a specified domain.

The /etc/named.conf file contains statements and can contain comments. Statements end with a semicolon (;), they can contain a block of statements enclosed within curly braces ({}), and each statement in the block is terminated with a semicolon (;). Comments can start with /* and end with */, can follow either # or //, and can extend to the end of the line.

The table shows /etc/named.conf statements and their definitions.

Statement Definitions for the /etc/named.conf File

Statement

Definition

acl

Defines a named IP address match list used for access control. The address match list designates one or more IP addresses or IP prefixes. The named IP address match list must be defined by an acl statement before it can be used elsewhere. No forward references are permitted.

options

Controls global server configuration options, and sets default values for other statements.

zone

Defines a zone. It applies options selectively on a per-zone basis, rather than to all zones.

The image shows the contents of the /etc/named.conf file.

The /var/named/named.root file specifies name-to-address mappings for the root servers.

The information in this file is described as hints to the named daemon because the daemon attempts to contact one of the root servers listed until one of the servers responds. The responding root server returns a list of root servers. The name daemon uses this list that is returned from the root server and does not use the servers that are specified in the hints file again until the TTL value expires on the cached root-server information.

Accordingly, it is not imperative that this file be precisely up-to-date, but it should be checked every few months because root servers change from time to time.

The forward domain file (db.one.edu, in this example) contains the mappings of host names to IP addresses for all systems in the domain that are being served by this name server. In addition, this file must specify an SOA record and NS records for all name servers for this domain.

The $TTL directive sets the default time to live for the zone’s information to eight hours.

The SOA record is mandatory and has the following items:

   * An at sign (@) in the name field - This is a shortcut for the domain that is being served (one.edu. in this case). The actual value for the @ comes from the second field of the appropriate record in the named.conf file that references this file. The @ also defines the default origin that determines the domain appended to any partially qualified domain name in the configuration file’s resource records.
   * Data field argument 1 (sys12.one.edu.) - This is the name of the primary master server for this domain in FQDN format.
   * Data field argument 2 (root.sys12.one.edu) - This is an email address, in the format of DNS_admin_name.domain_name, that you can use to report problems with the domain. The administrator is usually the root user, as shown in this example. Note that the @ is replaced with a dot in the SOA record because the @ has special meaning in this file.
   * Data field argument 3 - This is the version (Serial) number that the secondary slave servers use to determine if they need to perform a zone transfer to get a fresh copy of zone data. Any time you make changes to this file, remember to update this number in such a way that it gets larger. It is always safe to start at 1 and add 1 with each change, or to use today’s date.
   * Data field argument 4 - The refresh timer is the time interval, in seconds, after which the secondary servers should check to determine if the serial number has changed, and, if it has, a zone transfer needs to occur.
   * Data field argument 5 - The retry timer is the time interval, in seconds, after which the secondary servers check back if a normal refresh failed. This timer is usually set to a smaller value than the refresh timer.
   * Data field argument 6 - The expire timer is the time interval in seconds after which, if a secondary server cannot contact the primary server or another secondary server, the entire zone data should be discarded. This prevents the secondary servers that have lost contact with the rest of the name servers from continuing to give out potentially stale information.
   * Data field argument 7 - The negative caching timer (Minimum) is the default value of time that the server keeps negative responses from other authoritative servers.

You should define an NS record for all name servers in this domain that you want to be recognized by DNS servers.

Most of the remaining resource records are address records for each system in the domain. Most of the host names are not fully qualified. The names that are not fully qualified have the domain name origin (the value of the @ in the SOA record by default) appended to them. This shorthand method can save typing and improve the readability and maintainability of the file.

The CNAME record defines host aliases, or nicknames for hosts. The CNAME record in this instance is similar to the following entry in a /etc/inet/hosts file:

192.168.1.1 sys11 router

The localhost entry specifies the loopback address for all hosts.

Reverse domain files (db.192.168.1, in this example) contain mappings for address-to-name translation. Address-to-name translation is important and is used by various utilities, such as NFS, web servers, BIND, and sendmail.

Observe the following about this file:

   * The @ (at the top of this resource record) in this example refers to the 1.168.192.in-addr.arpa. reverse domain, as indicated in the /etc/named.conf file in which this reverse file is referenced.
   * The address-to-name mappings are defined with the PTR record type. The domain field in the PTR record contains the host portion of the IP address. Because these resource records do not end with a . (dot), the value of the @ is appended to each record. The argument field of the PTR record should contain the FQDN of the name of the system at which the record points. This completes the reverse address-to-name mapping.

Reverse loopback domain files specify the reverse loopback domain address-to-name translation. The contents are hard-coded, with the exception that the server name changes depending upon on which server the file is installed. This file is required on all DNS servers. Every name server is the master for its own loopback address.

Observe the following about this file:

   * You can use the @ when the domain name is the same as the origin, 127.in-addr.arpa. in this example.
   * The only items that you change from domain to domain in the SOA record are the host name (first) argument and the email address used to report problems.
   * You must specify the name of the system being configured on the NS line.
   * Use all other lines as shown in this example.

Dynamic updates cause a DNS server to be updated automatically with DHCP host information from a DHCP server. This enables nomadic DHCP users to have access to systems and services without manual administration.

To configure a server to permit dynamic updates to occur, complete the following steps:

  1. Log in as root on the DNS primary server, edit the /etc/named.conf file, and add allow-update statements to both the forward and reverse zones. For example:

zone “one.edu” in {

       type master;
       file “db.one.edu”;
       allow-update { 127.0.0.1; 192.168.1.2; };

}; zone “1.168.192.in-addr.arpa” in {

       type master;
       file “db.192.168.1″;
       allow-update { 127.0.0.1; 192.168.1.2; };

};

  2. Restart the named process by using the svcadm commands. For example:

1. svcadm restart svc:/network/dns/server:default

     or

1. svcadm disable svc:/network/dns/server:default
2. svcadm enable svc:/network/dns/server:default

Because of the nature of the Internet, DNS can be vulnerable to unauthorized access.

Beginning with BIND version 8.x.x, security features are implemented through the /etc/named.conf configuration file. Two important security considerations are the control of name queries and the control of zone transfers. By default, servers respond to any query or request for a zone transfer. You can modify this behavior by using the allow-query and allow-transfer keywords.

The allow-query statement enables you to establish an IP address-based access list for queries. You can apply this access list to a specific zone or to all queries that are received by the server. The IP address list determines which systems receive responses from the server.

You can restrict queries to all zones by using the allow-query keyword as an argument to the options statement for the zone.

For example:

options {

       allow-query { 192.168.1/24; 192.168.3/24; };

};

In this case, only systems with the IP addresses 192.168.1.xxx and 192.168.3.xxx receive responses from the name server.

You can restrict queries for a specific zone by using the allow-query keyword as an argument to the zone statement. For example:

zone “one.edu” in {

       type master;
       file “forward.zone”;
       allow-query { 192.168.3/24; };

};

In this case, only subnet 192.168.3.0 has access to the resource records for this zone.

In the same manner, the allow-transfer keyword can limit which systems may receive a zone transfer from a name server. You can restrict zone transfers from a name server by using allow-transfer in the options statement. For example:

options {

       allow-transfer { 192.168.1.3/32; };

};

The allow-transfer keyword can also be applied to a specific zone, if you want. Another feature that often is associated with restricting queries and transfers is access control lists (ACLs). The list of IP addresses used in the previous examples could be replaced by an ACL.

You can configure ACLs by using the acl keyword to build an ACL list that can be used as an argument to the allow-query and allow-transfer keywords.

For example:

acl “local” { 192.168.1.0/24; 192.168.2.0/24; 192.168.3.0/24; }; zone “one.edu” in {

       type master;
       allow-query { “local”; };
       allow-transfer { “local”; };

};

The contents of the /etc/named.conf file on the secondary DNS server can be less complex than that of the primary server. If a server is to act as both a primary server for some domains and a secondary server for other domains, the /etc/named.conf file must contain keywords that are appropriate to both functions. The master keyword denotes a primary server for a domain, and the slave keyword denotes a secondary server for a domain when used as arguments to the type directive.

An example of an /etc/named.conf file for a secondary server is:

options {

    directory “/var/named”;

}; zone “.” {

    type hint;
    file “db.root”;

}; zone “one.edu” {

    type slave;
    file “db.one.edu.slave”;
    masters
    {
         192.168.1.2;
    };

}; zone “1.168.192.in-addr.arpa” {

    type slave;
    file “db.192.168.1.slave”;
    masters
    {
         192.168.1.2;
    };

}; zone “0.0.127.in-addr.arpa” in {

    type slave;
    file “db.127.0.0.slave”;
    masters
    {
         192.168.1.2;
    };

};

Observe the following about this file:

   * Secondary servers are configured with and use the same root server hints file as the primary name server.
   * Secondary servers are configured with and use the same syntax for a reverse loopback domain file as the primary name server uses, except that the secondary name server is always listed as the primary for the loopback address.
   * The reverse.backup and reverse.rbackup files and their contents are created automatically by the secondary server’s named daemon after the primary name server is contacted successfully.
   * The IP address from which the secondary server should download its zone files is listed following the masters keyword. Up to 10 IP addresses can be listed. The server or servers listed can be the primary server or secondary servers.

Secondary servers start the named daemon during the boot process if the /etc/named.conf file exists. The daemon is started by SMF.

The named-checkconf and named-checkzone commands can be used to check the integrity of the named.conf and database files. These commands report syntax errors.

The named-checkconf command is used to check the /etc/named.conf file.

Missing punctuation can be detected:

sys12# named-checkconf /etc/named.conf:32: missing ‘;’ before ‘zone’

Misspelled keywords are exposed:

sys12# named-checkconf /etc/named.conf:32: unknown option ‘zonee’

Missing required keywords are reported:

sys12# named-checkconf /etc/named.conf:38: zone ‘one.edu’: type not present

The named-checkzone command is used to check the any of the zone files.

A clean one.edu zone in the db.192.168.1 file is reported:

1. named-checkzone one.edu db.192.168.1

zone one.edu/IN: loaded serial 2005010101 OK

Typographical errors in the SOA record are detected:

sys12# named-checkzone one.edu db.192.168.1 dns_master_load: db.192.168.1:10: unknown RR type ‘SA0′ zone one.edu/IN: loading master file db.192.168.1: unknown class/type

Missing NS records are reported:

sys12# named-checkzone one.edu db.192.168.1 zone one.edu/IN: has no NS records

All DNS clients require the presence of the /etc/nsswitch.conf and /etc/resolv.conf files. Note that the DNS server must also be configured as a DNS client if it intends to use its own DNS services.

The /etc/nsswitch.conf file specifies the resolver library routines to be used for resolving host names and addresses. Modify the /etc/nsswitch.conf file by editing the hosts entry and adding the dns keyword. To ensure proper network interface configuration during the boot process, make sure that the files keyword is listed first. The following example shows a hosts entry configured for DNS:

hosts: files dns

The /etc/resolv.conf file specifies the name servers that the client must use, the client’s domain name, and the search path to use for queries.

resolv.conf file for DNS clients of the one.edu domain

search one.edu two.edu three.edu nameserver 192.168.1.2 nameserver 192.168.1.3

Observe that the search keyword specifies domain names to append to queries that were not specified in the FQDN format. The first domain listed following the search keyword designates the client’s domain. If both “domain” and “search” keywords are present, then the last one in the file is used and the other one(s) are ignored.

The nameserver keyword specifies the IP address of the DNS servers to query. Do not specify host names. You can use up to three nameserver keywords to increase your chances of finding a responsive server. In general, list the name servers that are nearer to the local network first. The client attempts to use the loopback address if there is no nameserver keyword or if the /etc/resolv.conf file does not exists. Starting the Client Service

The following svcadm command enables the DNS default client service:

1. svcadm enable svc:/network/dns/client:default

1. svcs -a | grep dns

online 23:02:34 svc:/network/dns/client:default

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.

   * Digg
   * del.icio.us
   * Netvouz
   * DZone
   * ThisNext
   * MisterWong
   * Wists
   * BlinkList
   * StumbleUpon
   * Technorati
   * Reddit
   * Slashdot
   * YahooMyWeb

Related Post:

1. Configuring and Managing DHCP Clients
2. Configuring the Name Service Switch
3. Troubleshooting DHCP Clients
4. Configuring the Network Infomation Service (NIS) (part2)
5. Introducing Client-Server Processes

Enter your search terms Web learning-solaris.com Submit search form AddThis Social Bookmark Button Category

   * Access Control and System Messaging Configuration (8)
   * Apache-MySQL-PHP-SSL (4)
   * Archiving and Restoring the System (5)
   * Archiving Files and Remote Transfer (11)
   * Configuring and Managing Network Applications (15)
   * Configuring the Network (22)
   * Configuring the Network Interface Layer (3)
   * Managing File Systems (23)
   * Managing Network Printers and System Processes (11)
   * Manipulating and Managing Files and Directories (20)
   * Naming Services Setup (12)
   * Network Basics (5)
   * Performing User and Security Administration (7)
   * Searching and Process Manipulation (6)
   * Solaris 10 installation (2)
   * Solaris 10 OS x64/x86-Based Systems Differences (81)
   * Storage Volume Management (12)
   * System Boot Procedures (9)
   * Using Components of the Desktop System (12)
   * Virtual File Systems and Core Dump Management (15)
   * Working With the Shell (10)

Resources

   *
     Link exchange
         o Aspiring Sysadmin
         o DaniWeb IT Discussion Community
         o EatonWeb Blog Directory
         o Free IT Ebooks
         o Learning Cisco Cert
         o Solaris 10 blog
         o Solaris Central
         o Sun Help
         o Unix Tutorials
         o Useful Links

You wanna to put link ! Contact me: hoanginlove81@yahoo.com

Rate Me on BlogHop.com! the best pretty good okay pretty bad the worst help?

UserOnline

   *
     1 User Online

Alexa Certified Traffic Ranking for www.learning-solaris.com Logo Exchange : mail to hoanginlove81@yahoo.com )

ITexpert | Technology - Certification - Training Community Top 100 Linux Sites

Computers Blogs - Blog Top Sites Top Blog Lists Find Blogs in the Blog Directory Geo Visitors Map

Unix solaris 10 tutorials, training resources is powered by WordPress 2.1.3 and K2 RSS Entries and RSS Comments

===================== from web =========================

DNS Configuration

DNS allows systems to look up host names, both within the private network and across the Internet. There are other ways of doing this, for example you could just run identical hosts files on all your machines. But somehow, this is more fun. In addition, Windows 95 machines examine their hosts databases in an odd order which makes using host tables difficult; the win95netbug FAQ rovides information on this, as well as help on how to reconfigure win95 to reorder the lookup order.[24]

You can set up the DNS server on any Unix system. The standard Solaris 2.6 install comes with BIND 4.9.x, suitably altered to deal with the additional Solaris naming systems. However, 4.9.x seems to do a great deal of maintenance work at fairly random times. This is fine if you have a permanent connection, but not so fine with a dialup. As a result, I have got BIND 8.2 from the Internet Software Consortium and installed that instead.[12]

As a result, I'm going to talk about BIND 8.2 here. The version of BIND which comes with Solaris 2.5.1 seems a lot more dialup friendly. So, if you are using an older version of Solaris, you can probably stay with the supplied version; the boot files are considerably different, however, so you will need to examine the documentation.

Compiling BIND 8.2

Compiling BIND 8.2 is fairly straightforward. However, before compiling, you will need to apply any patches to the supplied source code. The command patch < patch1 will apply the patch.

To configure the Makefiles, use make depend from the src directory. To make the programs, use make To install, first remove the .settings file and then use make install Installation goes into directories under /usr/local

The source code for BIND does not come with any manual pages. A separate documentation download contains man pages. The install Makefile for the man pages, however, expects a BSD-style install and, therefore, you will need to put /usr/ucb at the start of your PATH environment variable if you want a painless install. You may also need to modify the Makefile to remove pre-formatted man pages.

DNS Server Configuration

To configure the DNS server, you need to set up a number of (text) database files. The DNS server daemon (called named) first consults a boot file. This boot file tells the daemon to consult a series of further database files which gives it enough information to start serving names.

Choosing a Domain

Before setting up your DNS server, you will need to choose a domain name. Since nobody, except you, will accept your domain as a genuine domain (we hope) you have a reasonable amount of latitude over what domain names you can pick.

Since I work for AFS, I have decided to call my domain canberra.afs.net.au I am pretty certain that nobody else is going to use that name.

You'll have to decide what domain name to pick. As a suggestion, if you are connecting to ORAC, then a domain of whimsical-name.orac.net.au might be a good idea. On the other hand, I haven't consulted ORAC about this, so it might not.

For the purposes of example, I an going to use the domain name flibble.orac.net.au

The Boot File

The boot file is consulted by named to on startup, so that initial options and data can be loaded. A sample /usr/local/etc/named.conf file for a server is shown in figure 2.

Figure 2: Sample named.conf File for BIND

2. Boot file for server solaris, primary server
3. for flibble.orac.net.au.

options {

   directory "/var/named";
   forwarders {
       299.18.99.151;
       299.8.183.1;
   };
   forward first;
   dialup yes;
   heartbeat-interval 1440;

};

zone "." {

   type hint;
   file "named.ca";

};

zone "flibble.orac.net.au." {

   type master;
   file "private.hosts";

};

zone "3.5.10.in-addr.arpa." {

   type master;
   file "private.rev";

};

zone "0.0.127.in-addr.arpa." {

   type master;
   file "private.local";

};

The meaning of the lines in this file are:

directory

   The directory in which the database files will be found. The /var/named directory is traditional, although inexplicable, since configuration files usually go under pathname/etc

forwarders

   A list of IP addresses to forward queries to. This saves us from doing all the work of working down the domain tree when finding a domain. You can set your forwarders to the name servers supplied by your ISP.

forward

   The forwarding behaviour. Queries are first forwarded to the addresses listed in forwarders. Only if no forwarding server responds will this server do its own work. Setting this option to only means that this server never does its own search.

dialup

   Indicate that this is a dialup machine and that, therefore, maintenance work should be grouped together rather than done at any old time. This option is the main reason for my installing BIND 8.2.

heartbeat-interval

   The interval (in minutes) between performing maintenance activities. This option is set, by default, to 60 minutes. Setting it to 1440 minutes means than maintenance is done once a day.

zone

   Data about a particular domain. The string in double quotes give the domain name, with . being the top-level, root domain. The name server is to be the master server for the domain flibble.orac.net.au (name to IP-address) and the networks 10.5.3 and 127.0.0 (IP-Address to name).

type

   The type of domain data. hint means that the data is there so that the top-level domain servers can be found. master means that this is the master server for this domain.

file

   The file to read the name server data from. These files are discussed below. 

The /var/named/named.ca File

The server, when it is doing its own work, rather than forwarding, needs a start point for searching for domains. This file contains the IP addresses of the servers for the root domain name servers. The base version of this file is shown in figure 3. The first section of this file states that the name servers (NS) for the root domain (.) are the ones listed. The second section says, for each name server, what its IP-address (A) is. The numbers (518400 and 3600000) give the time-outs in seconds for these entries; these figures should be large enough for the time out not to be a problem.

Once you have this file, it's a good idea to pick up the most current official version at ftp://rs.internic.net/domain/named.root.

Figure 3: Initial named.ca Cache File for BIND

Initial cache data for named servers

Servers

. 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET.

Addresses

D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 B.ROOT-SERVERS.NET. 3600000 IN A 128.9.0.107 C.ROOT-SERVERS.NET. 3600000 IN A 102.33.4.12

The /var/named/private.hosts file

This file contains the IP addresses of the private network. A sample private.hosts file is shown in figure 4.

Figure 4: Sample private.hosts File for BIND

Hosts file for domain flibble.orac.net.au.

name ttl class type data

Source of authority

@ IN SOA solaris.flibble.orac.net.au. root.solaris.flibble.orac.net.au. (

               2000050201    ; Serial
               10800    ; Refresh - 3 hours
               3600    ; Retry - 1 hour
               432000    ; Expire - 1 week
               86400)    ; Minimum - 1 day
        IN    NS    solaris.flibble.orac.net.au.

Machines for the flibble.orac.net.au domain

name ttl class type data

localhost IN A 127.0.0.1 solaris IN A 10.5.3.1 win95 IN A 10.5.3.21 linux IN A 10.5.3.22

Aliases

mail IN CNAME solaris www IN CNAME solaris

Domain mailing addresses

flibble.orac.net.au. IN MX 10 solaris.flibble.orac.net.au. flibble.orac.net.au. IN A 10.5.3.1

Some explanation of the various codes is probably in order:

@

   Domain. This is a short-hand for the domain given by the named.conf file (flibble.orac.net.au in this case).

IN

   Internet. Indicates that we are talking about the Internet class of records. Supposedly, there are other possible classes here.

SOA

   Source of Authority. This entry contains information on which machine is the primary name server for information about this domain (solaris.flibble.orac.net.au in this case) and who to contact in the case of trouble (root.solaris.flibble.orac.net.au). The serial number is used to indicate where changes have occurred. The other numbers give the time to expiry of the information broadcast by this name server.

   The serial numbers need to increase with each version of the file. A fairly common practice is to use YYYYMMDDVV with the year, month and day being the date of update and VV being the version number within the day. In the past, serial numbers of the form 1.2 were common, but this is now deprecated.

NS

   Name Server. This line indicates that solaris.flibble.orac.net.au is the name server for this domain.

A

   Address. These lines give the IP addresses of the various hosts.

CNAME

   Canonical Name. These lines give canonical names (aliases) for various common names. These names are not strictly needed, but redirect requests to www.flibble.orac.net.au etc. to solaris.flibble.orac.net.au

MX

   Mail Exchange This line gives the system to which mail addressed to user@flibble.orac.net.au should be sent to (solaris in this case). 

The /var/named/private.rev file

This file allows ``reverse lookup. With this file, a system can get the name of a host from its IP address. A sample private.rev file is shown in figure 5. The PTR code allows an IP address. The 10.5.3. part of the address is derived from the entry in the named.conf file (see section 3.4.2).

Figure 5: Sample private.rev File for DNS

Reverse address file for domain flibble.orac.net.au

name ttl class type data

Source of authority

@ IN SOA solaris.flibble.orac.net.au. root.solaris.flibble.orac.net.au. (

               2000050201    ; Serial
               10800    ; Refresh - 3 hours
               3600    ; Retry - 1 hour
               432000    ; Expire - 1 week
               86400)    ; Minimum - 1 day
       IN    NS    solaris.flibble.orac.net.au.

Machines names

name ttl class type data

1 IN PTR solaris.flibble.orac.net.au. 21 IN PTR win95.flibble.orac.net.au. 22 IN PTR linux.flibble.orac.net.au.

The /var/named/private.local file

This file allows reverse lookup for the localhost address. This file is not strictly necessary. A sample private.local file is shown in figure 6.

Figure 6: Sample private.local File for DNS

Reverse address file for localhost

name ttl class type data

Source of authority

@ IN SOA solaris.flibble.orac.net.au. root.solaris.flibble.orac.net.au. (

               2000050201    ; Serial
               10800    ; Refresh - 3 hours
               3600    ; Retry - 1 hour
               432000    ; Expire - 1 week
               86400)    ; Minimum - 1 day
       IN    NS    solaris.flibble.orac.net.au.

Machines names

name ttl class type data

1 IN PTR localhost.

Starting the named Daemon

Once you have the files for named set up, you can start the /usr/local/sbin/named daemon. This daemon will read the /usr/local/etc/named.conf file for its configuration.

You will probably want to make the named daemon start up during startup. To do this, modify the /etc/init.d/inetsvc file so that the lines which read

if [ -f /usr/sbin/in.named -a -f /etc/named.boot ]; then

   /usr/sbin/in.named;     echo "starting internet domain name server."

fi

now read

if [ -f /usr/local/sbin/named -a -f /usr/local/etc/named.conf ]; then

   /usr/local/sbin/named; echo "starting ISC internet domain name server."

elif [ -f /usr/sbin/in.named -a -f /etc/named.boot ]; then

   /usr/sbin/in.named;     echo "starting Solaris internet domain name server."

fi

If you have installed named in an automounted local directory, you may need to delay the starting of the daemon somewhat, until the automounter is running.

DNS Client Configuration

Once you have set up the DNS server, you will need to configure each system to use the name server.

Configuring Solaris Clients

To configure a Solaris client properly you will need to edit the /etc/nsswitch.conf so that the DNS server is consulted. Modify the hosts line in so that it reads:

hosts: files dns

This line means that the Solaris system will first look up a name in the /etc/hosts file (see section 3.3.1). If the name isn't there, then DNS will be used.

You will also have to set up the /etc/resolv.conf file so that the correct name servers are consulted. A sample resolver file is:

Resolver for domain flibble.orac.net.au.

domain flibble.orac.net.au nameserver 10.5.3.1 nameserver 203.30.77.33

The entries in this file are pretty self-evident. The name servers are tried in order, so if the local name server is down, the ORAC name server will be tried instead.

The last thing you need to do is set the local domain name. You probably do not have to do this, but neatness demands it. The two commands you need are domainname flibble.orac.net.au and domainname > /etc/defaultdomain where flibble.orac.net.au is replaced by your chosen domain name.

Disabling nscd Cache Refreshes

Solaris 2.6 comes with a name caching daemon, nscd This daemon keeps a cache of recent name queries to allow a more speedy response to common queries.

nscd is all very nice. But, in it's default configuration, it refreshes the queries in it's cache every hour or so. If you have a dial-out connection, this means that every hour, your line will come up to re-query any names that are in the cache; not a good thing.

To disable the refresh, alter /etc/nscd.conf so that the line reading keep-hot-count hosts 20 now reads keep-hot-count hosts 0 Then make the nscd daemon re-read it's configuration file by sending it a HUP signal.

Configuring Linux Clients

Configuring Linux DNS clients is similar to configuring Solaris clients as described above, in section 3.4.3, except that you do not have to configure the /etc/nsswitch.conf file and you only need to configure the domain name if you have NIS installed.

Configuring Windows 95 Clients

To configure DNS for Windows 95, you need to open the Network section of the Control Panel and choose the TCP/IP properties. For the example network, we have:

Tab Field Value DNS Configuration Enable DNS

 	Host 	win95
 	Domain 	flibble.orac.net.au
 	Add 	10.5.3.1
 	Add 	203.30.77.33

Testing the DNS Configuration

Once you have the DNS configuration working, you will probably want to test it. The basic tool for testing the server configuration is /usr/local/sbin/nslookup This tool allows you to interrogate the name server and see how it responds to various questions.

Testing the Server

The DNS daemon can be made to provide debugging information by sending it a USR1 signal, via kill. The daemon will start tracing its behaviour by writing records into the file /var/named/named.run Sending the daemon a USR2 signal turns off debugging.

The daemon can be made to dump it's current state into the file /var/named/named_dump.db by sending it a INT signal.

Testing the clients

For Unix systems, using nslookup to test client behaviour is obvious. Windows 95 does not have a suitable testing package. I used WS_Ping to test my setup.[25] WS_Ping is not freeware.