Internet domain name server
named [-(b|c) config_file] [-d debug_level] [-f] [-g group_name]
[-p portnum] [-r] [-t directory] [-u user_name]
[-w directory] [config_file]
- -b|-c config_file
- Use this alternate config_file; this argument is
overridden by any config_file which is specified at the end of
the command line. The default value is /etc/named.conf.
- -d debug_level
- Print debugging information. The debug_level is
a number that determines the level of messages printed. If negative,
debug_level is set to 1.
 |
The new debugging framework is considerably more sophisticated
than it was in older versions of named. The configuration
file's logging statement allows for multiple,
distinct levels of debugging for each of a large
set of categories of events (such as queries, transfers in
or out, and so on). See the description of
/etc/named.conf configuration file
for further information about these extensive new capabilities. |
- -f
- Run this process in the foreground; don't fork() and daemonize.
(The default is to daemonize.)
- -g group_name
- Specifies the group the server should run as after it initializes.
The value specified may be either a groupname or a numeric group ID.
- -p portnum
- Use the specified remote port server. This is the port number
to which named will send queries. The default
value is the standard port number, that is, the port number
returned by getservbyname() for service domain.
|
Previously, the syntax -pportnum[/localportnum] was
supported; the first port was used when contacting remote servers, and the second one was the
service port bound by the local instance of named. The current
usage is equivalent to the old usage without the localportnum
specified; this functionality can be specified with the listen-on clause of
the configuration file's options statement.
|
- -r
- Turn recursion off in the server. Answers can
come only from local (primary or secondary) zones. This
can be used on root servers. The default is to use recursion.
|
The -r option can be overridden by and is
deprecated in favor of the recursion clause of the
/etc/named.conf
configuration file's options statement.
|
- -t directory
- Specifies the directory the server should chroot into as
soon as it's finished processing command line arguments.
- -u user_name
- Specifies the user the server should run as after it initializes.
The value specified may be either a username or a numeric
userid. If the -g flag isn't specified, then the
group ID used will be the group of the user specified.
- -w directory
- Sets the working directory of the server. The directory
clause of the configuration file's options statement
overrides any value specified on the command line. The default
working directory is the current directory (``.'').
- config_file
- Use this configuration file. The default file is /etc/named.conf.
A config_file argument given at the end of the command line overrides any
config_file specified with the -b or -c flags.
The named daemon is used to map symbolic names
into IP addresses. If you have a registered domain name and
wish to allow Internet clients to resolve hostnames on your
domain, then you should configure and run named.
If you don't have a registered domain name, then you should
either:
- Use /etc/hosts exclusively
Or
- Configure the /etc/resolv.conf file to
point to another host that's already running a
named daemon.
For sample configuration files, see the
/etc/config/socket directory. For an in-depth
discussion of DNS, see Hunt's TCP/IP Network
Administration. For advanced DNS configuration, see
DNS and BIND by Paul Albitz and Cricket Liu,
O'Reilly & Associates (ISBN 1-56592-010-4).
Suppose you wanted to add support for TCP/IP networking to a
QNX Ethernet network. Rather than resolve IP addresses by
configuring each node to use a local
/etc/hosts file, DNS will let you disseminate
new host information throughout your network from a
single nameserver.
Most DNS configuration files share the same basic format and
use the same type of records to define information. These
records are known as resource records or RRs.
| RR type |
Text name |
Function
|
| SOA |
Start Of Authority |
Provides administrative information for the domain
|
| NS |
Name Server |
Indicates that this is an authoritative nameserver
|
| A |
Internet Address |
A hostname-to-address mapping
|
| CNAME |
Canonical Name |
An alias
|
| HINFO |
Host Information |
The host's hardware and OS
|
| WKS |
Well Known Services |
A list of services supported by the host
|
| MX |
Mail Exchanger |
The mail server where mail for a host will be delivered
|
| PTR |
Pointer |
An address-to-hostname mapping (for reverse queries)
|
All RRs follow this basic format:
name [ttl] IN type data
The fields are:
- name
- The name of the domain object that the RR applies
to-this can be an individual host or an entire domain.
If you leave this field blank, the RR applies to the object
named in the previous RR.
- ttl
- Stands for Time To Live. This
field specifies, in seconds, how long a domain resolver
should cache the RR before it throws it out and asks a
domain server again. If you leave this field blank, it
defaults to the ttl specified in the SOA record.
- IN
- Identifies the RR as a DNS record. There are other
record classes, but DNS uses only this class.
- type
- The type of RR (e.g. SOA, NS, etc.).
- data
- Information specific to this type of RR (e.g. the
data for a CNAME record would be an alias).
For more information on RRs, see RFC 1033 and
RFC 1035. You could also refer to TCP/IP
Network Administration.
Let's assume you have a five-node QNX TCP/IP network in
which each node boots from its own hard drive:
A 5-node Ethernet network.
We're now going to set up a primary nameserver for
this network. A DNS server can be one of three basic types:
- a primary server, which keeps the zone files
that provide the definitive information for the domain
- a secondary server, which transfers these files from the
primary server
- a caching-only server, which runs the named
server daemon but doesn't keep the zone files.
Primary and secondary servers are authoritative
servers, whereas caching-only servers, which provide
only second-hand information, aren't authoritative.
Now let's assume your domain is called sample.com
and you want node5 to act as the primary
nameserver. The following table shows the complete set of
named configuration files you need to create on
node5. (On the left you see the conventional names
of these files; we've chosen filenames that are more
meaningful to this example.)
| Conventional name |
Name in example |
Function
|
| named.conf |
named.conf |
Provides general parameters and location of remaining
config files
|
| named.ca |
root.cache |
Cache initialization file
|
| named.local |
localhost.resolve |
Resolves the loopback address
|
| named.hosts |
sample.com.hosts |
(zone file) Contains most domain information, including
hostname-to-address mappings
|
| named.rev |
sample.com.reverse |
(zone file) Contains address-to-hostname mappings
|
With the exception of named.conf, all these
files share the same basic format.
Here's the named.conf file:
options {
directory "/etc/namedb";
};
zone "." {
type hint;
file "root.cache";
};
zone "sample.com" {
type master;
file "sample.com.hosts";
};
zone "78.231.198.IN-ADDR.ARPA" {
type master;
file "sample.com.reverse";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost.resolve";
};
The named daemon is much more configurable than in the previous release. There
are entirely new areas of configuration, such as access control lists
and categorized logging. Many options that previously applied to all
zones can now be used selectively. These features, plus a consideration
of future configuration needs, led to the creation of a new configuration
file format.
For more information, see the /etc/named.conf
configuration file.
Here's the root.cache file:
; @(#)root.cache 5.1 (Berkeley) 6/30/90
; Servers for the root domain
; Initial cache data for root domain servers.
. 99999999 IN NS NS.INTERNIC.NET.
99999999 IN NS KAVA.NISC.SRI.COM.
99999999 IN NS TERP.UMD.EDU.
99999999 IN NS NS.NIC.DDN.MIL.
; Root servers by address
; Prep the cache (hotwire the addresses).
; Order doesn't matter.
NS.INTERNIC.NET. 99999999 IN A 198.41.0.4
KAVA.NISC.SRI.COM. 99999999 IN A 192.33.33.24
TERP.UMD.EDU. 99999999 IN A 128.8.10.90
NS.NIC.DDN.MIL. 99999999 IN A 192.112.36.4
Near the top of this file, you see NS records that identify
the root servers. Next, you see several
A records that give the address of
each root server. Finally, note that the ttl for
every record is 99999999-the largest possible
value-so that the root servers are never removed from
the cache.
If your system isn't connected to the Internet, it won't be
able to communicate with the root servers. In that case,
simply create a root.cache that has entries
pointing to the major nameservers on your LAN.
The localhost.resolve file is the zone file for
the reverse domain 0.0.127.IN_ADDR.ARPA. This file is used
to convert the address 127.0.0.1 (the loopback
address) to the name localhost.
Here's the localhost.resolve file:
@ IN SOA node5.sample.com. node5.sample.com.(
950110 ; serial
604800 ; refresh (168 hours)
3600 ; retry (1 hour)
3600000 ; expire (1000 hours)
604800 ) ; minimum (168 hours)
IN NS node5.sample.com.
1.0 IN PTR localhost.
Note the SOA resource record, which provides administrative
information for the domain. This information is important,
so let's take a closer look at the record's syntax:
name [ttl] IN SOA origin person (
serial
refresh
retry
expire
minimum )
where:
- name
- The name of the zone. The at-sign (@) refers back to the
primary statement (in named.boot)
that points to this zone file.
- origin
- The name of the host on which the master zone file
resides.
- person
- A mailbox for the person responsible for the zone. This
is formatted like a mailing address but the at-sign that
normally separates the user from the hostname is replaced
with a dot.
Note that this SOA record indicates that
node5.sample.com. is both the server
responsible for this zone and the email address for any
questions regarding the zone.
- serial
- The version number of the zone file. You should
increment this any time you change data in the zone.
For info on the remaining fields, see TCP/IP Network
Administration.
After the SOA record, you see an NS record that indicates
the computer's hostname (i.e.
node5.sample.com.). Since this record is
defined in the sample.com.hosts file, it's
optional here.
Note the IN PTR localhost. record at the end of the
file. Because all systems use 127.0.0.1 as the loopback
address, this record can be identical on every server.
The files we covered so far -
named.boot, root.cache, and
localhost.resolve - are the only files
required to configure a caching-only server. The remaining
files - sample.com.hosts and
sample.com.reverse - are more complex and are
created only on a primary server.
The sample.com.hosts file contains most of
the domain information. It converts hostnames to IP
addresses, and consequently contains several A
resource records. It also contains NS records to
define the domain and its servers, and MX records
to define mail servers. It could also contain other record
types, such as CNAME and WKS.
Here's the sample.com.hosts file:
;
; Address to hostname mappings
;
@ IN SOA node5.sample.com. node5.sample.com.(
950110 ; serial
604800 ; refresh (168 hours)
3600 ; retry (1 hour)
3600000 ; expire (1000 hours)
604800 ) ; minimum (168 hours)
IN A 198.231.78.5
IN HINFO 486 "QNX 4.23"
; define the nameservers and the mail servers
IN MX 10 node5.sample.com.
IN MX 20 node1.sample.com.
IN NS node5.sample.com.
; define the hosts in this zone
node1 IN A 198.231.78.1
IN MX 5 node5.sample.com.
node2 IN A 198.231.78.2
IN MX 5 node5.sample.com.
node3 IN A 198.231.78.3
IN MX 5 node5.sample.com.
node4 IN A 198.231.78.4
IN MX 5 node5.sample.com.
node5 IN A 198.231.78.5
IN MX 5 node5.sample.com.
; define local host
localhost IN A 127.0.0.1
Note the first MX record:
IN MX 10 node5.sample.com.
This defines a mail server for the entire domain.
Specifically, it indicates that
node5.sample.com. is the mail server for
sample.com with a preference of 10.
Similarly, the second MX record indicates that
node1.sample.com. is also a mail server, but
with a preference of 20. Giving
node1.sample.com. a larger preference number
effectively makes it a backup mail server. (The host with
the lowest preference number is always tried first. If it's
unreachable, then the host with the next largest number is
tried, and so on.) Keep in mind that you'd have to configure
node5.sample.com. and
node1.sample.com. as mail servers for the
mail to work.
The remaining A records convert hostnames to IP
addresses. They also define the mail server for each host,
which isn't necessary since we've already defined the
default mail servers. However, by adding these MX
entries we can do things such as adjust the preference level
for each host.
The last configuration file (sample.com.reverse)
converts IP addresses to hostnames. As a result, it looks a
lot like localhost.resolve with its use of PTR records:
;
; Address to hostname mappings
;
@ IN SOA node5.sample.com. node5.sample.com.(
950110 ; serial
604800 ; refresh (168 hours)
3600 ; retry (1 hour)
3600000 ; expire (1000 hours)
604800 ) ; minimum (168 hours)
IN NS node5.sample.com.
1 IN PTR node1.sample.com.
2 IN PTR node2.sample.com.
3 IN PTR node3.sample.com.
4 IN PTR node4.sample.com.
5 IN PTR node5.sample.com.
Let's now look at how to set up the client side of DNS on
each of the remaining nodes (node1 through
node4).
Under QNX, the resolver (i.e. the code that queries the
domain) uses the /etc/resolv.conf file to
resolve the nameserver's domain and IP address. The
resolv.conf file can also define backup
servers in case the default server doesn't respond.
The /etc/resolv.conf file contains at least
the following entries:
- nameserver address
- Identifies, by IP address, the server that the resolver
will query for domain information. The file can contain more
than one nameserver entry. If there's more than one entry,
the resolver queries the first server defined; if there's no
response, it queries the second server; if there's still no
response, it queries the third server, and so on.
If resolv.conf contains no nameserver
entries, or if no resolv.conf file exists,
all nameserver queries are sent to the local host (i.e. the
/etc/hosts file).
- domain name
- Defines the default domain name. The resolver appends
this default name to any host that doesn't end with a dot.
It then uses the expanded hostname in the query it sends to
the nameserver.
For example, let's say that the resolver receives the
hostname node1 (which doesn't contain a dot) and
that the value for name is
sample.com. In that case, the resolver would
query for: node1.sample.com
For our example, resolv.conf could contain
the following:
;
; Domain name resolver configuration file -
; '/etc/resolv.conf'
;
domain sample.com
nameserver 198.231.78.5
To query a nameserver and retrieve any of the information it
knows about, you can use nslookup. This tool is
especially handy when you're trying to establish whether or
not you've configured your nameserver properly.
Here's a sample nslookup session:
# nslookup -v
Default Server: node5
Address: 198.231.78.5
>> node2
Server: node5
Address: 198.231.78.5
Non-authoritative answer:
Name: node2.sample.com
Address: 198.231.78.2
First, nslookup returned the primary server's
hostname and IP address. Then, after we entered a query for
node2, it returned the server name and IP address
again, followed by the hostname and IP address for
node2.
By default, nslookup queries for A
records, which provide hostname-to-address mappings. To
change to another RR type, use nslookup's
set type command. For example, the following
session contains a query for mail information about
node2:
>> set type=mx
>> node2
Server: node5
Address: 198.231.78.5
Non-authoritative answer:
node2.sample.com preference = 5, mail exchanger =
node5.sample.com
Authoritative answers can be found from:
sample.com nameserver = node5.sample.com
node5.sample.com internet address = 198.231.78.5
Now let's look at an example of how nslookup can
help you catch errors. Let's assume that one of the IN
MX entries in sample.com.hosts ended
without a dot:
node1 IN A 198.231.78.1
IN MX 5 node5.sample.com
Given this error, here's what nslookup would show
if you did an MX query for node1:
>> set type=mx
>> node1
Server: node5
Address: 198.231.78.5
Non-authoritative answer:
node1.sample.com preference = 5, mail exchanger =
node5.sample.com.sample.com
Authoritative answers can be found from:
sample.com nameserver = node5.sample.com
node5.sample.com internet address = 198.231.78.5
As you can see, the ``mail exchanger'' hostname is
resolved to:
node5.sample.com.sample.com
With no dot at the end of the above IN MX entry,
the resolver appended the domain to the host and produced
the doubled name.
The following signals have the specified effect when sent to the server
process using the kill() command:
- SIGHUP
- Causes server to read named.conf and reload the database.
- SIGINT
- Dumps the current data base and cache to named_dump.db.
- SIGILL
- Dumps statistics data into named.stats.
- 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.
- SIGUSR2
- Turns off debugging completely. (SIGFPE on older systems without
SIGUSR2.)
- SIGWINCH
- Toggles logging of all incoming queries via syslog().
- /etc/named.conf
- Default name server configuration file.
- /etc/namedb/named.pid
- The process ID.
- named_dump.db
- Dump of the name server database.
- named.run
- Debug output.
- named.stats
- Nameserver statistics data.
gethostbyname(),
hostname,
kill (QNX OS Utilities Reference),
signal() (C Library Reference)
RFC 882, RFC 883, RFC 973, RFC 974, RFC 1033