Don't Discard That Rotten Apple:

Make It an Internet Server, Part III

© 2001 Richard S. Sternberg

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.

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.

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.

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.

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

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.