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 frankly, you had better be delegating these decisions to a skilled consultant, not looking in a Linux HOWTO.
Should you choose to host web space for your domain on your own server(s), refer to other documents, such as the WWW-HOWTO, for configuration help. I strongly recommend that this service be run on a different machine from the private network gateway machine, for security reasons.
Basically, the same arguments apply to FTP hosting as apply to WWW hosting, with the exception that active content is not an issue for FTP, and CGI scripts don't appear. Most of the recent ftpd exploits have come from buffer overruns resulting from the creation of large directory names in anonymously-writable upload directories, so if your ISP allows uploads and is lax in keeping up with security updates on the FTP daemon, you might be better off hosting this service yourself.
Should you choose to host FTP for your domain on your own server(s), make sure to get the latest version of your FTP daemon, and consult the configuration instructions there. Once more, I strongly recommend that this service be run on a different machine from the private network gateway machine, for security reasons.
For wu-ftpd, I would recommend the following configuration options:
Some ISPs will put packet filters on their network, to protect the users of the system from each other, or from external attackers. Cable modem networks and similar broadcast networks have had embarrassing problems when users of Windows 95 or 98 inadvertently set up disk shares, exporting the full contents of their hard drives to anybody on the network segment who cared to browse for active servers in the neighbourhood. In some cases, the solution has been to tell the users not to do that, but some providers have put filtering into the access hardware to prevent people from exporting their data by accident.
Packet filtering is really something which you ought to do yourself. It fits in easily into the kernel running on your private network gateway machine and gives you a better idea of what's happening around you. You often will find that you have to make small tweaks to the firewall to optimize it during the initial setup, and this is much easier to do in real time than through a technical support contact.
Should you choose to do packet filtering for your domain, see section Setting Up Packet Filtering for configuration help.