DNS server

To install DNS slave server on new clon10 file /etc/named.conf was copied, and directory /var/named was tared and copied. After that command

svcadm enable /network/dns/server

was issued (following messages appeared some time ago, but everything was working; last time it were no messages

clon10:/etc> svcadm enable /network/dns/server
clon10:/etc> Nov 21 21:25:11 clon10 named[745]: /etc/named.conf:20: unknown logging category 'panic' ignored
Nov 21 21:25:11 clon10 named[745]: /etc/named.conf:21: unknown logging category 'packet' ignored 
Nov 21 21:25:11 clon10 named[745]: /etc/named.conf:22: unknown logging category 'eventlib' ignored
Nov 21 21:25:11 clon10 named[745]: /etc/named.conf:25: unknown logging category 'cname' ignored)

Seems it started:

clon10:/etc> svcs | grep dns
online         21:25:12 svc:/network/dns/server:default

Stop DNS client if it was running:

svcadm disable /network/dns/client

=========================== from the web ========================

Setting up a DNS from scratch can be complicated. Although you can read the man pages and generate valid map files from scratch, it is not very efficient. A better way is to follow an example template provided in the next section.

Unpacking Instructions

Download this template (copy from old clon00/clon10 installation) to a work directory, such as /var. To unpack the file, at the command line type:

   zcat name.tar.Z | tar xvf -

Fast Installation Overview

For quick installation, do the following:

  1. Determine what type of DNS you want and what support information you need from your network provider, such as global caching DNS.
  2. Edit the named.* files you need. For releases prior to Solaris 7, use named.boot, named.local, named.cache, named.mydomain, and named.mydomain.rev. For Solaris 7 and Solaris 8, the map files are the same, but edit the named.conf instead of named.boot.
  3. Edit the /etc/resolv.conf file. It should look like the following:

   domain mydomain.com
   nameserver 127.0.0.1     ;if DNS server runs on this host
   nameserver 129.200.9.1   ;if this is a remote client

  4. Create a symbolic link in /etc/ to either the named.boot or named.conf file and start the DNS (/usr/sbin/in.named).
  5. You can verify the DNS is working properly by running some queries to test forward and reverse resolution.

Detailed Installation

  1. Determine what kind of DNS you need.

     If you are at a trade show and without Internet access, you need to be a primary.

     If you are at a trade show and have Internet access, find the ISP and ask whether they have (a) a world resolvable caching DNS and (b) a primary for the show floor. If they have (a) but not (b), you will need to be a primary for this subnet. Any reputable ISP will have at least (a). If they have both (a) and (b), but are unreliable for (b), you should be a secondary. If (b) does not have a complete map or maps, you may need to create your own primary for that subnet.

     If you are just starting a new subnet (e.g. you are at a startup company and the person who knows anything about network administration is the IT person), then you probably want to be your own primary for the subnet. You should talk it over with your ISP. If your ISP is responsive and reliable, and doesn't mind that you constantly re-assign IP addresses and hosts, you should use them as your primary. Otherwise, if you are planning to do some very complicated DHCP, IP address sharing, NAT, or network customization, you probably should be your own primary. In other words, if you want your network to be resolvable and routable outside of your network, you may want to arrange with your ISP to give you primary domain DNS control for your subnet and have the ISP act as a "secondary" to your subnet domain. This configuration is common at many large universities. For example, each department or college group manages its own subnet within a large Class A or B network. The institution's top level DNS is actually a secondary for the various smaller subnet primaries.

     If you need to resolve Internet host names outside of the corporate network, but have an inadequate primary DNS on your network, you should become a secondary DNS for your local subnet. You can also add a forwarders entry to the corporate top-level gateway DNS so that you can resolve IP addresses outside of the corporate network. Other people can then configure their hosts to use your DNS as their default to use these features.
  2. If you are running Solaris 7 or Solaris 8, examine the named.conf file. If you are running releases prior to Solaris 7, see the named.boot file. Each file is self explanatory and you can copy the /etc/hosts file and add Authoritative records (A) and pointer records (PTR) to your maps.

     Note: For Solaris 7 users who are familiar with BIND8 (old) format named.boot files and want to convert them to the new BIND9 format named.conf files, you can run the /usr/sbin/named-bootconf -i infile -o outfile utility.

     Edit all the files you need, usually:

         Mandatory files
         named.boot or named.conf (depending on OS version)
         named.cache
         named.local

         Optional files (for primary DNS)
         named.mydomain
         named.mydomain.rev
         [other reverse or forward maps] 

     You may have multiple forward and reverse maps because this DNS may be supporting multiple domain names and subnets.
      
  3. Edit the /etc/resolv.conf file. It should look like the following:

   domain mydomain.com
   nameserver 127.0.0.1     ;if DNS server runs on this host
   nameserver 129.200.9.1   ;if this is a remote client

     You can have multiple DNS entries in the resolv.conf file. Each entry is searched in top-to-bottom order until the server responds, or times out. Therefore, you should put the server that is the most robust and responds the fastest at the top of the list. When a DNS is successfully queried, it is general practice for the client to use only that server for querying, even if the DNS responds that there are no entries. If the DNS you configured to use on the client is not resolving all of the hosts you know exist, you should contact the administrator for that DNS or simply change to a server that can resolve all the names. If a DNS server is down, you may experience a long wait before the client application fails and switches to use the next DNS. This can vary from 15 to 60 seconds per DNS entry in the resolv.conf file. If you are experiencing DNS resolution delays repeatedly and have access to another server, you should change the resolv.conf file to use another DNS.
      
  4. Create a symbolic link in /etc/ to either the named.boot or named.conf file. For example, if you unpacked the file in /var/named on a Solaris 2.6 system, type at the command line:

   ln -s /var/named/named.boot /etc/named.boot

     Start the DNS server by typing:

   /usr/sbin/in.named

  5. Test the DNS by running some queries to test forward and reverse resolution. You can use the following forward test:

   /usr/sbin/nslookup myhost

     A sample response looks like:

   Server: localhost
   Address: 127.0.0.1

   Name: myhost.mydomain.com
   Address: 129.200.9.1

     You should repeat your test using an IP address instead:

   /usr/sbin/nslookup 129.200.9.2

     A sample response looks like:

   Server: localhost
   Address: 127.0.0.1

   Name: myhost2.mydomain.com
   Address: 129.200.9.2

     If the DNS is set up to resolve Internet addresses, you can test this by typing:

   /usr/sbin/nslookup nuc.berkeley.edu

     A sample response looks like:

   Server: localhost
   Address: 127.0.0.1

   Non-authoritative answer:

   Name: nuc.berkeley.edu
   Address: 128.32.142.96

Disclaimer

This template is supplied "AS IS" without support or warranties.

=========================== from the web ========================

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:

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

 # svcadm enable svc:/network/dns/server:default
 # svcadm enable svc:/network/dns/client:default
 # 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 folllowing table shows /etc/named.conf statements and their definitions.

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:

 # svcadm restart svc:/network/dns/server:default
 #

or

 # svcadm disable svc:/network/dns/server:default
 # 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:

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

 # svcadm enable svc:/network/dns/client:default

 # svcs -a | grep dns
 online         23:02:34 svc:/network/dns/client:default