DNS server

=========================== from 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:

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