The Domain Name System (DNS) provides an important user service that should be used on every system connected to the Internet. The vast majority of Unix implementations of DNS are based on the Berkeley Internet Name Domain (BIND) software. BIND provides both a DNS client and a DNS server.
The BIND client issues name queries and is implemented as library routines. It is called the resolver. The resolver is configured in the resolv.conf file. All systems run the resolver.
The BIND server answers name queries and runs as a daemon. It is called named. named is configured by the named.conf file, which defines where the server gets the DNS database information and the type of server being configured. The server types are master, slave, and caching servers. Because all servers are caching servers, a single configuration often encompasses more than one server type.
The original DNS database source files are found on the master server. The DNS database file is called a zone file. The zone file is constructed from standard resource records (RRs) that are defined in RFCs. The RRs share a common structure and are used to define all DNS database information.
The DNS server can be tested using nslookup. This test tool is included with the BIND release.
In this chapter we have seen how to configure and test DNS. In the next chapter, we configure several other services.
Sunday, September 21, 2008
Local Network
The Network File System (NFS)
The Line Printer Daemon (LPD) and the Line Printer (LP) service
Windows file and print services (Samba)
The Network Information Service (NIS)
Dynamic Host Configuration Protocol (DHCP)
The Post Office Protocol (POP)
Internet Message Access Protocol (IMAP)
All of these software packages are designed to provide service to systems within your organization and are not intended to service outsiders. Essential services that are as important to external users as they are to in-house users, such as email, web service, and name service, are covered in separate chapters.
We begin our discussion of local network services with NFS, which is the server that provides file sharing on Unix networks.
The Line Printer Daemon (LPD) and the Line Printer (LP) service
Windows file and print services (Samba)
The Network Information Service (NIS)
Dynamic Host Configuration Protocol (DHCP)
The Post Office Protocol (POP)
Internet Message Access Protocol (IMAP)
All of these software packages are designed to provide service to systems within your organization and are not intended to service outsiders. Essential services that are as important to external users as they are to in-house users, such as email, web service, and name service, are covered in separate chapters.
We begin our discussion of local network services with NFS, which is the server that provides file sharing on Unix networks.
Sunday, September 14, 2008
Common Routing Configurations
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
172.16.12.0 172.16.12.15 U 1 8 dnet0
224.0.0.0 172.16.12.15 U 1 0 dnet0
127.0.0.1 127.0.0.1 UH 20 3577 lo0
The first entry is the route to network 172.16.12.0 through interface dnet0. Address 172.16.12.15 is not a remote gateway address; it is the address assigned to the dnet0 interface on this host. The other two entries do not define routes to real physical networks; both are special software conventions. 224.0.0.0 is the multicast address. This entry tells Solaris to send multicast addresses to interface 172.16.12.15 for delivery. The last entry is the loopback route to localhost created when lo0 was configured.
Look at the Flags field for these entries. All entries have the U (up) flag set, indicating that they are ready to be used, but no entry has the G (gateway) flag set. The G flag indicates that an external gateway is used. The G flag is not set because all of these routes are direct routes through local interfaces, not through external gateways.
The loopback route also has the H (host) flag set. This indicates that only one host can be reached through this route. The meaning of this flag becomes clear when you look at the Destination field for the loopback entry. It shows that the destination is a host address, not a network address. The loopback network address is 127.0.0.0. The destination address shown (127.0.0.1) is the address of localhost, an individual host. Some systems use a route to the loopback network and others use a route to the localhost, but all systems have some route for the loopback interface in the routing table.
Although this routing table has a host-specific route, most routes lead to networks. One reason network routes are used is to reduce the size of the routing table. An organization may have only one network but hundreds of hosts. The Internet has thousands of networks but millions of hosts. A routing table with a route for every host would be unmanageable.
Our sample table contains only one route to a physical network, 172.16.12.0. Therefore, this system can communicate only with hosts located on that network. The limited capability of this routing table is easily verified with the ping command. ping uses the ICMP Echo Message to force a remote host to echo a packet back to the local host. If packets can travel to and from a remote host, it indicates that the two hosts can successfully communicate.
To check the routing table on this system, first ping another host on the local network: % ping -s crab
PING crab.wrotethebook.com: 56 data bytes
64 bytes from crab.wrotethebook.com (172.16.12.1): icmp_seq=0. time=11. ms
64 bytes from crab.wrotethebook.com (172.16.12.1): icmp_seq=1. time=10. ms
^C
----crab.wrotethebook.com PING Statistics----
2 packets transmitted, 2 packets received, 0% packet loss
round-trip (ms) min/avg/max = 10/10/11
ping displays a line of output for each ICMP ECHO_RESPONSE received.When ping is interrupted, it displays some summary statistics. All of this indicates successful communication with crab. But if we check a host that is not on network 172.16.12.0, say a host at O'Reilly, the results are different.
Sun's ping would display only the message "crab is alive" if the -s option was not used. Most ping implementations do not require the -s option. % ping 207.25.98.2
sendto: Network is unreachable
Here the message "sendto: Network is unreachable" indicates that this host does not know how to send data to the network that host 207.25.98.2 is on. There are only three routes in this system's routing table, and none is a route to 207.25.98.0.
Even other subnets on books-net cannot be reached using this routing table. To demonstrate this, ping a host on another subnet. For example: % ping 172.16.1.2
sendto: Network is unreachable
These ping tests show that the minimal routing table created when the network interfaces were configured allows communication only with other hosts on the local network. If your network does not require access to any other TCP/IP networks, this may be all you need. However, if it does require access to other networks, you must add more routes to the routing table.
Wednesday, September 3, 2008
Servers Configuration
The powerful features that add to the utility and flexibility of TCP/IP also add to its complexity. TCP/IP is not as easy to configure as some other networking systems. TCP/IP requires that the configuration provide hardware, addressing, and routing information. It is designed to be independent of any specific underlying network hardware, so configuration information that can be built into the hardware in some network systems cannot be built in for TCP/IP. The information must be provided by the person responsible for the configuration. This assumes that every system is run by people who are knowledgeable enough to provide the proper information to configure the system. Unfortunately, this assumption does not always prove correct.
Configuration servers make it possible for the network administrator to control TCP/IP configuration from a central point. This relieves the end user of some of the burden of configuration and improves the quality of the information used to configure systems.
TCP/IP has used three protocols to simplify the task of configuration: RARP, BOOTP, and DHCP. We begin with RARP, the oldest and most basic of these configuration tools.
3.6.1 Reverse Address Resolution Protocol
RARP, defined in RFC 903, is a protocol that converts a physical network address into an IP address, which is the reverse of what Address Resolution Protocol (ARP) does. A Reverse Address Resolution Protocol server maps a physical address to an IP address for a client that doesn't know its own IP address. The client sends out a broadcast using the broadcast services of the physical network.The broadcast packet contains the client's physical network address and asks if any system on the network knows what IP address is associated with the address. The RARP server responds with a packet that contains the client's IP address.
Like ARP, RARP is a Network Access Layer protocol that uses physical network services residing below the Internet Layer. See the discussion of TCP/IP protocol layers.
The client knows its physical network address because it is encoded in the Ethernet interface hardware. On most systems, you can easily check the value with a command. For example, on a Solaris 8 system, the superuser can type: # ifconfig dnet0
dnet0: flags=1000843 mtu 1500 index 2
inet 172.16.12.1 netmask ffffff00 broadcast 172.16.12.255
ether 0:0:c0:dd:d4:da
The ifconfig command can set or display the configuration values for a network interface,dnet0 is the device name of the Ethernet interface. The Ethernet address is displayed . In the example, the address is 0:0:c0:dd:d4:da.
for information about the ifconfig command.
The RARP server looks up the IP address that it uses in its response to the client in the /etc/ethers file. The /etc/ethers file contains the client's Ethernet address followed by the client's hostname. For example: 2:60:8c:48:84:49 clock
0:0:c0:a1:5e:10 ring
0:80:c7:aa:a8:04 24seven
8:0:5a:1d:c0:7e limulus
8:0:69:4:6:31 arthropod
To respond to a RARP request, the server must also resolve the hostname found in the /etc/ethers file into an IP address. DNS or the hosts file is used for this task. The following hosts file entries could be used with the ethers file shown above: clock 172.16.3.10
ring 172.16.3.16
24seven 172.16.3.4
limulus 172.16.3.7
arthropod 172.16.3.21
Given these sample files, if the server receives a RARP request that contains the Ethernet address 0:80:c7:aa:a8:04, it matches it to 24seven in the /etc/ethers file. The server uses the name 24seven to look up the IP address. It then sends the IP address 172.16.3.4 out as its ARP response.
RARP is a useful tool, but it provides only the IP address. There are still several other values that need to be manually configured. Bootstrap Protocol (BOOTP) is a more flexible configuration tool that provides more values than just the IP address and can deliver those values via the network.
BOOTP is defined in RFCs 951 and 1532. The RFCs describe BOOTP as an alternative to RARP; when BOOTP is used, RARP is not needed. BOOTP, however, is a more comprehensive configuration protocol than RARP. It provides much more configuration information and has the potential to offer still more. The original specification allowed vendor extensions as a vehicle for the protocol's evolution. RFC 1048 first formalized the definition of these extensions, which have been updated over time and are currently defined in RFC 2132. BOOTP and its extensions became the basis for the Dynamic Host Configuration Protocol (DHCP). DHCP has superseded BOOTP, so DHCP is the configuration protocol that you will use on your network
Configuration servers make it possible for the network administrator to control TCP/IP configuration from a central point. This relieves the end user of some of the burden of configuration and improves the quality of the information used to configure systems.
TCP/IP has used three protocols to simplify the task of configuration: RARP, BOOTP, and DHCP. We begin with RARP, the oldest and most basic of these configuration tools.
3.6.1 Reverse Address Resolution Protocol
RARP, defined in RFC 903, is a protocol that converts a physical network address into an IP address, which is the reverse of what Address Resolution Protocol (ARP) does. A Reverse Address Resolution Protocol server maps a physical address to an IP address for a client that doesn't know its own IP address. The client sends out a broadcast using the broadcast services of the physical network.The broadcast packet contains the client's physical network address and asks if any system on the network knows what IP address is associated with the address. The RARP server responds with a packet that contains the client's IP address.
Like ARP, RARP is a Network Access Layer protocol that uses physical network services residing below the Internet Layer. See the discussion of TCP/IP protocol layers.
The client knows its physical network address because it is encoded in the Ethernet interface hardware. On most systems, you can easily check the value with a command. For example, on a Solaris 8 system, the superuser can type: # ifconfig dnet0
dnet0: flags=1000843
inet 172.16.12.1 netmask ffffff00 broadcast 172.16.12.255
ether 0:0:c0:dd:d4:da
The ifconfig command can set or display the configuration values for a network interface,dnet0 is the device name of the Ethernet interface. The Ethernet address is displayed . In the example, the address is 0:0:c0:dd:d4:da.
for information about the ifconfig command.
The RARP server looks up the IP address that it uses in its response to the client in the /etc/ethers file. The /etc/ethers file contains the client's Ethernet address followed by the client's hostname. For example: 2:60:8c:48:84:49 clock
0:0:c0:a1:5e:10 ring
0:80:c7:aa:a8:04 24seven
8:0:5a:1d:c0:7e limulus
8:0:69:4:6:31 arthropod
To respond to a RARP request, the server must also resolve the hostname found in the /etc/ethers file into an IP address. DNS or the hosts file is used for this task. The following hosts file entries could be used with the ethers file shown above: clock 172.16.3.10
ring 172.16.3.16
24seven 172.16.3.4
limulus 172.16.3.7
arthropod 172.16.3.21
Given these sample files, if the server receives a RARP request that contains the Ethernet address 0:80:c7:aa:a8:04, it matches it to 24seven in the /etc/ethers file. The server uses the name 24seven to look up the IP address. It then sends the IP address 172.16.3.4 out as its ARP response.
RARP is a useful tool, but it provides only the IP address. There are still several other values that need to be manually configured. Bootstrap Protocol (BOOTP) is a more flexible configuration tool that provides more values than just the IP address and can deliver those values via the network.
BOOTP is defined in RFCs 951 and 1532. The RFCs describe BOOTP as an alternative to RARP; when BOOTP is used, RARP is not needed. BOOTP, however, is a more comprehensive configuration protocol than RARP. It provides much more configuration information and has the potential to offer still more. The original specification allowed vendor extensions as a vehicle for the protocol's evolution. RFC 1048 first formalized the definition of these extensions, which have been updated over time and are currently defined in RFC 2132. BOOTP and its extensions became the basis for the Dynamic Host Configuration Protocol (DHCP). DHCP has superseded BOOTP, so DHCP is the configuration protocol that you will use on your network
Tuesday, September 2, 2008
DNS
DNS overcomes both major weaknesses of the host table:
DNS scales well. It doesn't rely on a single large table; it is a distributed database system that doesn't bog down as the database grows. DNS currently provides information on approximately 100,000,000 hosts, while fewer than 10,000 were listed in the host table.
DNS guarantees that new host information will be disseminated to the rest of the network as it is needed.
Information is automatically disseminated, and only to those who are interested. Here's how it works. If a DNS server receives a request for information about a host for which it has no information, it passes on the request to an authoritative server. An authoritative server is any server responsible for maintaining accurate information about the domain being queried. When the authoritative server answers, the local server saves, or caches, the answer for future use. The next time the local server receives a request for this information, it answers the request itself. The ability to control host information from an authoritative source and to automatically disseminate accurate information makes DNS superior to the host table, even for networks not connected to the Internet.
In addition to superseding the host table, DNS also replaces an earlier form of name service. Unfortunately, both the old and new services were called name service. Both are listed in the /etc/services file. In that file, the old software is assigned UDP port 42 and is called nameserver or name; DNS name service is assigned port 53 and is called domain. Naturally, there is some confusion between the two name servers. There shouldn't be—the old name service is outdated. This text discusses DNS only; when we refer to "name service," we always mean DNS.
DNS scales well. It doesn't rely on a single large table; it is a distributed database system that doesn't bog down as the database grows. DNS currently provides information on approximately 100,000,000 hosts, while fewer than 10,000 were listed in the host table.
DNS guarantees that new host information will be disseminated to the rest of the network as it is needed.
Information is automatically disseminated, and only to those who are interested. Here's how it works. If a DNS server receives a request for information about a host for which it has no information, it passes on the request to an authoritative server. An authoritative server is any server responsible for maintaining accurate information about the domain being queried. When the authoritative server answers, the local server saves, or caches, the answer for future use. The next time the local server receives a request for this information, it answers the request itself. The ability to control host information from an authoritative source and to automatically disseminate accurate information makes DNS superior to the host table, even for networks not connected to the Internet.
In addition to superseding the host table, DNS also replaces an earlier form of name service. Unfortunately, both the old and new services were called name service. Both are listed in the /etc/services file. In that file, the old software is assigned UDP port 42 and is called nameserver or name; DNS name service is assigned port 53 and is called domain. Naturally, there is some confusion between the two name servers. There shouldn't be—the old name service is outdated. This text discusses DNS only; when we refer to "name service," we always mean DNS.
Subscribe to:
Posts (Atom)
