DNS and BIND 5th Edition_10 potx

Chapter 15 Miscellaneous 15.7 Additional Resource Records 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 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. 15.7.1 Host Information HINFO stands for Host INFOrmation. 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. 15.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 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 DNS & BIND 478 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. 15.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 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 DNS & BIND 15.7.3 X25, ISDN, and RT 479 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: 1. Internet host A wants to send a packet to host B, which is not connected to the Internet. 2. Host A looks up host B's RT records. This search also returns all address records (A, X25, and ISDN) for each intermediate host. 3. 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. 4. 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. 5. 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). 15.7.4 Location 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. DNS & BIND 15.7.4 Location 480 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 15.7.5 IPv6 Addresses If you're to believe the hype, IPv6 is coming soon to a network near you. Clearly, the existing A record won't accommodate IPv6'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 IPv6 address. AAAA takes as its record−specific data the textual format of an IPv6 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: DNS & BIND 15.7.5 IPv6 Addresses 481 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 IPv6, for example. Finally, RFC 1886 establishes a new reverse mapping namespace for IPv6 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 IPv6 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.IP6.INT. These domain names have PTR records attached, just as domain names under in−addr.arpa do. 15.7.6 SRV 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 ftping 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: DNS & BIND 15.7.6 SRV 482 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 DNS & BIND 15.7.6 SRV 483 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 [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 15.7.6 SRV 484 Chapter 15 Miscellaneous 15.8 DNS Versus X.500 X.500 is an ISO (International Standards Organization) standard distributed directory system that's sometimes seen as a "competitor" to DNS. X.500 does, indeed, include some of the same functionality DNS does. For example, you can use X.500 to retrieve address information for a particular host. And in some ways, the two are similar: X.500 directories store data in hierarchical name spaces, and use recursion and iteration (well, ISO calls them "chaining" and "referral"). While we can hardly claim to be experts on X.500, we can make some general comparisons between DNS and X.500: • X.500, as a directory service, supports many types of searching. Whereas DNS servers simply look up data attached to a given domain name, you can search the X.500 Directory Information Tree for soundalike matches, or specify incomplete information ("I know his last name is Buttle and he works in the Ministry of Information") and still turn up data. • X.500 is a full−blown distributed database meant to be used for a wide variety of applications. You can store the phone book in an X.500 database. You can store location data in an X.500 database. You can store information about all sorts of network devices and their attributes. DNS, on the other hand, is a relatively simple distributed database meant to solve a particular problem − an intractable HOSTS.TXT database. • X.500 has security features involving credentials and the support of multiple encryption types; DNS is not secure.[4] [4] Yet. The DNS Security Extensions described in RFC 2065 will allow cryptographic authentication of the source of zone data as well as data integrity checking, and more. Anyway, you get the idea. X.500 is rich in capabilities and will be extremely useful when it is completely defined, implemented, and optimized. DNS provides a few, critical functions. It is, for the most part, fully implemented, and it will continue to evolve and improve. Don't let this turn you off to DNS, though. The Domain Name System really is admirably good at its job, and it does it much faster than X.500 does. True, X.500 offers richer functionality, but it may never usurp DNS's position as the Internet's directory system of choice. 15.7 Additional Resource Records 15.9 DNS and WINS DNS & BIND 485 [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] DNS & BIND 486 Chapter 15 Miscellaneous 15.9 DNS and WINS In our first edition, we mentioned the close alignment between NetBIOS names and DNS domain names, but noted that, alas, there was no way for DNS to function as a NetBIOS name server. Basically, a DNS name server would need to support dynamic updates to function as a NetBIOS name server. Of course, BIND 8 supports dynamic updates. Unfortunately, Microsoft's DHCP server doesn't yet send dynamic updates to DNS server. It only talks to Microsoft's WINS servers. WINS servers handle dynamic updates, though only for NetBIOS clients. In other words, a WINS name server doesn't speak DNS. However, Microsoft provides a DNS server in Windows NT 4.0, which in turn can talk to WINS servers. The Microsoft DNS Server has a nice graphical administration tool, as you would expect from Microsoft, and provides a handy hook into WINS: you can configure the server to query a WINS server for address data if it doesn't find the data in a DNS zone. This is done with a new WINS record in the zone data file. The WINS record is attached to the zone's domain name, like the SOA record. It acts as a flag, to tell the Microsoft DNS Server to query a WINS server if it doesn't find an address for the name it's looking up. The record: @ 0 IN WINS 192.249.249.39 192.253.253.39 tells the Microsoft DNS Server to query the WINS servers running at 192.249.249.39 and 192.253.253.39 (in that order) for the name. The zero TTL is a precaution against the record being looked up and cached. There's also a companion WINS−R record that allows a Microsoft DNS Server to reverse map IP addresses using a NetBIOS NBSTAT request. If the data file for an in−addr.arpa zone contains a WINS−R record, like: @ 0 IN WINS−R movie.edu and the IP address sought doesn't appear in the file, the name server will attempt to send a NetBIOS NBSTAT request to the IP address being reverse mapped. This amounts to calling a phone number and asking the person on the end, "What's your name?" The result has a dot and the domain name in the record−specific data appended, in this case ".movie.edu". These records provide valuable glue between the two name spaces. Unfortunately, the integration isn't perfect. As they say, the devil is in the details. The main problem, as we see it, is that only the Microsoft DNS Servers support WINS and WINS−R.[5] Therefore, if you want lookups in the fx.movie.edu zone to be tried on the Special Effects Department's WINS server, then all fx.movie.edu name servers must be Microsoft DNS Servers. Why? Imagine that the DNS servers for fx.movie.edu were mixed, some Microsoft DNS Servers and some BIND. If a remote DNS & BIND 487 [...]... is that WINS and WINS−R are proprietary BIND name servers don't understand them, and in fact a BIND slave that transfers a WINS record from a Microsoft DNS Server primary master will fail to load the zone because WINS is an unknown type (We discussed this, and how to work around it, in greater detail in Chapter 13, Troubleshooting DNS and BIND. ) The answer to these problems is the DNS standard dynamic... service well 15.8 DNS Versus X.500 A DNS Message Format and Resource Records [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] 488 DNS & BIND Appendix A A DNS Message Format and Resource Records Contents: Master File Format DNS Message Header Section Format Resource Record Data This appendix outlines the format of DNS messages and enumerates all... mnemonics and values are defined: IN 1 the Internet CS 2 the CSNET class (obsolete − used only for examples in some obsolete RFCs) CH 3 the CHAOS class HS A.1.4 New Types from RFC 1664 501 DNS & BIND 4 the Hesiod class 15.9 DNS and WINS A.2 DNS Message [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] A.1.4 New Types from RFC 1664 502 DNS & BIND Appendix... characters Character string is treated as binary information, and can be up to 256 characters in length (including the length octet) A.3 Header Section Format B Compiling and Installing BIND on a Sun [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] 511 DNS & BIND Appendix B B Compiling and Installing BIND on a Sun Contents: Get the Source Code Unpack the... ] A.1.4 New Types from RFC 1664 502 DNS & BIND Appendix A DNS Message Format and Resource Records A.2 DNS Message In order to write programs that parse DNS packets, you need to understand the message format DNS queries and responses are most often contained within UDP packets Each message is fully contained within a UDP packet If the query and response are sent over TCP, then they are prefixed with... relate to the query, but are not strictly answers for the question A.1 Master File Format A.3 Header Section Format 503 DNS & BIND [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] 504 DNS & BIND Appendix A DNS Message Format and Resource Records A.3 Header Section Format (From RFC 1035, pages 26−28) 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +−−+−−+−−+−−+−−+−−+−−+−−+−−+−−+−−+−−+−−+−−+−−+−−+... the most significant octet is transmitted first A.2 DNS Message A.4 Resource Record Data [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] A.3.3 Data Transmission Order 509 DNS & BIND Appendix A DNS Message Format and Resource Records A.4 Resource Record Data A.4.1 Data Format In addition to two− and four−octet integer values, resource record data... MetaInfo's Meta IP /DNS, which is a port of BIND 8.1.1 with WINS capabilities added on Stock BIND, however, can't talk to WINS servers The best DNS WINS configuration we've heard of so far puts all WINS−mapped data in its own DNS zone, say mobile.movie.edu All the name servers for mobile.movie.edu are Microsoft DNS Servers, and the zone mobile.movie.edu contains just SOA records, NS records, and a WINS record... file: ftp > cd /isc /bind/ src/cur /bind 8 250 CWD command successful ftp > binary 200 Type set to I ftp > get bind 8.1.2−src.tar.gz 200 PORT command successful 150 Opening BINARY mode data connection for bind 8.1.2−src.tar.gz (675801 bytes) 226 Transfer complete 675801 bytes received in 89.5 seconds (7.4 Kbytes/s) ftp > quit 221 Goodbye A.4 Resource Record Data B Compiling and Installing BIND on a Sun B.2.. .DNS & BIND DNS server needed to look up a NetBIOS name in fx.movie.edu, it would choose which of the fx.movie.edu DNS servers to query according to round trip time If the server it happened to choose were a Microsoft DNS Server, it would be able to resolve the name to a dynamically assigned address But if it happened to choose a BIND server, it wouldn't be able to resolve the name [5] And a few . servers must be Microsoft DNS Servers. Why? Imagine that the DNS servers for fx.movie.edu were mixed, some Microsoft DNS Servers and some BIND. If a remote DNS & BIND 487 DNS server needed to. never usurp DNS& apos;s position as the Internet's directory system of choice. 15.7 Additional Resource Records 15.9 DNS and WINS DNS & BIND 485 [ Library Home | DNS & BIND | TCP/IP. | Practical Security ] DNS & BIND 486 Chapter 15 Miscellaneous 15.9 DNS and WINS In our first edition, we mentioned the close alignment between NetBIOS names and DNS domain names, but noted