|
Chapter 15 Miscellaneous |
|
|
|
Chapter 15 Miscellaneous |
|
There are a couple of resource records that we haven't covered yet in this book. The first of these has been around since the beginning, HINFO , but hasn't been widely used. The others were defined in RFC 1183 and several successive RFC s. 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.
HINFO stands for Host INFO rmation . The data are a pair of strings identifying the host's hardware type and operating system. The strings should 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 is quite possible you won't find your system in the list anyway. Originally, host information records were designed to let services like FTP determine how to interact with the remote system. This would have made it possible to negotiate data type transformations automatically. Unfortunately, this didn't happen - few 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 hardware type or operating system must be surrounded with quotes if it includes any whitespace:
; ; These machine names and system names did not come from RFC 1340 ; wormhole IN HINFO ACME - HW ACME - GW cujo IN HINFO "Watch Dog Hardware" "Rabid OS "
As we pointed out, HINFO records are a security risk - by providing easily accessible information about a system, you are making it easier for a hacker to break in.
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 a registered trademark of Transarc Corporation, which sells AFS as a 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 fileservers 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 the record is attached to gives the name of the cell the server knows about. Cells are often named after 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 systems 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 , and another DCE name server on aliens . She should set up the AFSDB records as follows:
; Our DCE cell is called fx.movie.edu, same as the domain 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.
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 arguments (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 have proposed using 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 only being able to route mail 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 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 delivering 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 ).
RFC 1876 defines an experimental record type, LOC , that allows domain administrators to encode the location of their computers, subnets and networks. In this case, location means latitude, longitude and altitude. Future applications could use this information to produce network maps, assess routing efficiency, and more.
In its basic form, the LOC record takes latitude, longitude and altitude (in that order) as its record-specific data. Latitude and longitude are expressed in the format:
<degrees> [minutes [seconds.<fractional seconds>]] (N|S|E|W)
Altitude is expressed in meters.
If you're wondering how in the world you're going to get that data, check out " RFC 1876 Resources," at http://www.ckdhr.com/dns-loc/ . This site, created by Christopher Davis, one of the authors of RFC 1876, is an indispensable collection of information and useful links and utilities for people creating LOC records.
If you don't have your own Global Positioning System receiver to carry around to all of your computers, two sites that may come in handy are Etak's Eagle Geocoder, at http://www.geocode.com/eagle.html-ssi , which you can use to find the latitude and longitude of most addresses in the United States; and AirNav's Airport Information, at http://www.airnav.com/airports/ , which will let you find the elevation of the closest airport to you. If you don't have a major airport near you, don't worry: the database even includes the helipad at my neighborhood hospital!
Here's a LOC record for one of our hosts:
huskymo.acmebw.com. IN LOC 40 2 0.373 N 105 17 23.528 W 1638m
Optional fields in the record-specific data allow you to specify how large the entity you're describing is, in meters ( LOC records can describe networks, after all, which can be quite large), as well as the horizontal and vertical precision. The size defaults to one meter, which is perfect for a single host. Horizontal precision defaults to 10,000 meters, and vertical precision to ten meters. These defaults represent the size of a typical ZIP or postal code, the idea being that you can fairly easily find a latitude and longitude given a ZIP code.
You can also attach LOC records to the names of subnets and networks. If you've taken the time to enter information about the names and addresses of your networks in the format described in RFC 1101 (covered earlier in this chapter), you can attach LOC records to the network names:
; ; Map
HP
's network name to 15.0.0.0. ; hp-net.hp.com. IN PTR 0.0.0.15.in-addr.arpa. IN LOC 37 24 55.393 N 122 8 37 W 26m
If you're to believe the hype, IP v6 is coming soon to a network near you. Clearly, the existing A record won't accommodate IP v6's 128-bit addresses: BIND expects an A record's record-specific data to be a 32-bit address in dotted-octet format.
RFC
1886 introduces a new address record,
AAAA
, used to store a 128-bit
IP
v6 address.
AAAA
takes as its record-specific data the textual format of an
IP
v6 record described in
RFC
1884. This format expresses the 128 bits of the address as eight sets of four hexadecimal digits, separated by colons (":"). The first set of four digits encodes the high-order 16 bits of the address. Every set of four bits are compressed into the equivalent hexadecimal digit (e.g.,
1111
becomes
f
). You can omit leading zeroes in a set of hexadecimal digits.
So, for example, you'd see AAAA records like this:
ipv6 IN AAAA 4321:0:1:2:3:4:567:89ab
RFC 1886 also extends the additional processing that BIND and other name servers do, so that name servers include AAAA records for mail exchangers and name servers that speak IP v6, for example.
Finally, RFC 1886 establishes a new reverse mapping namespace for IP v6 addresses, called ip6.int . Each level of subdomain under ip6.int represents a nibble (a 4-bit quantity) in the 128-bit address, with the low-order nibble encoded first (appearing at the far left of the domain name). Unlike the format of addresses in AAAA records, omitting leading zeroes is not allowed, so there are always 32 nibbles and 32 levels of subdomain below ip6.int in a domain name corresponding to a full IP v6 address. The domain name that corresponds to the address in the example above is:
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4. IP 6. INT .
These domain names have PTR records attached, just as domain names under in-addr.arpa do.
Locating a service or server within a zone, if you don't know which host it runs on, is a difficult problem. Some domain administrators have attempted to solve this problem by using service-specific aliases in their zones. For example, at Movie U. we created the alias ftp.movie.edu and point it to the domain name of our FTP archive:
ftp.movie.edu. IN CNAME plan9.fx.movie.edu.
This makes it easy for people to guess a domain name that will get them to our FTP archive, and separates the name people use to access to archive from the domain name of the host it runs on. If we were to move the archive to a different host, we could simply change the CNAME record.
The experimental SRV record, introduced in RFC 2052, is a general mechanism for locating services. SRV also provides powerful features that allow domain administrators to distribute load and provide backup services, similar to the MX record.
A unique aspect of the SRV record is the format of the domain name it's attached to. Like service-specific aliases, the domain name to which an SRV record is attached gives the name of the service sought, as well as the protocol it runs over, concatenated with a domain name. So, for example:
ftp.tcp.movie.edu
would represent the SRV records someone ftp ing to movie.edu should retrieve in order to find the movie.edu FTP servers, while:
http.tcp.www.movie.edu
represents the SRV records someone accessing the URL http://www.movie.edu/ should look up in order to find the www.movie.edu web servers.
The names of the service and protocol should appear in the latest Assigned Numbers RFC (the most recent as of this writing is RFC 1700), or be unique names used only locally. Don't use the port or protocol numbers , just the names.
The SRV record has four resource record-specific fields:
priority weight port target
priority , weight , and port are unsigned 16-bit numbers (between 0 and 65535). target is a domain name.
Priority works very similarly to the preference in an MX record: the lower the number in the priority field, the more desirable the associated target. When searching for the hosts offering a given service, clients should try targets at the same priority before trying those at a higher priority value.
Weight allows domain administrators to distribute load to multiple targets. Clients should query targets at the same priority in proportion to their weight. For example, if one target has a priority of zero and a weight of one, and another target also has a priority of zero but a weight of two, the second target should receive twice as much load (in queries, connections, whatever) as the first.
Port specifies the port on which the service being sought is running. This allows domain administrators to run servers on non-standard ports. For example, a domain administrator could use SRV records to point web browsers at a web server running on port 8000 instead of the standard HTTP port (80).
Target , finally, specifies the domain name of a host on which the service is running (on the port specified in the port field). Target must be the canonical name of the host (not an alias), with address records attached to it.
So, for the movie.edu FTP server, we added these records to db.movie :
ftp.tcp IN SRV 1 0 21 plan9.fx.movie.edu. IN SRV 2 0 21 thing.fx.movie.edu.
This instructs SRV -capable FTP clients to try the FTP server on plan9.fx.movie.edu 's port 21 first when connecting to movie.edu , and then to try the FTP server on thing.fx.movie.edu 's port 21 if plan9 's FTP server isn't available.
The records:
http.tcp.www IN SRV 0 2 80 www.movie.edu. IN SRV 0 1 80 www2.movie.edu. IN SRV 1 1 8000 postmanrings2x.movie.edu.
direct web queries for www.movie.edu to www.movie.edu 's port 80 and www2.movie.edu 's port 80, with www.movie.edu getting twice the queries that www2.movie.edu does. If neither is available, queries go to postmanrings2x , on port 8000.
Unfortunately, we don't know of any clients that support the SRV record yet. That's really too bad, given how useful SRV could be. Since SRV isn't widely supported, don't use SRV records in lieu of address records. It's prudent to include at least one address record for the "base" domain name to which your SRV records are attached, and more if you'd like the load spread between addresses. If you only list a host as a backup in the SRV records, don't include its IP address. Also, if a host runs a service on a non-standard port, don't include an address record for it, since there's no way to redirect clients to a non-standard port with an A record.
So, for www.movie.edu , we include all of these records:
http.tcp.www IN SRV 0 2 80 www.movie.edu. IN SRV 0 1 80 www2.movie.edu. IN SRV 1 1 8000 postmanrings2x.movie.edu. www IN A 200.1.4.3 IN A 200.1.4.4
Browsers that can handle SRV records (whenever they come out) will send twice as many requests to www.movie.edu as to www2.movie.edu , and will only use postmanrings2x.movie.edu if both of the main web servers are unavailable. Browsers that don't use SRV records will have their requests round-robinned between www and www2 .
|
|
|
|
| 15.6 Network Names and Numbers |
|
15.8 DNS Versus X.500 |