Once you "own" a domain, you have complete freedom to create, deploy, and delegate as many sub-domains as you dare desire, and on a moment's notice. With tinydns, you are truly master of your own domain.

Let's consider this case study of the well-known international NGO, Example Org.

Example has headquarters offices in Fluxemborg, with far-flung field operations in dozens of countries scattered throughout some of the most remote reaches of the world. Although each field office has different IT capacities and bandwidth, Example would like to provide consistent and coordinated network services as far as is possible.

Here is a sketch, showing a piece of the functional topology of Example. Fluxemborg is the main office, with satellite offices in each of Etheropia, Gnubia, and Hackistan:

example.org

             +---+
             |   | "ether"
             |   |
             |   |
             +---+
            
           
"fluxe"   
    +---+
    |   |       +---+
    |   |       |   | "gnubi" 
    |   |       |   |
    +---+       |   |
                +---+
         
          
           
            +---+
            |   | "hacki"
            |   |
            |   |
            +---+

First, of course, Example registers and pays for its own domain, "example.org". They may use any of a number of DNS registration services for this, sticking with one of the common ".org", ".com", or ".net" top-level domains, and they will pay no more than, oh, about $12 per year. And from here on they will need to pay nothing more for DNS registrations for any sub-domain of "example.org", no matter how many field offices they set up in the future.

Next, each office is set up with its own Internet connection, doing the best it can with whatever local Internet service providers can offer. Alternatively, in the extreme conditions faced by very remote offices, satellite links are arranged; although the metered bandwidth usually comes at a higher cost, sometimes it is the only option.

Note that persistent connections are not strictly necessary for the field offices, because we can do a lot with "store and forward" technologies, and other strategies for bandwidth-challenged environments. But preferably --and for this illustration-- each office should be set up with its own static IP address.

Example then designates its own sub-domains for each field office. The naming scheme is based on the country code for the top-level domain ("cctld") of each location:

The last column describes the services provided by the local server at each location. Etheropia has minimal capabilities, and relies on Fluxemborg to relay all mail to/from the office, via intermittent connections. Gnubia has its own Internet-connected mail server, but relies on Fluxemborg for DNS services. Hackistan has the most capability, including its own DNS server; it only needs a delegation of authority from the primary DNS in Fluxemborg.

The sysadmin at headquarters can now get to work. First, these entries in the tinydns data file just for the Fluxemborg office:

# tinydns/root/data
# example.org
# ===
###
### SOA (SOA/NS/A):
.example.org:1.2.3.4:a:259200
### HOST (A/PTR):
=fluxe.example.org:1.2.3.4:86400
### MX (MX/A):
@example.org:1.2.3.4:mailhub.example.org:0:86400
### ALIAS (A):
+www.example.org:1.2.3.4:86400

Then these records for the Etheropia office. Although the office has its own IP address, Fluxemborg serves as the maildrop:

### etheropia:
###
### HOST (A only):
+ether.example.org:66.77.11.33:86400
+ep.example.org:66.77.11.33:86400
+ether.ep.example.org:66.77.11.33:86400
### MX (MX/A) maildrop here:
@ep.example.org:1.2.3.4:maildrop.ep.example.org:0:86400

Next the records for the Gnubia office. They have their own mailserver on "gnubi" as well as a web-server with items of interest. (As for the mailserver, we can collect mail in Fluxemborg if the Gnubi system is unreachable.)

### gnubia:
###
### HOST (A only):
+gnubi.example.org:112.211.212.121:86400
+gx.example.org:112.211.212.121:86400
+gnubi.gx.example.org:112.211.212.121:86400
### MX (MX/A) primary:
@gx.example.org:112.211.212.121:a:0:86400
### MX (MX/A) backup maildrop here:
@gx.example.org:1.2.3.4:maildrop.gx.example.org:10:86400
### ALIAS (A, gnubi own web server):
+www.gx.example.org:112.211.212.121:86400

Finally, the entries for the Hackistan office. Since Hackistan has its own DNS server, we just delegate the authority to it from Fluxemborg:

### hackistan:
###
### HOST (A only):
+hacki.example.org:90.80.70.60:86400
### NS delegation (NS/A):
&hs.example.org:90.80.70.60:a:259200

The sysadmin in Hackistan can maintain the tinydns data file on "hacki", like so:

# tinydns/root/data
# hs.example.org
# ===
###
### SOA (SOA/NS/A):
.hs.example.org:90.80.70.60:a:259200
### HOST (A/PTR):
=hacki.hs.example.org:90.80.70.60:86400
### MX (MX/A):
@hs.example.org:90.80.70.60:a:0:86400
### ALIAS (A):
+www.hs.example.org:90.80.70.60:86400

That's it! Example Org now has an integrated DNS system, with consistent naming conventions throughout the network. This will provide a flexible foundation for delivering other services throughout the organization, especially when it comes to electronic mail, as we will soon see in sections to come:

• fastforward internationale
• bushmail

1. Don't run your own DNS servers; be at the mercy of numerous incompetent and unresponsive local ISPs to do this for you.

2. In each country of operations, pay a high price to register a unique, inconsistent, and completely ambiguous domain name with that country's own DNS authority.

3. Use the "free" commercial webmail services, such as Yahoo! and Hotmail, for your organization's mail access.

Of course this way will cost more money --we have seen DNS registration charges as high as $200 per year, per domain in some countries. Users will also need good bandwidth for webmail, for even higher costs. And this strategy will ensure that all network integration efforts are more difficult or impossible.

Strangely, this does seem to be the preferred way of many international NGOs we have observed. Perhaps the higher costs helps them feel justified in asking donors for more money. And the more challenges, well, all the better to demonstrate the unrelenting efforts required to cope with them.

If you ask us, though, we think the djb way is better!