![[Previous]](../prev.gif) |
![[Contents]](../contents.gif) |
![[Index]](../keyword_index.gif) |
![[Next]](../next.gif) |
|
|
|
|
 |
This version of this document is no longer maintained. For the latest documentation, see http://www.qnx.com/developers/docs. |
Internet domain name server
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]
Neutrino
 |
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. |
|
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. |
|
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. |
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:
Or:
|
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). |
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.
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:
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 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 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:
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.
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.
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.
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.
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.
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:
hostname, kill, /etc/named.conf, named-xfer, syslogd
gethostbyname(), signal() in the Library Reference
RFC 882, RFC 883, RFC 973, RFC 974, RFC 1033
|
|
|
|