BIND 9 DNS server meets SMF/Predictive Self Healing

Overview

---

If you have been reading about Solaris 10, chances are that you have already heard of a new feature, Predictive Self Healing or the Service Management Facility- SMF for short. There is lots of excellent information about this useful feature. You are assumed to be familiar with end user SMF concepts and CLI programs.


Since we integrated the Internet Systems Consortium's BIND 9 server in Solaris 10 and made it SMF aware, I have been asked several questions about how to configure it, what's changed from the " stock " BIND and what if anything is needed to run named, chroot. Some users also asked these same questions of ISC.


I should point out that Sun fully stands behind the Solaris integrated BIND code in the sense that we offer what we call " level one" support. This essentially means that if you think there'is a bug in the Solaris integrated BIND, you should let us know and we will investigate it and if applicable, fix it ourselves rather than pointing you to the " community " or an ISV. Sun works closely with ISC to address any issues that we find during or after integration. Sun is also an OEM level BIND Forum member.


The BIND version 9 server is new for Solaris 10. Previous versions of Solaris shipped with the BIND v8 server. The DNS client portion continues to be based on the well known BIND resolver, a defacto standard on Unix and Linux. The 03/2005 Release of Solaris 10 ships with the BIND 9.2.4 version. The server and tools ship in the same location as their BIND 8 counterparts- in /usr/sbin.

DNS Service Manifests and Upgrade to Solaris 10

---

Solaris 10 ships with two manifests for DNS service- a client manifest and a server manifest. The client manifest is located in /var/svc/manifest/network/dns/client.xml. The server manifest is located in /var/svc/manifest/network/dns/server.xml. The DNS client service is automatically enabled at initial boot if /etc/resolv.conf exists. Similarly the DNS server is enabled if the /etc/named.conf file exists. In both cases this assumes that all services upon which the DNS client and server depend, are enabled.


If you are upgrading from a previous Solaris version and used either or both of the DNS client and server- meaning if you have the configuration files mentioned above, the upgrade to Solaris 10 will automatically enable the services. No user intervention needed! If these configuration files don't exist, you should create them manually before attempting to enable these services. You might want to use webmin to configure these files.


Of course, given that the BIND v9 server is much more finicky about syntax errors, you may well see that a previously working DNS server configuration may not work without tweaking the named.conf file. In that case, take a look at the syslog output. The BIND v9 server is much better in terms of telling you which particular line and/or option it could not parse and/or what it expected.


May 31 14:39:03 manisha named[2586]: [ID 873579 daemon.error] /etc/named.conf:4: expected quoted string near '/'

That " /etc/named:4: " above refers to the configuration
file and the line number where the parsing failed and the part
after the colon is what the parser expected to see. This also applies to zone data syntax errors.


May 31 14:26:12 manisha named[3494]: [ID 873579 daemon.error] dns_master_load: named.local:3: unexpected end of line

May 31 14:26:12 manisha named[3494]: [ID 873579 daemon.error] zone 0.0.127.in-ad
dr.arpa/IN: loading master file named.local: unexpected end of input


The upgrade to Solaris 10 also automatically runs " rndc-confgen -a " to create /etc/rndc.key which enables rndc to control a local
BIND 9 server. This allows BIND 9 and rndc to be drop-in replacements for BIND 8 and ndc. More on this in the next section.

Administrative Interfaces

---

This is the part where some users have had the most questions- and for good reasons. With previous releases of Solaris (which included BIND 8) ndc was the
only BIND server control tool available. rndc has replaced ndc for BIND 9 but it also lacks one important option- start, which means it cannot be used to start the name server like ndc. (This is true as of the 03/2005 Release of Solaris 10, i.e. BIND 9.2.4) rndc can, in its current state of evolution, stop the BIND name server, get status information, reload the entire configuration or some specified parts of it, toggle query logging, change the debugging level or flush the server's cache. But, with Solaris 10, general purpose SMF CLI tools (such as svcadm and svcs) are also available to control the BIND 9 server. So which admin tool should be used? The short answer is that using the SMF tools may help maintain a common experience with other Solaris services while rndc will always support a deeper set of BIND service options. Specifically and as a guideline, svcadm could be used to start, restart or stop DNS service and rndc could be used for some of the other tasks listed above.


Note that for most configurations (we describe the one exception later on) rndc stop and svcadm disable dns/server are equivalent and interchangeable. Let's look at a couple of example interactions:

{root:dnssrv:25} svcs dns/server
STATE STIME FMRI
online 15:57:57 svc:/network/dns/server:default
{root:dnssrv:26} rndc stop
{root:dnssrv:27} svcs dns/server
STATE STIME FMRI
disabled 15:58:07 svc:/network/dns/server:default

{root:dnssrv:29} svcs dns/server
STATE STIME FMRI
online 16:00:00 svc:/network/dns/server:default
{root:dnssrv:30} svcadm disable dns/server
{root:dnssrv:31} rndc status
rndc: connect failed: connection refused

If you who do not want to use the SMF framework at all, i.e. start the DNS server directly from the command line, rndc stop/halt works as you would expect and svcs/svcadm is expectedly unaware of the presence of the named process.

{root:dnssrv:32} /usr/sbin/named
{root:dnssrv:33} svcs dns/server
STATE STIME FMRI
disabled 16:00:17 svc:/network/dns/server:default
{root:dnssrv:35} rndc halt

Many of you may already know this but one of the changes between ndc and rndc (true for many platforms, not just Solaris) is that the former
used hardcoded Unix domain sockets by default to communicate with the BIND
server whereas the latter uses authenticated TCP sockets. However this also
means that unless you run rndc-confgen -a on a freshly installed (as opposed to an upgraded) Solaris 10 system, rndc will not work.

Running the server in a chroot environment

---

Here we look at how you might leverage the DNS server manifest that ships with Solaris 10 to customize your own manifest to run the DNS server in a chroot jail. General chroot setup is out of scope here and the reader is referred to the many online resources on how to setup BIND v9 server for a chroot configuration. In this case we assume you are not only interested in running the DNS server chrooted, but also have it managed by the SMF framework. Remember we said that there was one configuration for which rndc stop and svcadm disable dns/server:instance are not interchangeable? Well, this is that configuration! In the case of a chrooted DNS server on Solaris 10 that is started using the SMF framework you cannot stop/halt it using rndc. It must be disabled using the svcadm CLI tool.


Here's an example interaction:

manisha# rndc status
number of zones: 4
<...output truncated for brevity...>
server is up and running
manisha# rndc halt
use svcadm(1M) to manage named
manisha# svcadm disable dns/server
manisha# rndc status
rndc: connect failed: connection refused

It is also possible to run the BIND server within a dedicated non-global Solaris 10 Container.
More about that in another blog entry!

However I am running ahead of myself. I mentioned that I would show how to customize the shipping DNS server manifest to run the service chrooted. One way to do that would be to copy the supplied manifest ( server.xml ) file to a new file (say) - ( server-chroot.xml ). We do not recommend modifying the supplied manifest directly to preserve the ability to upgrade/patch. Another way could be to modify the properties via svccfg. We use the former method. You could start off by using a different instance name for your customized service- say 'chroot'. You then change two properties- start/exec and start/user both of which are of type astring. The former could be something like /usr/sbin/named -t /var/named instead of just /usr/sbin/named in the supplied manifest. The latter could be any non-privileged uid you choose to run the DNS server chrooted. We use the " noaccess" user in this example. Finally you need to adjust the privileges in the method credential to include proc_chroot. For further details on what that means, see the man page for privileges(5) on Solaris 10. The complete modified manifest can be found here.


You now import the manifest into the repository and enable the chrooted instance. (You may optionally want to disable any other instances of the DNS server already enabled.)

Sendmail On Solaris 10

http://alanpae.tripod.com/sendmail/

DNS On Solaris

Domain Name Service
DNS Setup & Configuration in Unix

Domain name services resolves names to the ipaddresses of clients and vice versa..Domain name system provides a convenient way of finding computer systems in network based on its name and ip address . With increased internet usage and globalization of companies setting up of dns servers has become a major responsibility of system administarators worldwide .
The following article describes in simple step the how to setup a dns server . Though the article focus on Solaris but any operating system which uses BIND the procedure will remain the same.

1.0 Introduction
s . Domain name system is a hierarchical system where we have a top level domain serving sub domain and clients with names & ip address.
The system that runs the name services to resolve names into ipaddresses is called name server and the sofware is generally BIND (Berkley Internet Domain) .
Core process of DNS is a daemon called named . Depending on the role assigned the name servers can be a primary, secondry or caching only. Secondry server takes over when primary is down and is updated automatically . Caching server provide only the caching information to the clients
Each of domain or sub domain have information (in zone files or data files) about its clients and is called authorative for these clients . For other clients for which it doesn't have any information or it is not authorative , it passes query to its higher domain .
The client knows about their name servers through a file called resolve.conf which contains addresses of the name servers (Primary secondary and Caching) along with their domain name.
The main files in serve are named.conf which contains server parameters and reference to other data files containing client information.

2.0 Requirements :
1) BIND (Berkely Internet Domain) software . Source code can be downloaded and compiled for your platform from internet at http://www.isc.org/index.pl?/sw/bind/ However BIND may be available in precompiled version along with OS so check your OS if it is already there . The situation you may want to compile from source code is that you want to cutomize it differently by giving different configuration options at compiling time
2) Root cache file from internic at ftp://internic.com/pub/root
3) C Compiler to compile the bind source distribution .

3.0 Installation and configuration
Download the BIND software from from http://www.isc.org/index.pl?/sw/bind/ if you want to build it from source code.
Make a directory to store and compile dns disyribution source say /usr/dns/src
Unzip the distribution using gzip command

#gzip -d bind-9.2.5.tar.gz
unpack using tar
#tar xvf bind-9.2.5.tar
compilation require a c compiler if you don't have one you can download from gnu site (www.gnu.org).
#./configure
#make
#make install
make install will ultimately place named , configuration file named.conf and related commands in /etc and /usr/local/bin directory .

4.0 named.conf fileThis is the main configuration file in BIND which defines the name servers and zones with the name and ip address of the hosts.
The named.conf has a number of options for starting the name server which can be configured as per requirement .A list of complete options can be seen using man named command.
By default you will find zone files for local host by the name localhost and 127.0.0.in-addr.arpa . For additional zones you need to create the the files and put a reference in named.conf .
Below is a basic functional named.conf file which is installed after the BIND 8..2.P5 is installed This can be used for starting name server , all you need to do is to put your hosts entries in the zone files referenced here .You will find explanation of terms used in this configuration file after this listing of named.conf.
// This is a configuration file for named (from BIND 8.1 or later).
// It would normally be installed as /etc/named.conf.

options { directory "/var/named";
check-names master warn; /* default. */
datasize 20M;
deallocate-on-exit yes;
listen-on {10.20.30.100;
};
forward first;
};
zone "localhost" IN {
type master;
file "/var/named/localhost.zone";
check-names fail;
allow-update { none; };
allow-transfer { any; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "/var/named/127.0.0.zone";
check-names fail;
allow-update { none; };
allow-transfer { any; };
};
zone "." IN {
type hint;
file "/var/named/root.hint";
};
logging {
channel xfer-log {
file "/var/tmp/bind-xfer.log" versions unlimited size 10m;
print-category yes;
print-severity yes;
print-time yes;
severity info;
};
category xfer-in { xfer-log; };
category xfer-out { xfer-log; };
category notify { xfer-log; }
category load { xfer-log; };
};
zone "30.20.10.in-addr.arpa" IN {
type master;
file "/var/named/100.30.20.10.zone";
check-names fail;
allow-update { none; };
allow-transfer { any; };
};
zone "mydomain.com" {
type master;
file "/var/named/mydomain.com.hosts";
};

Explanation of the terms used in named.conf above

4.1 options statement
The options lists working directory for the named - the name server daemon to read the configurations files and port to listen on (default is port 53) .

{ directory "/var/named";
This directive defines the working dir of the name server where main configuration file named.conf will be located
check-names master warn; /* default. */
The ``check-names'' directive tells BIND to check names in master zone and give a warning in system's log files if there is any discrepancy. Names are considered good if they match RFC 952's expectations (if they are host names), or if they consist only of printable ASCII characters (if they are not host names).
Other options are fail and ignore in that case bind will follow these directives
datasize 20M;
datasize The maximum amount of data memory the server mayuse. The default is system dependent.
deallocate-on-exit yes;
deallocate the memory on exit otherwise it will be left to os to clear the memory.
listen-on {10.20.30.100};
Host address and port for listening ; if port is not mentioned it is default 53.
forward first
ForwardingForwarding is can be used for two main scenario
1. Creating a large site wide cache on different servers thereby using less network bandwidth.
2. For servers which do not have a direct access to the internet but have to lookup for the external names.
Forwarding occurs only for names for which the server is not authoritative, and it does not have the answer in its cache.
forward
This option specify where to query the name first - 'first' directive will cause query to send to forwarder first and check itself if it fails .'Only' - directive will query the forwarders only .
forwarders
Specifies the IP addresses to be used for forwarding. The default is no forwarding .

4.2 Zones statements
zone "localhost" IN {
type master;
file "/var/named/localhost.zone";
check-names fail;
allow-update { none; };
allow-transfer { any; };
};
Zone statement declares a zone name , its type - master , slave or stub , files containing the zone data .and options relating to zone - update , checking , transfer etc.
localhost and 0.0.127.in-addr.arpa are default for the localhost and points to file of this name
Zone types
There are three types of zone .master : This is the master copy of the data in a zone.slave - This is a replica of a master zone. The masters list specifies one or more IP addresses that the slave contacts to update its copy of the zone. If file is specified, then the replica will be written to the file. Use of file is recommended, since it often speeds server startup andeliminates a needless waste of bandwidth.stub - A stub zone is like a slave zone, except that it replicates only the NS records of a master zone instead of the entire zone.hint - The initial set of root name servers is specified using a hint zone. When the server starts up, ituses the root hints to find a root name server and get the most recent list of root name servers.
previous releases of BIND used the term primary for a master zone, secondary for a slavezone, and cache for a hint zone.
Zone Directives
allow-updateSpecifies which hosts are allowed to submit dynamic DNS updates to the server. The default is to deny updates from all hosts.allow-transferSpecifies which hosts are allowed to receive zone transfers from the server. allow-transfer may also be specified in the zone section, in which case it overrides the options allow-transfer statement. If not specified, the default is to allow transfers from all hosts.zone "." refers to the root file for the domains - and contains references to the root servers at network solutions to resolve the names which are beyond the current domain . you can download the root cache file from ftp://internic.com/pub/root

4.3 Logging statement
logging {
channel xfer-log {
file "/var/tmp/bind-xfer.log" versions unlimited size 10m;
print-category yes;
print-severity yes;
print-time yes;
severity info;
};

The logging statement specifies logging channel/s which logs various categories of messages . In statement above a channel xfer-log - a user defined name , is defined. Each time name server is started it starts writing to the defined log file , size limits the maximum size of log file and once the limit is reached it stops writing the file. Each individual start or restart of named causes a new version of log file to be created. Version statement defines how many versions are allowed for the log file , unlimited option will allow any number of version,
Only one logging statement is used to define as many channels and categories as are wanted. If there are multiple logging statements in a configuration, the first definition determines the logging and warnings are issued for the other logging statements .
If there is no logging statement, the default logging configuration is used which is
logging {
category default { default syslog; default_debug;};
category panic { default syslog; default_stderr;};
category packet { default_debug;};
category eventlib { default_debug;};
};

The default debug file is named.run .
Channel Phrase
All log output goes to one or more "channels"; you can make as many of them as you want. Every channel definition must include a clause that says whether messages selected for the channel go to a file, to a particular syslog facility, or are discarded. It can optionally also limit the message severity level that will be accepted by the channel (default is "info"), and whether to include a named-generated time stamp, the category name and/or severity level (default is not to include any). The word null as the destination option for the channel will cause all messages sent to it to be discarded; other options for the channel are meaningless.The file clause defines size and versions of the file which will be saved each time the file is opened. if the file ever exceeds the size, then named will just not write anything more to it . The default behavior is to not limit the size of the file.
As per selection the log messages will either go to syslog() or a file and severity level determines which type of messages goes there . Default severity level is info. and it can be critical , error , debug and dynamic.
Note that only syslog messages can go to syslog . Print-time , print-category - logs the time & category of the messages . The print- options can be used in any combination but will always be printed in the following order: time, category, severity.
category xfer-in { xfer-log; };
category xfer-out { xfer-log; };
category notify { xfer-log; }
These directives put diffrent categories of log messages in to xfer-log channel
Category option mentions the category of the log and file name for logging
logging {
channel xfer-log {
file "/var/tmp/bind-xfer.log" versions unlimited size 10m;
print-category yes;
print-severity yes;
print-time yes;
severity info;
};

this defines a channel called xfer-log with various options.
these categories directs various types of logs into the channel

5.0 ZONE files
Zone files are used to define the name and ip addresses of the hosts in a domain .Generally two zone files are defined for a particular zone - one file maps the the name to the ipaddress of the host machines and other is used for reverse lookup i.e. ipaddress to name .address .
Each master zone file should begin with an SOA (Start of Authority) record for
the zone. The SOA specifies a serial number, which should be changed
each time the master file is changed. it is 32 bit size field . Slave servers check the serial no. at refresh time and if the detect changed serial no in master zone transfer is carried out to keep its zone files updated.

If a master server cannot be contacted within the interval given by the expire time, all data from the zone is discarded by slave servers.
The minimum value is the time-to-live (``TTL'') used by records in the file with no explicit time-to-live value.
The details of all type of records used in a zone file are given below
Type of records
SOA marks the start of a zone of authority (domain of originating host, domain address of maintainer, a serial number and the following parameters in seconds: refresh, retry, expire and minimum TTL. (see RFC 883)).
NULL a null resource record (no format or data)
RP a Responsible Person for some domain name
PTR a domain name pointer (domain)
HINFO host information (cpu_type OS_type)
A a host address (dotted quad)
NS an authoritative name server (domain)
MX a mail exchanger (domain), preceded by a preference value (0..32767), with lower numeric values representing higher logical preferences.
CNAME the canonical name for an alias (domain)

Following are the three functional zone files representing local host and a master zone.
The explanation of the terms are at the end.
/var/named/localhost
localhost. 1D IN SOA localhost.mydomainr.com. hostmaster.mydomain.com. (
42 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
localhost. NS dns
localhost. A 127.0.0.1

/var/named/ 0.0.127.in-addr.arpa

0.0.127.in-addr.arpa IN SOA localhost. root.localhost. (
42 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum

0.0.127.in-addr.arpa IN NS dns.mydomain.com
1.0.0.127.in-addr.arpa. PTR localhost

/var/named/mydomain.com

mydomain.com. IN SOA dns.mydomain.com hostmaster.dns. (
200010016 ;serial
10800
3600
3600
86400 )
mydomain.com. 1D IN NS dns.mydomain.com.
IN MX 20 mx1.domaingateway.net.
IN MX 10 mail-in.mydomain.com.

;mydomain hosts below
www IN CNAME mydomain.com.
localhost IN A 127.0.0.1
mail IN A xxx.xxx.xxx.xxx
ns1 IN A xxx.xxx.xxx.xxx
dns IN A xxx.xxx.xxx.xxx
news IN A xxx.xxx.xxx.xxx
root cache file
localhost. NS dns
this is declaration of the type of localhost it declares that local host is a name server with hostname dns
localhost. A 127.0.0.1
this declares the address of local host.
0.0.127.in-addr.arpa IN NS dns.mydomain.com
1.0.0.127.in-addr.arpa. PTR localhost
Similarly in reverse zone map file reverse address is declared as ns record of name dns and a pointer record ptr , points this rev address to the localhost.
Resource records normally end at the end of a line, but may be continued across lines between opening and closing parentheses. Comments are introduced by semicolons and continue to the end of the line.Note that there are other resource record types, not shown where. You should consult the BIND Operations Guide (BOG') for the complete list. Some resource record types may have been standardized in newer RFC's but not yet implemented in this version of BIND.

6.0 Client Configuration
Each client need a configuration file /etc/resolv.conf which informs it about the domain name server . This is a editable text file with following entries :
domainname yourdomainname.com
nameserver 10.20.30.40
nameserver 10.20.30.41

7.0 Signals
The following signals have the specified effect when sent to the server process named using the kill command.

SIGHUP
Causes server to read named.boot and reload the database. If the server is built with the FORCED_RELOAD compile-time option, then SIGHUP will
also cause the server to check the serial number on
all secondary zones. Normally the serial numbers
are only checked at the SOA-specified intervals.
SIGINT :
Dumps the current data base and cache to
/var/named/named_dump.db
SIGIOT :
Dumps statistics data into /var/named/named.stats .if the server is compiled with -DSTATS. Statistics data is appended to the file. Some systems use SIGABRT rather than SIGIOT for this.
SIGSYS :
Dumps the profiling data in /var/named if the
server is compiled with profiling (server forks, chdirs and exits).
SIGTERM:
Dumps the primary and secondary database files.
Used to save modified data on shutdown if the
server is compiled with dynamic updating enabled.
SIGUSR1:
Turns on debugging; each SIGUSR1 increments debug level. (SIGEMT on older systems without SIGUSR1)
SIGUSR2:
Turns off debugging completely. (SIGFPE on older
systems without SIGUSR2)
SIGWINCH
Toggles logging of all incoming queries via sys-
log(8) (requires server to have been built with the
QRYLOG option)

Starting/Controlling services

In most Unix systems, startup scripts in /etc/rc3.d, etc, are used to start and stop services. Solaris 10 uses a different approach. There are two advantages to the Solaris 10 method:

• The system can come up faster, because startup of various systems can be done in parallel.
• The system knows more about what is going on. It can monitor processes and restart them.

Services are managed by svcadm. The most common commands are :

.- svcadm enable SERVICE

.- svcadm disable SERVICE

Note that enable and disable are persistent. That is, if you enable a service it will be brought back up after a reboot. Similarly with disabling. If you want to stop a service but have it come back up after the next reboot, use "svcadm -t disable SERVICE". That stops it temporarily.
To look at services, two common commands are :

svcs {lists summary of all}

svcs -l SERVICE {details on one service}

Solaris 10 still pays attention to /etc/rcN.d, but services defined there are "legacy", and can't be fully monitored and controlled.

To define a service, you create an XML file that specifies dependencies, and methods to start and stop it. Then you do "svccfg import FOO.xml". Normally the XML file is written to create an instance but not enable it. So if the import works, you would need to do "svcadm enable SERVICE" to start it.

A good way to start writing the XML file is to look at existing ones. They are in subdirectories of /var/svc/manifest. Sun suggests system/utmp.xml as a simple example. Since many of your services may be network services, take a look at what is in network. In network, there are two types of services, some that are standard daemons (e.g. http_apache2) and some there are run by inet (e.g. telnet).

If you add services, you probably want to put your .xml files in /var/svc/manifest and your scripts in /lib/svc/method. That way anyone who needs to work with the system can find them, just as they now know to look in /etc/init.d for all startup scripts. However I suggest making those symbolic links to files that are actually in /usr/local/svc/manifest and /usr/local/svc/method. That way you won't lose your information in a system reinstallation.

I suggest two pages in Sun's BIGADMIN site:
Predictive Self-Healing. This is the best brief introduction to the SMF system.
Configuring JBoss to use with SFM Step by step instructions to configure a typical daemon. Note there is one possible error in the XML. One dependency is given a name of "ssh_multi-user-server". I had problems until I changed the name. I suggest SERVICE_multi-user-server, where SERVICE is your service name.

Most of the XML files refer to scripts to do start, stop and restart. The Sun scripts all reside in /lib/svc/method. It's worth looking at some of the examples. There are two standard approaches: a script that just starts the service. You then use :kill in the XML file to stop it. This causes all processes started by the start script to be killed. Or you have a script that looks a lot like a traditional init.d script, which is called as "SCRIPT start" and "SCRIPT stop". Use that if you need to do something beyond just killing the process.

For a quick conversion you can use the example above, and call the init.d script with start and stop. However you may want to change the script slightly:
Be careful about return values. You should return 0 if the action is taken. (With stop you should return 0 even if the process was already stopped.) Otherwise you'll need to return a value defined by SMF.

When starting and stopping, don't return until the process is running and ready to respond to user requests, or until it's really dead. If you need to wait, make sure you use a timeout. The second item is critical if other processes depend upon this one, since they'll go on to the dependencies as soon as the start process returns. If there are no dependencies, you can get away with a simple init.d script, as long as it returns 0.
Note that if all processes started by a service die, the system will try to restart the service by doing a stop and then a start.

You can also define a "refresh" action, which prods a service if a configuration file changes.