Tải bản đầy đủ
[Chapter 4] 4.5 Other Services

[Chapter 4] 4.5 Other Services

Tải bản đầy đủ

[Chapter 4] 4.5 Other Services

TCP/IP provides the tools you need to create a reliable, flexible electronic mail system. Servers are
one of the tools that improve reliability. It is possible to create a peer-to-peer email network in which
every end system directly sends and receives its own mail. However, relying on every system to
deliver and collect the mail requires that every system be properly administered and consistently up
and running. This isn't practical, because many small systems are offline for large portions of the day.
Most networks use servers so that only a few systems need to be properly configured and operational
for the mail to go through.
The terminology that describes email servers is confusing because all of the server functions usually
occur in one computer, and all of the terms are used interchangeably to refer to that system. In this
text we differentiate between these functions, but we expect you will do all of these tasks on one
UNIX system running sendmail. We use these terms in the following manner:
Mail server
The mail server collects incoming mail for other computers on the network. It supports
interactive logins as well as POP or IMAP so that users can read their mail as they see fit.
Mail relay
A mail relay is a host that forwards mail between internal systems and from internal systems to
remote hosts. Mail relays allow internal systems to have simple mail configurations because
only the relay host needs to have software to handle special mail addressing schemes and
aliases.
Mail gateway
A mail gateway is a system that forwards email between dissimilar systems. You don't need a
gateway to go from one Internet host to another because both systems use SMTP. You do need
a gateway to go from SMTP to X.400 or to a proprietary mailer. In a pure TCP/IP network, this
function is not needed.
The mail server is the most important component of a reliable system because it eliminates reliance on
the user's system. A centrally controlled, professionally operated server collects the mail regardless of
whether or not the end system is operational.
The relay host also contributes to the reliability of the email system. If mail cannot be immediately
delivered by the relay host, it is queued and processed later. An end system also queues mail, but if it
is shut down no attempts can be made to deliver queued mail until the system is back online. The mail
server and the mail relay are operated 24 hours a day.
The design of most TCP/IP email networks is based on the following guidelines:



Use a mail server to collect mail, and POP or IMAP to deliver the mail.
Use a mail relay host to forward mail. Implement a simplified email address scheme on the
relay host.

file:///C|/mynapster/Downloads/warez/tcpip/ch04_05.htm (2 of 3) [2001-10-15 09:17:58]

[Chapter 4] 4.5 Other Services




Standardize on TCP/IP and SMTP. Users who insist on using a proprietary email system
should be responsible for obtaining and configuring an SMTP mail gateway for that system in
order to connect to your TCP/IP email network.
Standardize on MIME for binary attachments. Avoid proprietary attachment schemes; they just
cause confusion when the users of Brand X email cannot read attachments received from
Brand Y.

For their client configurations, provide the users with the hostname and IP address of the mail server
and the mail relay. The mail server will also require a username and password for each person.

Previous: 4.4 Planning
Naming Service
4.4 Planning Naming Service

TCP/IP Network
Administration
Book Index

Next: 4.6 Informing the
Users
4.6 Informing the Users

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch04_05.htm (3 of 3) [2001-10-15 09:17:58]

file:///C|/mynapster/Downloads/warez/tcpip/ch04_04.htm

Previous: 4.3 Planning
Routing

Chapter 4
Getting Started

Next: 4.5 Other Services

4.4 Planning Naming Service
To make your network user-friendly, you need to provide a service to convert hostnames into IP
addresses. Domain name service (DNS) and the host table, explained in Chapter 3, perform this
function. You should plan to use both.
To configure her computer, a network user needs to know the domain name, her system's hostname,
and the hostname and address of at least one name server. The network administrator provides this
information.

4.4.1 Obtaining a Domain Name
The first item you need for domain name service is a domain name. You can obtain an official domain
name from the InterNIC. Your ISP may be willing to do this for you or to assign you a name within its
domain; however, it is likely that you will have to apply for a domain name yourself. You can
download the application from ftp://rs.internic.net/templates/domain-template.txt.
Pre-select a domain name and have your primary domain name server up and running before you
attempt to register the domain name. Use whois as described in Chapter 13, Internet Information
Resources , to see if the name you want is in use. Double-check with nslookup as described in
Chapter 8, Configuring DNS Name Service . When you are reasonably sure the domain name is still
available, start your primary name server running. If you don't want to run your own server, ask your
ISP if they offer this service. If they don't, you must either find a new ISP that does, or run the service
yourself.
Having the primary server up and running doesn't mean that your entire domain must be fully
operational, but it does mean that a server must be running to respond to basic queries. When asked,
the server should answer that it is the name server for your domain. Configure the primary server as
described in Chapter 8. Test it with nslookup. Once you are sure that it at least answers queries about
itself, register the domain name.
Submit the domain name application form via email to hostmaster@internic.net with a subject line
containing the words "NEW DOMAIN" followed by the name of your domain. For example,
assuming the completed template is stored in the file domain.application on a Solaris system, the
file:///C|/mynapster/Downloads/warez/tcpip/ch04_04.htm (1 of 4) [2001-10-15 09:17:59]

file:///C|/mynapster/Downloads/warez/tcpip/ch04_04.htm

following command might be used to mail it to the InterNIC for a domain named nuts.com:
% Mail hostmaster@internic.net
Subject: NEW DOMAIN nuts.com
~r domain.application
"domain.application" 49/2732
^D
EOT
In response to your email, you receive a reply that contains a tracking number that you use to monitor
the status of your domain registration.
Use the domain name registration form to change or delete your existing domain name registration.
Just fill in the form with the corrected information and mail it to hostmaster@internic.net with a
subject line that contains either "MODIFY DOMAIN" or "REMOVE DOMAIN", as appropriate,
followed by your domain name. In the very first field of the application form, item 0, ask for the type
of registration action: either New ("N"), Modify ("M"), or Delete ("D"). Make sure the letter in this
field matches the action indicated on the subject line when you mail in the application.
You're required to use email to submit the domain name application. The logic behind this is that if
you don't have at least email access to the Internet, you don't need an Internet domain name. This
helps reduce the number of frivolous domain name requests, and it automates part of the registration,
further reducing the burden of handling domain name requests.
Another thing that dramatically reduces the number of frivolous domain name applications is the $100
registration fee. The registration service charges each domain $50 a year to be maintained in the
registry. The initial $100 fee covers the first two years. Question 9 asks if the InterNIC should send
the bill for the registration fee to you via email or postal mail. Answer with an "E" or a "P". If your
"bean counters" will accept an email bill, go that way. You'll get everything finished more quickly.
The application form is largely self-explanatory, but a few items require some thought. Two things
may be confusing - handles and servers. One is the request for a NIC handle. You have a NIC handle
only if you are registered in the NIC white pages. The white pages (discussed in Chapter 12) is a
directory of information about users, networks, hosts, and domains. A NIC handle is a record
identifier for this directory. A personal NIC handle for a user entry is composed of the user's initials
and perhaps a number. For example, my initials are cwh and my NIC handle is cwh3. It is unlikely
that you will have a handle unless you have contacted the NIC before. If you don't have a handle, just
leave it blank. The NIC will assign you one.
You're also asked for the names and addresses of your primary and secondary name servers. The
servers listed must be operational and connected to the Internet. [7] Provide the full domain name of
the primary server in response to question 7a; e.g. almond.nuts.com. The primary server is usually a
name server located at your site, but not always. It isn't necessary to provide your own primary server;
and if you aren't directly connected to the Internet, you can't. Even though you are not connected, you
may still want to register your domain name with the NIC if you have email access to the Internet.
file:///C|/mynapster/Downloads/warez/tcpip/ch04_04.htm (2 of 4) [2001-10-15 09:17:59]

file:///C|/mynapster/Downloads/warez/tcpip/ch04_04.htm

This allows you to use an email address that clearly identifies your organization. In order to do this,
the online service that receives your email must be able to provide your primary name service. Check
with them before you fill out this form.
[7] Chapter 8 tells you how to get a name server up and running.
The secondary server should be on a separate physical network from the primary server. Putting it on
a different network guarantees that other sites can look up information about your network, even if
access to your network is unavailable for some reason. A large organization may have multiple
independent networks, but for many sites this requirement means asking another organization to
provide a secondary name server. Who do you ask?
Again, you should turn to the people who are providing your Internet access. The network that
connects you to the Internet should provide secondary name servers as a service to its users. If they do
not, they should be able to point you to other organizations that do provide the service. It is even
possible for two organizations who are both applying for new domains to provide secondary service
for each other. In other words, you provide someone with a secondary server; in return, they provide a
secondary server for you.
Read the instructions that come with the domain application. The remainder of the form should be
easy to fill out.
4.4.1.1 Obtaining an IN-ADDR.ARPA domain
When you obtain your Internet domain name, you should also apply for an in-addr.arpa domain. This
special domain is sometimes called a reverse domain. Chapter 8 contains more information about how
the in-addr.arpa domain is set up and used, but basically the reverse domain maps numeric IP
addresses into domain names. This is the reverse of the normal process, which converts domain names
to addresses. If your ISP provides your name service or your ISP assigned you an address from a
block of its own addresses, you may not need to apply for an in-addr.arpa domain on your own.
Check with your ISP before applying. If you do need to get a reverse domain, you can obtain the
application from ftp://rs.internic.net/templates/in-addr-template.txt.

4.4.2 Choosing a Hostname
Once you have a domain name, you are responsible for assigning hostnames within that domain. You
must ensure that hostnames are unique within your domain or subdomain, in the same way that host
addresses must be unique within a network or subnet. But there is more to choosing a host name than
just making sure the name is unique. Choosing a hostname is a surprisingly emotional issue. Many
people feel very strongly about the name of their computer because they identify their computer with
themselves or their work.
RFC 1178 provides excellent guidelines on how to choose a hostname. Some key suggestions from
these guidelines are:
file:///C|/mynapster/Downloads/warez/tcpip/ch04_04.htm (3 of 4) [2001-10-15 09:17:59]

file:///C|/mynapster/Downloads/warez/tcpip/ch04_04.htm







Use real words that are short, easy to spell, and easy to remember. The point of using
hostnames instead of IP addresses is that they are easier to use. If hostnames are difficult to
spell and remember, they defeat their own purpose.
Use theme names. For example, all hosts in a group could be named after human movements:
fall, jump, hop, skip, walk, run, stagger, wiggle, stumble, trip, limp, lurch, hobble, etc. Theme
names are often easier to choose than unrestricted names, and increase the sense of community
among network users.
Avoid using project names, personal names, acronyms, numeric names, and technical jargon.
Projects and users change over time. If you name a computer after the person who is currently
using it or the project it is currently assigned to, you will probably have to rename the
computer in the future. Use nicknames to identify the server function of a system, e.g., www,
ftp, ns, etc. Nicknames can easily move between systems if the server function moves. See the
description of CNAME records in Chapter 8 for information on creating nicknames.

The only requirement for a hostname is that it be unique within its domain. But a well-chosen
hostname can save future work and make the user happier.
Name service is the most basic network service, and it is one service that you will certainly run on
your network. There are, however, other services that you should also include in your network
planning process.

Previous: 4.3 Planning
Routing
4.3 Planning Routing

TCP/IP Network
Administration
Book Index

Next: 4.5 Other Services
4.5 Other Services

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch04_04.htm (4 of 4) [2001-10-15 09:17:59]

[Chapter 4] 4.3 Planning Routing

Previous: 4.2 Basic
Information

Chapter 4
Getting Started

Next: 4.4 Planning Naming
Service

4.3 Planning Routing
In Chapter 2, we learned that hosts communicate directly only with other computers connected to the
same network. Gateways are needed to communicate with systems on other networks. If the hosts on
your network need to communicate with computers on other networks, a route through a gateway
must be defined. There are two ways to do this:




Routing can be handled by a static routing table built by the system administrator. Static
routing tables are most useful when the number of gateways is limited. Static tables do not
dynamically adjust to changing network conditions, so each change in the table is made
manually by the network administrator. Complex environments require a more flexible
approach to routing than a static routing table provides.
Routing can be handled by a dynamic routing table that responds to changing network
conditions. Dynamic routing tables are built by routing protocols. Routing protocols exchange
routing information that is used to update the routing table. Dynamic routing is used when
there are multiple gateways on a network, and is essential when more than one gateway can
reach the same destination.

Many networks use a combination of both static and dynamic routing. Some systems on the network
use static routing tables, while others run routing protocols and have dynamic tables. While it is often
appropriate for hosts to use static routing tables, gateways usually run routing protocols.
The network administrator is responsible for deciding what type of routing to use and for choosing the
default gateway for each host. Make these decisions before you start to configure your system. Here
are a few guidelines to help you plan routing. If you have:
A network with no gateways to other TCP/IP networks
No special routing configuration is required in this case. The gateways referred to in this
discussion are IP routers that interconnect TCP/IP networks. If you are not interconnecting
TCP/IP networks, you do not need an IP router. Neither a default gateway nor a routing
protocol needs to be specified.
A network with a single gateway
If you have only one gateway, don't run any routing protocols. Specify the single gateway as
file:///C|/mynapster/Downloads/warez/tcpip/ch04_03.htm (1 of 4) [2001-10-15 09:18:00]

[Chapter 4] 4.3 Planning Routing

the default gateway in a static routing table.
A network with internal gateways to other subnets and a single gateway to the world
Here there is a real choice. You can statically specify each subnet route and make the gateway
to the world your default route, or you can run a routing protocol. Decide which you want to
do based on the effort involved in maintaining a static table versus the slight overhead of
running a routing protocol on your hosts and networks. If you have more than a few hosts,
running a routing protocol is probably easiest.
A network with multiple gateways to the world
If you have multiple gateways that can reach the same destination, use a routing protocol. This
allows the gateways to adapt to network changes, giving you redundant access to the remote
networks.
Figure 4.1 shows a subnetted network with five gateways identified as A through E. A central subnet
(172.16.1.0) interconnects five other subnets. One of the subnets has a gateway to an external
network. The network administrator would probably choose to run a routing protocol on the central
subnet (172.16.1.0) and perhaps on subnet 172.16.12.0, which is attached to an external network.
Dynamic routing is appropriate on these subnets because they have multiple gateways. Without
dynamic routing, the administrator would need to update every one of these gateways manually
whenever any change occurred in the network - for example, whenever a new subnet was added. A
mistake during the manual update could disrupt network service. Running a routing protocol on these
two subnets is simpler and more reliable.
Figure 4.1: Routing and subnets

file:///C|/mynapster/Downloads/warez/tcpip/ch04_03.htm (2 of 4) [2001-10-15 09:18:00]