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.)
posted by Mauricio Marín T. at
6:10 AM
|
0 comments
