Chapter 3. Where Do I Start?
“What do you call yourself?” the Fawn said at last. Such a soft sweet voice it had!
“I wish I knew!” thought poor Alice. She answered, rather sadly, “Nothing, just now.”
“Think again,” it said: “that won’t do.”
Alice thought, but nothing came of it. “Please, would you tell me what you call yourself?” she said timidly. “I think that might help a little.”
“I’ll tell you, if you come a little further on,” the Fawn said. “I can’t remember here.”
Now that you understand the theory behind the Domain Name System, we can attend to more practical matters. Before you set up your zones, you may need to get the BIND software. Usually, it’s standard in most Unix-based operating systems. Often, though, you’ll want to seek out a more recent version with all the latest functionality and security enhancements.
Once you have BIND, you need to decide on a domain name for your main zone; this may not be quite as easy as it sounds because it entails finding an appropriate place in the Internet namespace. With that decided, you need to contact the administrators of the parent of the zone whose domain name you’ve chosen.
One thing at a time, though. Let’s talk about where to get BIND.
Getting BIND
If you plan to set up your own zones and run nameservers for them, you first need the BIND software. Even if you plan to have someone else run the nameservers for your zones, it’s helpful to have the software around. For example, you can use a local nameserver to test your zone datafiles before giving them to your remote nameserver administrator.
Most commercial Unix vendors ship BIND with the rest of their standard TCP/IP networking software. And the networking software is usually included with the operating system, so you get BIND free. Even if the networking software is priced separately, you’ve probably already bought it, since you clearly do enough networking to need DNS, right?
If you don’t have a version of BIND for your flavor of Unix, though, or if you want the latest, greatest version, you can always get the source code. As luck would have it, it’s freely distributed. The source code for the most up-to-date versions of BIND as of this writing (the BIND 8.4.7 and 9.3.2 releases) is available via anonymous FTP from the Internet Software Consortium’s web site, ftp://ftp.isc.org, in /isc/bind/src/8.4.7/bind-src.tar.gz and /isc/bind9/9.3.2/bind-9.3.2.tar.gz, respectively. Compiling these releases on most common Unix platforms is relatively straightforward.[*] The ISC includes a list of Unix-ish operating systems that BIND is known to compile on in the file src/INSTALL (for BIND 8) and README (for BIND 9), including several versions of Linux, Unix, and even Windows. There’s also a list of other Unix-ish and not-so-Unix-ish (MPE, anyone?) operating systems BIND has supported in the past, most recent versions of BIND will probably compile on these systems without much effort. Regardless of which category your operating system falls into, we strongly recommend reading all of the sections of the file that are relevant to your OS. In Appendix C, we also include instructions for compiling BIND 8.4.7 and 9.3.2 on Linux; it’s a remarkably short appendix.
Some of you may already have a version of BIND that came with your operating system, but you’re wondering whether you need the latest, greatest version of BIND. What does it have to offer that earlier versions of BIND don’t? Here’s an overview:
- Security fixes
Arguably the most important reason to run the newest BIND is that only the most recent versions are patched against most attacks, some of them widely known. BIND 8.4.7 and BIND 9.3.2 are resistant to all well-known attacks. Earlier versions of BIND have widely known vulnerabilities. Historically, BIND 9 has a much better security track record than BIND 8 (that is, significantly fewer vulnerabilities have been found in BIND 9 nameservers).
If you’re running a nameserver on the Internet, we strongly recommend that you run BIND 9.3.2, or at the very least BIND 8.4.7, or whatever the current released version is as you read this.
- Security features
BIND 8 and BIND 9 support access lists on queries, zone transfers, and dynamic updates. BIND 9 also supports views, which allow you to run multiple, virtual nameserver configurations on a single nameserver. Certain nameservers, particularly those running on bastion hosts or other security-critical hosts, may require these features.
We cover these features in Chapter 11.
- DNS UPDATE
BIND 8 and BIND 9 support the Dynamic Update standard described in RFC 2136. This allows authorized agents to update zone data by sending special update messages to add or delete resource records. (Older versions of BIND don’t support Dynamic Update.) BIND 9 supports finer-grained authorization of dynamic updaters than BIND 8 does.
We cover Dynamic Update in Chapter 10.
- Incremental zone transfer
Current versions of BIND 8 (such as 8.4.7) and BIND 9 support incremental zone transfer, which allows slave nameservers to request just the changes to a zone from their master servers. This makes zone transfers faster and more efficient, and is particularly important for large, dynamic zones. In our experience, BIND 9’s implementation is much more robust than BIND 8’s.
If, after reading through this list and checking the appendix, you’re convinced you need BIND 8 or BIND 9’s features and neither a BIND 8 nor BIND 9 nameserver comes with your operating system, download the source code and build your own.
Handy Mailing Lists and Usenet Newsgroups
Instructions on how to port BIND to every possible version of Unix could consume another book this size, so we’ll have to refer you to the BIND users mailing list ([email protected]) or the corresponding Usenet newsgroup (comp.protocols.dns.bind) for further help.[*] The folks who read and contribute to the BIND users mailing lists can be enormously helpful in your porting efforts. Before sending mail to the list asking whether a particular port is available, be sure to check the searchable archive of the mailing list at http://www.isc.org/index.pl?/ops/lists. Also, take a look at the ISC’s BIND web page at http://www.isc.org/sw/bind for notes or links specific to your operating system.
Another mailing list you might be interested in is the namedroppers list. Folks on the namedroppers mailing list are involved in the IETF working group that develops extensions to the DNS specifications, DNSEXT. For example, the discussion of a new, proposed DNS record type would probably take place on namedroppers instead of the BIND users mailing list. For more information on DNSEXT’s charter, see http://www.ietf.org/html.charters/dnsext-charter.html.
The address for the namedroppers mailing list is [email protected]. The list is gatewayed into the Internet newsgroup comp.protocols.dns.std. To join the namedroppers mailing list, send mail to [email protected] with the text “subscribe namedroppers” as the body of the message.
Finding IP Addresses
You’ll notice that we gave you a number of domain names of hosts that have ftpable software, and the mailing lists we mentioned include domain names. This should underscore the importance of DNS: see what valuable software and advice you can get with the help of DNS? Unfortunately, it’s also something of a chicken-and-egg problem: you can’t send email to an address with a domain name in it unless you’ve got DNS set up, so how can you ask someone on the list how to set up DNS?
Well, we could give you the IP addresses for all the hosts we mentioned, but since IP addresses change often (in publishing timescales, anyway), we’ll show you how you can temporarily use someone else’s nameserver to find the information instead. As long as your host has Internet connectivity and the nslookup program, you can retrieve information from the Internet namespace.
To look up the IP address for ftp://ftp.isc.org, for example, you could use:
%nslookup ftp.isc.org. 207.69.188.185This instructs nslookup to query the nameserver running on the host at the IP address 207.69.188.185 to find the IP address for ftp://ftp.isc.org, and should produce output like:
Server: ns1.mindspring.com Address: 207.69.188.185 Name: ftp.isc.org Address: 204.152.184.110
Now you can FTP to ftp://ftp.isc.org’s IP address, 204.152.184.110.
How did we know that the host at IP address 207.69.188.185 runs a nameserver? Our ISP, Mindspring, told us—it’s one of their nameservers. If your ISP provides nameservers for its customers’ use (and most do), use one of them. If your ISP doesn’t provide nameservers (shame on them!), you can temporarily use one of the nameservers listed in this book. As long as you use it only to look up a few IP addresses or other data, the administrators probably won’t mind. It’s considered very rude, however, to point your resolver or query tool at someone else’s nameserver permanently.
Of course, if you already have access to a host with Internet connectivity and have DNS configured, you can use it to ftp what you need.
Once you have a working version of BIND, you’re ready to start thinking about your domain name.
Choosing a Domain Name
Choosing a domain name is more involved than it may sound because it entails both choosing a name and finding out who runs the parent zone. In other words, you need to find out where you fit in the Internet domain namespace, then find out who runs that particular corner of the namespace.
The first step in picking a domain name is finding where in the existing domain namespace you belong. It’s easiest to start at the top and work your way down: decide which top-level domain you belong in, then which of that top-level domain’s subdomains you fit into.
Note that in order to find out what the Internet domain namespace looks like (beyond what we’ve already told you), you’ll need access to the Internet. You don’t need access to a host that already has name service configured, but it would help a little. If you don’t have access to a host with DNS configured, you’ll have to “borrow” name service from other nameservers (as in our previous ftp://ftp.isc.org example) to get you going.
On Registrars and Registries
Before we go any further, we need to define a few terms: registry, registrar, and registration. These terms aren’t defined anywhere in the DNS specs. Instead, they apply to the way the Internet namespace is managed today.
A registry is an organization responsible for maintaining a top-level domain’s (well, zone’s, really) datafiles, which contain the delegation to each subdomain of that top-level domain. Under the current structure of the Internet, a given top-level domain can have no more than one registry. A registrar acts as an interface between customers and registries, providing registration and value-added services. Once a customer has chosen a subdomain of a top-level zone, the customer’s registrar submits to the appropriate registry the zone data necessary to delegate that subdomain to the nameservers the customer specified. The registries act, more or less, as wholesalers of delegation in their top-level zone. The registrars then act as retailers, usually reselling delegation in more than one registry.
Registration is the process by which a customer tells a registrar which nameservers to delegate a subdomain to and provides the registrar with contact and billing information. To give you some concrete examples of registries and registrars in the real world, Public Interest Registry runs the org registry. VeriSign currently acts as the registry for the com and net top-level domains. There are dozens of registrars for com, net, and org, including GoDaddy.com, Register.com, and Network Solutions. An organization called EDUCAUSE runs the registry and is the only registrar for edu. But before we get too off-track, let’s get back to our story.
Where in the World Do I Fit?
If your organization is attached to the Internet outside of the United States, you first need to decide whether you’d rather request a subdomain of one of the generic top-level domains, such as com, net, and org, or a subdomain of your country’s top-level domain. The generic top-level domains aren’t exclusively for U.S. organizations. If your company is a multi- or transnational company that doesn’t fit in any one country’s top-level domain, or if you’d simply prefer a generic top-level to your country’s top-level domain, you’re welcome to register in one. If you choose this route, skip to the section "The generic top-level domains" later in this chapter.
If you opt for a subdomain under your country’s top level, you should check whether your country’s top-level domain is registered and, if it is, what kind of structure it has. Consult our list of the current top-level domains (Appendix D) if you’re not sure what the name of your country’s top-level domain would be.
Some countries’ top-level domains, such as New Zealand’s nz, Australia’s au, and the United Kingdom’s uk, are divided organizationally into second-level domains. The names of their second-level domains, such as co or com for commercial entities, reflect organizational affiliation. Others, like France’s fr domain and Denmark’s dk domain, are divided into a multitude of subdomains managed by individual universities and companies, such as the University of St. Etienne’s domain, univ-st-etienne.fr, and the Danish Unix Users Group’s dkuug.dk. Many top-level domains have their own web sites that describe their structures. If you’re not sure of the URL for your country’s top-level domain’s web site, start at http://www.allwhois.com, a directory of links to such web sites.
If your country’s top-level domain doesn’t have a web site explaining how it’s organized, but you have some idea of which subdomain you belong in, you can use a DNS query tool such as nslookup to find the email address of the technical contact for the subdomain. (If you’re uncomfortable with our rushing headlong into nslookup without giving it a proper introduction, you might want to skim Chapter 12.)
To find out whom to ask about a particular subdomain, you’ll have to look up the corresponding zone’s start of authority (SOA) record. In each zone’s SOA record, there’s a field that contains the electronic mail address of the zone’s technical contact.[*] (The other fields in the SOA record provide general information about the zone—we’ll discuss them in more detail later.)
For example, if you’re curious about the purpose of the csiro.au subdomain, you can find out who runs it by looking up csiro.au’s SOA record:
%nslookup - 207.69.188.185>set type=soaLook for start of authority data >csiro.au. for csiro.au Server: ns1.mindspring.com Address: 207.69.188.185#53 csiro.au origin = zas.csiro.au mail addr = hostmaster.csiro.au serial = 2005072001 refresh = 10800 retry = 3600 expire = 3600000 minimum ttl = 3600 >exit
The mail addr field is the Internet address of csiro.au’s contact. To convert the address into Internet email address format, change the first “.” in the address to an “@”. So hostmaster.csiro.au becomes [email protected].[*]
whois
The whois service can also help you figure out the purpose of a given domain. Unfortunately, there are many whois servers—most good administrators of top-level domains run one—and they don’t talk to each other like nameservers do. Consequently, the first step to using whois is finding the right whois server.
One of the easiest places to start your search for the right whois server is at www.allwhois.com (Figure 3-1). We mentioned earlier that this site has a list of the web sites for each country code’s top-level domain; it also sports a unified whois search facility.
Say you were wondering what a particular subdomain of jp was for. You can click on “Japan (jp)” in the list of registries at the bottom of http://www.allwhois.com/ and jump directly to a web page that lets you query the right whois server, as shown in Figure 3-2.
Obviously, this is a useful web site if you’re looking for information about a domain outside the United States.
Once you’ve found the right web site or the right contact, you’ve probably found the registrar. Outside the United States, most domains have a single registrar. A few, though, such as Denmark’s dk and Great Britain’s co.uk and org.uk, have multiple registrars. However, most registries’ web sites contain links to their registrars, so you can use the registry’s web site as a starting point.
Back in the U.S.A.
In true cosmopolitan spirit, we covered international domains first. But what if you’re from the good ol’ U.S. of A.?
If you’re in the United States, where you belong depends mainly on what your organization does and how you’d like your domain names to look. If your organization falls into one of the following categories, you may want to consider joining us:
K-12 (kindergarten through 12th grade) schools
Community colleges and technical vocational schools
State and local government agencies
That’s because these organizations have historically registered under us, according to the namespace design documented in RFC 1480. In that design, a high school, for example, would register under k12.<state>.us, where <state> is the two-letter postal abbreviation for the state in which the school is located. A city government would register under ci.<state>.us, and a county government under co.<state>.us.
However, even these organizations don’t need to follow this rigid structure. Many K-12 schools, community colleges, and government agencies register subdomains of org or even com. The registry that runs us has relaxed the restrictions placed on us registrants, too: now you can register in either the locality space (<state>.us) or the expanded space. In the expanded space, you could register (for example) acme.us rather than acme.co.us.
Many people, however, prefer the better-known generic top-level domains. For information on registering in one of those, read on.
The generic top-level domains
As we said, there are many reasons why you might want to ask for a subdomain of one of the generic top-level domains, such as com, net, and org: you work for a multi- or transnational company, you like the fact that they’re better-known, or you just prefer the sound of your domain name with “com” on the end. Let’s go through a short example of choosing a domain name under a generic top-level domain.
Imagine you’re the network administrator for a think tank in Hopkins, Minnesota. You’ve just gotten a connection to the Internet through a commercial ISP. Your company has never had so much as a dialup link, so you’re not currently registered in the Internet namespace.
Since you’re in the United States, you have the choice of joining either us or one of the generic top-level domains. Your think tank is world-renowned, though, so you feel us wouldn’t be a good choice. A subdomain of a generic top-level domain would be best.
But which one? As of this writing, there are five open to anyone:
- biz
A new generic top-level domain
- com
The original generic top-level domain, and the best known
- info
A new generic top-level domain
- net
Originally used by networking organizations, but now open to anyone
- org
Originally used by nonprofit and other noncommercial organizations, but now open to anyone
The think tank is known as The Gizmonic Institute, so you decide gizmonics.com might be an appropriate domain name. Now you’ve got to check whether the name gizmonics.com has been taken by anyone, so you use an account you have at UMN:
%nslookupDefault Server: ns.unet.umn.edu Address: 128.101.101.101 >set type=anyLook for any records >gizmonics.com. for gizmonics.com Server: ns.unet.umn.edu Address: 128.101.101.101 gizmonics.com nameserver = ns1.11l.net gizmonics.com nameserver = ns2.11l.net
Whoops! Looks like gizmonics.com is already taken (who would have thought?) Well, gizmonic-institute.com is a little longer, but still intuitive:[*]
%nslookupDefault Server: ns.unet.umn.edu Address: 128.101.101.101 >set type=anyLook for any records >gizmonic-institute.com. for gizmonic-institute.com Server: ns.unet.umn.edu Address: 128.101.101.101 *** ns.unet.umn.edu can't find gizmonic-institute.com.: Non-existent host/domain
gizmonic-institute.com is free, so you can go on to the next step: picking a registrar.
Choosing a registrar
Choose a registrar? Welcome to the brave new world of competition! Before the spring of 1999, a single company, Network Solutions, Inc., was both the registry and sole registrar for com, net, and org, as well as edu. To register a subdomain of any of these generic top-level domains, you had to go to Network Solutions.
In June 1999, ICANN, the organization that manages the domain namespace (we mentioned ICANN in the last chapter) introduced competition to the registrar function of com, net, and org. There are now dozens of com, net, and org registrars from which you can choose. For more information, check out the InterNIC site (operated by ICANN) at http://www.internic.net/regist.html.
We won’t presume to tell you how to pick a registrar, but take a look at the price of registration, the registrar’s reputation for customer service, and any other services the registrar provides that interest you. See if you can get a nice package deal on registration and aluminum siding, for example.
Checking That Your Network Is Registered
Before proceeding, you should check whether your IP network or networks are registered. Some registrars won’t delegate a subdomain to nameservers on unregistered networks, and network registries (we’ll talk about them shortly) won’t delegate an in-addr.arpa zone that corresponds to an unregistered network.
An IP network defines a range of IP addresses. For example, the network 15/8 is made up of all IP addresses in the range 15.0.0.0 to 15.255.255.255. The network 199.10.25/24 starts at 199.10.25.0 and ends at 199.10.25.255.
The InterNIC, now operated by ICANN, was once the official source of all IP networks; they assigned all IP networks to Internet-connected networks and made sure no two address ranges overlapped. Nowadays, the InterNIC’s old role has been largely assumed by Internet service providers (ISPs), who allocate space from their own networks for customers to use. If you know your network came from your ISP, the larger network from which your network was carved is probably registered (to your ISP). You may still want to double-check that your ISP took care of registering its network, but you don’t have to (and probably can’t) do anything yourself, except nag your ISP if it didn’t register their network. Once you’ve verified its registration, you can skip the rest of this section and move on.
Tip
It’s not necessary to register RFC 1918 address space (e.g., the networks 10/8, 192.168/16). In fact, you can’t because these networks are used by so many different organizations.
If your network was assigned by the InterNIC, way back when, or you are an ISP, you should check to see whether your network is registered. Where do you go to check whether your network is registered? Why, to the same organizations that register networks, of course. Each of these organizations, called regional Internet registries, or RIRs, handle network registration in some part of the world. In North America, the American Registry of Internet Numbers (ARIN; http://www.arin.net) hands out IP address space and registers networks. In Asia and the Pacific, the Asia Pacific Network Information Center (APNIC; http://www.apnic.net) serves the same function. In Europe, it’s the RIPE Network Coordination Centre (http://www.ripe.net). And Latin America and the Caribbean are served by the Latin America and Caribbean Internet Addresses Registry (LACNIC; www.lacnic.net). Each RIR may also delegate registration authority for a region; for example, LACNIC delegates registration authority for Mexico and Brazil to registries in those countries. Be sure to check for a network registry local to your country.
If you’re not sure your network is registered, the best way to find out is to use the whois services provided by the various network registries to look for your network. Here are the URLs for each registry’s whois web page:
If you find your network isn’t registered, you need to get it registered before setting up your in-addr.arpa zones. Each registry has a different process for registering networks, but most involve money changing hands (from your hands to theirs, unfortunately).
You may find out that your network is already assigned to your ISP. If this is the case, you don’t need to register independently with the RIR.
Once all your Internet-connected hosts are on registered networks, you can register your zones.
Registering Your Zones
Different registrars have different registration policies and procedures, but most, at this point, handle registration online, through their web sites. Since you found or chose your registrar earlier in the chapter, we’ll assume you know which web site to use.
The registrar will need to know the domain names and addresses of your nameservers and enough information about you to send a bill or charge your credit card. If you’re not connected to the Internet, give the registrar the IP addresses of the Internet hosts that will act as your nameservers. Some registrars require that you already have operational nameservers for your zone. (Those that don’t may ask for an estimate of when the nameservers will be fully operational.) If that’s the case with your registrar, skip ahead to Chapter 4 and set up your nameservers. Then contact your registrar with the requisite information.
Most registrars will also ask for some information about your organization, including an administrative contact and a technical contact for your zone (who can be the same person). If your contacts aren’t already registered in the registrar’s whois database, you’ll also need to provide information to register them in whois. This includes their names, surface mail addresses, phone numbers, and electronic mail addresses. If they are already registered in whois, just specify their whois handles (unique alphanumeric IDs) in the registration.
There’s one more aspect of registering a new zone that we should mention: cost. Most registrars are commercial enterprises and charge money for registering domain names. Network Solutions, the original registrar for com, net, and org, charges $35 per year to register subdomains under the generic top-level domains. (If you already have a subdomain under com, net, or org and haven’t received a bill from Network Solutions recently, it’d be a good idea to check your contact information with whois to make sure they have a current address and phone number for you.)
If you’re directly connected to the Internet, you should also have the in-addr.arpa zones corresponding to your IP networks delegated to you.[*] For example, if your company was allocated the network 192.201.44/24, you should manage the 44.201.192.in-addr.arpa zone. This will let you control the IP address-to-name mappings for hosts on your network. Chapter 4 also explains how to set up your in-addr.arpa zones.
In the section “Checking That Your Network Is Registered,” we asked you to find the answers to several questions: is your network a slice of an ISP’s network? Is your network, or the ISP’s network that your network is part of, registered? If so, in which RIR? You’ll need these answers to get your in-addr.arpa zones.
If your network is part of a larger network registered to an ISP, you should contact the ISP to have the appropriate subdomains of its in-addr.arpa zone delegated to you. Each ISP uses a different process for setting up in-addr.arpa delegation. Your ISP’s web page is a good place to research that process. If you can’t find the information there, try looking up the SOA record for the in-addr.arpa zone that corresponds to your ISP’s network. For example, if your network is part of UUNET’s 153.35/16 network, you could look up the SOA record of 35.153.in-addr.arpa to find the email address of the technical contact for the zone.
If your network is registered directly with one of the regional Internet registries, contact it to get your in-addr.arpa zone registered. Each network registry makes information on its delegation process available on its web site.
Now that you’ve registered your zones, you’d better take some time to get your house in order. You have some nameservers to set up, and in the next chapter, we’ll show you how.
[*] Compiling early versions of BIND 9 (before 9.1.0) can be a little tricky because these versions require pthreads and many OSes sport broken pthreads implementations. BIND 9.1.0 and later can be built without pthreads by running configure—disable-threads.
[*] To ask a question on an Internet mailing list, all you need
to do is send a message to the mailing list’s address. If you’d
like to join the list, however, you have to send a message to the
list’s maintainer first, requesting that your electronic mail
address be added to the list. Don’t send this request to the list
itself; that’s considered rude. The Internet convention is that
you can reach the maintainer of a mailing list by sending mail to
list-request@domain, where
list@domain is the address
of the mailing list. So, for example, you can reach the BIND users
mailing list’s administrator by sending mail to
[email protected].
[*] The subdomain and the zone have the same domain name, but the SOA record really belongs to the zone, not the subdomain. The person at the zone’s technical contact email address may not manage the whole subdomain (there may be additional delegated subdomains beneath), but he should certainly know the purpose of the subdomain.
[*] This form of Internet mail address is a vestige of two former DNS records, MB and MG. MB (mailbox) and MG (mail group) were supposed to be DNS records specifying Internet mailboxes and mail groups (mailing lists) as subdomains of the appropriate domain. MB and MG never took off, but the address format they would have dictated is used in the SOA record, maybe for sentimental reasons.
[*] If you’re having a hard time figuring out a good domain name, many registrars’ web sites provide suggestions for free. For example, www.nameboy.com recommends various combinations of “gizmonic” and “institute,” even using rhyming words.
[a] Microsoft has said that IE 7.0 will support internationalized domain names.
[*] For information on IPv6 reverse-mapping, see Chapter 11.