Missing IPv4 or IPv6 connection and Running BIND on Solaris?

BIND 9’s named(1M) performance can be vastly improved when running on Solaris operating environment where either no IPv4 or no IPv6 connectivity is available.

The issue is documented in the named(1M) manual page:

BUGS
By default, named attempts to contact remote name servers by
either their IPv4 or IPv6 address, even though the host sys-
tem does not have either IPv4 or IPv6 connectivity (that is,
a  configured  and active interface). To address this issue,
either provide the missing connectivity or use the  relevant
-4  or  -6  command  line option. When using svccfg(1M), set
application property options/ip_interfaces to either IPv4 or
IPv6.

Essentially ‘named’ receives both IPv4 and IPv6 addresses for name
servers. As it goes about its business of resolving queries it
attempts to send UDP packets to those addresses. Ideally it would be informed of a missing transport and quickly fail. Alas defect 6320428 “sendto() should return errors up the stack” means that does not happen and thus ‘named’ waits for a response that is never going to come.

As an example, lets take a peek at the root name server addresses using dig (domain Internet Groper):

$ dig . ns
; <> DiG 9.3.6-P1 <> . ns
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 878
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;.				IN	NS
;; ANSWER SECTION:
.			498528	IN	NS	c.root-servers.net.
.			498528	IN	NS	d.root-servers.net.
.			498528	IN	NS	e.root-servers.net.
.			498528	IN	NS	f.root-servers.net.
.			498528	IN	NS	g.root-servers.net.
.			498528	IN	NS	h.root-servers.net.
.			498528	IN	NS	i.root-servers.net.
.			498528	IN	NS	j.root-servers.net.
.			498528	IN	NS	k.root-servers.net.
.			498528	IN	NS	l.root-servers.net.
.			498528	IN	NS	m.root-servers.net.
.			498528	IN	NS	a.root-servers.net.
.			498528	IN	NS	b.root-servers.net.
;; ADDITIONAL SECTION:
a.root-servers.net.	498238	IN	A	198.41.0.4
a.root-servers.net.	195801	IN	AAAA	2001:503:ba3e::2:30
b.root-servers.net.	593090	IN	A	192.228.79.201
c.root-servers.net.	412662	IN	A	192.33.4.12
d.root-servers.net.	592857	IN	A	128.8.10.90
e.root-servers.net.	419480	IN	A	192.203.230.10
g.root-servers.net.	26029	IN	A	192.112.36.4
i.root-servers.net.	592963	IN	A	192.36.148.17
j.root-servers.net.	498528	IN	A	192.58.128.30
j.root-servers.net.	498528	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	593006	IN	A	193.0.14.129
k.root-servers.net.	589950	IN	AAAA	2001:7fd::1
l.root-servers.net.	3378	IN	A	199.7.83.42
l.root-servers.net.	195801	IN	AAAA	2001:500:3::42
;; Query time: 3 msec
;; SERVER: 129.156.86.11#53(129.156.86.11)
;; WHEN: Thu Aug 27 12:53:49 2009
;; MSG SIZE  rcvd: 500

As documented in named(1M) the solution is to enable only IPv4 or IPv6 transports. On Solaris 10 or above this should be accomplished using SMF properties:

Example 1 Configuring named to Transmit Only over IPv4  Net-
works
The following command sequence configures named such that it
will transmit only over IPv4 networks.
# svccfg -s svc:network/dns/server:default setprop \
> options/ip_interfaces=IPv4
# svcadm refresh svc:network/dns/server:default
#

On Solaris 8 or 9 modify init.d(4) script /etc/init.d/inetsvc and append either -4 or -6 to the BIND 9 startup line.

Note BIND 9 should be used as documented in
SunAlert 239392.

For example, the following is a excerpt from a modified /etc/init.d/inetsvc to start named(1M) so that it only uses IPv4 transports:

if [ -f /usr/lib/dns/named -a -f /etc/named.conf ]; then
echo 'starting internet domain name server.'
/usr/lib/dns/named -4&
fi

By limiting ‘named’ to the available transport its performance is vastly improved.

BIND 9.3.6 and beyond require poll

BIND 9.3.6-P1 requires poll(7d) to improve networking performance which was very badly impacted by the changes applied to BIND to help fight of attack from the Kaminsky issue, Sun Alert 239392.

If BIND’s named process is running within a chroot(2) environment then that environment requires the poll device to be installed. Though I recommend using zones(5) and Role-Based Access Control,
rbac(5), rather than chroot environments which does then avoid this issue.

Example 1: missing poll device:

# /usr/sbin/named -t /var/named -u dns -f -g
31-Jan-2009 21:07:16.697 starting BIND 9.3.6 -t /var/named -u dns -f -g
31-Jan-2009 21:07:16.697 found 8 CPUs, using 8 worker threads
31-Jan-2009 21:07:16.715 socket.c:3259: unexpected error:
31-Jan-2009 21:07:16.715 open(/dev/poll) failed: No such file or directory
31-Jan-2009 21:07:16.715 ./main.c:495: unexpected error:
31-Jan-2009 21:07:16.715 isc_socketmgr_create() failed: file not found
31-Jan-2009 21:07:16.715 create_managers() failed: unexpected error
31-Jan-2009 21:07:16.715 exiting (due to early fatal error)

The ‘-t /var/named‘ option causes named to use the /var/named as the chroot directory. Named is unable to continue because the required device /dev/poll is missing.

To address the missing poll device simply create it:

Example 2: Create poll device with same properties as root (/) device using mknod(1M)

# ls -ld /devices/pseudo/poll@0:poll
crw-rw-rw-  1 root  sys  138, 0 May 28 04:25 /devices/pseudo/poll@0:poll
# cd /var/named/dev
# ls
null    random
# mknod poll c 138 0
# chmod 666 poll

If using SMF remember to clear and re-enable the service:

# svcadm clear svc:/network/dns/server:default
# svcadm enable svc:/network/dns/server:default

---

See also CR 6799867

BIND training with the ISC

The ISC (Internet Systems Consortium) have scheduled further training course on BIND. The next one is in March at the ISC’s headquarters in Redwood City, CA. I’m looking forward to attending, last I heard there was still a couple of places open if your interested.

Running BIND server ‘named’ as a different user on Solaris 10

The named process is started by root and thus inherits roots privileges, as were traditionally needed, to access the DNS communication channel (port 53). BIND administrators know the named command accepts a -u username option which causes the process to switch user attributes after opening privileged interfaces. The idea being that should the service be compromised the effective user is not all powerful.

In the Solaris 10 Operating Environment the process privilege model, privileges(5), allows for a more fine-grained control. Coupled with the Service Management Facility, smf(5), services may inherit less privileges and alternative user process and group identities at start-up. Therefore under the Solaris 10 OE named may be configured at start to run with an alternative user identity making the -u option superfluous.

To have the BIND server named start with an alternative user
identity and group under the Solaris 10 OE complete the following
steps:

1. Add the user to the solaris.smf.manage.bind role

# usermod -A solaris.smf.manage.bind dnsadmin
# tail -1 /etc/user_attr
dnsadmin::::type=normal;auths=solaris.smf.manage.bind
#

Without this role the server, named, will be unable to manage it’s
SMF FMRI and named will automatically be restarted by SMF after an rndc
stop or halt command. As indicated by the syslog message “error: smf_disable_instance() failed for svc:/network/dns/server:default : insufficient privileges for action”

2. Modify the service properties

# svccfg
svc:> select svc:/network/dns/server:default
svc:/network/dns/server:default> setprop start/user = dnsadmin
svc:/network/dns/server:default> setprop start/group = dnsadmin
svc:/network/dns/server:default> exit
# svcadm refresh svc:/network/dns/server:default
# svcadm restart svc:/network/dns/server:default

3. Specify an alternative location for the pid-file

As only root has write access to create the default
pid-file; /var/run/named.pid named must be configured to
use an alternative path. For Example:

# mkdir /var/named/tmp
# chown dnsadmin /var/named/tmp</b
# head /etc/named.conf
options {
directory “/var/named”;
pid-file “/var/named/tmp/named.pid”;
};

zone “0.0.127.in-addr.arpa” in {
type master;
file “db.127.0.0”;
};
#

---

Updated 25 Feb 2009 with instructions on how to add user to authority.

BIND 9.3.4-P1 available with Solaris 10

An upgrade to BIND 9.3.4-P1 is available for Solaris 10 Operating
Environment by installing patch 119783-05 for SPARC or 119784-05 for
x86 architectures.

BIND 9.3.4 provided a number of new features over BIND 8 which was
supplied with the Solaris 8 and 9 Operating Environments. Additionally BIND
9.3.4 provides a number of compatibility features not available in
BIND 9.2.4 (the FCS version of BIND in Solaris 10 OE). For details of
all the changes refer to the
migration
notes.

Summary of Differences between BIND 9.3 from BIND 9.2

BIND 9.3 has a number of new features over 9.2 including:

• DNSSEC is now Delegation Signer (DS) based,
  RFC4033,
  RFC4034 and
  RFC4035.
  This collection of RFCs is otherwise known as DNSSEC-bis.

• DNSSEC Look-aside Validation (DLV) (experimental),
  RFC4431

• check-names is now implemented.

• rrset-order is more complete.

• IPv4/IPv6 transition support, “dual-stack-servers”.

• IXFR deltas can now be generated when loading master files,
  “ixfr-from-differences”.

• It is now possible to specify the size of a journal,
  “max-journal-size”.

• It is now possible to define a named set of master servers
  to be used in masters clause, “masters”.

• The advertised EDNS UDP size can now be set,
  “edns-udp-size”.

• New Name Server SMF properties. With the introduction of BIND
  9.3.4 new Name Server smf(1) properties have been introduced to
  provide an SMF compliant method for setting BIND 9.3.4 command
  line options. Changing the “start method” property of the BIND 9
  service is no longer recommended.

For further information refer to the migration
notes as above.

Solaris unaffected by latest BIND 9 vulnerabilities

Sun supported Solaris Operating Environments are not affected by the
latest BIND
vulnerabilities documented by the Internet Systems Consortium.

Solaris 8, 9 and 10 OE’s are unaffected as they provide earlier
versions of BIND which are not vulnerable to these latest vulnerabilities:

• SIG Query Processing (CVE-2006-4095):

Recursive servers:

Queries for SIG records will trigger a assertion failure if more
than one SIG (covered) RRset is returned. Exposure can be
minimised by restricting sources that can ask for recursion.

Authoritative servers:

If a nameserver is serving a RFC 2535 DNSSEC zone and is queried for the SIG records where the are multiple SIG(covered) RRsets (e.g. a zone apex) then named will trigger a assertion failure when it tries to construct the response.

• Excessive Recursive Queries INSIST failure (CVE-2006-4096):

It is possible to trigger an INSIST failure by sending enough recursive queries that the response to the query arrives after all the clients looking for the response have left the recursion queue.

Exposure can be minimised by restricting sources that can ask for recursion.

Note for BIND 9.2.x: Code handling this path for 9.2.x has been determined to be wrong, though ISC has not been able to detect an execution path that would trigger the erroneous code in 9.2.x.

Stace

Tag: topic:[BIND]

BIND training from the ISC

The ISC are offering two instructer-lead training courses in San Francisco:

• Introduction to DNS & BIND
• Advanced DNS and BIND topics

I’m very happy to see the ISC offering these as the number of configuration issues that come through my email suggest it is dearly needed.

Tag: topic:[BIND] topic:[DNS]