14.7 Additional Resource Records | DNS on Windows 2000


Team-Fly

	DNS on Windows 2000, 2nd Edition By Matt Larson, Cricket Liu
	Table of Contents

	Chapter 14. Miscellaneous

14.7 Additional Resource Records

There are a number of resource records that we haven't covered yet in this book. The first of these, HINFO, has been around since the beginning but hasn't been widely used. The others were defined in RFC 1183 and several successive RFCs. Most are experimental, but some are on the standards track and are coming into more prevalent use. We'll describe them here to give you a little head start in getting used to them.

14.7.1 Host Information

HINFO stands for h ost info rmation. The record-specific data is a pair of strings identifying the host's hardware type and operating system. The strings are supposed to come from the MACHINE NAMES and OPERATING SYSTEM NAMES listed in the Assigned Numbers RFC (currently RFC 1700), but this requirement is not enforced; you can use your own abbreviations. The RFC isn't at all comprehensive, so it's quite possible you won't find your system in the list anyway. Originally, host information records were intended to let services like FTP determine how to interact with a remote system. This would have made it possible to negotiate data type transformations automatically, for example. Unfortunately, this didn't happenfew sites supply accurate HINFO values for all their systems. Some network administrators use HINFO records to help them keep track of the machine types, instead of recording the machine types in a database or a notebook. Here are two examples of HINFO records (note that the values in the CPU type and Operating system fields must be surrounded with quotes if they include any whitespace):

 ; ; These machine names and system names did not come from RFC 1700 ; wormhole  IN  HINFO  ACME-HW  ACME-GW cujo      IN  HINFO  "Watch Dog Hardware"  "Rabid OS"

You'd see the window shown in Figure 14-8 if you added an HINFO record with the DNS console.

Figure 14-8. Adding an HINFO record with the DNS console

If you include whitespace in the values you type in the CPU type and Operating system fields, the DNS console will automatically put double quotes around them, so don't use double quotes in either fieldyou'll get double double quotes.

Before you go adding them to your zoneparticularly a zone visible from the Internetyou should know that HINFO records can present a security risk. By providing easily accessible information about a system, you may be making it easier for a hacker to break into it.

14.7.2 AFSDB

AFSDB has a syntax like that of the MX record and semantics a bit like that of the NS record. An AFSDB record gives either the location of an AFS cell database server or of a DCE cell 's authenticated name server. The type of server the record points to, and the name of the host running the server, are contained in the record-specific data portion of the record.

So what's an AFS cell database server? Or AFS, for that matter? AFS originally stood for the Andrew File System, designed by the good folks at Carnegie-Mellon University as part of the Andrew Project. (It's now an IBM product.) AFS is a network filesystem, like NFS, but one that handles the latency of wide-area networks much better than NFS does and provides local caching of files to enhance performance. An AFS cell database server runs the process responsible for tracking the location of filesets (groups of files) on various AFS file servers within a cell (a logical group of hosts ). So being able to find the AFS cell database server is the key to finding any file in the cell.

And what's an authenticated name server? It holds location information about all sorts of services available within a DCE cell. A DCE cell? That's a logical group of hosts that share services offered by The Open Group's Distributed Computing Environment (DCE).

And now, back to our story. To access another cell's AFS or DCE services across a network, you must first find out where that cell's cell database servers or authenticated name servers are. Hence the new record type. The domain name to which the record is attached gives the name of the cell the server knows about. Cells are often share names with DNS domains, so this usually doesn't look at all odd.

As we said, the AFSDB record's syntax is like the MX record's syntax. In place of the preference value, you specify the number 1 for an AFS cell database server or 2 for a DCE authenticated name server.

In place of the mail exchanger host, you specify the name of the host running the server. Simple!

Say an fx.movie.edu system administrator sets up a DCE cell (which includes AFS services) because she wants to experiment with distributed processing to speed up graphics rendering. She runs both an AFS cell database server and a DCE name server on bladerunner.fx.movie.edu , another cell database server on empire.fx.movie.edu , and another DCE name server on aliens .fx.movie.edu . She should set up the AFSDB records as follows :

 ; Our DCE cell is called fx.movie.edu, same as the domain name of the zone fx.movie.edu.  IN  AFSDB  1 bladerunner.fx.movie.edu.                IN  AFSDB  2 bladerunner.fx.movie.edu.                IN  AFSDB  1 empire.fx.movie.edu.                IN  AFSDB  2 aliens.fx.movie.edu.

14.7.3 X25, ISDN, and RT

These three record types were created specifically in support of research on next -generation internets . Two of the records, X25 and ISDN, are simply address records specific to X.25 and ISDN networks, respectively. Both take record-specific data appropriate to the type of network. The X25 record type uses an X.121 address (X.121 is the ITU-T recommendation that specifies the format of addresses used in X.25 networks.) The ISDN record type uses an ISDN address.

ISDN stands for Integrated Services Digital Network. Telephone companies around the world use ISDN protocols to allow their telephone networks to carry both voice and data, creating an integrated network. Although ISDN's availability is spotty throughout the U.S., it has been widely adopted in some international markets. Since ISDN uses the telephone companies' networks, an ISDN address is just a phone number and, in fact, consists of a country code, followed by an area code or city code, then by a local phone number. Sometimes there are a few extra digits you wouldn't see in a phone number at the end, called a subaddress. The subaddress is specified in a separate field in the record-specific data.

Examples of the X25 and ISDN record types are:

 relay.pink.com.  IN  X25  31105060845 delay.hp.com.    IN  ISDN  141555514539488 hep.hp.com.      IN  ISDN  141555514539488 004

These records are intended for use in conjunction with the Route Through (RT) record type. RT is syntactically and semantically similar to the MX record type: it specifies an intermediate host that will route packets (instead of mail) to a destination host. So now, instead of being able to route mail only to a host that isn't directly connected to the Internet, you can route any kind of IP packet to that host by using another host as a forwarder. The packet could be part of a Telnet or FTP session or perhaps even a DNS query!

Like MX, RT includes a preference value, which indicates how desirable delivery to a particular host is. For example, the records:

 housesitter.movie.edu.  IN  RT  10 relay.pink.com.                         IN  RT  20 delay.hp.com.

instruct hosts to route packets bound for housesitter.movie.edu through relay.pink.com (the first choice) or through delay.hp.com (the second choice).

The way RT works with X25 and ISDN (and even A) records is like this:

Internet host A wants to send a packet to host B, which is not connected to the Internet.
Host A looks up host B's RT records. This search also returns all address records (A, X25, and ISDN) for each intermediate host.
Host A sorts the list of intermediate hosts and looks for its own domain name. If it finds it, it removes it and all intermediate hosts at higher preference values. This is analogous to sendmail 's "paring down" a list of mail exchangers.
Host A examines the address record(s) for the most-preferred intermediate host that remains. If host A is attached to a network that corresponds to the type of address record indicated, it uses that network to send the packet to the intermediate host. For example, if host A were trying to send a packet through relay.pink.com , it would need connectivity to an X.25 network.
If host A lacks appropriate connectivity, it tries the next intermediate host specified by the RT records. For example, if host A lacked X.25 connectivity, it might fall back to connecting via ISDN to delay.hp.com .

This process continues until the packet is routed to the most-preferred intermediate host. The most-preferred intermediate host may then deliver the packet directly to the destination host's address (which may be A, X25, or ISDN).


Team-Fly

Top