 | Chapter 3 |  |
| Chapter 3 | |
Contents:
Getting BIND
Choosing a Domain Name
"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 a domain, you may need to get the BIND software. Usually, it's included as a standard part of most UNIX-based operating systems. Occasionally, however, you'll need to seek out a version for a more obscure operating system, or you'll want the current version with all the latest functionality.
Once you've got BIND, you need to decide on a domain name - which may not be quite as easy as it sounds, because it entails finding an appropriate parent domain in the Internet name space. That decided, you need to contact the administrators of the parent domain of the domain name you've chosen.
One thing at a time, though. Let's talk about where to get BIND.
If you plan to set up your own domain and run name servers for it, you'll need the BIND software first. Even if you're planning on having someone else run your domain, it's helpful to have the software around. For example, you can use your local name server to test your data files before giving them to your remote domain administrator.
Most commercial UNIX vendors ship BIND with the rest of their standard TCP/IP networking software. And, quite often, the networking software is 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 most up-to-date BIND source, as of this writing (the BIND 8.1.2 release), is available on the web at the Internet Software Consortium's web site, http://www.isc.org/, or via anonymous ftp from ftp.isc.org in /isc/bind/src/cur/bind-8/bind-src.tar.gz. Compiling it on most common UNIX platforms should be relatively straightforward. The ISC includes sample definitions in the top-level Makefile for most common versions of UNIX, including HP-UX, Irix, AIX, Solaris, and SunOS. We include instructions on compiling BIND 8.1.2 on Solaris 2.x as Appendix B, Compiling and Installing BIND on a Sun.
Some of you may already have a version of BIND that comes with your operating system, but you're wondering whether you really need the latest, greatest version of BIND. What does it have to offer that earlier versions of BIND don't? Here's an overview:
Arguably the most important reason to run the newest BIND is that only the most recent version is patched against most name server attacks, some of them widely known. BIND 8.1.2 is resistant to a variety of these attacks, while BIND 4.9.7 can withstand an important subset of them. Earlier versions of BIND have many well-known vulnerabilities. If you're running a name server on the Internet, we strongly recommend you run BIND 8.1.2 or at least BIND 4.9.7, or whatever the current released version is as you read this.
BIND 8.1.2 supports access lists on queries, zone transfers, and dynamic updates. BIND 4.9 servers supported access lists on queries and zone transfers. Earlier versions of BIND didn't support access lists at all. Certain name servers, particularly those running on bastion hosts or other security-critical hosts, may require these features.
We cover these features in Chapter 10, Advanced Features and Security.
BIND 8.1.2 supports 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. BIND 4 servers don't support Dynamic Update.
We cover Dynamic Update in Chapter 10.
BIND 8.1.2 supports zone change notification, which allows the primary master name server for a zone to notify the zone's slaves when the serial number has incremented. BIND 4 servers don't support NOTIFY.
We describe NOTIFY in Chapter 10.
BIND 8's configuration syntax is completely different from BIND 4's. While the new configuration syntax is more flexible and more powerful, it will also require learning a brand-new system for configuring BIND. But then, you have this book to help you through that.
We introduce the BIND 8 configuration syntax in Chapter 4, Setting Up BIND, and describe it throughout the rest of the book.
If, after reading through this list, you're convinced you need BIND 8's features, and a BIND 8 server doesn't come with your operating system, download the source code and build your own.
Instructions on how to port BIND to every other 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.[1] The bind-workers mailing list, [email protected], used by folks testing the new versions of BIND 8 code, is also an excellent place to turn. The folks who read and contribute to the BIND lists can be enormously helpful in your porting efforts. Be sure to ask whether the port you're after has already been done - you may be pleasantly surprised. Also, take a look at the BIND 8 errata page at http://www.isc.org/bind8/errata/ for notes specific to your operating system, and check Andras Salamon's DNS Resource Directory for pre-compiled BIND software. The directory currently has a short list of pre-compiled binaries at http://www.dns.net/dnsrd/bind.html.
[1] 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 him or her to add your electronic mail address 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 workers mailing list's administrator by sending mail to [email protected].
Another mailing list you might be interested in is the namedroppers list. Folks on the namedroppers mailing list usually discuss DNS issues, rather than BIND-specific problems. For example, a discussion of extensions to the DNS protocol or proposed DNS record types would probably take place on namedroppers instead of the BIND mailing list. Avoid sending the same message to more than one of these mailing lists; many people are on more than one.
The address for the namedroppers mailing list is [email protected], and it is gatewayed into the Internet newsgroup comp.protocols.tcp-ip.domains. To join the namedroppers mailing list, send mail to [email protected] with the text "subscribe namedroppers" as the body of the message. The InterNIC also provides a web-based front end for subscribing at http://rs.internic.net/cgi-bin/lwgate/NAMEDROPPERS/.
You'll notice we gave you a number of domain names of hosts that have ftpable software, and the mailing lists we mentioned include domain names. That 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 DNS up?
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 name server to find the information instead. As long as your host has Internet connectivity and the nslookup program, you can retrieve information from the Internet name space. To look up the IP address for ftp.isc.org, for example, you could use:
%nslookup ftp.isc.org. 207.69.188.185
This instructs nslookup to query the name server running on the host at IP address 207.69.188.185 to find the IP address for ftp.isc.org, and should produce output like:
Server: ns1.mindspring.com Address: 207.69.188.185 Name: pub1.pa.vix.com Address: 204.152.184.33 Aliases: ftp.isc.org
Now you can ftp to ftp.isc.org's IP address, 204.152.184.33.
How did we know that the host at IP address 207.69.188.185 runs a name server? Our ISP, Mindspring, told us - it's one of their name servers. If your ISP provides name servers for its customers' use (and most do), use one of them. If your ISP doesn't provide name servers (shame on them!), you can temporarily use one of the name servers listed in this book. As long as you only use it 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 name server permanently.
Of course, if you already have access to a host with Internet connectivity and DNS configured, you can use it to ftp the stuff you need.
Once you've got a working version of BIND, you're ready to start thinking about your domain name.
|  | |
| 2.7 Caching |  | 3.2 Choosing a Domain Name |