|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://rtm-cs.sinp.msu.ru/manual/howto/mini/Domain.html
Дата изменения: Thu May 4 20:20:02 2000 Дата индексирования: Mon Oct 1 21:23:54 2012 Кодировка: |
This is a preliminary document. I have glossed over many things which could be given in much more detail, and have probably missed important sections entirely. Any suggestions for additions, deletions, or areas where I ought to provide more or less detail are very welcome.
The most recent version of this document can be found at http://caliban.physics.utoronto.ca/neufeld/Domain.HOWTO/.
Copyright (c) by Christopher Neufeld. This document may be distributed only subject to the terms and conditions set forth in the LDP License at this location.
This is a guide to setting up your own domain of Linux machines, or mixed Linux and Windows machines, on an always-up connection with a static IP and a named domain. It is not really intended for setups which use dynamic IPs, or which are regularly disconnected from their provider for long periods of time, though some basic hints for operating such a setup are available in section Using A Dynamic IP.
With the increasing availability of permanent connections and static IPs, it's becoming easier for people and organizations to set up a real domain, with the associated Internet presence. Proper planning at the outset can reduce problems later.
Much of this document describes techniques for implementing unobtrusive security on the newly exposed network. This deals with protection from external attack, and from casual internal attack. It does not claim to provide an extremely secure setup, but is usually enough to discourage the less determined attacker.
This document is primarily directed at small organizations which have an existing network of computers, possibly with a shared dialup line, which are trying to move to a permanent, relatively high-speed connection, either to improve data transfer with the outside world, or to create a WWW or FTP site. The document is also directed at new organizations which want to skip the early stage and start out with higher speed networking and services under their own domain name.
Throughout this document, I will discuss the configuration of a newly registered domain, example.com. Note that the name example.com is reserved by the Internet Assigned Numbers Authority for use in documentation, and so will never correspond to an actual domain.
Much of the information in this document is available in other places. I have tried to distill the material relevant to the creation of a new domain. Where detail on a specific subject is lacking, you may want to consult one of the more comprehensive documents.
This document will also assume a mixed OS environment. Specifically, I will assume that some desktop machines are running some version of Microsoft Windows, while servers and the private network gateway are running Linux.
While there are arguments which can be made for many different network layouts, the requirements of many organizations can be met by putting the desktop machines and private servers on a private masqueraded subnet, and the publicly accessible machines on valid external IPs. The machines on valid external IPs will be referred to in this document as ``exposed hosts''. This leads to the following (example) topology:
+--------------+
| | +---------------+
| ISP-supplied |---------------| FTP server |
| router | | +---------------+
| | |
+--------------+ | +---------------+
|------| WWW server #1 |
| +---------------+
|
| +---------------+
|------| WWW server #2 |
| +---------------+
|
~
~
|
| +---------------+
|------| Private |
| Network |
| Gateway |
+---------------+
|
|
|
|
+------------+ | +-------------------+
| Desktop #1 |-------------------|------| Private server #1 |
+------------+ | +-------------------+
|
. -------------------|-------- .
. | .
. -------------------|-------- .
|
+------------+ | +-------------------+
| Desktop #N |-------------------|------| Private server #N |
+------------+ +-------------------+
In this example, the router provided by the ISP (Internet Service Provider), FTP server, WWW servers, and the machine labelled ``private network gateway'' all have externally visible IP numbers, while the desktop and private server machines have IP numbers allocated from RFC 1918, reserved for private use. The IP numbers you choose for use within the private network (everything below the private network gateway machine) should be chosen to be unique, not only among the hosts under your control, but should also not conflict with numbers assigned on similar private subnets at other sites or partner companies with whom you might, at some time, want to implement a virtual private network, in order to reduce confusion and reconfiguration when the networks are merged in that way. As outlined in the RFC, you can choose from any class C network from 192.168.0.* to 192.168.255.*, or any class B network from 172.16.*.* to 172.31.*.*, or the class A network 10.*.*.*. In the rest of this document I will assume that your private network (if you've chosen to create one) is on the class C network 192.168.1.*, and your private network gateway machine is at IP number 10.1.1.9, one of the IP numbers provided to you by your provider (note that this is not a valid external IP, I use it as an example only). I will also assume that there is a machine, betty.example.com, at 10.1.1.10, which will handle both www and FTP services.
Take note of the number of external IP numbers which you need for your own machines. You will need one IP number for each machine which lies outside the private network gateway, plus one for the gateway itself. This count does not include any IP numbers which may be taken by routers, broadcast addresses, and so on. You should ask your provider for a block of addresses large enough to mount the given number of machines. For example, in my office network, of the 8 IP numbers allocated from the ISP, three were not usable by my computers, leaving enough IP numbers for four machines outside the gateway, plus the gateway itself.
This network topology is not correct for everybody, but it is a reasonable starting point for many configurations which don't have special needs. The advantages of this configuration include:
Some of the potential disadvantages of such a configuration are:
You should consider these points in planning your network topology, and decide if a fully visible network is more appropriate for your situation. In the rest of this document I will assume that you have configured your network as shown above. If you have chosen to have a fully visible network, some details will differ, and I will try to point out such differences in this document.
As a special case, if you do not need any external servers, the ISP-supplied router can be attached directly to your external interface on the private network gateway machine, rather than with a hub.
As with anything, shop around. Determine which services are available in your area, as well as the costs associated with those services. Not all locations are wired to accept DSL, and some locations may not be suitable for wireless connections due to constraints of the landscape, architecture, or environment. Be prepared to provide the street address of the location where your hookup will be installed, as DSL speeds are strongly dependent on your distance from the switch, and ask specifically about such details as bandwidth between your machine and the provider, what has to be done to install the connection, and what hardware is provided in the quoted monthly rate. Also, you should have some idea of how many IP numbers you need for your own machines (remember that not all IP numbers in the block you get from the provider will be available for attaching your computers). Ask the provider what their total bandwidth is out to the outside world, as the quoted speed is only between your site and theirs. If the provider has insufficient bandwidth to the outside, the customers will suffer bottlenecks within the provider's network.
Once you have narrowed down a list of candidates, ask around, see if anybody can provide you with recommendations for the services you're considering. Ask them what sort of bandwidth they get to unloaded sites. Also, if you intend to have fast connections between the new domain and local ISP accounts from home, for telecommuting, or just remote administration, it is essential that you do a traceroute from your home ISP account to a host operating on the service you're considering. This will tell you how many hops, and how much latency you should expect, between home and the new domain. Latencies much above 100 to 200 milliseconds can be difficult to use for extended periods of time. The traceroute should be run around the time of day that you expect to make use of the network connection between home and the new domain.
After you have chosen the provider and service type for the new domain, ask about installation details. You may require service calls from the telephone company as well as from the ISP in order to install the service, and the technicians may need access to controlled areas of your building, so inform the building engineer of the installation requirements.
Before the ISP technician arrives, ask for the network parameters, specifically the IP number, netmask, broadcast address, gateway routing address, DNS server address, and also what cabling you need to connect to the hardware delivered by the technician (i.e. straight-through or crossover RJ45 cabling, etc.).
Have one machine available for testing, and put it close to where the network connection hardware will be installed. If possible, configure it before the service technician arrives, setting the IP number and netmask, and have the appropriate cabling ready so that the installation and testing can be done quickly.
With your test machine attached to the ISP's hardware, make sure that you can ping sites beyond the ISP. If not, a traceroute to the outside can help to show where the connection is failing. If traceroute shows no successful hops it indicates that your test machine's network configuration (default route, interface address, NIC drivers, DNS, etc.) is incorrectly set. If it shows one hop, that could mean that your router is not correctly configured to communicate with the ISP. If it shows several hops before failing, the problem is almost certainly in the ISP or in the outside world, and beyond your immediate control.
The benefits of a corporate connection, with a static IP block and various hosted services, comes with a cost. It can be more than ten times as expensive as a high speed home connection on DSL or cable modem. If the budget can't support a corporate connection, or if no such connections are available in your area, you might want to try to set up a domain on a dynamic IP. Instead of a range of IP numbers, you typically get exactly one, which means that your private network gateway machine will also have to host any incoming services from the outside.
First, you might want to check the legality of it. Many companies' user agreements explicitly forbid setting up externally-accessible servers on personal accounts. They may enforce this with packet filters blocking incoming connections on the http and FTP ports. You should also be aware that the quoted connection speed for personal accounts such as home DSL or cable modem are the downlink speeds, and that the uplink speeds might be much slower. The uplink speed is what is important for serving up FTP or web content.
If you have a dynamic IP, and you want to have incoming connections, you will have to subscribe to a dynamic IP hosting service, such as DynIP, DynHOST, TZO, or fdns.net. These all work by running software on your machine which passes your current IP number on to the company's servers. When your current IP number arrives at the servers, their DNS tables are updated to reflect the new value. You can either get a domain name under their domain name, such as ``example.dynip.com'' or ``example.dynhost.com'', or you can register your own domain and set the primary DNS authority to point to the company providing this service (usually at a higher cost).
There is also a free hosting service, at Domain Host Services. They seem fairly new, and there are few details on their web site at the moment, but you might find it worth a look.
If you have set up a dynamic IP, and subscribed to one of these services, it will affect some of the decisions you make in section Deciding Which Domain Services You Will Host. In particular, there is little point subscribing to a dynamic IP hosting service if you do not plan to host at least one of web or FTP services. You will have to set primary DNS authority to point to the company you've chosen. You should not have a named daemon answering requests from outside your private network. Other details, such as handling of email, will depend on the specifics of the service you've subscribed to, and can best be answered by the support staff of that company.
One final note: if you want to have remote access to a machine with a dynamic IP, but don't need it for hosting other services, the inexpensive solution is to create a ``drop box'' on a publicly accessible machine with a static IP, and have your dynamic IP host send its IP number there, either in email or simply by writing it into a file on a shell account. When you want to access your machine remotely, first extract the current IP number from the drop box, then use slogin to attach directly to that IP number. This is, after all, really all that a dynamic IP hosting service does, they just do it automatically over standard services, saving you some steps.
In order for people in the outside world to locate your servers under the domain name of your choice, whether for web, FTP, or email delivery, you will have to register the domain name for insertion into the relevant top level domain database.
Exercise some simple prudence in choosing your domain name. Certain words or phrases may be forbidden on the grounds of community standards, or may be offensive to visitors whose language or slang differs from that of your region. Domain names can contain only the 26 letters of the Roman alphabet (without accents), the hyphen (though not at the beginning or end of the name), and the 10 digits. Domain names are not case-sensitive, and can be at least 26 characters long (this limit is subject to change). Be careful not to register a name which you can reasonably have been expected to know infringes on the trademarks of an existing company, the courts are not kind to cybersquatters. Some information on the circumstances under which your poorly-chosen domain name might be stripped from your control are available in this Uniform Domain Name Dispute Resolution Policy.
There are many companies which register names in the ``.com'', ``.net'', and ``.org'' top level domains. For a current list, check the list of accredited registrars.
To register a name under a country top level domain, such as a ``.ca'', ``.de'', ``.uk'', etc., check with the appropriate authority, which can be located in the Country Code Top-Level Domains database.
Typically, you have to provide the registrar with contact information, primary and secondary DNS IP numbers, a change request validation scheme (you wouldn't want just anybody changing your domain for you), and money in the form of an annual fee. If you're not comfortable with the change request validation schemes offered by a registrar, let them know that you're not willing to use the service until they address your security concerns.
Most full-service ISPs will provide a variety of domain services for their customers. This is largely because of the problems associated with hosting these services under certain other, more popular desktop and server operating systems. These services are much easier to provide under Linux, and can be hosted on fairly inexpensive hardware, so you should decide what services you want to take on for yourself. Some of these services include:
In each of these, you basically have to weigh convenience against control. When your ISP performs one or more of these services, you can usually be fairly sure that they have people with experience maintaining the service, so you have less to learn, and less to worry about. At the same time, you lose control over these services. Any changes require that you go through the technical support of your ISP, something which may sometimes be inconvenient or cause longer delays than you would like. There's also a security issue involved, the ISP is a much more tempting target to attackers than your own site. Since an ISP's servers might host email and/or web space for the dozens of companies which are their customers, an attacker who compromises one of those servers gets a much higher return for his efforts than one who attacks your personal servers, where only one company's data is kept.
When a person somewhere in the outside world attempts to connect to a machine in the new example.com domain, queries are sent between various servers on the Internet, ultimately resulting in the IP number of that machine being returned to the software of the person attempting the connection. The details of this sequence are beyond the scope of this document. Neglecting many details, when a request is made for the machine fred.example.com, a centralized database is consulted to determine what is the IP number of the machine which holds primary DNS authority for the example.com domain. This IP number is then queried for the IP number of the machine fred.example.com.
There must be a primary and a secondary DNS server for every domain name. The names and IP numbers of these two servers are stored in a centralized database whose entries are controlled by domain registration authorities such as Network Solutions.
If you elect to have primary DNS authority hosted by your ISP, these two servers will probably both be machines controlled by the ISP. Any time you want to add an externally visible machine to your network, you will have to contact the ISP and ask them to put the new machine in their database.
If you elect to hold primary DNS authority on your own host, you will still use another machine as your secondary. Technically, you should use one on a redundant Internet connection, but it is very common that the secondary is held on one of your ISP's machines. If you want to add an externally visible machine to your network, you will have to update your own database, and then wait for the change to propagate (something which takes, typically, a small number of hours). This allows you to add barney.example.com without having to go through your ISP.
It is a good idea to set up secondary DNS on a geographically distant host, so that a single cable cut near your ISP doesn't take both your primary and secondary DNS servers off line. The domain registrar you used to register your domain name may provide secondary DNS service. There is also a free service, Granite Canyon, available to anybody who asks.
Regardless of whether or not you choose to act as primary DNS authority for your domain, see section Setting Up Name Resolution for configuration help. You will want some sort of name resolution system for your private network, even if you delegate primary DNS authority to the ISP.
When you subscribe with your ISP, they will typically supply a number of email boxes. You can elect to use this service exclusively, in which case all incoming email is stored on the ISP's servers and your users read their mail with POP3 clients which connect to the ISP's servers. Alternately, you may decide to set up email on your own machines. Once again, you should weigh the merits of the two approaches, and choose the one which you prefer.
Things to remember if you use the ISP for all email:
Things to remember if you provide your own email:
One possible approach is to host email yourself, but also use the several email addresses provided by the ISP. People who need email accessible from outside the private network can have an email address in your domain which gets redirected to one of the ISP-supplied email addresses. Others can have local email on the private network. This requires a bit more coordination and configuration, but gives more flexibility than either of the other approaches.
Should you choose to host email for your domain, see section Setting Up Email For Your Domain for configuration help.
If you decide not to host email for your domain, refer to section DNS Configuration If You Are Not Hosting Email for important notes on the name resolution configuration.
Your ISP may allocate you a certain amount of space on their web servers. You might decide to use that, or you might have a web hosting machine which you put on your external network, in one of your external IP numbers.
Points to remember if you choose to use the ISP's web space hosting:
Points to remember if you choose to host your own web space:
Notice that I do not mention anything about the ISP having more powerful hardware, higher peak data rates, and so on. By the time these things become important, you're talking about very high data rate network connections, and, quite