3.2.1 Where in the World Do I Fit?

If your organization is attached to the Internet outside of the United States, you first need to decide whether you'd rather request a domain under the generic top-level domains, like com and edu, or under your country's top-level domain. The generic top-level domains, even though some are used largely by U.S. organizations, aren't exclusively for U.S. organizations. If your company is a multi- or transnational company, you may wish to join a generic top-level domain, or if you'd simply prefer a generic top-level to your country's top-level domain, you're welcome to ask to join one. If you choose this route, skip to the section Section 3.2.2.2, "The generic top-level domains" later in this chapter.

If you opt for a subdomain under your country's top level, you should check whether your country's top-level domain is registered, and if it is, what kind of structure it has. Consult our list of the current top-level domains (Appendix C, Top-Level Domains) if you're not sure what the name of your country's top-level domain would be.

Some countries' top-level domains, like New Zealand's nz, Australia's au, and the United Kingdom's uk, are divided organizationally into second-level domains. The names of their second-level domains, like co or com for commercial entities, reflect organizational affiliation. Others, like France's fr domain, and Canada's ca domain, are divided into a multitude of subdomains managed by individual universities and companies, like the University of St. Etienne's domain, univ-st-etienne.fr and Bell Northern Research's bnr.ca. You'll have to use a tool like nslookup to grope around and discover your top-level domain's structure if it isn't well-known. (If you're uncomfortable with our rushing headlong into nslookup without giving it a proper introduction, you might skim Chapter 11, nslookup.) For example, here's how you could list the au domain's subdomains using nslookup:

% nslookup - 207.69.188.185    - Use the name server at 207.69.188.185
Default Server:  ns1.mindspring.com
Address:  207.69.188.185

> set type=ns                  - Find the name servers (ns)
> au.                          - for the au domain
Server:  ns1.mindspring.com
Address: 207.69.188.185

au      nameserver = MUNNARI.OZ.AU
au      nameserver = MULGA.CS.MU.OZ.AU
au      nameserver = JATZ.AARNET.EDU.AU
au      nameserver = NS.UU.NET
au      nameserver = NS.EU.NET
au      nameserver = NS1.BERKELEY.EDU
au      nameserver = NS2.BERKELEY.EDU
au      nameserver = VANGOGH.CS.BERKELEY.EDU
MUNNARI.OZ.AU     internet address = 128.250.1.21
MUNNARI.OZ.AU     internet address = 128.250.22.2
MULGA.CS.MU.OZ.AU       internet address = 128.250.1.22
MULGA.CS.MU.OZ.AU       internet address = 128.250.37.150
JATZ.AARNET.EDU.AU      internet address = 139.130.204.4
NS.UU.NET         internet address = 137.39.1.3
NS.EU.NET         internet address = 192.16.202.11
NS1.BERKELEY.EDU  internet address = 128.32.136.9
NS1.BERKELEY.EDU  internet address = 128.32.206.9
NS2.BERKELEY.EDU        internet address = 128.32.136.12
NS2.BERKELEY.EDU        internet address = 128.32.206.12

> server ns1.berkeley.edu.        - Now query one of these name servers - preferably a close one!
Default Server:  ns1.berkeley.edu
Addresses:  128.32.136.9, 128.32.206.9

> ls au.  - List the au
zone
          - the zone's NS records mark delegation to
          - subdomains and will give
          - you the names of the subdomains
          - Note that not all name servers will allow you to list zones, for security reasons.
 [ns1.berkeley.edu]
          3D IN SOA      munnari.OZ hostmaster.munnari.OZ (
                  1998051400      ; serial
                  6H              ; refresh
                  1H              ; retry
                  23w5d16h        ; expire
                      3D )        ; minimum

              3D IN NS                        munnari.OZ
              3D IN NS                        mulga.cs.mu.OZ
              3D IN NS                        vangogh.CS.Berkeley.EDU.
              3D IN NS                        ns1.Berkeley.EDU.
              3D IN NS                        ns2.Berkeley.EDU.
              3D IN NS                        ns.UU.NET.
              3D IN NS                        ns.eu.NET.
ORG           1D IN NS                        yalumba.connect.COM
yalumba.connect.COM      1D IN A                 203.8.183.1
ORG           1D IN NS                        mulga.cs.mu.OZ
mulga.cs.mu.OZ           1D IN A                 128.250.1.22
              1D IN A                         128.250.37.150
ORG           1D IN NS                        rip.psg.COM.
              1D IN NS                        munnari.OZ
munnari.OZ               1D IN A                 128.250.1.21
              1D IN A                         128.250.22.2
info          1D IN NS                        ns.telstra.net.
              1D IN NS                        ns1.telstra.net.
              1D IN NS                        munnari.oz
munnari.oz               1D IN A                 128.250.1.21
              1D IN A                         128.250.22.2
info                     1D IN NS                svc01.apnic.net.
a             3D IN A                         139.130.23.2
otc           4H IN NS                        ns.telstra.com
ns.telstra.com           4H IN A                 192.148.160.10
otc           4H IN NS                        ns2.telstra.com
ns2.telstra.com          4H IN A                 192.148.160.11
otc           4H IN NS                        munnari.oz
munnari.oz               1D IN A                 128.250.1.21
              1D IN A                         128.250.22.2
CSIRO                    1D IN NS                steps.its.CSIRO
steps.its.CSIRO          1D IN A                 152.83.8.3
CSIRO                    1D IN NS                munnari.OZ
munnari.OZ               1D IN A                 128.250.1.21
                         1D IN A                 128.250.22.2
CSIRO                    1D IN NS                manta.vic.cmis.CSIRO
manta.vic.cmis.CSIRO     1D IN A                 144.110.16.100
CSIRO                    1D IN NS                dmssyd.nsw.cmis.CSIRO
dmssyd.nsw.cmis.CSIRO    1D IN A                 130.155.16.1
CSIRO                    1D IN NS                zoiks.per.its.CSIRO
zoiks.per.its.CSIRO      1D IN A                 192.245.210.1
[]

> ^D

The basic technique we used is straightforward: look up the list of authoritative name servers for the top-level domain - because they're the only ones with complete information about the corresponding zone - then connect to one of those name servers, and list the name servers for the second-level domains.

If you can't tell from the names of the subdomains which one you belong in, you can look up the contact information for the corresponding zone and send email to the technical contact asking, politely, for advice. Similarly, if you think you should be part of an existing subdomain but aren't sure, you can always ask the folks who administer that subdomain to double-check.

To find out who to ask about a subdomain, you'll have to look up the corresponding zone's SOA record. In each zone's start of authority (SOA) record, there's a field that contains the electronic mail address of the zone's technical contact.[2](The other fields in the start of authority record provide general information about a zone - we'll discuss them in more detail later.) You can look up the zone's SOA record with nslookup, too.

[2] The subdomain and the zone have the same domain name, but the SOA record really belongs to the zone, not the subdomain. The person at the zone's technical contact email address may not manage the whole subdomain (there may be additional delegated subdomains beneath), but he should certainly know what the purpose of the subdomain is.

If you're curious about the purpose of the csiro subdomain, you can find out who runs it by looking up csiro.au's SOA record:

% nslookup - 207.69.188.185
Default Server:  ns1.mindspring.com
Address:  207.69.188.185

> set type=soa     - Look for start of authority data
> csiro.au.        - for csiro.au
Server:  ns1.mindspring.com
Address: 207.69.188.185

csiro.au
        origin = steps.its.csiro.au
        mail addr = hostmaster.csiro.au
        serial = 1997122201
        refresh = 10800 (3 hours)
        retry   = 3600 (1 hour)
        expire  = 3600000 (41 days 16 hours)
        minimum ttl = 86400 (1 day)

The mail addr field is the Internet address of csiro.au's contact. To use the address with most UNIX mailers, you'll need to change the first "." in the address to a "@". So hostmaster.csiro.au becomes [email protected].[3]

[3] This form of Internet mail address is a vestige of two former DNS records, MB and MG. MB (mailbox) and MG (mail group) were to be DNS records specifying Internet mailboxes and mail groups (mailing lists) as subdomains of the appropriate domain. MB and MG never took off, but the address format they would have dictated is used in the SOA record, maybe for sentimental reasons.

3.2.1.1 whois

The whois service can also help you figure out what a given domain is for. Many vendors ship a simple whois client that queries a database on a host at the InterNIC (or on another host that you specify) for information about domains, networks, and the people that run them. For example:

% whois bob

will turn up every match for bob in the database, including people, networks and domains. To restrict the search to domains or networks, you can use the keywords dom or net, respectively:

% whois dom foo # print information on all domains that match foo
% whois -h whois.arin.net. net 17  # print information on network 17

If your copy of whois is outdated, it'll probably try to query the InterNIC's database on an old host, like sri-nic.arpa or nic.ddn.mil. That'll produce either a pleasant message from the InterNIC staff or a gruff error like this:

sri-nic.arpa: Unknown host

If this happens and you have access to the source code and a compiler, just recompile whois to query whois.internic.net. If you don't have the source, you can still direct whois to use whois.internic.net from the command line with the -h option, as in:

% whois -h whois.internic.net dom au

If you don't have a whois client, or would prefer a friendlier interface, you can use the InterNIC's whois web page, at http://rs.internic.net/cgi-bin/whois/. This gives you an HTML forms-based interface for querying the InterNIC's database.

Unfortunately, the InterNIC's whois database only lists contacts for top-level country domains and subdomains of generic top-level domains, so you won't find csiro.au. Still, you can use it to find the administrative contact for au.

Click on search, and you'll see a screen like Figure 3.1.[4]

[4] Believe it or not, when we did this for the first edition of this book, there was only one match.

Figure 3.1: The InterNIC's web-based whois interface

If we scroll down a little, we find "Australia top-level domain," which is what we're after. If you click on the hypertext link labeled "AU-DOM" on that line, you'll see a screen like Figure 3.2, which tells us to talk to Robert Elz about the top-level au domain.

Figure 3.2: Results of an InterNIC whois search

To get csiro.au contact information on the web, you'd need to query the Australian NIC. Is there such a thing? You can check http://www.allwhois.com/, shown in Figure 3.3 to find out. Click on "Australia" in the left-hand frame, and you'll see a screen like the one shown in Figure 3.4.

Figure 3.3: Detailed results of an InterNIC whois search

Figure 3.4: www.allwhois.com

Click on "Whois" to take you to a forms front-end that will let you query the AUNIC's (Australian NIC's) database.

Obviously, this is a very useful web site if you're looking for the contact for a domain outside of the U.S.

3.2.2 Elsewhere in the World

In true cosmopolitan spirit, we covered international domains first. But what if you're from the good ol' U.S. of A.?

If you're in the U.S., where you belong depends mainly upon how many hosts you have. If you only have one or two, or maybe a handful of hosts you'd like registered in the Internet's domain name space, you can join the us domain. The us domain registers individual hosts under third-level domains largely named after cities; the second-level domains correspond to the appropriate U.S. Postal Service two-letter state abbreviation (recall our discussion in the section called "The Internet Domain Name Space" in Chapter 2, How Does DNS Work?). So, for example, if all you need is to register the two internetworked hosts in your basement in Colorado Springs, Colorado, you can just have them added to the colospgs.co.us domain.

You can even get your own domain to manage, thanks to a change in policy by the administrators of the us domain. Originally, the us domain was purely geographical. The us domain administrators added address and mail handling information for your host(s) (more on this in the next two chapters - be patient), but not name server information. In other words, they wouldn't delegate a portion of their domain to you. Nowadays, they encourage U.S. schools, governments, and companies to join the us domain. If you're interested in the details, check out RFC 1480, available from ftp://ftp.ds.internic.net/rfc/rfc1480.txt, or see the information on the us domain on ISI's web site, at http://www.isi.edu/in-notes/usdnr/.

You can also ask for a subdomain of one of the generic top-level domains, like edu and com. As long as you don't ask for an overly long subdomain name (the InterNIC recommends 12 letters or fewer), or one that's already taken, you should get the one you ask for. We'll cover membership under the generic top-levels later in this chapter.

3.2.3 Checking That Your Network Is Registered

Before proceeding, you should check whether or not your IP network or networks are registered. Many parent domains won't delegate a subdomain to name servers on unregistered networks, and registries won't delegate an in-addr.arpa subdomain that corresponds to an unregistered network.

An IP network defines a range of IP addresses. For example, the network 15/8 is made up of all IP addresses in the range 15.0.0.0 to 15.255.255.255. The network 199.10.25/24 starts at 199.10.25.0 and ends at 199.10.25.255.

The InterNIC was once the official source of all IP networks; they assigned all IP networks to Internet-connected networks and made sure no two ranges overlapped. Nowadays, the InterNIC's old role has been largely assumed by Internet Service Providers (ISPs), who allocate space from their own networks for customers to use. If you know your network came from your ISP, the larger network from which your network was carved is probably registered (to your ISP). You may still want to double-check that your ISP took care of registering their network, but you don't (and probably can't) do anything yourself, except nag your ISP if they didn't register their network. Once you've verified their registration, you can skip the rest of this section and move on.

If, however, your network was assigned by the InterNIC, way back when, or you are an ISP, you should check to see whether your network is registered. Where do you go to check whether your network is registered? Why, to the same organizations that register networks, of course. These organizations, called (what else?) registries, each handle network registration in some part of the world. In the Western Hemisphere, ARIN, the American Registry of Internet Numbers, at http://www.arin.net/, hands out IP address space and registers networks. In Asia and the Pacific, APNIC, the Asia Pacific Network Information Center, at http://www.apnic.net/, serves the same function. In Europe, it's the RIPE Network Coordination Centre, at http://www.ripe.net/. Each registry may also delegate registration authority for a region; for example, ARIN delegates registration authority for Mexico and for Brazil to registries in each country. Be sure to check for a registry local to your country.

If you're not sure your network is registered, the best way to find it is to use the whois service provided by the various registries and look for your network. Here are the URLs for each registry's whois page:

ARIN

http://www.arin.net/whois/arinwhois.html

APNIC

http://www.apnic.net/reg.html

RIPE

http://www.ripe.net/db/whois.html

If you find out your network isn't registered, you'll need to get it registered before setting up your in-addr.arpa zones. Each registry has a different process for registering networks, but most involve money changing hands (from your hands to theirs, unfortunately).

You may find out that your network is already assigned to your ISP. If this is the case, you don't need to register independently with the registry.

Once all your Internet-connected hosts are on registered networks, you can give your parent domain a call.

3.2.4 Registering with Your Parent

Different domains have different registration policies. We've included the InterNIC's current registration form for second-level domains as Appendix D, Domain Registration Form. The form is only valid for registration under the InterNIC-run generic top-level domains like com and edu. (In other words, don't submit it to the administrators of the au or fr domain and expect them to honor it.) It should, however, give you an idea of what to expect in a registration form (especially if you're registering under one of the InterNIC's domains). Other domains often have more informal registration processes. Sometimes simply sending the "registrar" the necessary information in an email message will do.

Since the forms will undoubtedly become obsolete before we update this book again, you should check out the InterNIC's online, HTML forms-based registration process at http://www.rs.internic.net/rs-internic.html. Although this process doesn't actually submit the form yet, it does automate the process of creating a properly-formatted request that you can then email to the InterNIC. Or you can just retrieve the current forms and print them, then fill them out by hand.

The basic information that your parent needs is the names and addresses of your domain name servers. If you're not connected to the Internet, give them the addresses of the Internet hosts that will act as your name servers. Some parent domains also require that you already have operational name servers for your domain. (The InterNIC doesn't, but they ask for an estimate of when the domain will be fully operational.) If that's the case with your parent, skip ahead to Chapter 4, and set up your name servers. Then contact your parent with the requisite information.

If the InterNIC runs your parent domain, they'll also ask for some information about your organization, and for an administrative contact and a technical contact for your domain (which can be the same person). If your contacts aren't already registered in the InterNIC's whois database, you'll also need to provide information to register them in whois. This includes their names, surface mail addresses, phone numbers, and electronic mail addresses. If they are already registered in whois, just specify their InterNIC whois "handle" (a unique alphanumeric ID) in the registration.

There's one more aspect of registering a new domain with the InterNIC that we should mention: cost. Network Solutions, Inc. (NSI), the contractor that manages the InterNIC, has begun charging to register new top-level domains and domains under the generic top-level domains com, net, and org. The startup fee is $70 (U.S.). NSI has also instituted an ongoing, annual charge of U.S. $35 for each domain. If you already have a subdomain under com, net, or org and haven't received a bill from NSI recently, it'd be a good idea to check your contact information with whois to make sure they've got a current address and phone number for you. For more information on the billing policy and the current scoop on the InterNIC registration process, see http://www.rs.internic.net/rs-internic.html.

If you're directly connected to the Internet, you should also have the in-addr.arpa domains corresponding to your IP networks delegated to you. For example, if your company was allocated the network 192.201.44/24, you should manage the 44.201.192.in-addr.arpa domain. This will let you control the IP address-to-name mappings for hosts on your network. Chapter 4 also explains how to set up your in-addr.arpa domains.

In the last section, "Checking That Your Network Is Registered," we asked you to find the answers to several questions: is your network a slice of an ISP's network? Is your network, or the ISP's network that your network is part of, registered? In which registry? You'll need these answers to have your in-addr.arpa domains delegated to you.

If your network is part of a larger network registered to an ISP, you should contact the ISP to have the appropriate subdomains of in-addr.arpa delegated to you. Each ISP uses a different process for setting up in-addr.arpa delegation. Your ISP's web page is a good place to research that process. If you can't find the information there, try looking up the SOA record for the in-addr.arpa domain that corresponds to your ISP's network. For example, if your network is part of UUnet's 153.35/16 network, you could look up the SOA record of 35.153.in-addr.arpa to find the email address of the technical contact for the zone.

If your network is registered directly with one of the regional registries, contact them to get your in-addr.arpa domain registered. Each registry makes information on their delegation process available on its web site. ARIN's template for requesting in-addr.arpa delegation, inaddrtemplate.txt, is included in this book as Appendix E, in-addr.arpa Registration Form, and available online at http://rs.arin.net/templates/inaddrtemplate.txt.

Now that you've sent your prospective parent word that you'd like to be adopted, you'd better take some time to get your things in order. You've got a domain to set up, and in the next chapter, we'll show you how.