Web Site Administrator's Survival Guide - Chapter 3: Establishing the Connection

Web Site Administrator's Survival Guide

Chapter 3: Establishing the Connection

Contents

• Sample Situations
• IP Addresses
• Subnets
• Obtaining Your Own IP Address
• The Future
• Talking Past Your Provider: Routing
• The Routing Table
• Default Gateways
• Routing Protocols
• routed
• Troubleshooting
• The Language of the Internet
• Host and Domain Names
• Host Names
• Domain Names
• Domain Name Types
• Registering Your Own Domain Name
• What's in a Name? Setting Up Name Services
• The hosts Table
• BIND and DNS
• Name Server Configuration
• named.boot
• Mapping Files
• The Cache File
• Resolver Configuration
• Starting the Server
• DNS Tools
• nslookup
• dig
• Connecting the Dots
• Buzzword Checklist

Establishing the Connection

Chapter 2, "Getting Connected," describes the pieces necessary to get connected to the Internet. This chapter guides you through the next step: establishing the connection. You learn about the following:

• Routing
  
  
• Internet communications protocols
  
  
• IP addresses
  
  
• Host and domain names
  
  
• BIND and DNS
  
  

Sample Situations

If you're just joining us, or if you skipped Chapter 2, you might not be aware that we are providing example situations of web site construction. The situations are realistic examples of organizations that want to set up a web site. Most likely, you'll fit into one of the situations—or at least be close to one.

At this point, each of our four administrators has chosen a connectivity option and method, and has received everything necessary to link to the Internet.

As a reminder, here are the four new sites:

• Arkham University's paleontology department
  
  
• JazzAge, Ltd., a jazz music manufacturer, producer, and distributor
  
  
• SquareNut, Inc., a small fastener distributor
  
  
• Wild Onion Internet, a start-up ISP
  
  

Check out the beginning of Chapter 2 for some background information on these organizations.

IP Addresses

Some network interface cards have a unique identification number. This six-byte value is called a physical or hardware address and is created by the manufacturer of the card. Each manufacturer has a range of numbers that it uses so that no two cards have the same physical address—just like snowflakes and fingerprints. Token Ring and Ethernet network cards have these physical addresses.

Before you can use any of the Internet protocols, each side of the connection must have a unique logical network address, which is called an IP address. These logical addresses are mapped to physical addresses in the system's Address Resolution Protocol, or ARP, table. The ARP table enables the computer to send and deliver packets to the correct physical location. Networks transfer packets of information. Inside each packet is the IP address of the sender and the destination. Without this information, delivery would not be possible. This address is a 32-bit number that not only uniquely identifies a single network interface within a host on the Internet, but also identifies the network of that host.

To accomplish this identification, the address is composed of two parts: network number and host number. The division between the parts, however, varies depending on the class of IP address. There are five classes of IP addresses in use today; they are called, simply enough, class A, class B, class C, class D, and class E. Class D is used for special networking considerations, and class E is reserved for future use; therefore they are not used commonly for Internet communications.

A class is identified by the first bits in the address. Each class reserves a certain number of bits for the network portion, and the remaining bits are for the host portion. This is how the dividing line varies. Table 3.1 shows the number of bytes available for network and host identification for classes A, B, and C.

Table 3.1. IP address class structure.

Class

Network Bytes

Host Bytes

Table 3.2 demonstrates the number of usable addresses by class.

Table 3.2. Usable IP addresses by class.

Class

Network Range

# of Usable Networks

# of Usable Hosts

Figure 3.1 illustrates the number of bits and their positions in class A, B, and C addresses.

Figure 3.1. Bit positions of class A, B, and C IP addresses.

With the network bit size varying, you can see that the total number of networks and hosts is different between all classes of addresses. As you can see, for each class—A, B, or C—there are one, two, or three bytes defining the host. It is common to place a period between each byte when referring to an IP address. This representation is called dotted quad notation.

All of the bits can be used in a network or host, with a few exceptions for each. Networks above 223 are reserved and not used. Networks 0 and 127 are also reserved and not used, but they have special meanings. Network 0 is reserved for the default route. You learn about this in detail later in the section titled "Talking Past Your Provider: Routing" later in this chapter. Network 127 is reserved for the loopback address. This special address always refers back to the calling host; it's like a built-in network address.

Two host numbers are reserved as well. If all of the bits of a host address are set to 0, this address refers to the network itself. For example, the class B network 170.137 would be referred to as 170.137.0.0. The network portion (170.137) is the first two bytes, and the host portion (0.0) is the last two bytes. All bits of the host portion are set to 0.

If all of the bits of a host address are set to 1, this signifies the broadcast address. This enables sending to all hosts on a network with one packet. Following the preceding example, to broadcast a packet to the entire 130.33.0.0, you would use the broadcast address 130.33.255.255.

Please be advised that all IP addresses used in examples (such as 170.137.0.0) are actual, assigned IP addresses in use by networks today. Do not use these addresses at your site or you might cause problems for your own network and the networks that use these numbers.

Subnets

Although the IP address format is standard, individual sites might implement what is known as a subnet. A subnet is a standard IP address that is modified to make additional networks available at the expense of hosts. By subnetting your IP address, you will gain different networks but lose host addresses.

Subnets are specified by a subnet mask, which defines the bits that are used for both the network and host portions of an address. Imagine a set of vertical blinds covering a window. When some of the slats are open, only a portion of the light gets through. A subnet mask is like a set of blinds that only lets the network portion get through. The host portion is blocked off. Remember the division between the host and network portions of the IP address? Subnetting is nothing more than moving that dividing line to the right.

For example, Table 3.3 shows the standard subnet masks for three classes of IP addresses.

Table 3.3. Standard subnet masks.

Class

Mask

As you can see, the standard subnet mask for each class blocks out, or masks, the host portion of each address class.

Subnetting class A and class B addresses is done, but not as frequently as class C subnetting. This is because class A and B addresses provide for multiple networks, whereas a Class C network is just one single network.

The most common class C subnet is known as a two-bit subnet. The subnet mask for this would be 255.255.255.192. The last value, 192, is a byte (eight bits) with the first two bits set to 1, hence the name. Figure 3.2 shows the result of a two-bit subnet on a class C IP address.

Figure 3.2. Class C subnet of two bits.

So what does this really mean, you ask? On a standard class C IP address, you'll gain three new networks. Instead of having one big network, you'll have a total of four networks. Very cool, you think? It is—but you've lost some hosts.

For each subnetwork of your class C address, you lose two hosts. This is because of that little rule stated earlier: Any host address that is set to all zeroes is a network, and any host address set to all ones is a broadcast address. So instead of losing two hosts, you lose a total of eight hosts. This is a decent trade-off if you need more networks.

For an example of a subnetted class C address and what it actually looks like, consider the IP address 199.3.187.0. This is a standard class C IP address. The owners of this address currently have two different networks of minimal hosts toward which they want to apply this IP address. They decide to go with a two-bit subnet. Their subnet mask will be 255.255.255.192. Table 3.4 shows the four network addresses and their broadcast addresses. Figure 3.3 illustrates a subnetted network.

Table 3.4. A class C subnet addressing scheme.

Network

Broadcast

Available Hosts

Figure 3.3. A subnetted class C network.

Another example is that of a class B address. Class B addresses are commonly subnetted to class C addresses. The subnet mask would be eight bits, or 255.255.255.0. This makes a class B address look and act like 254 class C networks.

Remember to use good judgment when selecting your subnet; sometimes they can cause confusion. The previous two-bit example is clean-cut and simple to understand. If you were to apply a similar subnet mask to a class B, such as a four-bit mask, you'd get 16 networks with more than 4,000 hosts on each network. Not a big deal if that's what you're after, but hosts on the same network will not necessarily share a similar IP address. Let's look at another example.

If you subnet a class B address into 16 subnets with a four-bit subnet mask, the mask is 255.255.240.0. Table 3.5 shows how the subnet lays out.

Table 3.5. A class B four-bit subnet addressing scheme.

Network

Broadcast

Available Hosts

This might look straightforward, but the scary part is that there are what appear to be 13 separate class C IP addresses that are part of the first subnet. IP addresses 170.137.1.3 and 170.137.12.44 are actually on the same subnet. Just be wary of the consequences of supporting such a subnet.

Obtaining Your Own IP Address

Obtaining an IP address is done only if your Internet Service Provider does not give you one when you begin using its service. This address has been registered to the ISP. When you stop using the ISP, the IP address still belongs to the provider.

If you plan to expand your network in the future, or you switch providers, you should have your own IP address. Switching all of the IP addresses in your network at one time is a big hassle and will probably cost an entire weekend's worth of work! You can avoid this problem by getting your own IP address; do this by applying for one from the InterNIC.

What Is the InterNIC?

The InterNIC is a consortium of sorts between AT&T and Network Solutions, Inc. This entity manages the task of assigning IP addresses and domain names to the Internet community. This activity is funded by the National Science Foundation (NSF). In the past, this service was provided for free, but there is now a charge for some services because of the immense number of domain registrations that are being requested. Check with the InterNIC for the latest prices.

The InterNIC provides registration services and database services. To reach either with FTP or telnet, use rs.internic.net for registration services or ds.internic.net for database services.

The InterNIC is on the web at https://www.internic.net.

The InterNIC has a form that you can fill out and send back to the organization by e-mail. The form is available using FTP from rs.internic.net. The following is the current form you must fill out to obtain a valid IP address:

 [URL ftp://rs.internic.net/templates/internet-number-template.txt ]  [08/95]
********************** PLEASE DO NOT REMOVE Version Number ********************
Network Version Number: 2.0
****************** Please see attached detailed instructions ******************
1a.  Approximate date of Internet
     connection.....................:
1b.  Name of Internet access
     provider (if known)............:
Technical POC
2a.  NIC handle (if known)..........:
2b.  Name (Last, First).............:
2c.  Title..........................:
2d.  Postal address.................:
2e.  Phone Number...................:
2f.  E-Mailbox......................:
3.   Network name...................:
4a.  Name of Organization...........:
4b.  Postal address of Organization.:
5.   Previously assigned addresses..:
     Explain how addresses have been
     utilized, to include:
5a.  Number of hosts.................:
5b.  Number of subnets...............:
5c.  Subnet mask.....................:
Justification
Host Information
6a.  Initially.......................:
6b.  Within 1 year...................:
Subnet Information
6c.  Initially.......................:
6d.  Within one year.................:
7a.  Number of addresses requested...:
7b.  Additional supporting
     justification...................:
If requesting 16 C's or more, you are required to submit the
network topology plan in the format of the example below:
----------------------------------------------------------------------------
Subnet#    Subnet Mask       Max   Now   1yr    Description
----------------------------------------------------------------------------
1.0        255.255.255.224    30    8     16    Network Group (use 0!)
1.1        255.255.255.224    30   17     22    Engineering
1.2        255.255.255.224    30   12     12    Manufacturing
1.3        255.255.255.224    30    5      9    Management
1.4        255.255.255.224    30   10     15    Sales
1.5        255.255.255.224    30    7      8    Finance
1.6        255.255.255.224    30    0      0    (spare)
----------------------------------------------------------------------------
           Totals            210   59     82
----------------------------------------------------------------------------
If requesting a Class B or 256 C's (/16 prefix) a network diagram
should also be included with your request.
8.  Type of network..................:

Explicit directions on what each field means and how to answer each question are given at the end of the form. If you are lost, your Internet Service Provider can answer many of the questions.

The Future

At the Internet's current rate of expansion, the InterNIC will run out of IP addresses to assign within the next five years. This has prompted calls for a new IP addressing strategy. The latest is called IPng (for IP: Next Generation), also known as IP version 6 (IPv6). The current 32-bit IP addressing system is IP version 4 (IPv4). The web page at https://playground.sun.com/pub/ipng/html/ipng-main.html is devoted to IPng.

IPng addresses are 128 bits in size instead of 32 bits, thus providing quite a bit more address space than the current system. IPng is designed to be introduced slowly and is interoperable with the current IP addressing scheme. Because the foundation of the Internet has been around for many years, it will be interesting to see the effects of this change on the Internet and its users.

Talking Past Your Provider: Routing

Now that your network interface and name server are configured, you need the capability to connect to outside networks. Usually, a single machine is your gateway to the Internet. This machine can be connected to a modem or it can use a leased line. In any case, the machine receives the Internet feed and needs to know what to do with it.

Routing is the process of pointing packets of information in the right direction. When the Internet feed hits your gateway box, there is nowhere for it to go without routing. Likewise, any traffic on your network bound for the Internet has no routes to travel. This section examines some general routing concepts.

The Routing Table

Every system that uses TCP/IP has what is known as a routing table. This table is used by the system to direct traffic. In fact, you can think of it as a traffic cop.

By default, there are a minimum of two routes in every routing table. The first one is the loopback address, 127.0.0.1. The second entry informs the system that your network interface device is the route to its own network. This entry is vital if you want to communicate with other nodes on your own local network. When your system starts up and configures your network interface device or devices, these two routes will be built for you.

On Unix systems, two programs can access and modify the routing tables; they are netstat and route, respectively. Logical equivalents exist for other operating systems. For some reason, most implementations of the route program cannot list the entire routing table. That is why netstat is needed.

The netstat option -r tells netstat to print the routing table. You can place an n after the -r if you want to stop netstat from resolving host IP addresses. This can speed up the time it takes to display the routing table if your name server is not configured or is down. Take a look at the routing tables for honey.snookums.com:

munster@honey$ netstat -rn
Routing tables
Internet:
Destination      Gateway            Flags     Refs     Use  Interface
127.0.0.1        127.0.0.1          UH          1     4566  lo0
170.137.254.0    170.137.254.3      U           0      393  we0

The routing table defines the gateways necessary to reach every destination on a network and lists the interface to use. In addition to this information, there is a flags field that defines the status of the route.

Many flags can appear in this field. The most common is the U flag, which means "up." The U flag ensures that the route is up, running, and available. Table 3.6 lists all of the available route flags.

Table 3.6. Route flags.

Flag

Meaning

You will never see most of the flags. The ones you will see the most are D, G, H, M, R, and U. Looking back to the routing table for honey, you can see that the loopback route has the flags U and H. This means that the route is up and usable, and that the destination is a single host as opposed to a network. You can also see that the route to the local network is up and usable.

You might have noticed the D flag in the preceding table. This flag is for a dynamically created route. As you've probably guessed, there are two different types of routes: static and dynamic. Both are valid routes, but it is how they were created that defines their types.

Static routes are created either at start-up by the start-up script or manually with the route command. Small and nonconnected networks utilize static routes solely to communicate. Static routes also are used when there is only one route to any one destination.

Dynamic routes are created on the fly as needed. Usually, networks that have multiple pathways to a single destination use dynamic routing. These routes are broadcast to the network with a routing protocol. Any system receiving this broadcast adjusts its routing table accordingly. This provides not only a "best" route to a destination, but automatic backup pathways to destinations if the primary route is broken. You learn about the routing protocols later in the "Routing Protocols" section of this chapter.

The proper way to read the routing table is to understand that the gateway is the path to the destination. In honey's table, you see that gateway 127.0.0.1 is the path to reach 127.0.0.1. The H flag indicates that this route is a host route, which means that the gateway only provides a pathway to reach a single host.

The second route in the table is to the local network. It says that the gateway 170.137.254.3 (honey's IP address) is the gateway to the rest of the 170.137.254.0 network. Look at Figure 3.4, which shows a portion of the snookums.com network.

Figure 3.4. The snookums.com network layout.

The network interface in honey, 170.137.254.3, is the route that any data must take to reach any other node on the 170.137.254.0 network. But what happens if your data must go to a network that is not in your routing table? In that case, you need a default gateway.

Default Gateways

The default route is the route to take when all else fails. The default route generally is associated with a default gateway. This gateway is the path to the rest of the world, as far as your machine is concerned. If a packet is addressed to a destination off of your local network, it goes to the default gateway.

In the sample network (refer back to Figure 3.4), there is a router connected to the Internet (gateway.snookums.com). A router, by nature, routes information between two different networks. It's like a black box. Forget how the router works and focus on the fact that it does work. And what a service to provide! In addition, your router might perform protocol conversion (for example, from analog to digital).

In our little network, honey would add a default route that points to gateway.snookums.com as the default gateway for the network. Using the route command, let's add a new static route:

root@honey$ route add default 170.137.254.1

Although the command names might be the same, each flavor of UNIX takes different arguments to those commands. honey runs a BSD-type UNIX. Check your man page for route instead of assuming that the preceding command will work on your system.

That's all there is to it. If you check out the routing table now, you'll see that the default route is in there:

root@honey$ netstat -rn
Routing tables
Internet:
Destination      Gateway            Flags     Refs     Use  Interface
default          170.137.254.1      UG         56    39475  we0
127.0.0.1        127.0.0.1          UH          1     4566  lo0
170.137.254.0    170.137.254.3      U           0      393  we0

Just a quick note: Some implementations of netstat do not show the word default under the Destination line. Remember the discussion of IP addresses when you learned there are two reserved networks? One of those is network 0. Network 0 is the default route. Be aware that you might see 0.0.0.0 instead of the word default.

Routing Protocols

Some networks have more than one path to reach a single destination. These networks employ what is known as dynamic routing. Dynamic routing is accomplished through the use of a routing protocol. There are many routing protocols, but RIP, or Routing Information Protocol, is the most commonly used. RIP comes standard today with most implementations of UNIX.

RIP is a broadcast protocol—routing changes are broadcast to the network every 30 seconds (usually) for anyone to receive. The changes are in the form of updates and deletions. Each change has an associated cost, or hop count. A hop is a physical jump from one network interface to another. Figure 3.5 exemplifies a four-hop route.

Figure 3.5. Hopping around.

When an RIP update is received by your system, if the hop count is lower than the hop count of the current route in your routing table, the new route is kept and the old route is removed. This enables your routing table to always know the fastest route to any destination. The program that applies these updates to your routing table is called routed, or "route daemon."

A daemon is a background UNIX process. Most UNIX daemons end with the letter d, and they are pronounced "program-dee," so named is pronounced "name-dee."

routed

routed is the process that runs and manages your routing table utilizing RIP. routed listens on a special port for RIP updates; as the packets are received, it dynamically manages your routing table.

routed also advertises the routes that you have in your routing table to the network. routed can run in a "quiet mode" that does not advertise your routes. This option is usually -q, but check your man page to be sure.

You can start routed on your system by issuing the following command:

root@honey$ routed

You probably will want to add this command to your start-up script.

Troubleshooting

Fortunately, only a few things can go wrong with RIP. The most common of all problems is the dreaded error message:

sendto: network is unreachable

This happens when your system can't route to the destination address. Figuring out why it happens is another story.

If your system can't reach another system, it will be for one or more of the following reasons:

• Your local network is down
  
  
• Your default gateway is unreachable
  
  
• Your default gateway is destroyed
  
  
• Your routing table is misconfigured
  
  
• Your link is down
  
  
• Your provider's routing table is misconfigured
  
  
• Your provider's link is down
  
  

Check each reason individually. When you've looked into and verified that each one is not occurring, your routing should be working.

Checking your link and your provider's link is easy. Call your ISP and ask if it is having any troubles. To check your link, check your router or modem. It should give you some indication of a link. Consult your router or modem manual for more information regarding how to check your link status.

You should be able to determine if your local network is down by using the ping program. ping a few hosts on your network and verify that you've received a response. If you can ping any system other than your own, your local network is up and running. Check that off the list!

ping is a program that uses the Internet Control Message Protocol, or ICMP, to see if other network nodes are alive. (You learn about ICMP in the next section.)

ping sends a packet to the destination with a time stamp on it. The destination system, upon reception, sends the packet back to the sender. The sender then calculates the difference in the time stamps and displays the information. Here is a sample Ping session:

munster@honey$ ping whitehouse.gov
PING whitehouse.gov (198.137.241.30): 56 data bytes
64 bytes from 198.137.241.30: icmp_seq=0 ttl=247 time=200.846 ms
64 bytes from 198.137.241.30: icmp_seq=1 ttl=247 time=44.288 ms
--- whitehouse.gov ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 37.132/63.727/200.846 ms

Press Ctrl+C to cancel the ping. At the end, statistics are displayed that tell you the minimum, maximum, and average time it took the packet to make the trip.

Although ping originated in UNIX, it is available with most TCP/IP implementations.

To check your default gateway, first try to ping it. If you can ping your default gateway, you've verified that it is up and running.

Secondly, you need to verify that your default gateway is routing properly. To do this, you use a program called traceroute. traceroute is a UNIX program that will actually show you each hop on a route to a destination. Here is traceroute to the White House from mars.mcs.net:

Mars:~$ traceroute whitehouse.gov
traceroute to whitehouse.gov (198.137.241.30), 30 hops max, 40 byte packets
 1  sl-chi-11-S2/2-T1.sprintlink.net (144.228.151.13)  8.062 ms  8.363 ms  5.014 ms
 2  sl-chi-3-F0/0.sprintlink.net (144.228.50.3)  5.029 ms  6.896 ms  4.847 ms
 3  sl-pen-2-H2/0-T3.sprintlink.net (144.228.10.37)  30.868 ms  32.836 ms  30.413 ms
 4  sl-pen-1-F0/0.sprintlink.net (144.228.60.1)  30.905 ms  32.75 ms  30.755 ms
 5  sl-dc-6-H2/0-T3.sprintlink.net (144.228.10.33)  33.01 ms  33.457 ms  33.168ms
 6  sl-dc-3-F0.sprintlink.net (144.228.20.3)  44.115 ms  38.162 ms  33.57 ms
 7  sl-eop-1-S0-T1.sprintlink.net (144.228.72.66)  46.171 ms  38.039 ms  36.774ms
 8  whitehouse.gov (198.137.241.30)  49.951 ms  37.441 ms  36.247 ms

As you can see, each line shows a single hop on the route to the White House. Use the traceroute program to trace a route past your default gateway. Pick a destination that would normally be reachable off of your local network. If you cannot traceroute the route, your problem is most likely in the routing table of your default gateway.

If your gateway is working properly, traceroute will show you that the packets are dying at your ISP. This can mean that your ISP's routing is not working or that its link is down. In either case, call your ISP and have it fix the problem.

If traceroute did not come with your system, you can find the source code at

ftp://ftp.uu.net

The Language of the Internet

Chapter 2 describes transmission protocols such as ATM and Frame Relay. These protocols are how the hardware that sits between the physical links talks to each other. There are other levels, or layers, of communication that occur in your connection. One of these layers is the network layer, which is responsible for communicating between two hosts. It also shields the layers above it from the underlying details of the network.

Most communication across the Internet is done with TCP/IP. Just as love is the international language, TCP/IP is the language of the Internet. It is a complex protocol composed of two parts. The lower layer of TCP/IP is IP, which stands for Internet Protocol. This layer is the foundation of all Internet connections.

On top of the IP layer sit three more important protocols. These are TCP (completing TCP/IP), UDP, and ICMP. TCP, or Transmission Control Protocol, works in conjunction with IP to provide a connection-based, reliable connection that is used to send streams of data. UDP, or User Datagram Protocol, also works in conjunction with IP but provides a potentially unreliable, connectionless protocol that can be used to send and receive packets of data. The last layer, ICMP, stands for Internet Control Message Protocol. As the name implies, this protocol is used to send control messages across the Internet. You have already learned about the ping program, which uses ICMP packets. Figure 3.6 shows how the Internet protocol suite fits into the network-layer model. There are other protocols that use IP, but they are not relevant to this discussion.

Figure 3.6. How the Internet protocols fit into the network protocol layers.

Host and Domain Names

Remembering IP addresses can be difficult (wait until IPng!). In addition to the physical and logical address of a network node, there is one last identifying piece of information: the host name. Host names free you from the burden of remembering a list of IP addresses. All you need to remember is the host name.

Just as there are two portions of an IP address—the network and the node address—there are two portions to a host name. The first portion is the local portion, which is most commonly referred to as the host name. The second portion is known as the domain name. This name refers to the site at which the host resides. The host name and domain name are referred together as a fully qualified domain name, or FQDN.

Host Names

The host name can be almost anything. It is not necessarily indicative of any particular thing, but that doesn't mean it has no meaning. Most host names are hand-picked by the system administrator and are simply nicknames. You'll find that in places where many machines are managed for use by other people (for example, in school labs), the host names are quite unimaginative, such as labsun11, xterm6, and vdt39xa. This is not always the case, but it's generally true.

Choosing a host name is like naming a pet. You don't want to call your iguana cs1x35, but derf is a cool name. Be goofy or silly or serious. It's your new pet!

When you're naming hosts, there are two general rules to follow:

• Use complete words that mean something: planets, pets, loved ones, cartoon characters, and so on. Try to use a name that is all letters with no numbers. Numbers are not completely out of the question. Just use them when necessary; for example, ftp1 or ftp3.
  
  Using abbreviations and numbers defeats the purpose to some degree. One of the major reasons host names came into being was that IP addresses (numbers) were too hard to remember.
  
  
• Never use the type of machine in the host name.
  
  If you were poking around on a network with the following hosts: fred, barney, wilma, betty, and cray1, which would you try to access?
  
  

Domain Names

A domain name identifies a group of hosts. This is synonymous with the network portion of an IP address. The Internet keeps track of all domain names through a system called the Domain Name System, or DNS. The Domain Name System is a distributed database of host names used to translate, or resolve, host names into IP addresses. Because it is distributed, there is no central storage of any data. No single server knows everything about all domains.

Domain names exist in a general hierarchy that is illustrated by Figure 3.7. At the top of the hierarchy is the unnamed root domain. Because it is unnamed, it is signified by a single period (.). This domain is served by what are called the root servers. These servers are the backbone of the DNS system. They always know which servers should be queried for each domain.

Figure 3.7. Domain hierarchy.

Under the root domain are the top-level domains (TLDs). There are currently three types of TLDs: normal domains, country domains, and special domains. Normal and country domains are identical in their layout. The special domain is not. You learn about this special domain later in the "Domain Name Types" section of this chapter.

Domain names are written from left to right, in order from specific to general. Each level is separated by a period (.). Going from the domain name type on the right and heading left, each level gets more specific. Think of it as an inverse pyramid. Figure 3.8 illustrates this point.

Figure 3.8. A domain name.

Domain Name Types

The normal domains are those that fit into an organizational structure. There are currently seven types of normal domains available. It is extremely unlikely that any new domains will be created. Table 3.7 shows the domain types and their meanings.

Table 3.7. Domain types.

Domain

Organizations Used By

For more detailed information regarding domain name types, check out RFC-1591. It is available at

https://www.internic.net/ds/dspg1intdoc.html

Instead of a three-character identifier such as com, edu, or gov, country domains consist only of a two-character country code. Some examples were shown in Figure 3.7; they are listed in Table 3.8.

Table 3.8. Country domains.

Domain

Owner

The gov and mil domains are strictly reserved for United States governmental and military agencies. Most foreign organizations use the country domains. In the United States, the us domain is used primarily by individuals, bulletin board systems, or small groups that do not fit into an organization or do not warrant a domain name of their own.

There is only one special domain at this time: the reverse, or arpa domain. This domain exists to resolve IP addresses into host names. This is the exact opposite of the purpose of normal and country domains. The arpa domain has one second-level domain: in-addr. The third, fourth, fifth, and sixth levels under the arpa domain are the IP address quadrants. For example, the IP address 170.137.254.221 would be 221.254.137.170.in-addr.arpa under this domain. With this information and a properly configured server, you can find the host name for any IP address on the Internet. You'll see how this is done in the "BIND and DNS" section later in this chapter.

Registering Your Own Domain Name

Your domain name is your own, and you must apply for it from the InterNIC. When you apply for a domain name, you choose a name that closely reflects your organization or network. It is not unlike choosing a host name for your system. This name is going to have the domain name type appended to it. For example, if your company is Snookums, Inc., you'd choose the domain name snookums.com. It is possible that someone already has your domain name. If this is the case, you might need to choose a new name or seek legal advice.

The InterNIC allows applicants to apply for a domain name regardless of their company names. It is up to the applicant to ensure that the domain name is not trademarked, or otherwise legally protected, by another entity.

The most famous case regarding this involves MTV. Adam Curry, a video jockey for the cable network, applied for and set up the domain mtv.com on behalf of MTV. After Curry quit, he kept the mtv.com site running. This did not sit well with MTV management. A bitter lawsuit ensued and Curry relinquished control of the domain. He now runs metaverse.com. Check out https://www.metaverse.com and https://www.mtv.com.. They are both interesting sites.

Another case involved McDonald's. Before McDonald's Corporation got their own domain, Josh Quittner, then a writer from Wired magazine, applied for and received the domain name mcdonalds.com. In the magazine article describing the acquisition, he asked people to send e-mail to [email protected] to suggest what he should do with the domain. McDonald's Corporation now has control of the domain so it is unclear what he actually did with it.

As a side note, Burger King quickly registered its domain after this incident. (Neither Burger King nor McDonald's has a web site at the time of this writing.)

Because of these new legal hurdles thrown at the InterNIC, it now has a policy statement regarding this issue. For the most current policy, check out the following URL:

ftp://rs.internic.net/policy/internic/internic-domain-4.txt

To see if a domain name is already taken, you can use a service called Whois that is provided by the InterNIC. telnet to whois.internic.net and follow the instructions to search existing domains. Here is a sample session looking for the name "Snookums":

SunOS UNIX 4.1 (rs0) (ttyp8)
***************************************************************************
* -- InterNIC Registration Services Center  --
*
* For wais, type:                    WAIS <search string> <return>
* For the *original* whois type:     WHOIS [search string] <return>
* For referral whois type:           RWHOIS [search string] <return>
*
* For user assistance call (703) 742-4777
# Questions/Updates on the whois database to [email protected]
* Please report system problems to [email protected]
***************************************************************************
Please be advised that use constitutes consent to monitoring
(Elec Comm Priv Act, 18 USC 2701-2711)
6/1/94
We are offering an experimental distributed whois service called referral
whois (RWhois). To find out more, look for RWhois documents, a sample
client and server under:
gopher: (rs.internic.net) InterNIC Registration Services ->
        InterNIC Registration Archives -> pub -> rwhois
anonymous ftp: (rs.internic.net) /pub/rwhois
Cmdinter Ver 1.3 Sun Nov  5 18:06:13 1995 EST
[vt220] InterNIC > whois
Connecting to the rs Database . . . . . .
Connected to the rs Database
InterNIC WHOIS Version: 1.2 Sun, 5 Nov 95 18:06:22
Whois: snookums.com
No match for "SNOOKUMS.COM".
Whois: snookums
No match for "SNOOKUMS".
Whois: quit

If you don't have telnet access, or if you prefer to use your web browser, check out https://rs.internic.net/cgi-bin/whois. This is an interface to the Whois information system. Also, many UNIX systems have a whois command that connects and performs the search for you.

The Application

Unlike the IP address application, the domain name application can be filled in using a web browser. The address is

https://rs.internic.net/cgi-bin/reg/domain-form

If you don't have access to a web browser, here is a copy of the form. The form is also available through FTP from rs.internic.net. Fill it out and e-mail it to [email protected].

 [ URL ftp://rs.internic.net/templates/domain-template.txt ]        [ 09/95 ]
******************* Please DO NOT REMOVE Version Number ********************
Domain Version Number: 2.0
**************** Please see attached detailed instructions *****************
******** Only for registrations under ROOT, COM, ORG, NET, EDU, GOV ********
0.   (N)ew (M)odify elete....:
1.   Purpose/Description........:
2.   Complete Domain Name.......:
Organization Using Domain Name
3a.  Organization Name..........:
3b.  Street Address.............:
3c.  City.......................:
3d.  State......................:
3e.  Postal Code................:
3f.  Country....................:
Administrative Contact
4a.  NIC Handle (if known)......:
4b.  Name (Last, First).........:
4c.  Organization Name..........:
4d.  Street Address.............:
4e.  City.......................:
4f.  State......................:
4g.  Postal Code................:
4h.  Country....................:
4i.  Phone Number...............:
4j.  E-Mailbox..................:
Technical Contact
5a.  NIC Handle (if known)......:
5b.  Name (Last, First).........:
5c.  Organization Name..........:
5d.  Street Address.............:
5e.  City.......................:
5f.  State......................:
5g.  Postal Code................:
5h.  Country....................:
5i.  Phone Number...............:
5j.  E-Mailbox..................:
Billing Contact
6a.  NIC Handle (if known)......:
6b.  Name (Last, First).........:
6c.  Organization Name..........:
6d.  Street Address.............:
6e.  City.......................:
6f.  State......................:
6g.  Postal Code................:
6h.  Country....................:
6i.  Phone Number...............:
6j.  E-Mailbox..................:
Primary Name Server
7a.  Primary Server Hostname....:
7b.  Primary Server Netaddress..:
Secondary Name Server(s)
8a.  Secondary Server Hostname..:
8b.  Secondary Server Netaddress:
Invoice Delivery
9.   mail (P)ostal...........:

The InterNIC now charges for commercial domain names. Until October 1, 1995, domain registration was a free service funded by the National Science Foundation. The NSF can no longer fund the InterNIC, however, so it now must charge for the service. It now costs $100 to register a domain name. This covers the cost of the domain for a two-year period. The cost for existing domains is $50 per year. For more information, check out

ftp://rs.internic.net/policy/internic/internic-domain-3.txt

Because of the current interest in the Internet, domain-name registration can take up to eight weeks to complete. Plan accordingly.

What's in a Name? Setting Up Name Services

Under each of the top-level domains of the Internet's Domain Name System, there are servers called Domain Name Servers. Each domain on the Internet is required to have two Domain Name Servers. This section will explain the fundamentals of host-name resolution and the setup of these services.

The hosts Table

The most basic of all host-name resolution mechanisms is the hosts table (or hosts file), which resides in the /etc directory of any UNIX system.

This file is nothing more than a flat file database of IP addresses and host names that can be located anywhere on the Internet, not just locally. Here is a sample hosts file:

# /etc/hosts
#
170.137.254.3     honey.snookums.com
170.137.254.4     pookie.snookums.com
198.41.0.5        rs.internic.net

When you type in a command such as ping honey.snookums.com or telnet rs.internic.net, the system looks in the hosts table to find the correct IP address. The host name is the human-readable form of the IP address. It does the computer no good to have that name, so the host table acts as a translator to convert the host name to something the computer can understand. This is similar to computer programming languages: Most languages must be compiled into machine-readable code before the computer can execute a program. Similarly, host names must be resolved to IP addresses before the computer can "talk" to their systems.

Originally, before the distributed domain name system was in place, there was a huge hosts table that was maintained by the InterNIC. It contained similar information for every machine on the Internet. This table is still maintained today, but it is not complete. It contains only a few hosts from each site, and no new records are added. You can download this file and check it out if you want; it's available from ftp://nic.ddn.mil/netinfo/hosts.txt.

The format of the hosts.txt file is different from a local /etc/hosts file. There are three types of records in this file: "NET," "HOST," and "GATEWAY." NET records define networks (170.137.0.0), HOST records define hosts (170.137.254.221), and GATEWAY records define gateways to other networks.

BIND and DNS

After users started communicating over the Internet with several hosts, their hosts table began to get large. A software package was developed at the University of California - Berkeley that is still used today: the Berkeley Internet Name Domain, or BIND.

BIND is a package of software with two components: a name server and a name resolver. The server is an actual running process that the resolver portion queries for resolutions. The resolver is not a process, but a set of library calls that are used by programs to resolve host names.

The BIND server is called named, which stands for "name daemon." named has three different operational modes: primary, secondary, and caching-only. These modes are defined by configuring the named database in different ways. named is not restricted to running only one mode at a time. It can be configured to be a primary and secondary at the same time. Let's configure named for the domain snookums.com for each of the three modes.

Just a reminder: A daemon is a background UNIX process. Most UNIX daemons end with the letter d, and they are pronounced "program-dee," so Named is pronounced "name-dee."

A primary server is the authoritative server for that domain. This server is supposed to know everything about the domain it serves. Every domain on the Internet is required to have a single primary domain.

A secondary server is a backup to the primary server. It is also considered authoritative for that domain. Part of the configuration of named involves setting expiration times. As domains expire, the secondary server (if any) rereads the domain information from its primary server to stay current.

It is possible, and encouraged, to have multiple secondary servers. These can provide extra backup in a pinch.

The final server mode, caching-only, is similar to a secondary server but is not considered authoritative. A caching-only server forwards all queries to other servers and caches the responses for later use. Entries in the cache are valid only for a certain amount of time. When this time expires, the cache entry is removed. The server is then forced to re-forward all queries. However, while a domain's data still exists in the cache, the server can respond to queries about that domain.

One final note: named can run as a primary and secondary server at the same time, although not for the same domains. For example, the primary server for snookums.com can be the secondary server for bunny.com, and vice versa.

Name Server Configuration

The named database is distributed among several files. These files are normal text files and can be created and maintained with any text editor. The first file, named.boot, is the server configuration file. This file's name can be changed and specified on the named command line.

The second file type maps host names to IP addresses. Each line contains a host name and its associated IP address.

The third file type maps IP addresses to host names (for reverse lookups).

If you have more than one network, you might want to separate your reverse mappings. A good way to do this is to use the IP network as part of the filename. For example, the rev file for 170.137.254.0 would be called rev.170.137.254, or db.170.137.254. It is entirely up to the administrator how the files are named and organized, but a little organization now can save changes and expansion from being difficult tasks.

The fourth and last file type is the cache file, which tells named the addresses of the root servers. Remember the root servers? They are the seed servers for the entire domain name system.

The database files are commonly stored in the /etc directory. But, as your network grows, you might have more than the four files. The examples here use a subdirectory called /etc/namedb to store the database files.

named.boot

named.boot is the configuration file for the server. It tells the server what mode it should operate in, which domain and IP network it serves, and where to look for the other database files. Each line of the file contains a command and the information needed to complete the command. Table 3.9 shows the commands that are supported in named.boot.

Table 3.9. named.boot commands.

Command

Action

This chapter does not cover the forwarders and slave commands because they are rarely used on web servers. Let's make a sample configuration for each of the three modes, however—starting with a primary server mode.

To configure this sample server as a primary server, the named.boot file is as follows:

;
; File:    /etc/named.boot
; Comment: DNS configuration for ns1.snookums.com
;
directory                                     /etc/namedb
primary          snookums.com                 snookums.hosts
primary          254.137.170.in-addr.arpa     db.170.137.254
primary          0.0.127.in-addr.arpa         db.127.0.0
cache            .                            named.cache

The directory statement tells the server to look for any files in the directory /etc/namedb.

The first primary statement tells the server that the file snookums.hosts is the mapping file for snookums.com. This file maps host names to IP addresses. (You learn about how to format this in the next section.) All primary statements have the same format: the primary command, the domain name, and the database filename.

The second primary statement defines an in-addr.arpa domain for network 170.137.254.0. This domain is the reverse of your normal domain—think of it as your domain's evil twin! This file enables your server and others to perform reverse host name lookups of your domain. The format for the domain portion of this command is always the IP network address in reverse with .in-addr.arpa appended to the end.

The third primary statement tells the server that the file db.127.0.0 is the reverse mapping file for the 127.0.0 network. This network is a special network that exists on every UNIX machine. It contains only one node (127.0.0.1), the loopback address. This is also an entry in your hosts table, but putting it in your named configuration will make lookups faster.

Configuring your server to be a caching-only server requires just a slight modification of the configuration file stated earlier: Simply remove the primary commands related to snookums.com and you're done! Note that the 127.0.0 network remains because you always have your loopback address.

;
; File:    /etc/named.boot
; Comment: DNS configuration for ns3.snookums.com
;
directory                                     /etc/namedb
primary          0.0.127.in-addr.arpa         db.127.0.0
cache            .                            named.cache

Now that the primary named server for snookums.com is configured, let's configure a secondary server for it. The secondary server for a domain is like a backup name server. This server has a disk copy and a copy in memory that are refreshed periodically. The configuration is similar to a primary server, but there is one extra parameter.

The secondary command requires not only the filename of the data, but also the IP address of the primary server for that domain. This is the IP address that will be polled to refresh named's cache.

;
; File:    /etc/named.boot
; Comment: DNS configuration for ns2.snookums.com
;
directory                                     /etc/namedb
secondary        snookums.com                 170.137.254.3     snookums.hosts
secondary        254.137.170.in-addr.arpa     170.137.254.3     db.170.137.254
primary          0.0.127.in-addr.arpa         db.127.0.0
cache            .                            named.cache

The first secondary command tells the server that we are the secondary server for the domain snookums.com. All of the information for that domain can be retrieved from the server at IP address 170.137.254.3. If that server is down, there is a copy of the data in the file /etc/namedb/snookums.hosts. The same goes for the second secondary command in the file, but it relates to the in-addr.arpa domain. Note that we are still the primary server for the 127.0.0 network. This is because it exists on every machine.

If the file specified on the secondary line does not exist, the server retrieves a copy of the domain and writes it to that file. If the file does exist, the server verifies its contents and updates it if it is not current. If the file is current, the server simply loads the file and does not transfer the information from the primary server. This saves time and network bandwidth.

Mapping Files

Each configured domain requires two mapping files. One file maps host names to IP addresses, and the second file maps IP addresses to host names (the reverse). These filenames should match the names they were given in your named.boot file. The preceding example used snookums.hosts and db.170.137.254.

All mapping files use the same format, which is different from the named.boot format already described and allows for more detailed identification of each node in your network. The formatting records used are called resource records, or RRs. There are seven commonly used types of RRs. (See Table 3.10.)

Table 3.10. RR types.

Type

Description

Function

Each RR has the same format:

<object> [<ttl>] [<class>] <type> <data>

• object is the host name or IP address that applies to this record. Some record types allow for this to be blank, which causes the object from the last record to be used.
  
  
• ttl is the time-to-live, which defines the amount of time, in seconds, before the record expires in a server's memory. The default value for this field is specified in the SOA record.
  
  
• class is the class of the record. The only class used by DNS systems is the IN class, which represents the "Internet" class.
  
  
• type is the type of record. (Refer back to Table 3.10.)
  
  
• data represents the data associated with the record. Each type has different data requirements.
  
  

For a more thorough description of these records and domain administration, check out RFC-1033, available from

https://www.internic.net/ds/dspg1intdoc.html.

The start of authority, or SOA, record is usually the first record in every mapping file. It designates the start of a domain, or zone. This zone ends at the next encountered SOA record. There should be only one SOA record per zone.

The SOA record has the following format:

<name>  [<ttl>]  [<class>]  SOA  <origin>  <person>  (
                           <serial>
                           <refresh>
                           <retry>
                           <expire>
                           <minimum> )

• name is the name of the domain or zone.
  
  
• origin is the host name of the machine where the primary domain file lives.
  
  
• person is the e-mail address of the person responsible for this zone. Replace the @ in the e-mail address with a period (.).
  
  
• serial is the version number of the zone file. You should increment this number any time a change is made to the file. If you do not adjust this, your changes will not be picked up by other downstream servers.
  
  
• refresh is the number of seconds between each check that a secondary server makes to a primary server to see if an update is needed. A typical refresh value is one hour, or 3600.
  
  
• retry is the number of seconds that a secondary server should retry before moving on after a failed refresh check. A typical retry value is 10 minutes, or 600.
  
  
• expire is the maximum number of seconds that data will live when a refresh has not been possible. You typically want to set this value very high because you might get cut off from the Net and you don't want your name server to lose its entire cache. Try setting it to 42 days, or 3600000.
  
  
• minimum is the minimum number of seconds to be used for all nonspecified ttl values in RRs. A typical value is one day, or 86400.
  
  

Here is the SOA record that will be used in the files for snookums.com:

@   IN   SOA     ns1.snookums.com.     root.ns1.snookums.com (
                 951106001             ; Serial Number
                 3600                  ; Refresh
                 600                   ; Retry
                 3600000               ; Expire
                 86400 )               ; Minimum

A good practice is to use the date plus a number as the serial number. This way you can track when you last changed your configuration files. To keep the serial number increasing, use the following format:

YYMMDDXXX

Where

YY is the year

MM is the month

DD is the day

XXX is the change number of that day

There might be days when you change the file five or six times; other times, it might only change once per month. This way you've got a record of when it was changed.

Now you're ready to construct your mapping files. The two files needed are the host-to-IP mapping and the IP-to-host mapping. Here is snookums.com's host-to-IP mapping file:

; File:    snookums.hosts
; Comment: Host name to IP address mapping file
@   IN   SOA     ns1.snookums.com.     root.ns1.snookums.com (
                 951106001             ; Serial Number
                 3600                  ; Refresh
                 600                   ; Retry
                 3600000               ; Expire
                 86400 )               ; Minimum
;
; Name Servers
;
     IN     NS     ns1.snookums.com
     IN     NS     ns2.snookums.com
     IN     NS     ns3.snookums.com
;
; Hosts
;
localhost     IN     A     127.0.0.1
honey         IN     A     170.137.254.3
pookie        IN     A     170.137.254.4

Here is the IP-to-host mapping file:

; File:    db.170.137.254
; Comment: IP address to host name mapping file
@   IN   SOA     ns1.snookums.com.     root.ns1.snookums.com (
                 951106001             ; Serial Number
                 3600                  ; Refresh
                 600                   ; Retry
                 3600000               ; Expire
                 86400 )               ; Minimum
;
; Name Servers
;
     IN     NS     ns1.snookums.com
     IN     NS     ns2.snookums.com
     IN     NS     ns3.snookums.com
;
; Hosts
;
3     IN     PTR     honey.snookums.com.
4     IN     PTR     pookie.snookums.com.

You can omit the domain name and just use host names in your mapping file. However, using the FQDN of each host is more readable and easier to maintain. If you do use the FQDN, you must place a period (.) at the end of each name. This is because named will try adding the domain name to any host name in the file unless it ends with a period.

The Cache File

The cache file is a list of all the known root servers. The server needs to have this list to operate properly. At start-up, the server reads the list from the cache file. It then tries to contact each server in the list in order, requesting the most current list of root servers. After one server has responded, the cached list from the cache file is replaced with the server list retrieved from the root server.

An actual cache file follows. You are welcome to use this in your own configuration. The first half consists of NS, or name server, records. If you recall, the root domain is signified by a period (.). Each name server record says that for the domain ., this is a name server. The 99999999 represents the number of seconds until each record expires. The second half of the file consists of the address records. These map host names to IP addresses. As you can see, the ttl is also set to 99999999 for these records as well.

;
; Generic DNS Cache file
;
.                   99999999 IN NS A.ROOT-SERVERS.NET.
                    99999999 IN NS B.ROOT-SERVERS.NET.
                    99999999 IN NS C.ROOT-SERVERS.NET.
                    99999999 IN NS D.ROOT-SERVERS.NET.
                    99999999 IN NS E.ROOT-SERVERS.NET.
                    99999999 IN NS F.ROOT-SERVERS.NET.
                    99999999 IN NS G.ROOT-SERVERS.NET.
                    99999999 IN NS H.ROOT-SERVERS.NET.
                    99999999 IN NS I.ROOT-SERVERS.NET.
;
A.ROOT-SERVERS.NET. 99999999 IN A 198.41.0.4
B.ROOT-SERVERS.NET. 99999999 IN A 128.9.0.107
C.ROOT-SERVERS.NET. 99999999 IN A 192.33.4.12
D.ROOT-SERVERS.NET. 99999999 IN A 128.8.10.90
E.ROOT-SERVERS.NET. 99999999 IN A 192.203.230.10
F.ROOT-SERVERS.NET. 99999999 IN A 39.13.229.241
G.ROOT-SERVERS.NET. 99999999 IN A 192.112.36.4
H.ROOT-SERVERS.NET. 99999999 IN A 128.63.2.53
I.ROOT-SERVERS.NET. 99999999 IN A 192.36.148.17

Resolver Configuration

The second part of BIND setup is configuring your resolver. The resolver is linked in with every executable that needs it. It usually comes as part of any development language in the form of a code library.

There is a file that lives in /etc called resolv.conf. This file tells the resolver libraries where to look for information. The format of this file is quite simple.

The first line in the file names the default domain for this machine. The command is

domain <domain name>

The second and subsequent lines are name server lines. The word nameserver is followed by the IP addresses of each of your name servers in the order that you would like them to be searched, as follows:

nameserver <ip address>

Using IP addresses in /etc/resolv.conf is not mandatory. However, if you use host names, ensure that the host names you use are listed in your hosts table. If your system attempts to resolve something and can not even resolve the host name in /etc/resolv.conf, you will have some trouble.

Here is the resolv.conf file for snookums.com:

domain snookums.com
nameserver 170.137.254.3
nameserver 170.137.254.4

Note that the first nameserver line points to our primary name server and the second nameserver line points to our secondary name server.

If you decide not to run named at your site, simply place the IP addresses of your ISP's name servers in this file. Your system will resolve names with your ISP.

Starting the Server

After you've configured the server and the resolver, you are ready to start the server! Generally, you'll want the server to start at boot time. Issue the following command as the root user:

root@honey# named

This starts up the server. If any problems occur, check your system log for messages.

DNS Tools

Now that your server is running, you should test your configuration. Testing is simple with a couple of tools that are widely available. One comes as part of BIND: nslookup. The other is dig. Like nslookup, dig enables you to debug your configuration, but it is more of a query tool.

There is a site on the Internet devoted to DNS. This site is called the DNS Resources Directory. There you can find RFCs, newsgroups, documentation, and tools, all relating to domain name service. The DNSRD URL is

https://www.dns.net/dnsrd

nslookup

nslookup stands for name server lookup. It enables you to look up a host name for an IP address, or vice versa. It can run in a command-line mode or an interactive mode. The command-line mode format is simple and can be written in two ways:

nslookup [host name]

or

nslookup [IP address]

Here is a sample of a successful command-line session:

munster@honey$ nslookup pookie.snookums.com
Server: honey.snookums.com
Address: 170.137.254.3
Name:   pookie.snookums.com
Address: 170.137.254.4

Here is an unsuccessful one:

munster@honey$ nslookup cuddly.snookums.com
Server: honey.snookums.com
Address: 170.137.254.3
*** honey.snookums.com can't find cuddly.snookums.com: Non-existent host/domain

Each time you run nslookup, it displays the name and address of the server that it is talking with to resolve your query.

dig

dig stands for Domain Information Groper. It enables you to query any name server for any information. The command line for dig is as follows:

dig [@server] [domain] [q-type] [q-class] {q-opt} {d-opt} [%comment]

• @server is the server to query, which defaults to the default server for the current domain.
  
  
• domain is the name for which you've asked it to query.
  
  
• q-type is the type of RRs to query for (A, ANY, MX, NS, SOA, HINFO, WKS, and so on). The default is type A.
  
  
• q-class is the class of RRs to query for (IN, ANY, and so on). The default is type IN.
  
  

With dig, you can query for individual records in your DNS configuration. nslookup has the same capabilities, but the supporting information and query times are not provided. dig is much more thorough in its query-response display. For example, let's retrieve all of the NS records for snookums.com:

munster@honey$ dig snookums.com NS
; <<>> DiG 2.1 <<>> snookums.com ns
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; Ques: 1, Ans: 2, Auth: 0, Addit: 2
;; QUESTIONS:
;;      snookums.com, type = NS, class = IN
;; ANSWERS:
snookums.com.       20871   NS      honey.snookums.com.
snookums.com.       20871   NS      pookie.snookums.com.
;; ADDITIONAL RECORDS:
honey.snookums.com.    65853   A       170.137.254.3
pookoe.snookums.com.        24481   A       170.137.254.4
;; Total query time: 11 msec
;; FROM: honey.snookums.com to SERVER: default -- 170.137.254.3
;; WHEN: Mon Nov  6 23:03:53 1995
;; MSG SIZE  sent: 26  rcvd: 104

As you can see, the answers to the query were received. In addition, the support for those answers is provided along with the time the query took to complete and the server from which it was received.

dig can be found at

ftp://ftp.is.co.za/networking/ip/dns/dig/dig.2.0.tar.Z

Connecting the Dots

After reading this chapter, you should have a good understanding of IP addresses, host services, and domain name services. You should also know if you need to apply for an IP address and how to apply for your own domain name.

Let's check with our example organizations and see what they've done about IP addresses and domain names:

• Arkham University's paleontology department doesn't need a new IP address. The university already has a class B IP address assigned to it. The department has requested an IP address from the network administrator and it is ready to go.
  
  The department also has a domain name because the rest of the university is on the Internet. Its domain, arkham.edu, has been registered for quite some time. The paleontology department has chosen the host name raptor.arkham.edu for its machine.
  
  
• JazzAge, Ltd., has had a class C IP address for some time. The company applied for it from the InterNIC. JazzAge currently has a network of UNIX machines. It did need to apply for a domain name, jazzage.com, so the company could connect to the Internet.
  
  
• SquareNut, Inc., was given an IP address from its ISP. The ISP has also applied for the domain squarenut.com from the InterNIC on the company's behalf.
  
  
• Wild Onion Internet, the start-up ISP, has been given a class C IP address by its ISP. The company has applied for the domain name onion.net from the InterNIC.
  
  

Buzzword Checklist

• cache file
  
  
• default gateway
  
  
• default route
  
  
• domain name
  
  
• Domain Name Server
  
  
• Domain Name Service
  
  
• /etc/hosts
  
  
• FQDN
  
  
• host name
  
  
• /etc/hosts
  
  
• ICMP (Internet Control Message Protocol)
  
  
• InterNIC
  
  
• IP (Internet Protocol)
  
  
• IP address
  
  
• IPng
  
  
• mapping files
  
  
• named
  
  
• named.boot
  
  
• netstat
  
  
• /etc/resolv.conf
  
  
• RIP
  
  
• route
  
  
• routed
  
  
• routing protocol
  
  
• routing table
  
  
• subnet
  
  
• TCP/IP (Transmission Control Protocol/Internet Protocol)
  
  
• UDP (User Datagram Protocol)
  
  

Comments are welcome