FIGURE 9.1 The Domain Space
MacDNS, Apple Computer.
QuickDNS Pro and QuickDNS Lite, Men&Mice.
Sonic DNS Internet Server, Sonic Systems.
To add or update a link, send mail to updates@pism.com.
The Domain Name System, or DNS, is a naming scheme for dotted decimal Internet Protocol, or IP, addresses. Every computer, or "host," on the Internet has an IP address assigned to it; every host name refers to an IP address.
Host names were put into place to benefit people; computers are perfectly content to call each other by number. Even if you've been on the Internet for some time, you may know relatively few of the 32-bit long IP addresses, but even a relative newcomer knows several host names, from his or her e-mail address, which probably uses a host name, to favorite FTP sites. And the Web has us guessing host names, as we use the form www.companyname.com with wild abandon.
In fact, it's considered bad form to go around using IP addresses, since IP addresses can change. Because of the Domain Name System's higher level of abstraction, it's a more reliable way to name a service - when an IP address changes, a domain name server can be updated, so that the old name can be resolved into the new address. DNS makes the Internet seem a much friendlier, more stable place.
Who makes this all happen? In many cases, your Internet Service Provider can provide domain name service for your computers, and will even help you register your own domain name (explained later), as part of a package of services it offers. You may choose to run your own DNS if your ISP doesn't offer those services or doesn't meet your needs in terms of cost or turnaround time - or if your local network is more than a few machines, in which case you may find the ability to offer domain name resolution for the local network, and to make changes to the domain name database when needed, quite useful. Whether or not you choose to run your own domain name server, however, it is helpful to be aware of the domain name architecture to at least some extent, and a quick read over the first part of this chapter, covering the general concepts behind DNS, can give you a useful, basic understanding of the domain name system.
Domain Name Architecture
The Domain Name Database
The Domain Name System uses a client/server mechanism, with domain name resolvers as the clients and domain name servers as the servers. For most TCP/IP applications under the Mac OS, the resolver built into MacTCP or Open Transport is used, although some applications, like Apple Internet Mail Server, use their own domain name resolver.
The Domain Name System is implemented as a distributed database, existing in something called a domain name space. The key features of such an implementation are that it allows local control of domain names, and doesn't put too much load or responsibility on one, centralized authority. The domain name space is organized hierarchically, with the root domain at the top, and the rest of the structure branching from this root domain. Conceptually, the domain name space is a large, inverted tree. Figure 9.1, shows a portion of that name space.
FIGURE 9.1 The Domain Space
Key here is that there is no master domain name database; because the domain name system is a distributed one, each domain generally keeps records only of its next-level subdomains. However, all domain name resolvers have a pointer to the root domain (served by multiple servers), which in turn has pointers to all the top-level domains (those one level below the root domain - com, edu, org, and so on), which in turn have pointers to their subdomains, and so on, so that any name within the name space can be queried and resolved.
Resolvers and Servers
Domain name queries are sent by domain name resolvers to domain name servers, which return a result. That's straightforward enough. However, due to the distributed nature of DNS, name servers act as both name servers and resolvers: they answer queries for which they are authoritative, and they attempt to resolve, or query, other name servers about information regarding domains for which they are not authoritative.
For example, a name server may know that it is authoritative for any host in the domain freedonia.org. If any resolver asks it for information about a host in freedonia.org - say, for example, for the IP address for www.freedonia.org - the name server can respond with an answer to its query. But if the same name server were asked for information about a host for which it is not authoritative - say, the IP address for abs.apple.com - it in turn queries a root name server, which then refers it to a name server in the next-level domain - in this case, com - which would then refer it to a server authoritative for the Apple domain, and so on, until the query is resolved. The name server would then return the result to the client that requested the information.
You might ask, why would a name server be asked for information about which it is not an authority in the first place? If MacTCP and Open Transport contain their own resolvers, why would a name server need to act in this role? Indeed, name servers normally act as resolvers only for their local network - the root name servers always refer queries to only authoritative name servers. However, it's usually the case that on a local network only the name server knows about the root servers, so that resolvers like MacTCP or Open Transport don't need to keep track of this info - if they did, it could easily make configuring each host a nightmare. Also, on machines that don't run the Mac OS, resolvers associated with TCP/IP stacks may not have the smarts to follow referrals to other name servers, as the name server did in our preceding example.
Recursion and Iteration
The previous example was an illustration of recursion. The name server followed successive referrals until it found an answer. The local host's resolver is said to have issued a recursive query.
Resolvers can also issue iterative queries, in which the queried name server must return the requested information or the name of a name server that can in turn be queried for the requested information. In the example just given, in which the local host's resolver issued a recursive query, the name server (acting as a resolver) issued a succession of iterative queries; it was referred by name servers to other name servers, which it then queried, and so on, until it found the information it was looking for.
Caching
To reduce network traffic and answer queries more quickly, most resolvers and name servers store the answers they receive to queries in a cache. If a resolver or name server then receives a successive query for the same information, it can simply return the requested data from its cache. Even if a resolver or name server hasn't cached the exact answers to the query, it can still use its cached data to speed up queries; for example, if the name server from our previous example is asked to resolve www.apple.com after resolving solutions.apple.com, it can do so by directly querying the name server for apple.com, and avoid querying name servers authoritative for the root and com domains.
Of course, when information about other domains change, cached data becomes outdated and useless. Because of this, all information records have associated with them a time to live: the amount of time for which that information should be assumed valid. After the time to live for a record expires, that information is flushed from the cache, and the authoritative name server for the flushed data is again consulted.
Hosts, Domains, and Zones
Hosts are computers with a network connection. Although the term "host" could be interpreted to mean a computer that provides information to clients - a server - it's come to mean any machine on the network, whether or not its primary purpose is to provide resources via the network.
Domain names usually refer to specific hosts - for example, a domain name north.freedonia.org might refer to a computer, north, in the domain freedonia.org - but don't always do so: north might simply be a subdomain of freedonia.org, with the hosts wintry and cold within it, which would have the domain names wintry.north.freedonia.org and cold.north.freedonia.org, respectively; wintry.north.freedonia.org, then, would be a subdomain of north.freedonia.org, but also a domain in its own right; similarily, there might be a host north.freedonia.org or there might not - in either case, north.freedonia.org is still a domain name (whether it refers to a specific computer or not).
A zone is an administrative division of the domain name space. Name servers are said to be authoritative for any portion of the domain name space for which they contain complete data; a zone consists of the name space for which a server is authoritative.
Zones are not always congruous with domains. For example, a name server hail.freedonia.org for the domain freedonia.org might delegate the authority over some of its subdomains to others - perhaps north.freedonia.org and east.freedonia.org - while retaining control of other subdomains - south.freedonia.org and west.freedonia.org. In this case, the domain would include all its subdomains - north, south, east, and west - but the zone would include only those subdomains over which the name server maintained authority - south.freedonia.org and west.freedonia.org, as well as freedonia.org.
If the domain for which you're responsible contains no subdomains, it's likely your domain and your zone are one and the same.
Primary and Secondary Servers
Every domain connected to the Internet needs to be served by at least two servers, so that if one server becomes unavailable, name service can still be provided. In most cases, one of the servers serving your domain will be a secondary server, although you can run two primary servers, as well.
A primary server gets its domain name information from an administrator-configured database or from administrator-configured files. Under the Mac OS, these might be plain text files or information stored in the server application's preferences file (or elsewhere), depending upon the server application. A secondary server gets its data instead from another server on the network, performing what is called a zone transfer.
Using a secondary server means domain name information needs to be maintained in only one place - on the primary server. Information is kept current on the secondary server by the secondary server periodically checking the primary server for changes, and updating its database if a change has been made.
Registering Your Domain Name
To become part of the domain name space, you need to become a subdomain of an existing domain. This means you'll need to determine where you fit within the existing name space, and contact the administrator of the appropriate domain. Most domains are registered in the "com" top-level domain, although a subdomain to a geographical or other domain may be more appropriate to your situation. The following overview of the domain structure should give you enough context that you'll be able to determine where your network would fit within the domain name system.
Top-Level Domains
Top-level domains are organized along two lines: organizationally (the com, edu, and gov domains, among others), and geographically (us, nz, and au, among others).
Organizational Domains
In the United States, most domain names in use are split along organizational lines; there's a total of seven recognized top-level organizational domains by the Internic, a central registry for top-level domains supported in part by the National Science Foundation. These top-level organizational domains are:
com: For use by commercial organizations.
edu: For use by four-year colleges and universities. Other schools are registered under geographical domains.
gov: For use by agencies of the U.S. federal government.
int: For use by international organizations, those established by international treaty.
mil: For use by the U.S. military.
net: For use by network providers.
org: For use by miscellaneous organizations that don't fit in the other top-level domains.
Geographical Domains
Geographical domains are based upon the two-letter country codes listed in Table 9.1 (see pages 298300). Each geographical domain can be organized however the administrative organization for the domain sees fit; not all adhere to the U.S. model, described next.
The U.S. Top-Level Domain. The hierarchy of the U.S. top-level domain is based on political geography. The general format is a host name, followed by an organization name, followed by a locality, followed by a two-letter postal abbreviation for the state, followed by us, although actual domain names can and do differ.
Beyond the Top Level: states, fed, and dni. Two-letter postal abbreviation for a state: Most second levels in the us top-level domain use the two-letter postal abbreviation for a state - for example, ca.us or mn.us.
fed: For use by federal agencies.
dni: For use by distributed national institutes, organizations that go across state or regional boundaries and that have facilities in multiple regions.
locality: cities, counties, parishes, and townships. For example, berkeley.ca.us. Berkeley might also have been set up as a subdomain under Alameda county, in which case it would have been berkeley.alameda.ca.us.
cc: For use by community colleges. For example, elcamino.cc.ca.us.
ci: For use by city agencies. For example, ci.berkeley.ca.us.
co: For use by county agencies. For example, co.hennepin.mn.us.
gen: For use by miscellaneous organizations that don't fit in the other domains defined under the state level. For example, rfo.gen.mn.us.
k12: For use by primary and secondary schools. Subdomains are usually the school district, then the school name. For example, happy-valley.hvsd.k12.ca.us.
pvt: For use by private K-12 schools as a subdomain to the k12 domain. For example, nueva.pvt.k12.ca.us.
lib: For use by libraries. For example, hennepin.lib.mn.us.
state: For use by state agencies. For example, northstar.state.mn.us.
tec: For use by technical and vocational schools. For example, washburn.tec.ca.us.
Searching the Domain Space
Once you have an idea of the domain name your service or organization might belong in, you'll want to search the domain space to find contact information or to see that no one else already has authority over the domain you seek. One way to do this is to use the Whois service, available from many UNIX hosts, including rs.internic.net, which you can access using a telnet client (
SunOS UNIX 4.1 (rs) (ttyp5)
[...]
[vt220] InterNIC > whois domain mcdonalds
Connecting to the rs Database . . . . . .
Connected to the rs Database
McDonald's Corporation (MCDONALDS-DOM)
Network Computing
Facilities and Systems
McDonald's Plaza
Oak Brook, IL 60521
Domain Name: MCDONALDS.COM
Administrative Contact, Technical Contact, Zone Contact:
Rush, Chuck (CR21) crush@BIGMAC.MCD.COM
(708) 575-6512
Record last updated on 04-Jan-95.
Domain servers in listed order:
PJL53PK.I-P.MAIL.ATT.NET 198.152.3.8
PJL53IG.I-P.MAIL.ATT.NET 198.152.2.8
PJL53WO.I-P.MAIL.ATT.NET 198.152.4.8
Here, we searched for all domains that contain "mcdonalds" using the domain command, and found that mcdonalds.com is indeed registered. We were then given contact info for the domain, and the domain name servers that are authoritative for the domain. No match would have indicated that the domain name may be available for registration. (Of course, someone else may have submitted a registration that is in process; the domain registry usually has a turnaround time of several days.)
However, Whois contains information only for second-level organizational domains and top-level geographical domains. Usually, Whois is sufficient to find an appropriate contact if you wish to register a subdomain to a geographical or second-level organizational domain.
For additional commands you can use with Whois, type help from the Whois prompt, or whois help from a UNIX prompt.
Domain Registry
The Internic domain registration template, found at the end of this chapter (see page 301), is appropriate for registering second-level domains in the com, edu, gov, net, and org domains. In the fall of 1995 the Internic began charging a hundred dollars per domain registration in the com, org, and net domains, with an annual maintenance fee of fifty dollars starting in the third year. For other domain registrations, you should contact the domain's administrative contact - see Searching the Domain Space, discussed earlier.
Naming Hosts
When setting up a domain name server, you'll need to name the hosts within your domain. Some general guidelines follow.
Don't worry about using common names. Names can only conflict with other names within your particular subdomain; for example, there can be a host called indigo.freedonia.org, and another called indigo.geeks.org, with no conflict.
Resource Records
When configuring your name server, you'll largely be dealing with resource records, or RRs. Resource records are returned to a domain name resolver when it queries a domain name server. There are several record types that hold different kinds of information for your domain and the hosts in your domain, detailed next.
Record Types
There are fewer than a dozen common resource record types, and several that are "experimental" or obsolete; we cover the six most important record types here, which, in almost all situations, will be the only record types you'll need to be aware of. These are:
A Start of Authority (SOA) record indicates that the records held by a server for the named domain are authoritative; that is, the name server knows the best answers to questions regarding this domain.
A Start of Authority record contains the following information:
Name Server (NS) records list the name servers for a domain. A Name Server record contains the following information:
Mail Exchanger (MX) records point to hosts that can accept mail for a domain. For example, an MX record could exist for freedonia.org which would point to hail.freedonia.org; when mail is then sent to an account carl@freedonia.org, it would be routed to the machine hail.freedonia.org.
A Mail Exchanger record contains the following information:
Address (A) records convert domain names to dotted decimal IP addresses, and are the raison d'tre of a domain name server. An Address record contains the following information:
Canonical Name (CNAME) records define an alias for the official (canonical) host name, stored in an A record in your Hosts file. This can be useful when providing Internet services in which there is a common naming scheme (such as host names providing WWW and FTP service beginning with www and ftp, respectively), and you don't plan on solely dedicating a host to the named service. A Canonical Name record contains the following information:
Pointer (PTR) records are used for reverse domain name mapping - when someone has an IP address, and would like to find its host's name. This is commonly done for storing addresses in log files, and sometimes used for simple authentication. For example, ftp.apple.com will reject your connection unless your machine's IP address reverse maps into a host name.
Pointer records map host names to their IP numbers using a special domain, in-addr.arpa. The domain in-addr.arpa exists so that all IP numbers can be recorded in a separate, hierarchical space; hence it isn't necessary to search the entire domain name space to find a host with a given IP address.
The in-addr.arpa address of a host that has an IP address of 192.0.1.1 would be 1.1.0.192.in-addr.arpa. You'll notice the IP address is reversed. This is because host names are ordered from the most specific domain, on the left, to the least specific domain (closest to root) on the right, while the order of IP addresses is the opposite - from the least specific number, on the left, to the most specific number, on the right.
A Pointer record contains the following information:
MIND (Macintosh Internet Name Daemon) is a freeware domain name server for the Macintosh made available by ACME Technologies.
Configuring MIND
MIND is configured through a text file in virtually the same format as UNIX BIND, or Berkeley Internet Name Domain, the standard software package for providing domain name services on UNIX boxes. To configure MIND, you'll need to edit the Hosts file, found in the same folder as MIND, with a text editor, such as SimpleText or BBEdit. This is a sample Hosts file, which we'll walk through step by step:
; a sample hosts file ; ; origin ; the origin is appended to all domain names not ending in a "." (period) ; "@" refers to a name which is the origin ; $ORIGIN freedonia.org. ; ; start of authority information ; here, "@" can be read as "freedonia.org." ; "IN" stands for the Internet data class ; "hostmaster.freedonia.org." translates into ; the mail address "hostmaster@freedonia.org" ; @ IN SOA hail.freedonia.org. hostmaster.freedonia.org. ( 9503231 ; serial (yymmddn) 36000 ; refresh (every 10 hours) 7200 ; retry (after 2 hours) 604800 ; expire (after 1 week) 86400 ) ; minimum time to live (1 day) ; ; name servers ; the "@" is now implied ; IN NS hail.freedonia.org. IN NS ns.geeks.org. ; ; mail exchangers ; IN MX 10 mail.freedonia.org. ; ; host addresses ; hail IN A 192.0.1.1 mail IN A 192.0.1.2 nail IN A 192.0.1.3 ; ; aliases ; www IN CNAME nail.freedonia.org. ; ; files to include ; ReverseZones holds reverse information for inverse queries ; RootServers holds top level domain information $INCLUDE ReverseZones $INCLUDE RootServers
The Hosts file is formatted using a number of conventions from UNIX BIND configuration files. Generally:
Fields in records are separated by any amount of white space, and usually organized in columns for readability; the order of these fields is:
A MIND Hosts file begins with a $ORIGIN command, which sets the origin for relative domains. In the sample Hosts file, the origin is set to "freedonia.org"; any relative domain - any domain not ending in a dot (.) - will have "freedonia.org" appended to it. Any domain name in the Hosts file which does not end with a dot (.) is expanded with the origin. Domain names ending with a dot are called absolute, or fully qualified, domains, and are not expanded with the origin.
The at symbol (@) is used to denote the current origin, and we use it in our Start of Authority record, below. The @ symbol can't be used to append the origin to a domain; instead, use relative domains, as described. You could also use a relative or fully qualified domain name in place of the at symbol; its use is in no way required in any particular context.
The $INCLUDE command inserts the named file into the current file. We include two files in our Hosts file example, ReverseZones and RootServers. It wasn't necessary to include these files: we could have just placed the same information into the Hosts file directly, but administration and maintainance of the Hosts file can be made slightly easier by using the $INCLUDE command. ReverseZones holds the Pointer records for the zone; RootServers contains Address records for the name servers for the root domain.
@ IN SOA hail.freedonia.org. hostmaster.freedonia.org. ( 9503231 ; serial (yymmddn) 36000 ; refresh (every 10 hours) 7200 ; retry (after 2 hours) 604800 ; expire (after 1 week) 86400 ) ; minimum time to live (1 day)
The origin in the preceding Start Of Authority record, then, is expanded into "freedonia.org." IN is supplied for the Internet data class - since MIND uses the same file format as BIND and BIND allows data class types other than Internet, it's included here, although the other data classes aren't supported by MIND (and needn't be). Next is given the record type, followed by the name of the primary name server, followed by the e-mail address of the technical contact for this domain. For historical reasons, the first dot (.) of this field is replaced with an at sign (@) to form the e-mail address; in the case of an account that includes a dot - for example, carl.steadman@freedonia.org - this dot can be escaped with a backslash (\ character, so that the field would read carl\.steadman.freedonia. org. Following that are the serial, refresh, retry, expire, and minimum time to live fields. The serial number should be incremented every time the file is edited, and it is given in yymmddn format, where yy=year, mm=month, dd=day, and n=a per-day revision number, although any format that works for you can be used. The refresh, retry, expire, and minimum time to live values are given in seconds.
The Name Server records in the sample MIND configuration file read:
IN NS hail.freedonia.org. IN NS ns.geeks.org.
Here, the Domain Name field is implied from the SOA entry, so it doesn't need to be supplied again. If we had, the NS records would have looked like this:
@ IN NS hail.freedonia.org. @ IN NS ns.geeks.org.
which would have been equivalent to:
freedonia.org. IN NS hail.freedonia.org. freedonia.org. IN NS ns.geeks.org.
We could have also taken three more shortcuts in specifying the data in these records: we could have allowed the Class field, which holds the value IN, to be implied as well; we could have omitted the second NS, for the same reason; and we could have typed hail for the name of the first name server, in which case freedonia.org. would have been appended to hail. For the sake of readability and maintainability, however, we're taking shortcuts only in the first field, the domain name field. This is standard practice among many BIND maintainers.
The next record in the sample file is a Mail Exchanger record.
IN MX 10 mail.freedonia.org.
As with the Name Server record, the domain name for which the service is being offered is implied - we can read it as "freedonia.org." IN we can safely ignore, knowing it stands for the Internet data class and that we needn't worry about other data classes, and MX is the designation for a mail exchanger record. The next value is the preference number for this record - see the explanation of MX records, discussed earlier, for more details. Following that, and delimited by a single space - for conformance with standard BIND formatting - is the domain name of the mail server, mail.freedonia.org. which can accept mail for the domain name in the first field, freedonia.org., so that all mail sent to user@freedonia.org gets routed to mail.freedonia.org.
The next three lines in our sample file are Address records.
hail IN A 192.0.1.1 mail IN A 192.0.1.2 nail IN A 192.0.1.3
Since these follow the same format as the previous two record types, these should be fairly self-explanatory. In our first Address record, hail, which isn't fully qualified - it doesn't end in a dot - has the origin appended to it, and it is expanded to hail.freedonia.org. It's then of the Internet data class, is an Address, or A, record type, and has the Address data 192.0.1.1, which is the IP address for the host hail. The hosts mail and nail are then assigned IP addresses, as well.
We then list a canonical name for the alias www:
www IN CNAME nail.freedonia.org.Here, www is expanded into www.freedonia.org., the data class is of type Internet, and the record type is CNAME, or canonical name. We then give the canonical domain name for the www.freedonia. org. alias: nail.freedonia.org. (Once again, we could have simply typed nail and let the name expand with the origin, but, for the sake of readability and maintainability, we didn't.) This CNAME record allows us to refer to the same machine under two different names: in our example, nail may be a machine that does more than just serve Web pages, but should be known as www to the outside world for the sake of consistency with other Web sites.
Finally, two files are included with the $INCLUDE command (see the discussion of $INCLUDE, earlier) - ReverseZones and RootServers.
$INCLUDE ReverseZones $INCLUDE RootServersReverseZones has the same formatting as the sample Hosts file; it begins with its own origin and SOA record, since it uses the special in-addr.arpa. domain discussed in the section on pointer records in our description of record types. Our sample ReverseZones file looks like this:
; a sample reverse zones file ; ; origin ; the origin is appended to all domain names not ending in a "." (period) ; "@" refers to a name which is the origin ; $ORIGIN 1.0.192.in-addr.arpa. ; ; start of authority information ; here, "@" can be read as "freedonia.org." ; "IN" stands for the Internet data class ; "hostmaster.freedonia.org." translates into ; the mail address "hostmaster@freedonia.org" ; @ IN SOA hail.freedonia.org. hostmaster.freedonia.org. ( 9503231 ; serial (yymmddn) 36000 ; refresh (every 10 hours) 7200 ; retry (after 2 hours) 604800 ; expire (after 1 week) 86400 ) ; minimum time to live (1 day) ; ; pointer records ; 1 IN PTR hail.freedonia.org. 2 IN PTR mail.freedonia.org. 3 IN PTR nail.freedonia.org.As with our previous records, the 1 for the first Pointer record, not being fully qualified (not ending in a dot), is expanded by the origin into 1.1.0.192.in-addr.arpa.; IN stands for the Internet data class, PTR signifies the Pointer record type, and "hail.freedonia.org." is the name of the host to which this pointer record refers. The Pointer records for mail.freedonia.org. and nail.freedonia.org. follow the same format.
Finally, our sample RootServers file contains the following:
; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . <file>" ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC registration services ; under anonymous FTP as ; file /domain/named.root ; on server FTP.RS.INTERNIC.NET ; -OR- under Gopher at RS.INTERNIC.NET ; under menu InterNIC Registration Services (NSI) ; submenu InterNIC Registration Archives ; file named.root ; ; last update: Nov 8, 1995 ; related version of root zone: 1995110800 ; ; ; formerly NS.INTERNIC.NET ; . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET ; . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; End of FileThis is from the file available from <ftp://rs.internic.net/domain/ named.root>. The RootServers file allows MIND to find answers to any query it might need to answer, by giving it the addresses of root servers, which can then point to subdomains of the root-level domain, which can then point to subdomains of those domains, and so on, until an answer is found - see Domain Name Architecture, discussed previously.
You'll note a second column we haven't been using in our MIND configuration files - the time to live value we mentioned in our discussion of the Start of Authority record type. These time to live values override any values found in the SOA record; you'll want this list of root servers never to expire, since they're needed to find any other domain, and 3600000 seconds, or three years, is comfortably considered to be forever on the Internet. You'll also note that IN is only used once, and then assumed for the rest of the records - once again, we could have done that in our sample files, but we think that the files are easier to read and maintain if the IN is explicit for each record.
QuickDNS
Men and Mice offer two DNS products for the Mac OS: QuickDNS Lite, which is covered here, and QuickDNS Pro, a full-featured DNS server that should be available by the time you read this.
QuickDNS Lite is a caching-only name server. This means it can provide only name services for entries that already exist in the domain name database; you won't be able to enter any domain name records or otherwise provide primary or secondary name services for a domain. If, however, you have a network of computers connected to the outside world through a slow link, and no name server already in place on your side of the Net connection, you can point all the local machines at a single Mac OS machine running QuickDNS Lite to take advantage of caching - storing requested records in memory of the machine running QuickDNS Lite - for the local network, instead of using only the cache for each local networked machine's MacTCP, Open Transport, or the TCP/IP stack running on non-Mac OS platforms. Although MIND will cache DNS records as well, QuickDNS Lite allows you to provide a caching name service with absolutely no configuration.
To run QuickDNS Lite, you simply need to double-click on its icon. You'll then see the QuickDNS Lite status screen, shown in Figure 9.2. Free memory is the amount of memory, in bytes, that QuickDNS Lite has available to it; when this number drops below 40000, entries are purged from the cache. Packets in and Packets out list the number of UDP packets sent in and out of QuickDNS Lite (UDP is a transport layer, like TCP, that sits atop the IP network layer). Requests in and Requests out log the number of times QuickDNS Lite talks to domain name resolvers (clients), and Replies in and Replies out record the number of times QuickDNS Lite talks to domain name servers. Replies from cache tells you how effective the caching of QuickDNS Lite is for your environment.
FIGURE 9.2 QuickDNS Status Screen.
Testing Your DNS
After setting up a domain name server, you'll normally want to ensure that it's answering queries with the proper data. We'll cover two utilities that allow you to do that: MacTCP Watcher, which runs under the Mac OS, and nslookup, available on most UNIX systems.A utility we're not covering here is Query It!, which runs under the Mac OS and handles record types beyond Address and Pointer - the extent of the record types that MacTCP Watcher will return. Because Query It! relies on MacTCP to provide domain name resolution, however, and because MacTCP doesn't appropriately handle some record types, such as Mail Exchanger, the situations in which Query It! provides truly useful output is limited.
Additionally, other utilities, such as DIG, are available under UNIX, but aren't as widely available as nslookup. And covering more than two UNIX utilities (Whois and nslookup), however briefly, in the same chapter in a book about providing Internet services via the Mac OS - even if it is the chapter on DNS - is probably bad luck.
MacTCP Watcher
MacTCP Watcher, freeware by Peter N Lewis, provides a lot of data from the MacTCP control panel. As its name would indicate, it wasn't designed to be used under Open Transport. The MacTCP Info screen is shown in Figure 9.3. The function of interest here is MacTCP Watcher's ability to perform DNS lookups, available from the DNS button or from Test DNS . . . from the File menu.
FIGURE 9.3 MacTCP Watcher Info ScreenWhen you select the DNS option, you're prompted for a domain name or IP address. If you provide a domain name, MacTCP Watcher will return the corresponding IP address; if you provide the IP address, MacTCP Watcher will return the corresponding domain name.
Some useful data, however, isn't returned, such as where MacTCP Watcher received its data from. Depending upon your situtation, this may or may not make a difference - MacTCP Watcher will query whatever name server(s) are specified in the MacTCP Control Panel (see Chapter 2 for configuration information), although you don't know whether MacTCP has gotten its answer from one of the servers listed in its Domain Name Server Information or if the query was answered by another server through a recursive query. If you're testing a single primary name server, and if the MacTCP control panel is configured to refer first to your primary name server, that usually isn't a problem, but if you need further information than Address or Pointer records, or need to know which server is producing the results returned to you, you'll want to take a look at nslookup.
nslookup
nslookup is a utility found on most UNIX machines for doing name server queries. Being a UNIX utility, you'll need to access it through Telnet using a UNIX account you have access to. If using a command-line utility for debugging purposes puts you off, you can rest assured that, in time, an nslookup-like utility will exist under the Mac OS. Until that time, however, nslookup will remain a valuable tool in the domain name administrator's toolbox, and it's very likely that others you need to work with to get your DNS up and running - the administrator of the name server providing secondary services for your domain, or your Internet Service Provider - will be using nslookup to test your configuration. Having an understanding of the utility can help you communicate with this person more effectively, and come to a resolution of any problems that may be occurring that much more quickly.
- % nslookup
- Default Server: ns.geeks.org
- Address: 199.199.123.1
The default server is the server being queried. In most cases, you'll want to set the default server to the name server you're testing. You can do this in nslookup using the server command.
- > server hail.freedonia.org.
- Default Server: hail.freedonia.org
- Address: 192.0.1.1
You'll note that we appended a dot to the end of the server name, using the fully qualified domain name; you'll get in the habit of using fully qualified domain names with nslookup, to ensure it's not appending a default domain name to your queries. Although there's a command, nodefname, that you can issue to nslookup to turn this default behavior off, it's usually just easier to append the dot yourself.
You can test name-to-address resolution with nslookup simply by typing the domain name in question and examining the output:
> nail.freedonia.org. Server: hail.freedonia.org Address: 192.0.1.1 Name: nail.freedonia.org Address: 192.0.1.3 > www.freedonia.org. Server: hail.freedonia.org Address: 192.0.1.1 Name: nail.freedonia.org Address: 192.0.1.3 Aliases: www.freedonia.orgIn our first example of name-to-address resolution, the name nail.freedonia.org resolves into the IP address 192.0.1.3. The next query is for www.freedonia.org; here, we discover that it is an alias for the host nail.freedonia.org with the IP address 192.0.1.3. To test address-to-name resolution, simply provide the address:
> 192.0.1.2 Server: hail.freedonia.org Address: 192.0.1.1 Name: mail.freedonia.org Address: 192.0.1.2You can also use nslookup to look up only certain types of records, using the set type=recordtype command. For example, to find all the mail exchanger records for freedonia.org, we can type:
> set type=mx > freedonia.org. Server: hail.freedonia.org Address: 192.0.1.1 freedonia.org preference = 10, mail exchanger = mail.freedonia.org mail.freedonia.org internet address = 192.0.1.2In the same vein, we can query for any record type, using set type=any:
> set type=any > freedonia.org. Server: hail.freedonia.org Address: 192.0.1.1 freedonia.org origin = hail.freedonia.org mail addr = hostmaster.freedonia.org serial = 9503231 refresh = 36000 (10 hours) retry = 7200 (2 hours) expire = 604800 (7 days) minimum ttl = 86400 (1 day) freedonia.org nameserver = hail.freedonia.org freedonia.org nameserver = ns.geeks.org freedonia.org preference = 10, mail exchanger = mail.freedonia.org hail.freedonia.org internet address = 192.0.1.1 mail.freedonia.org internet address = 192.0.1.2Finally, we can also use the LIST command in nslookup, ls, to list all the records for a given domain. The ls command performs a zone transfer and displays the results. To do so, we'll want to use the -d option to list all record types, so that our command becomes ls -d domainname:
> ls -d freedonia.org. [hail.freedonia.org] freedonia.org. SOA hail.freedonia.org hostmaster.freedonia.org. (9503231 36000 7200 604800 86400) hail A 192.0.1.1 mail A 192.0.1.2 nail A 192.0.1.3 www CNAME nail.freedonia.org freedonia.org. NS hail.freedonia.org freedonia.org. NS ns.geeks.org freedonia.org. MX 10 mail.freedonia.org freedonia.org. SOA hail.freedonia.org hostmaster.freedonia.org. (9503231 36000 7200 604800 86400)You can type help at an nslookup prompt to learn additional commands and parameters for nslookup.
| Table 9.1 Two-Letter Country Codes from ISO 3166 | |||
| Afghanistan | af | Albania | al |
| Algeria | dz | American Samoa | as |
| Andorra | ad | Angola | ao |
| Anguilla | ai | Antarctica | aq |
| Antigua and Barbuda | ag | Argentina | ar |
| Armenia | am | Aruba | aw |
| Australia | au | Austria | at |
| Azerbaijan | az | Bahamas | bs |
| Bahrain | bh | Bangladesh | bd |
| Barbados | bb | Belarus | by |
| Belgium | be | Belize | bz |
| Benin | bj | Bermuda | bm |
| Bhutan | bt | Bolivia | bo |
| Bosnia and Herzegovina | ba | Botswana | bw |
| Bouvet Island | bv | Brazil | br |
| British | Indian Ocean | Territory | io |
| Brunei Darussalam | bn | Bulgaria | bg |
| Burkina Faso | bf | Burundi | bi |
| Cambodia | kh | Cameroon | cm |
| Canada | ca | Cape Verde | cv |
| Cayman Islands | ky | Central African Republic | cf |
| Chad | td | Chile | cl |
| China | cn | Christmas Island | cx |
| Cocos (Keeling) Islands | cc | Colombia | co |
| Comoros | km | Congo | cg |
| Cook Islands | ck | Costa Rica | cr |
| Côte d'Ivoire | ci | Croatia (local name:Hrvatska) | hr |
| Cuba | cu | Cyprus | cy |
| Czech Republic | cz | Denmark | dk |
| Djibouti | dj | Dominica | dm |
| Dominican Republic | do | East Timor | tp |
| Ecuador | ec | Egypt | eg |
| El Salvador | sv | Equatorial Guinea | gq |
| Eritrea | er | Estonia | ee |
| Ethiopia | et | Falkland Islands (Malvinas) | fk |
| Faroe Islands | fo | Fiji | fj |
| Finland | fi | France | fr |
| France Metropolitan | fx | French Guiana | gf |
| French Polynesia | pf | French | Southern |
| Territories | tf | Gabon | ga |
| Gambia | gm | Georgia | ge |
| Germany | de | Ghana | gh |
| Gibraltar | gi | Greece | gr |
| Greenland | gl | Grenada | gd |
| Guadeloupe | gp | Guam | gu |
| Guatemala | gt | Guinea | gn |
| Guinea-Bissau | gw | Guyana | gy |
| Haiti | ht | Heard and McDonald Islands | hm |
| Honduras | hn | Hong | Kong hk |
| Hungary | hu | Iceland | is |
| India | in | Indonesia | id |
| Iran (Islamic Republic of) | ir | Iraq | iq |
| Ireland | ie | Israel | il |
| Italy | it | Jamaica | jm |
| Japan | jp | Jordan | jo |
| Kazakhstan | kz | Kenya | ke |
| Kiribati | ki | Korea Democratic People's Republic of | kp |
| Korea, Republic of | kr | Kuwait | kw |
| Kyrgyzstan | kg | Lao People's Democratic Republic | la |
| Latvia | lv | Lebanon | lb |
| Lesotho | ls | Liberia | lr |
| Libyan Arab Jamahiriya | ly | Liechtenstein | li |
| Lithuania | lt | Luxembourg | lu |
| Macau | mo | Macedonia, the Former Yugoslav Republic of | mk |
| Madagascar | mg | Malawi | mw |
| Malaysia | my | Maldives | mv |
| Mali | ml | Malta | mt |
| Marshall Islands | mh | Martinique | mq |
| Mauritania | mr | Mauritius | mu |
| Mayotte | yt | Mexico | mx |
| Micronesia, Federated States of | fm | Moldova, Republic of | md |
| Monaco | mc | Mongolia | mn |
| Montserrat | ms | Morocco | ma |
| Mozambique | mz | Myanmar | mm |
| Namibia | na | Nauru | nr |
| Nepal | np | Netherlands | nl |
| Netherlands Antilles | an | New Caledonia | nc |
| New Zealand | nz | Nicaragua | ni |
| Niger | ne | Nigeria | ng |
| Niue | nu | Norfolk | Esland nf |
| Northern Mariana Islands | mp | Norway | no |
| Oman | om | Pakistan | pk |
| Palau | pw | Panama | pa |
| Papua New Guinea | pg | Paraguay | py |
| Peru | pe | Philippines | ph |
| Pitcairn Island | pn | Poland | pl |
| Portugal | pt | Puerto Rico | pr |
| Qatar | qa | Reunion | re |
| Romania | ro | Russian Federation | ru |
| Rwanda | rw | Saint Kitts and Nevis | kn |
| Saint Lucia | lc | Saint Vincent and the Grenadines | vc |
| Samoa | ws | San Marino | sm |
| São Tome and Principe Islands | st | Saudi Arabia | sa |
| Senegal | sn | Seychelles | sc |
| Sierra Leone | sl | Singapore | sg |
| Slovakia (Slovak Republic) | sk | Slovenia | si |
| Solomon Islands | sb | Somalia | so |
| South Africa | za | South Georgia and the South Sandwich Islands | gs |
| Spain | es | Sri Lanka | lk |
| St. Helena | sh | St. Pierre and Miquelon | pm |
| Sudan | sd | Suriname | sr |
| Svalbard and Jan Mayen Islands | sj | Swaziland | sz |
| Sweden | se | Switzerland | ch |
| Syrian Arab Republic | sy | Taiwan, Province of China | tw |
| Tajikistan | tj | Tanzania, United Republic of | tz |
| Thailand | th | Togo | tg |
| Tokelau | tk | Tonga | to |
| Trinidad and Tobago | tt | Tunisia | tn |
| Turkey | tr | Turkmenistan | tm |
| Turks and Caicos Islands | tc | Tuvalu | tv |
| Uganda | ug | Ukraine | ua |
| United Arab Emirates | ae | United Kingdom | gb |
| United States | us | United States Minor Outlying Islands | um |
| Uruguay | uy | Uzbekistan | uz |
| Vanuatu | vu | Vatican City State (Holy See) | va |
| Venezuela | ve | Vietnam | vn |
| Virgin Islands (British) | vg | Virgin Islands (U.S.) | vi |
| Wallis and Futuna Islands | wf | Western Sahara | eh |
| Yemen | ye | Yugoslavia | yu |
| Zaire | zr | Zambia | zm |
| Zimbabwe | zw | ||
The Internic makes a domain registration template available at ftp://rs.internic.net/templates/domain-template.txt.
