for connected embedded systems
![[Previous]](../prev.gif) |
![[Contents]](../contents.gif) |
![[Index]](../keyword_index.gif) |
![[Next]](../next.gif) |
named
Internet domain name server
Syntax:
named [-(b|c) config_file] [-d debug_level] [-f]
[-g group_name] [-p portnum] [-q] [-r]
[-t directory] [-u user_name] [-w directory]
[config_file]
Runs on:
Neutrino
Options:
- -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 (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 (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 group name or a numeric group ID.
- -p portnum
- Use the specified remote port server. This is the port number
to which named sends 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; you can specify this functionality with the listen-on clause of the configuration file's options statement. - -q
- Trace all incoming queries.
- -r
- Turn recursion off in the server (default is to use recursion). Answers can
come only from local (primary or secondary) zones.
You can use this on root servers.
The -r option is deprecated; you can replace or override it with 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 is the group of the user specified.
- -w directory
- Sets the working directory of the server (the default working directory is the current directory "."). The directory clause of the configuration file's options statement overrides any value specified on the command line.
- config_file
- Use this configuration file (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.
Description:
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 TCP/IP Network Administration by Craig Hunt, O'Reilly & Associates (ISBN 1-56592-322-7). For advanced DNS configuration, see DNS and BIND by Paul Albitz and Cricket Liu, O'Reilly & Associates (ISBN 1-56592-010-4). |
Sample DNS nameserver
Suppose you wanted to add support for TCP/IP networking to an Ethernet network. Rather than resolve IP addresses by configuring each node to use a local /etc/hosts file, DNS lets you disseminate new host information throughout your network from a single nameserver.
Resource records (RRs)
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 |
|---|---|---|
| A | Internet Address | A hostname-to-address mapping |
| CNAME | Canonical Name | An alias |
| HINFO | Host Information | The host's hardware and OS |
| MX | Mail Exchanger | The mail server where mail for a host is delivered |
| NS | Name Server | Indicates that this is an authoritative nameserver |
| PTR | Pointer | An address-to-hostname mapping (for reverse queries) |
| SOA | Start Of Authority | Provides administrative information for the domain |
| WKS | Well Known Services | A list of services supported by the host |
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.
Authoritative servers
Let's assume you have a five-node 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 is one of these basic types:
- primary server -- keeps the zone files that provide the definitive information for the domain
- secondary server -- transfers these files from the primary server
- caching-only server -- 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.
Creating the configuration files
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.
named.conf
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.
root.cache
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.
localhost.resolve
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, refer to 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.
sample.com.hosts
The files we covered so far -- named.conf, 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 Neutrino 6.3.0"
; 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.
sample.com.reverse
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.
Configuring the client side
For the rules on setting up the client side of DNS see /etc/resolv.conf.
For our example, your resolv.conf should set the nameserver to 198.231.78.5 and the domain name to sample.com.
Debugging
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.
Diagnostics
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(). In order to capture the log messages, you need to have syslogd running.
Files:
- /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.
See also:
hostname, kill, /etc/named.conf, named-xfer, syslogd
gethostbyname(), signal() in the Library Reference
RFC 882, RFC 883, RFC 973, RFC 974, RFC 1033
|
|
|
|