| Title |
How do I use TCP/IP over my existing QNX4 Ethernet network? |
| Ref. No. |
QNX.000009301 |
| Category(ies) |
Network, Configuration |
| Issue |
Recently, I was asked to add support for TCP/IP networking to our QNX Ethernet network. To resolve IP addresses, I configured each node to use a local /etc/hosts file. What a mistake! Now, every time I want to do something like add a node or change an IP address, I have to update every /etc/hosts file on the LAN! I'm thinking of changing our setup to use the Domain Name System (DNS) instead-from what I've read, it'll make things a lot easier. Any suggestions on doing this under QNX?
|
| Solution |
DNS will certainly save you a lot of support headaches, since it lets you disseminate new host information throughout your network from a single nameserver.
The best way to learn how to use DNS is with an example. So I'm going to start with a simple network setup and describe the configuration files you need to create a DNS nameserver for that network. From there, you should find it relatively easy to set up your own nameserver.
Before we begin...
x09Most 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.
x09To understand the sample configuration files I'm about to show you, you need a basic understanding of RRs. So let's start with a rundown of the most common RR types:
RR typex09Text namex09Function
SOAx09Start Of Authorityx09Provides administrative information for the domain
NSx09Name Serverx09Indicates that this is an authoritative nameserver (I'll describe this later)
Ax09Internet Addressx09A hostname-to-address mapping
CNAMEx09Canonical Namex09An alias
HINFOx09Host Informationx09The hosts hardware and OS
WKSx09Well Known Servicesx09A list of services supported by the host
MXx09Mail Exchangerx09The mail server where mail for a host will be delivered
PTRx09Pointerx09An address-to-hostname mapping (for reverse queries)
x09You should also understand the basic format that all RRs follow:
x09name [ttl] IN type data
Fieldx09Description
namex09The 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.
ttlx09Stands 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.
INx09Identifies the RR as a DNS record. There are other record classes, but DNS uses only this class.
typex09The type of RR (e.g. SOA, NS, etc.).
datax09Information specific to this type of RR (e.g. the data for a CNAME record would be an alias).
x09For more information on RRs, see RFC-1033 and RFC-1035. You could also refer to TCP/IP Network Administration, which ships with TCP/IP for QNX.
And now, back to our example...
x09Let's assume you have a five-node QNX TCP/IP network in which each node boots from its own hard drive:
x09We're now going to set up a primary nameserver for this network. (This calls for one more digression before we continue. 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; or a caching-only server, which runs the named server daemon but doesn't keep the zone files. Primary and secondary servers am authoritative servers, while caching-only servers, which provide only second-hand information, are not.)
x09Now 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; I've chosen Renames that are more meaningful to this example.)
Conventionalx09Name in our
namex09examplex09Function
named.bootx09named.bootx09Provides general parameters and location of remaining config files
named.cax09root.cachex09Points to cache initialization file
named.localx09localhost.revx09Resolves the loopback address
named.hostsx09sample.com.hostsx09(zone file) Contains most domain information, including hostname-to-address mappings
named.revx09sample.com.revx09(zone file) Contains address-x09to-hostname mappings
x09With the exception of named.boot, all these files share the same basic format.
Configuring the primary server
Let's start with the named.boot file:
x09; @(#)named.boot 5.1 (Berkeley) 6/30/90
x09directory /etc/namedb
x09;typex09domainx09source host/file
x09cachex09.x09root.cache
x09primaryx09sample.comx09sample.com.hosts
x09primaryx0978.231.198.IN-ADDR.ARPAx09sample.com.rev
x09primaryx090.0.127.IN-ADDR.ARPAx09localhost.rev
x09This file contains several commands-directory, cache, and primary:
directory /etc/namedb
x09Tells named that the remaining configuration files (root.cache, sample.com.hosts, ...) reside under the /etc/namedb directory.
cache root.cache
x09Tells named to maintain a cache of nameserver responses and to use the root.cache file to initialize the cache.
primary sample.com sample.com.hosts
x09Declares that this node (node5) is the primary server for the sample.com domain. Also tells named to load the information for this domain from the sample.com.hosts zone file.
primary 78.231.198.IN-ADDR.ARPA sample.com.rev
x09Declares that this node (node5) is the primary server for the reverse domain 78.231.198.IN-ADDR.ARPA. (The reverse domain converts numeric IP addresses into domain names; you can apply for a reverse domain when you obtain your Internet domain name.) This command also tells named to load the information from the sample.com.rev zone file. This file contains the mappings to convert the IP addresses from 198.231.78.0 to hostnames.
primary 0.0.127.IN-ADDR.ARPA localhost.rev
x09States that the information for the loopback domain is contained in the localhost.rev file. The loopback domain is an IN-ADDR.ARPA domain that maps the address 127.0.0.1 to the name localhost.
x09For more information on these and other possible named.boot configuration commands, see TCP/IP Network Administration.
The root.cache file
x09The named.boot file we just looked at contains a cache statement. This statement points to the cache initialization file; in our example, root.cache. This initialization file contains the information needed to begin building a cache of domain data when the server starts.
x09The cache statement in the named.boot file contains a dot (.). This is the name of the root domain, which sits at the top of the. domain hierarchy. At a minimum, the root.cache file contains the names and address of the root servers, which are the nameservers for the root domain. (You should update the information in this file about once a month; see pp. 179-180 in TCP/IP Network Administration.) Here's the root.cache file:
x09;x09@(#)root.cache 5.1 (Berkeley) 6/30/90
x09;x09Servers for the root domain
x09;x09Initial cache data for root domain servers.
x09.x0999999999x09INx09NSx09NS.INTERNIC.NET.
x09x0999999999x09INx09NSx09KAVA.NISC.SRI.COM.
x09x0999999999x09INx09NSx09TERP.UMD.EDU.
x09x0999999999x09INx09NSx09NS.NIC.DON.MIL.
x09;x09Root servers by address
x09;x09Prep the cachex09(hotwire the addresses). Order doesn't matter.
x09NS.INTERNIC.NET.x0999999999x09INx09Ax09198.41.0.4
x09KAVA.NISC.SRI.COMx0999999999x09INx09Ax09192.33.33.24
x09TERP.UMD.EDU.x0999999999x09INx09Ax09128.8.10.90
x09NS.NIC.DON.MIL.x0999999999x09INx09Ax09192.112.36.4
x09Near 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.
x09If 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.rev file
The localhost.rev 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.rev file:
x09@x09INx09SOAx09node5.sample.com. node5.sample.com.(
x09x09x09x09950110x09;x09serial
x09x09x09x09604800x09;x09refresh (168 hours)
x09x09x09x093600x09;x09retry (1 hour)
x09x09x09x093600000x09;x09expire (1000 hours)
x09x09x09x09604800 )x09;x09minimum (168 hours)
x09x09INx09NSx09node5.sample.com.
x091.0x09INx09PTRx09localhost.
x09Note 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:
x09name [ttl] IN SOAx09origin person (
x09x09serial
x09x09refresh
x09x09retry
x09x09expire
x09x09minimum )
namex09The name of the zone. The at-sign (@) refers back to the primary statement (in named.boot) that points to this zone file.
originx09The name of the host on which the master zone file resides.
personx09A 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.
x09Note 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.
serialx09The version number of the zone file. You should increment this any time you change data in the zone.
x09For info on the remaining fields, see TCP/IP Network Administration
x09After the SOA record, you see an NS record that indicates the computer's hostname (i.e. node5.sample.com.). This record is optional here since it's defined in the sample.com.hosts file.
x09Note 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 sample.com.hosts file
x09The files we covered so far-named.boot, root.cache, and localhost.rev-are the only files required to configure a caching-only server. The remaining files-sample.com.hosts and sample.rev-are more complex, and are created only on a primary server.
x09The sample.com-hosts file contains most of the domain information. It converts hostnames to IP addresses, and, as a result, 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:
x09;
x09;x09Address to host names mappings
x09;
x09;x09@x09INx09SOAx09node5.sample.com.node5.sample.com.(
x09x09x09x09950110x09;x09serial
x09x09x09x09604800x09;x09refresh (168 hours)
x09x09x09x093600x09;x09retry (1 hour)
x09x09x09x093600000x09;x09expire (1000 hours)
x09x09x09x09604800 )x09;x09minimum (168 hours)
x09x09x09INx09A 198.231.78.5
x09x09x09INx09HINFO 486 "QNX 4.21"
x09;x09define the nameservers and the mail servers
x09x09INx09MXx0910x09node5.sample.com.
x09x09INx09MXx0920x09node1.sample.com.
x09x09INx09NSx09x09node5.sample.com.
x09;x09define the hosts in this zone
x09nodelx09INx09Ax09198.231.78.1
x09x09INx09MXx095 node5.sample.com.
x09node2x09INx09Ax09198.231.78.2
x09x09INx09MXx095 node5.sample.com.
x09node3x09INx09Ax09198.231.78.3
x09x09INx09MXx095 node5.sample.com.
x09node4x09INx09Ax09198.231.78.4
x09x09INx09MXx095 node5.sample.com.
x09node5x09INx09Ax09198.231.78.5
x09x09INx09MXx095 node5.sample.com.
x09;x09define local host
x09localhost IN A 127.0.0.1
Note the first MX record:
x09INx09MXx0910x09node5.sample.com.
x09This 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 at 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.
x09The 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 mail default servers. However, by adding these MX entries we can do things such as adjust the preference level for each host.
The sample.com.rev file
x09The last configuration file, sample.com.rev, converts IP addresses to hostnames. As a result, it looks a lot like localhost.rev, with its use of PTR records:
x09;
x09;x09Address to host name mappings
x09;
x09;x09@x09INx09SOAx09node5.sample.com. node5.sample.com.(
x09x09x09x09950110x09;x09serial
x09x09x09x09604800x09;x09refresh (168 hours)
x09x09x09x093600x09;x09retry (1 hour)
x09x09x09x093600000x09;x09expire (1000 hours)
x09x09x09x09604800x09;x09minimum (168 hours)
x09INx09NSx09node5.sample.com.
x091x09INx09x09PTRx09node1.sample.com.
x092x09INx09x09PTRx09node2.sample.com.
x093x09INx09x09PTRx09node3.sample.com.
x094x09INx09x09PTRx09node4.sample.com.
x095x09INx09x09PTRx09node5.sample.com.
Configuring the client side
x09Let's now look at how to set up the client side of DNS on each of the remaining nodes (node1 through node4).
x09Under 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.
x09The /etc/resolv.conf file contains at least the following entries:
nameserver address
x09Identifies, 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, the resolver queries the second server; if there's still no response, the resolver queries the third server, and so on.
x09If resolv.conf contains no nameserver entries, or if no resolv.conf file exists, all nameserver queries are sent t the local host (i.e. the /etc/hosts file).
domain name
x09Defines 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:
x09;
x09;x09Domain name resolver configuration file - '/etc/reselv.conf'
x09;
x09domain sample.com
x09nameserver 198.231.78.5
Debugging
x09To 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
x09First, nslookup returned the primary server's hostname and IP address. Then, after I entered a query for node2, it returned the server name and IP address again, followed by the hostname and IP address for node2.
x09By 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:x09node5
Address: 198.231.78.5
Non-authoritative answer:
node2.sample.com preference = 5, mail exchanger = node5.sample.com
Authoritative answers can he found from:
sample.com nameserver = node5.sample.com
node5.sample.com internet address = 198.231.78.5
x09Now 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:
node1x09INx09Ax09198.231.78.1
x09INx09MXx09node5.sample.com
Given this error, here's what nslookup would show if you did an MX query for node1:
> set type=mx
> node1
Server:x09node5
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 see, the "mail exchanger" hostname is resolved to nodeS.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.
|
|
