Washington Apple Pi

A Community of Apple iPad, iPhone and Mac Users

Don't Discard That Rotten Apple:

Make It an Internet Server, Part III

© 2001 Richard S. Sternberg

Washington Apple Pi Journal, July/August 1999, p. 13, reprint information

Sorry, The Prerequisites

You may not understand this article unless you recall the others. In the first, Don't Discard That Rotten Apple -- Make It an Internet Server, Part I, (Washington Apple Pi Journal, May/June 2000, pp. 25-30), or http://www.wap.org/journal/internetservers/internetservers1.html, we set up an old Ethernet-equipped Mac Centris 610 to run System 8.1 and we tapped the Mac OS native ability to serve as host to multiple Internet Protocol (IP) Addresses. In the second article, Don't Discard That Rotten Apple -- Make It an Internet Server, Part II, (Washington Apple Pi Journal, July/August 2000, pp. 67-70), or http://www.wap.org/journal/internetservers/internetservers2.html, we set up a freeware email server and a shareware or cheapware web server for multiple web sites and many, many email accounts on the same due-to-be-retired Centris. You should review those articles before continuing here. You're also welcome to meet me in cyberspace on the server I set up, where I've published the articles with live html links at http://RSSternberg.org/Multihost.html Reprint information is available at http://www.wap.org/journal/reprint.html.

It's been over a year since I set up my web server and email server hosting multiple IP Addresses for multiple domains and all their subdomains --plus innumerable free email addresses. All of this has been running on an ancient Ethernet-equipped Mac Centris 610, and it's been running reliably. The first two articles have been re-published at least twice on the Internet, and the series remains hosted on my own server. Today, we will finish empowering individual and small business users by freeing ourselves entirely from professional Internet service providers and learning to host our own domains.

In the last article, I complained that I had no solution for how to run free domain name hosting using only my ancient Apple. Even though I can control my own publicly recognizable services, like email and web pages, I was still paying $50 per year per domain for the fairly limited service of incorrectly inputting corrections to my name service. I even thought I'd wasted my time creating local email and web servers, because many of the discount web hosting services, like http://www.cedant.com/, won't sell domain name hosting separately.

It's taken a year, and we will need to make a few compromises, but I now buy cheaper and faster fiber-optic T-1 access to the Internet as I watch the market change.

Internet Service Providers (ISPs) are dividing into two groups: access providers, who sell broadband lines for discount prices, and domain hosting services, who provide equipment to host web and email services. The prices for these hosting services seems to be rising as they set up virtual offices in bullet-proof buildings near the Internet hubs. It is a basic tenet of these articles that such a high level of access and security is overpriced and irrelevant for many, many businesses and nearly all individuals.

There is good news for individuals seeking to create family domains, non-profits and small businesses who want to create less complex sites and host email across broadband. The price of DSL, T1, and other broadband technologies is dropping, particularly when bought in business areas where competition exists and where it isn't coupled with the more personnel-intensive hosting services. Because I fully host my own servers, I get access for my low volume servers cheaply, while my ISP saves money on the business-to-consumer interface.

To finish the job of hosting and become your own "responsible party" with your registrar, we must take the last step and provide domain name services.

Fig. 1: A registrar's Whois record, showing the author as responsible party.

Inadequate Mac solutions

My first objective was to run all of my Internet services from one discarded Mac Centris 610. This was overly ambitious. It would seem that domain name servers (DNS) have an easier job than web or email servers. After all, what domain name service (also, DNS) does is translate human language-based domain names, like SternbergLaw.Net, to and from machine language-based IP Addresses. The task becomes more complex at the bit level, particularly with the heavy loads and quantity of bad packets that DNSs often experience.

There were, at one time, two freeware, Mac DNS packages. Apple provides, without warranty, MacDNS 1.0.4, and QuickDNSLite was published by Men & Mice. According to informal polling of Washington Apple Pi volunteers who have tried desperately to make it work, MacDNS 1.0.4 is flaky and will not reliably serve zones either when sharing services with other Internet servers on the same machine or when placed alone on a machine and placed under load. QuickDNSLite is a sadder story: it apparently works fine for low load settings, but it was pulled from the market over a year and a half ago. My diligent efforts to obtain it failed.

Men & Mice produces a relatively low priced version called QuickDNS Pro, but it is sold for $349, which is significantly out of range for a freeware project. http://www.menandmice.com/infobase/mennmys/vefsidur.nsf/index/2.2.

Don't "Think Different" -- BIND it

Another choice is to keep your domain name service local using BIND. Most Macs can run Unix. Experts on the Pi Telecommunications System (TCS) compiled this list of various free sources of Unix on Macs:

http://www.netbsd.org/Ports/mac68k/

http://www.netbsd.org/Ports/macppc/

http://darwin.org/projects/darwin/

http://www.openbsd.org/mac68k.html

http://www.openbsd.org/powerpc.html

There are also fully-supported commercial products for running Unix within the Mac OS:

http://www.tenon.com/products/machten/ which features BIND;

http://www.tenon.com/products/webten/

http://www.tenon.com/products/netten/

http://www.tenon.com/products/itools/

For other information on Linux on the Mac, you can try:

http://www.linux-m68k.org/

http://mklinux.org/,

http://www.suse.com/us/products/susesoft/ppc/

http://www.yellowdoglinux.com/ (which could not be reached on the web when I searched), and

http://www.linuxppc.com/

I nevertheless doubt the sanity of doing this on an older, slower Mac. It still strikes me as silly to tear the Mac interface off a Mac and hobble it with another operating system (OS) so that you can run a non-native application, like BIND, on it. I suspect that the multiple levels of programming will probably reveal an undocumented bug or two, and you will have crawled into an area of niche programming where nobody will be able to help. I don't think this is a project for lay people.

Of course, a less complex choice is to run Linux on a recycled Wintel box, since old Windoz/Intel based computers can be purchased -- or found in a dump -- even cheaper than old Macs. That experience is beyond the scope of this article, since I am consistently baffled by Linux, having never put in the time to learn the basic structure of the OS. I can only say, based on my "travels" in researching this article, that the correct software within UNIX/Linux is BIND and that BIND is the most common DNS running worldwide. You'll find many, many people qualified to help with setting up BIND in the USENET newsgroups.

Sidebar: ZoneEdit on the Move

Zone Edit is an exciting commercial start-up providing DNS services. Formed in 2000, they've been active in making domain name service a popular commodity for webmasters and hobbyists. The services they offer seem to be expanding rapidly, and their CEO, Michael Krebs, seems to have set an informal objective of rolling out a new service each week. While such aspirations are unlikely to be maintained for long, I exchanged emails with Mr. Krebs late into the night as his team stayed to meet its objectives. Some of my favorites include:

Secondary service: Zone Edit intends to roll out secondary zone service, like Granite Canyon, so that subscribers can create their own unpublished primary servers or place their primary servers elsewhere and use Zone Edit as an additional set of secondary servers.

Backup email servers: While it is not clear whether this service will be offered free, like their DNS service, to personal subscribers, Zone Edit is planning a secondary email hosting service. If you follow the model I explained in these articles to host your own email service, you will not have the same backup protection provided by commercial providers. If your email server is out of service for more than a few hours, some of your email correspondents will get messages that their email hasn't been delivered. In another day or two, their email will be returned. This disadvantage will be eliminated if you have a backup email server listed in your DNS resource records. Zone Edit plans to provide such backup service, making your small Internet server look even more professional.

Dynamic IP Support: This is my personal favorite, and I'm told it already works. Using shareware named Dynamic DNS Client 2.0b.1, found at http://www.sentman.com/dyndns/, your Mac can inform Zone Edit through its web page when your IP address changes. The details are in FAQ #17 at http://www.zoneedit.com/doc/dynamic.html, but the bottom line is that DSL service with a dynamic IP address no longer precludes you from setting up your own Internet servers. A dial-up 28,800 connection will still be inadequate for a web server (and is not permitted as part of your Washington Apple Pi Explorer service). But, this may mean that the DSL customers who gave up on the project because they had dynamic IP addresses are now welcome to try.

One problem you may face in setting up a local DNS on any platform is Internet access. Almost by definition, your user set-up is located many stops away from the backbone of the Internet. This is of little concern for serving up the relatively simple web pages that the far majority of businesses and individuals need, and is utterly irrelevant to email service, which does its communicating outside the user's perception. This may be a problem for DNS, in which small packets are sent back and forth across inconceivably great expanses of wire and fiber repeatedly within milliseconds. A location near the hub for this essential but brief communication may massively increase reliability. Further, when you're distant from the backbone or have only one route to it, anyone upstream from you can shut you down. While this is also true of your web server, a web server error appears differently to users than a DNS error. Users who fail to get your web page will either get a cached copy of your pages, if they visit regularly, or will get a busy error. Absence of a DNS directory entry will tell visitors that your domain doesn't exist.

But, there are distinct advantages to having a local DNS serving as the primary source of your DNS, particularly if you don't publish the availability of that DNS server to the world by listing it in the Top Level Domain (TLD) servers of your registrar. Unless the address of your local DNS is listed with the InterNIC, resolvers seeking your Internet services will not look to your DNS. Your local DNS will never be bombarded with the potentially heavy traffic of repeated ping, traceroute, and nslookup commands from the public. It is that traffic that makes MacDNS 1.0.4 unstable. If you set up all of your other DNSs as secondary, obtaining their source information from your local DNS, then you can control your DNS changes locally and propagate them to the secondary servers you have selected.

Finding a suitable, local answer for any more than a local unpublished primary host is not going to be easy. Fortunately, the compromise I made was that I found access to free or cheap DNS services that eliminate the need for local name servers.

Free sources on the Internet

Unfortunately, I have not tried setting up a local primary host. My primary DNS is at http://ZoneEdit.com/, which provides free domain hosting for as many as five domains and very reasonable rates thereafter. But, when I set up my zones for this article, they didn't provide for secondary service unless they controlled the primary. (See Sidebar: ZoneEdit on the Move). I have secondary hosting service at the first free Public DNS in the world, at http://www.GraniteCanyon.com/, and their system allows you to choose them as primary or secondary and to write your zones freely, but they are extremely unreliable in spite of the non-dynamic and inaccurate statistics they post on their web site. It is unsafe to entrust any more than backup service to them. I escaped to ZoneEdit after struggling with a persistent crash and lack of communication from Granite Canyon for weeks, during which I watched them crash almost all of their 61,000 hosted sites. Free ... and worth every penny of it.

There are a number of other sources of DNS hosting on the Internet, even if local access providers and web hosting companies are disinterested. A comparative review of such providers can be found at http://www.dnsproviders.com/.

Basic DNS writing: It isn't rocket science -- but it looks like it is

It is much easier to write a DNS zone than to explain the details of DNS protocols. A problem many novices experience is that the experts who understand DNS try to answer the questions of novices by imitating the sage words of Albitz and Liu in their classic tome, DNS and BIND, 3rd Edition, (O'Reilly, September 1998), 499 pages, $37.95. A nice bibliography with hyperlinks is provided by Granite Canyon in their answer to FAQ #11. http://soa.granitecanyon.com/faq.shtml#other-dns-resources.

$ORIGIN sternberglaw.net.
sternberglaw.net. IN SOA ns3.zoneedit.com. dnsadmin.zoneedit.com
14400 ; refresh
7200 ; retry
864000 ; expiry
3600 ) ; minimum
sternberglaw.net. IN NS ns3.zoneedit.com.
sternberglaw.net. IN NS ns5.zoneedit.com.
sternberglaw.net. IN NS ns1.granitecanyon.com.
sternberglaw.net. IN NS ns2.granitecanyon.com.
sternberglaw.net. IN RP r.sternberg.wap.org. richard.sternberglaw.net.
richard.sternberglaw.net. IN TXT "Richard S. Sternberg, NIC handle: RSA219"
localhost.sternberglaw.net. IN A 127.0.0.1
sternberglaw.net. IN A 216.50.13.165
smtp.sternberglaw.net. IN CNAME sternberglaw.net.
pop3.sternberglaw.net. IN CNAME sternberglaw.net.
www.sternberglaw.net. IN CNAME sternberglaw.net.
; global MX records for unspecified subdomains in the zone
*.sternberglaw.net. IN MX 0 sternberglaw.net. ; GLOBALOK
; MX records for email addressed to the zone itself
sternberglaw.net. IN MX 0 sternberglaw.net.

Fig 2: Sample Resource Records for domain sternberglaw.net.

Other providers make this even easier by providing a web-based script to write your zones for you. I managed to set up my first zone at ZoneEdit.com within five minutes of surfing over to their site. It's that easy.

Writing a basic zone of resources records (RRs) for an average domain is not as exacting as understanding DNS protocols. Basically, copying an example provided by Granite Canyon will teach more than a lengthy essay on writing DNS zones. For a good example of a primary zone, go to http://soa.granitecanyon.com/pexample.html. For an embarrassingly easy example of a secondary zone, try http://soa.granitecanyon.com/sexample.html.

Sidebar: Primary, Secondary ... Bicentennial!

Many get caught trying to fathom the inner meaning of primary and secondary DNS service. Don't let 'em fool you -- it's easy. First, stop calling them primary and secondary and start calling them master and duplicate or master and slave. The master is the machine that contains the zone record which you want each of the slave servers and the whole world to copy. Though some people create dual masters to increase reliability, you usually wouldn't want more than one master -- unless you've mastered DNS. If the records in the dual masters wind up different, your slave servers will be following potentially inconsistent masters at different times. On the other hand, the only practical limitation on the number of slave/copied hosts is the number that your registrar will let you list with their Top Level Domain (TLD) registry. Network Solutions seems to allow one primary/master and five secondary/slave servers, but I could not make more that five DNSs show up at the resolver (the computers seeking to find the zones).

When resolvers decide that they don't know your address, they ask the TLD. It offers any one of its known DNSs without regard to which is primary. The resolver takes its solution from there, so long as that server is available. If one or more of the servers crashes, it is better to have the redundancy of multiple "secondaries." The crash will still slow some resolvers, but your sites won't disappear.

An unpublished primary/master is a combination of these concepts. The TLD doesn't know the unpublished primary exists, so no resolvers come to it for DNS solutions. The TLD believes that one of the servers is a master, but it treats masters and slaves as equally authoritative sources of your zone information. The slave servers, however, know that they must get their zone information from the unpublished master, so they are set up with none of the information discussed below and merely know the address of the master. The end result is that the user can control the zones freely from a distant side branch from the Internet backbone, but not be subjected to inquiries, bad packets, and even attacks from the world of resolvers.

Got it?

The first line in our sample primary DNS zone is the $ORIGIN line. Neither ZoneEdit nor Granite Canyon allows you to write this line yourself, so it is difficult to get it wrong. If you are creating a BIND name server on your own host, you need some command to distinguish between the different zones to be hosted. The $ORIGIN command defines the current zone. In BIND compliant DNSs, you may substitute the "@" symbol for the defined origin name, and the origin name will be automatically appended to any name that doesn't end with a period.

The SOA, or Start of Authority, resource record is considered by many to be the most complex, but most of its complexity can be avoided by skillfully stealing someone else's definition of good variables to insert. The record begins by naming the zone to which it applies, sternberglaw.net, concluded with a period, which I could have represented with an "@". The SOA record continues to name the host machine in which the primary records are said to be found, in this case, ns3.zoneedit.com -- ended with a period to avoid being interpreted as ns3.zoneedit.com.sternberglaw.net. This line appears to, but doesn't actually, end with the email address of the person responsible for that name server, with the name written in peculiar, DNS form -- the "@" is replaced by a period. (Because this form of expressing an email address can get confused for the address of a subdomain or host, it is sometimes necessary to fool a line editor, like nslint, into accepting the extra period; this is accomplished by using a backslash (\) as an escape character, making my WAP email address r\.sternberg.wap.org).

The variables that appear afterwards are confusing. They are expressed in seconds and may be noted in alphanumeric characters. In Figure 2, the variables are explained by comments placed after the semicolon symbol, but four numbers placed after the email address on an SOA record will be interpreted by the computer just as well without the comments. I asked Michael Krebs, CEO of ZoneEdit.com, to clarify the meaning of the variables:

"... the 'refresh' parameter on the SOA ... controls how often a slave will 'take the initiative' and attempt to perform a zone transfer. The 'retry' parameter controls how often a zone transfer will reoccur if a zone transfer fails. The 'expire' parameter controls when the slave will throw the zone away if it was unable to perform a zone transfer, even after all the retries. The 'TTL' [or 'minimum']... is now more often used as the default length of time that recursive DNS lookups are cached on the querying DNS server."

When you print out your zone, depending on the software and options you use for this, you may get an additional number before all of the other numeric variables. That number is called the serial number, and it tells querying secondary hosts whether they already have the latest DNS zone information. Your DNS provider, if it's ZoneEdit or Granite Canyon, issues you a new serial number each time a change is made to the zone, and other computers seeking to conform their data can begin by checking the serial number before requesting a zone transfer.

The bottom line is that Granite Canyon doesn't let you set the SOA variables. ZoneEdit sets them for you and lets you change them at your peril. Even if you write your own SOA resource record, you can copy different values from many sources, including the example given above.

After the SOA record, you need to name each of your name servers using an NS record that starts with the name of the zone affected, states that it is an Internet record, abbreviated IN, and then gives the name of the host machine where records about this zone can be found. Without this, the server you name as primary will not be able to notify its secondary servers when changes are made to the zone, and resolving DNSs across the world will not know where they can find information to refresh their records. It makes no difference in what order the NS records appear.

In a Granite Canyon zone, you must then proceed to create a responsible party (RP) record and a supplementary text (TXT) record. These records are generally considered optional by DNSs. Granite Canyon requires them to make users responsible for their zones. Users must provide an email address inside and outside the zone, in DNS form, in the RP record, and provide identifying information, such as your name and your NIC handle, in a TXT resource record. ZoneEdit does not support these records, and such records seem a bit redundant and rather easy to spoof.

The localhost record appears next in a Granite Canyon script, but is not required in a ZoneEdit script. All DNS resolvers set up correctly provide this. The need for this is more complex than a simple "how to" description. Just copy the record from my sample if you use Granite Canyon. Consult Albitz and Liu if your curiosity requires more.

We now begin the meat of the DNS record. The IP address of the host machine providing your Internet services is specified in an A record in the form shown in Figure 2. Note that IP addresses do not end in a period. There is some divergence in the field. Granite Canyon's documentation explicitly prohibits aiming more than one subdomain in a zone at the same IP address, declaring that CNAME commands, described below, are used for that purpose. ZoneEdit aims the www host and the domain itself at the same IP address using A records, and, by clicking on the IP Addresses button, allows you to point each of your subdomains to your IP Addresses using an A record. It also allows the older method of using CNAME records to direct subdomains. Due to changes in the way BIND handles CNAME records, some experts believe that CNAME records are an historical relic, and that each domain and subdomain should have A records rather than CNAME records. In a final twist, some growing number of providers allow load sharing, in which calls for Internet services are divided between multiple, identical web or email servers, by aiming one domain at two inconsistent IP addresses. The easiest answer is to understand the terminology and copy the form and rules of the DNS hosting service you select. The example given in Figure 2 is intentionally less complex and is likely to be acceptable with any provider.

Those names that cannot be directed with A records should generally use CNAME records. CNAME is short for Canonical Name, which loosely, and somewhat inaccurately, is a way of declaring an alias. In complex, ISP zones, a domain name might be divided into hundred or thousands of subdomains. For individuals and small businesses, such complexity is cumbersome and unnecessary. Nevertheless, it is here that you can correct the most common error ISPs make in setting up zones: you can set www, smtp, and pop3 to all be aliases of the domain name itself since they are all hosted on one machine. Users can then freely forget to put www in front of your web address and you can freely forget to set up your TCP/IP host names to remember the difference between pop and smtp protocols.

Those who read the example carefully will notice that I've also defined all subdomains of the zone to be the same domain name. This prevents future errors, may slightly decrease the possibility that someone can hijack one of your subdomains without your knowledge, and is accomplished by no more than using an asterisk as a wildcard for all other subdomains. While the wildcard covers the www, smtp, and pop3 CNAME records, the individually named records will be given priority, and taking the time to define them at the outset might help you remember how to expand when you do need to move your smtp and pop3 services to another host. Note that Granite Canyon' line editor, nslint, does not recognize asterisks, so, when using their service, it is necessary to put the escape code GLOBLOK in a comment field on the line where the asterisk appears.

Finally, we come to what information technology experts describe as the most inscrutable part of DNS protocol -- mail exchange (MX) resource records. Again, attempting to understand the concepts behind multiply redundant mail servers and load sharing and prioritizing mail servers might get difficult. Establishing a rudimentary mail exchange record is not. The example provided in Figure 2 ought to be adequate for copying.

Finally, you need a place to ask questions and to help debug errors. Create a newsgroup account in your news or email reader and point it to news.granitecanyon.com. There are three groups sponsored by Granite Canyon, and the group named soa.help is the one you should join. Though the servers are actually provided by a different volunteer, and Granite Canyon's volunteers rarely appear, the visitors populating the newsgroup are knowledgeable and friendly.

Testing & debugging tools

In the process of setting up and testing your DNS settings, you're going to require some Internet tools, but, as through the rest of this series, you won't need any commercial products. One of the original tools, published around 1996, was DNS lookup 0.91, but it's flaky, ancient, and clumsy. OTTools and WhatRoute will give you the ability to look up domain registrations from a Whois registry, and to ping and traceroute, but what you really want is a tool to do a Linux/Unix command called dig. Dig looks for the zone as it exists at a particular name server, rather than seeking the answer in the multiply redundant world of DNS. After a significant search, I found that Men & Mice, publishers of QuickDNS Pro, publish a freeware/crippleware version of their DNS Expert Professional. Hidden in the Tools menu, DNS Query is a wonderful dig engine which remembers your recent domain names and name servers. Find it at the link provided at http://us.mirror.menandmice.com/cgi-bin/DoDig.

Fig.3: Logo for DNS Expert Professional

At times during your testing, you may want to test from outside your IP address area. This can be particularly important if you do many repeated tests sequentially within a short period of time or if you are trying to determine whether the changes you've entered to your DNS zones have propagated. The Men & Mice web site mentioned above provides an excellent platform for remote digs, and the site at http://combat.uxn.com/, designed to enable hunting and tracking of spammers, provides another series of remote tools.

Changing your ISP at the Registrar

Sidebar: Can we give a zero-star rating to NSI!

It is plain that NSI is a clumsy, overpriced, unresponsive, monopolistic pig. It was designated as The Registrar in a misconceived and poorly executed public-private partnership before the web exploded and the expected registrations magnified from tens of thousands to hundreds of millions. Once the contract expired, the Department of Commerce forced NSI to surrender its monopoly, but it permitted them to have too strong a hand in creating the rules for their own competition. The result is obscene pricing of domains at $35 per year when the market rate appears to be between $7.50 and $11; surly, ill-mannered staff who can't even be reached because of an even more surly morass of useless and helpless automated forms; and a series of intentionally placed pitfalls and traps to ensure that you have to return your registration to NSI.

I still have all of my domain names at NSI because they forced me and I don't want to waste time or money moving them until the domains get close to expiring. The second tier of registrars is massive, and the registrar market will almost surely shake out before then. On the other hand, it is a pain waiting three emails, sent at least twice, plus two days, for a routine, automated update which, anywhere else, happens at close to the speed of light. An early change may be particularly urgent, since NSI is rumored to block registration changes either 60 days before or 60 days after a registration, and they send notices during this time and cybersquat names to prevent you from moving if you fail to renew them. And, almost all of the registrars -- except NSI -- credit extra time left over from a prior registrar. Maybe I'll switch before expiration!

Fortunately, there are competitors providing much cheaper and far more convenient and friendly service once you get past the monopolistic practices of NSI. And, on the web, shopping their services is nearly instantaneous. By an informal poll of folks on the help newsgroup of Granite Canyon, I got a list of a few of the best:

http://www.stargateinc.com/ offers $10 per year registration, which drops to $8 if you register two or more at the same time and bulk rates are available. Like most of the competing registrars, they tack the additional time on to the end of your present registration, so you lose nothing in the transition. While they are your registrar, they throw in little "extras," like URL redirection and masking, so you can host your site at a willing, free source, like Geocities, mac.com, or Yahoo.com, and link your new domain name to that host site without the types of servers covered by these articles.

http://ww.nameit.net offers $7.49 per domain for bulk registrations of 2000 names or more. Single transfers can range as high as $34, though, and I couldn't understand the price charts without undue study. Good reviews for responsiveness and ease of use.

http://www.10-domains.com/ charges $10 per domain.

http://gandi.net/ charges 12 euros, which is around $10-11. The FAQs are helpful and the staff is shockingly responsive to emails. They are in Paris.

http://www.dotster.com/ seems quite popular at $15.

http://www.mydomain.com/ provides registration and hosting, with some registration services running between $10-15. I didn't examine the web site closely enough to follow the terms and conditions. They received some bad reviews for service, for complex and limited terms, and for limited domain management tools.

http://register.com/ was one of the early entrants to this market after the doors swung open, and they sponsor Granite Canyon, so, if you use them, make sure to enter through the portal at http://www.GraniteCanyon.com/ to ensure proper credit, but they still charge $35 per domain per year. They throw in free domain hosting services, though, which would mean you won't need this article or Granite Canyon if you select them.

But, at bottom line, as one newsgroup contributor put it: "For God sakes, change to a different registrar where you can directly edit your DNS and other info... and for less money, to boot."

The final step in getting your new DNS servers on-line is to inform your registrar about them so they can put the data into their TLD DNSs. Some would think of this as a prerequisite. The ZoneEdit script guides you directly to the correct page of your registrar -- provided your registrar is Network Solutions. This is inconvenient for novices, anyway. At least for your first zones, you should click the blue button at the bottom right of the ZoneEdit box and skip changing your registration until your zones have been tested. You can return later to the correct form at NSI by clicking the "More Info" button in the ZoneEdit box warning you to change your designated name servers.

Nevertheless, finding the correct form in the morass of Network Solutions (NSI) is a singular challenge and initially took me well over an hour. Search for the form under "Make Changes" for "Change ISP." At other registrars, such changes are simple to make and nearly instantaneous to implement, though the changes may take as many as three days to propagate across the web. If you need help, a human will promptly and politely answer email -- except at NSI. (See Sidebar: Can we give a zero-star rating to NSI!)

The final frontier: NNTP Newsgroup Service?

The only other service I might consider hosting is newsgroup service. My new ISP prefers to provide the "telephone lines" without providing Internet services. It doesn't offer USENET newsgroups. I may not need the ability to provide a newsgroup to my visitors or co-workers, but I must give people inside the network access to USENET. The source of information on setting up BIND instructions is at comp.protocols.dns.bind in the USENET. It is unthinkable to run Linux, as we do for our firewall and master file server, without comp.os.linux.networking, comp.os.linux.security, comp.os.linux.setup, comp.protocols.appletalk, comp.protocols.smb, and comp.security.firewalls.

From the client side, newsgroup service is easy, since most email clients can read newsgroups just fine. Consult the help instructions for Outlook Express 5.0 or Netscape Communicator if you have problems with that. There are both Mac and UNIX/Linux answers for providing your own NNTP server, but the complexity of NNTP may be daunting. I sought free, complete, and open newsgroup servers on the Internet. INN meets all three criteria. Leafnode, http://www.leafnode.org/ gives up completeness in favor of reasonable scale and ease of administration. Stairways' product, Rumormill, regains some of the completeness, but gives up open and free. It is Mac shareware. Another cheap commercial product is Dnews, found at http://www.buller.se/DNews/default.htm.

I passed the word around the TCS and got these reviews of the various NNTP servers for Macs:

"Leafnode's interesting. It's basically the equivalent of a squid proxying web server, only for NNTP. If you ask it for the contents of a newsgroup, it'll go out and get maybe a hundred messages from that group for you to sample. And it'll continue picking up that group until it notices that no one's asked for it in a couple weeks, at which point it'll leave that one alone. As such, it self-adapts and scales and learns your small office's needs -- to a point, so long as your needs fall within a certain band. And given adequate storage.

"I'd expect Rumormill to be much easier to set up, but not nearly as easy to maintain once it's running. You'll need to add and remove groups manually, do some preventive maintenance on the back-end database file every now and again, and keep an eye on load to make sure the server will be able to handle a sudden burst of spam without being pushed over the edge. None of it [is] rocket science, but not something you can just put on a machine somewhere and leave alone.

"And, [it's] certainly not something you can piggy-back onto a 68K Mac which is already handling DNS, mail, and web services for a handful of domains. A 'moderate' newsfeed these days really demands Sparc hardware running Solaris and writing to carefully-tuned RAID storage. A little weenie leaf site getting only a couple dozen groups, depending on volume, should be [okay] on a PowerMac or FreeBSD box or something with a couple more gigabytes than you think you need.

"... [T]his won't get around the need for news services from an upstream provider. It will, however, allow you to roll your own authorizations and let you access a single consistent news server from wherever you are on the road."

Perhaps, as one expert concluded:

"NNTP has all the globally-distributed-database complexity of DNS, plus all the backwards-compatible-with-archaic-standards complexity of Sendmail, plus its own unique scaling and performance issues the likes of which you've not yet had to experience for anything. Setting up a full newsfeed requires big-time hardware and big-time ongoing attention to low-level performance details. Setting up even a local caching proxy still ends up making you learn too much about a protocol -- and, in fact, a virtual society -- to make it worth approaching lightly."

On the other hand, these same sources told me a year ago that it wasn't worth the effort -- or even possible -- for lay people to set up free and shareware web and email service. They were the same, talented computer professionals who told me six months ago that I couldn't master DNS. If you're inclined, try it. But, if you succeed, maintain the free tradition of the Internet and write an article about your successful experiences. And, write to me so I can spread the word.

I've concluded that it really is senseless to spend time setting up an NNTP newsgroup server. I do not wish to host a newsgroup locally, and my only needs are for reading the groups I want. That service can be purchased for $3.95 per month for an anonymous, record-free feed at http://www.1usenet.com/, if you don't mind some minor bandwidth limitations. If you do mind the bandwidth limitations, $5.95 per month buys 18 parallel servers and no limitations. Four years of 80,000 newsgroups on spam-filtered or unfiltered servers costs less than an hour of my time. That's close enough to freeware!

Richard S. Sternberg is a member of the Washington Apple Pi Board of Directors and a Washington, DC, lawyer. He has recently published a book entitled, The Querulous Commitment (Xlibris 2001), available at your favorite on-line or local bookstore.