comp.protocols.tcp-ip.domains FAQ - Section 2
INTRODUCTION / MISCELLANEOUS

Question 2.1. What is this newsgroup ?

Date: Thu Dec 1 11:08:28 EST 1994

comp.protocols.tcp-ip.domains is the usenet newsgroup for discussion on issues relating to the Domain Name System (DNS).

This newsgroup is not for issues directly relating to IP routing and addressing. Issues of that nature should be directed towards comp.protocols.tcp-ip.

Question 2.2. More information

Date: Fri Dec 6 00:41:03 EST 1996

You can find more information concerning DNS in the following places:

Question 2.3. What is BIND ?

Date: Tue Sep 10 23:15:58 EDT 1996

From the BOG Introduction -

The Berkeley Internet Name Domain (BIND) implements an Internet name server for the BSD operating system. The BIND consists of a server (or ``daemon'') and a resolver library. A name server is a network service that enables clients to name resources or objects and share this information with other objects in the network. This in effect is a distributed data base system for objects in a computer network. BIND is fully integrated into BSD (4.3 and later releases) network programs for use in storing and retrieving host names and address. The system administrator can configure the system to use BIND as a replacement to the older host table lookup of information in the network hosts file /etc/hosts. The default configuration for BSD uses BIND.

Question 2.4. What is the difference between BIND and DNS ?

Date: Tue Sep 10 23:15:58 EDT 1996

(text provided by Andras Salamon) DNS is the Domain Name System, a set of protocols for a distributed database that was originally designed to replace /etc/hosts files. DNS is most commonly used by applications to translate domain names of hosts to IP addresses. A client of the DNS is called a resolver; resolvers are typically located in the application layer of the networking software of each TCP/IP capable machine. Users typically do not interact directly with the resolver. Resolvers query the DNS by directing queries at name servers that contain parts of the distributed database that is accessed by using the DNS protocols. In common usage, `the DNS' usually refers just to the data in the database.

BIND (Berkeley Internet Name Domain) is an implementation of DNS, both server and client. Development of BIND is funded by the Internet Software Consortium and is coordinated by Paul Vixie. BIND has been ported to Windows NT and VMS, but is most often found on Unix. BIND source code is freely available and very complex; most of the development on the DNS protocols is based on this code; and most Unix vendors ship BIND-derived DNS implementations. As a result, the BIND name server is the most widely used name server on the Internet. In common usage, `BIND' usually refers to the name server that is part of the BIND distribution, and sometimes to name servers in general (whether BIND-derived or not).

Question 2.5. Where is the latest version of BIND located ?

Date: Mon Jun 15 21:22:45 EDT 1998

This information may be found at http://www.vix.com/isc/bind/.

Presently, there are two 'production level' versions of BIND. They are versions 4 and 8.

Version 4 is the last "traditional" BIND -- the one everybody on the Internet runs, except a few hundred sites running...

Version 8 has been called "BIND-ng" (Next Generation). Many new features are found in version 8.

BIND-8.1 has the following features:

Bind version 8.1.2 may be found at the following location: At this time, BIND version 4.9.7 may be found for anonymous ftp from

ftp.isc.org : /isc/bind/src/4.9.7/bind-4.9.7-REL.tar.gz

Other sites that officially mirror the BIND distribution are

You may need GNU zip, Larry Wall's patch program (if there are any patch files), and a C compiler to get BIND running from the above mentioned source.

GNU zip is available for anonymous ftp from

prep.ai.mit.edu : /pub/gnu/gzip-1.2.4.tar

patch is available for anonymous ftp from

prep.ai.mit.edu : /pub/gnu/patch-2.1.tar.gz

A version of BIND for Windows NT is available for anonymous ftp from

ftp.isc.org : /isc/bind/contrib/ntbind/ntdns497relbin.zip

and

ftp.isc.org : /isc/bind/contrib/ntbind/ntbind497rel.zip

If you contact access@drcoffsite.com, he will send you information regarding a Windows NT/WIN95 bind port of 4.9.6 release.

A Freeware version of Bind for NT is available at http://www.software.com.

Question 2.6. How can I find the path taken between two systems/domains ?

Date: Wed Jan 14 12:07:03 EST 1998

On a Unix system, use traceroute. If it is not available to you, you may obtain the source source for 'traceroute', compile it and install it on your system.

One version of this program with additional functionality may be found for anonymous ftp from

ftp.nikhef.nl : /pub/network/traceroute.tar.Z

Another version may be found for anonymous ftp from

ftp.psc.edu : /pub/net_tools/traceroute.tar

NT/Windows 95 users may use the command TRACERT.EXE, which is installed with the TCP/IP protocol support. There is a Winsock utility called WS_PING by John Junod that provides ping, traceroute, and nslookup functionality.

There are several shareware TCP/IP utilities that provide ping, traceroute, and DNS lookup functionality for a Macintosh: Mac TCP Watcher and IP Net Monitor are two of them.

Question 2.7. How do you find the hostname given the TCP-IP address ?

Mon Jun 15 21:32:57 EDT 1998

For an address a.b.c.d you can always do: 

         % nslookup
         > set q=ptr
         > d.c.b.a.in-addr.arpa.
Most newer version of nslookup (since 4.8.3) will recognize an address, so you can just say: 
         % nslookup a.b.c.d
DiG will work like this also: 
         % dig -x a.b.c.d
dig is included in the bind distribution. host from the bind distribution may also be used.

On a Macintosh, some shareware utilities may be used. IP Net Monitor has a very nice NS Lookup feature, producing DiG-like output; Mac TCP Watcher just has a simple name-to-address and address-to-name translator.

Question 2.8. How do I register a domain ?

Date: Mon Jun 15 23:03:43 EDT 1998

Procedures for registering a domain name depend on the top level domain (TLD) to which the desired domain name will belong, i.e. the rightmost suffix of the desired domain name. See the answer to "Top level domains" question in the DEFINITIONS SECTION of this FAQ.

Although domain registration may be performed by a direct contact with the appropriate domain registration authorities (domain name registrars), the easiest way to do it is to talk to your Internet Service Providers. They can submit a domain registration request on your behalf, as well as to set up secondary DNS for your domain (or both DNS servers, if you need a domain name for Web hosting and/or mail delivery purposes only).

In the case where the registration is done by the organization itself, it still makes the whole process much easier if the ISP is approached for secondary (see RFC 2182) servers _before_ the InterNIC is approached for registration.

In any case, you will need at least two domain name servers when you register your domain. Many ISP's are willing to provide primary and/or secondary name service for their customers. If you want to register a domain name ending with .COM, .NET, .ORG, you'll want to take a look to the InterNIC:

Please note that the InterNIC charges a fee for domain names in the "COM", "ORG", and "NET". More information may be found from the Internic at

http://rs.internic.net/domain-info/fee-policy.html.

Note that InterNIC doesn't allocate and assign IP numbers any more. Please refer to the answer to "How do I get my address assigned from the NIC?" in this section.

Registration of domain names ending with country code suffixes (ISO 3166 - .FR, .CH, .SE etc.) is being done by the national domain name registrars (NICs). If you want to obtain such a domain, please refer to the following links:

Additional domain/whois information may be found:

Many times, registration of a domain name can be initiated by sending e-mail to the zone contact. You can obtain the contact in the SOA record for the country, or in a whois server: 
         $ nslookup -type=SOA fr.
         origin = ns1.nic.fr
         mail addr = nic.nic.fr
         ...
The mail address to contact in this case is 'nic@nic.fr' (you must substitute an '@' for the first dot in the mail addr field).

An alternate method to obtain the e-mail address of the national NIC is the 'whois' server at InterNIC.

You may be requested to make your request to another email address or using a certain information template/application. You may be requested to make your request to another email address or using a certain information template/application. Please remember that every TLD registrar has its own registration policies and procedures.

Question 2.9. How can I change the IP address of our server ?

Date: Wed Jan 14 12:09:09 EST 1998

(From Mark Andrews) Before the move.

Move the machine after gracefully terminating any other services it is offering. Then,

Question 2.10. Issues when changing your domain name

Date: Sun Nov 27 23:32:41 EST 1994

If you are changing your domain name from abc.foobar.com to foobar.net, the forward zones are easy and there are a number of ways to do it. One way is the following:

Have a single db file for the 2 domains, and have a single machine be the primary server for both abc.foobar.com and foobar.net.

To resolve the host foo in both domains, use a single zone file which merely uses this for the host: 

foo             IN      A       1.2.3.4
Use a "@" wherever the domain would be used ie for the SOA: 
@               IN      SOA     (...
Then use this pair of lines in your named.boot: 
primary         abc.foobar.com  db.foobar
primary         foobar.net      db.foobar
The reverse zones should either contain PTRs to both names, or to whichever name you believe to be canonical currently.

Question 2.11. How memory and CPU does DNS use ?

Date: Fri Dec 6 01:07:56 EST 1996

It can use quite a bit ! The main thing that BIND needs is memory. It uses very little CPU or network bandwidth. The main considerations to keep in mind when planning are:

As an example, here is a snapshot of memory usage from CSIRO Division of Mathematics and Statistics, Australia 
      Named takes several days to stabilize its memory usage.
 
      Our main server stabalises at ~10Mb. It takes about 3 days to
      reach this size from 6 M at startup. This is under Sun OS 4.1.3U1.
As another example, here is the configuration of ns.uu.net (from late 1994): 
      ns.uu.net only does nameservice.  It is running a version of BIND
      4.9.3 on a Sun Classic with 96 MB of RAM, 220 MB of swap (remember
      that Sun OS will reserve swap for each fork, even if it is not needed)
      running Sun OS 4.1.3_U1.

      Joseph Malcolm, of Alternet, states that named generally hovers at 
      5-10% of the CPU, except after a reload, when it eats it all.

Question 2.12. Other things to consider when planning your servers

Date: Mon Jan 2 14:24:51 EST 1995

When making the plans to set up your servers, you may want to also consider the following issues: 

        A) Server O/S limitations/capacities (which tend to be widely
           divergent from vendor to vendor)
        B) Client resolver behavior (even more widely divergent)
        C) Expected query response time
        D) Redundancy
        E) Desired speed of change propagation
        F) Network bandwidth availability
        G) Number of zones/subdomain-levels desired
        H) Richness of data stored (redundant MX records? HINFO records?)
        I) Ease of administration desired
        J) Network topology (impacts reverse-zone volume)
 
  Assuming a best-possible case for the factors above, particularly (A), (B),
  (C), (F), (G) & (H), it would be possible to run a 1000-node domain
  using a single lowly 25 or 40 MHz 386 PC with a fairly modest amount of RAM 
  by today's standards, e.g. 4 or 8 Meg.   However, this configuration would 
  be slow, unreliable, and would provide no functionality beyond your basic 
  address-to-name and name-to-address mappings.
 
  Beyond that baseline case, depending on what factors listed above,
  you may want look at other strategies, such splitting up the DNS
  traffic among several machines strategically located, possibly larger ones,
  and/or subdividing your domain itself. There are many options, tradeoffs, 
  and DNS architectural paradigms from which to choose.

Question 2.13. Reverse domains (IN-ADDR.ARPA) and their delegation

Date: Mon Jun 15 23:28:47 EDT 1998

(The following section was contributed by Berislav Todorovic.)

Reverse domains (subdomains of the IN-ADDR.ARPA domain) are being used by the domain name service to perform reverse name mapping - from IP addresses to host names. Reverse domains are more closely related to IP address space usage than to the "forward" domain names used. For example, a host using IP address 10.91.8.6 will have its "reverse" name: 6.8.91.10.IN-ADDR.ARPA, which must be entered in the DNS, by a PTR record: 

6.8.91.10.in-addr.arpa.     IN     PTR     myserver.mydomain.com.
In spite of the fact that IP address space is not longer divided into classes (A, B, C, D, E - see the answer to "What is CIDR?" in the DEFINITIONS section), the reverse host/domain names are organized on IP address byte boundaries. Thus, the reverse host name 6.8.91.10.IN-ADDR.ARPA may belong to one of the following reverse domains, depending on the address space allocated/assigned to you and your DNS configuration: 
(1) 8.91.10.in-addr.arpa -> 
       assigned one or more "C class" networks (IP >= /24)
(2) 91.10.in-addr.arpa   -> 
       assigned a whole "B class" 10.91/16      (IP = /16)
(3) ISP dependent        -> 
       assigned < "C class" - e.g. 10.91.8/26   (IP < /24)
No matter what is your case (1, 2 or 3) - the reverse domain name must be properly delegated - registered in the IN-ADDR.ARPA zone. Otherwise, translation IP -> host name will fail, which may cause troubles when using some Internet services and accessing some public sites.

To register your reverse domain, talk to your Internet service provider, to ensure proper DNS configuration, according to your network topology and address space assigned. They will point you to a further instance, if necessary. Generally speaking, while forward domain name registration is a matter of domain name registrars (InterNIC, national NICs), reverse domain name delegation is being done by the authorities, assigning IP address space - Internet service providers and regional Internet registries (see the answer to "How do I get my address assigned from the NIC?" in this section).

Important notes:

(1) If you're assigned a block or one or more "Class C" networks, you'll have to maintain a separate reverse domain zone file for each "Class C" from the block. For example, if you're assigned 10.91.8/22, you'll have to configure a separate zone file for 4 domains: 

8.91.10.in-addr.arpa
9.91.10.in-addr.arpa
10.91.10.in-addr.arpa
11.91.10.in-addr.arpa
and to delegate them further in the DNS (according to the advice from your ISP).

(2) If you're assigned a whole "B class" (say, 10.91/16), you're in charge for the whole 91.10.IN-ADDR.ARPA zone. See the answer to "How do I subnet a Class B Address?" in the CONFIGURATION section.

(3) If you're assigned only a portion of a "C class" (say, 10.91.8.0/26) see the answer to "Subnetted domain name service" question in the CONFIGURATION section.

For more information on reverse domain delegations see:

Question 2.14. How do I get my address assigned from the NIC ?

Date: Mon Jun 15 22:48:24 EDT 1998

IP address space assignment to end users is no longer being performed by regional Internet registries (InterNIC, ARIN, RIPE NCC, APNIC). If you need IP address space, you should make a request to your Internet service provider. If you already have address space and need more IP numbers, make a request to your ISP again and you may be given more numbers (different ISPs have different allocation requirements and procedures). If you are a smaller ISP - talk to your upstream ISP to obtain necessary numbers for your customers. If you change the ISP in the future, you MAY have to renumber your network. See RFC 2050 and RFC 2071 for more information on this issue.

Currently, address space is being distributed in a hierarchical manner: ISPs assign addresses to their end customers. The regional Internet registries allocate blocks of addresses (usually sized between /19 (32 "C class") and /16 (a "B class")) to the ISPs. Finally - IANA (Internet Assigned Number Authority) allocates necessary address space (/8 ("A class") sized blocks) to the regional registries, as the need for address space arises. This hierarchical process ensures more efficient routing on the backbones (less traffic caused by routing information updates, better memory utilization in backbone routers etc.) as well as more rational address usage.

If you are an ISP, planning to connect yourself to more than one ISP (i.e. becoming multi-homed) and/or expecting to have a lot of customers, you'll have to obtain ISP independent address space from a regional Internet registry. Depending on your geographical locations, you can obtain such address blocks (/19 and larger blocks) from:

While the regional registries do not sell address space, they do charge for their services (allocation of address space, reverse domain delegations etc.)

Question 2.15. Is there a block of private IP addresses I can use?

Date: Sun May 5 23:02:49 EDT 1996

Yes there is. Please refer to RFC 1918: 

   1918 Address Allocation for Private Internets. Y. Rekhter, B.
        Moskowitz, D. Karrenberg, G. de Groot, & E. Lear. February 1996.
        (Format: TXT=22270 bytes)
RFC 1918 documents the allocation of the following addresses for use by ``private internets'': 
        10.0.0.0        -   10.255.255.255
        172.16.0.0      -   172.31.255.255
        192.168.0.0     -   192.168.255.255

Question 2.16. Does BIND cache negative answers (failed DNS lookups) ?

Date: Mon Jan 2 13:55:50 EST 1995

Yes, BIND 4.9.3 and more recent versions will cache negative answers.

Question 2.17. What does an NS record really do ?

Date: Wed Jan 14 12:28:46 EST 1998

The NS records in your zone data file pointing to the zone's name servers (as opposed to the servers of delegated subdomains) don't do much. They're essentially unused, though they are returned in the authority section of reply packets from your name servers.

However, the NS records in the zone file of the parent domain are used to find the right servers to query for the zone in question. These records are more important than the records in the zone itself.

However, if the parent domain server is a secondary or stub server for the child domain, it will "hoist" the NS records from the child into the parent domain. This frequently happens with reverse domains, since the ISP operates primary reverse DNS for its CIDR block and also often runs secondary DNS for many customers' reverse domains.

Caching servers will often replace the NS records learned from the parent server with the authoritative list that the child server sends in its authority section. If the authoritative list is missing the secondary servers, those caching servers won't be able to look up in this domain if the primary goes down.

After all of this, it is important that your NS records be correct !

Question 2.18. DNS ports

Date: Wed Jan 14 12:31:39 EST 1998

The following table shows what TCP/UDP ports bind before 8.x DNS uses to send and receive queries: 

   Prot Src   Dst   Use
   udp  53    53    Queries between servers (eg, recursive queries)
                    Replies to above
   tcp  53    53    Queries with long replies between servers, zone 
                    transfers Replies to above
   udp  >1023 53    Client queries (sendmail, nslookup, etc ...)
   udp  53    >1023 Replies to above
   tcp  >1023 53    Client queries with long replies
   tcp  53    >1023 Replies to above

   Note: >1023 is for non-priv ports on Un*x clients. On other client 
         types, the limit may be more or less.
BIND 8.x no longer uses port 53 as the source port for recursive queries. By defalt it uses a random port >1023, although you can configure a specific port (53 if you want).

Another point to keep in mind when designing filters for DNS is that a DNS server uses port 53 both as the source and destination for its queries. So, a client queries an initial server from an unreserved port number to UDP port 53. If the server needs to query another server to get the required info, it sends a UDP query to that server with both source and destination ports set to 53. The response is then sent with the same src=53 dest=53 to the first server which then responds to the original client from port 53 to the original source port number.

The point of all this is that putting in filters to only allow UDP between a high port and port 53 will not work correctly, you must also allow the port 53 to port 53 UDP to get through.

Also, ALL versions of BIND use TCP for queries in some cases. The original query is tried using UDP. If the response is longer than the allocated buffer, the resolver will retry the query using a TCP connection. If you block access to TCP port 53 as suggested above, you may find that some things don't work.

Newer version of BIND allow you to configure a list of IP addresses from which to allow zone transfers. This mechanism can be used to prevent people from outside downloading your entire namespace.

Question 2.19. What is the cache file

Date: Fri Dec 6 01:15:22 EST 1996

From the "Name Server Operations Guide" 

      6.3.  Cache Initialization
 
         6.3.1.  root.cache
 
                 The name server needs to know the servers that
            are  the  authoritative  name  servers for the root
            domain of the network.  To do this we have to prime
            the name server's cache with the addresses of these
            higher authorities.  The location of this  file  is
            specified  in  the  boot  file. ...

Question 2.20. Obtaining the latest cache file

Date: Fri Dec 6 01:15:22 EST 1996

If you have a version of dig running, you may obtain the information with the command 

      dig @a.root-servers.net. . ns
A perl script to handle some possible problems when using this method from behind a firewall and that can also be used to periodically obtain the latest cache file was posted to comp.protocols.tcp-ip.domains during early October, 1996. It was posted with the subject "Keeping db.cache current". It is available at http://www.users.pfmc.net/~cdp/cptd-faq/current_db_cache.txt.

The latest cache file may also be obtained from the InterNIC via ftp or gopher: 

      ;       This file is made available by InterNIC registration services
      ;       under anonymous FTP as
      ;           file                /domain/named.root
      ;           on server           FTP.RS.INTERNIC.NET
      ;       -OR- under Gopher at    RS.INTERNIC.NET
      ;           under menu          InterNIC Registration Services (NSI)
      ;              submenu          InterNIC Registration Archives
      ;           file                named.root

Question 2.21. Selecting a nameserver/root cache

Date: Mon Aug 5 22:54:11 EDT 1996

Exactly how is the a root server selected from the root cache? Does the resolver attempt to pick the closest host or is it random or is it via sortlist-type workings? If the root server selected is not available (for whatever reason), will the the query fail instead of attempting another root server in the list ?

Every recursive BIND name server (that is, one which is willing to go out and find something for you if you ask it something it doesn't know) will remember the measured round trip time to each server it sends queries to. If it has a choice of several servers for some domain (like "." for example) it will use the one whose measured RTT is lowest.

Since the measured RTT of all NS RRs starts at zero (0), every one gets tried one time. Once all have responded, all RTT's will be nonzero, and the "fastest server" will get all queries henceforth, until it slows down for some reason.

To promote dispersion and good record keeping, BIND will penalize the RTT by a little bit each time a server is reused, and it will penalize the RTT a _lot_ if it ever has to retransmit a query. For a server to stay "#1", it has to keep on answering quickly and consistently.

Note that this is something BIND does that the DNS Specification does not mention at all. So other servers, those not based on BIND, might behave very differently.

Question 2.22. Domain names and legal issues

Date: Mon Jun 15 22:15:32 EDT 1998

A domain name may be someone's trademark and the use of a trademark without its owner's permission may be a trademark violation. This may lead to a legal dispute. RFC 1591 allows registration authorities to play a neutral role in domain name disputes, stating that: 

     In case of a dispute between domain name registrants as to the
     rights to a particular name, the registration authority shall have
     no role or responsibility other than to provide the contact
     information to both parties.
The InterNIC's current domain dispute policy (effective February 25, 1998) is located at:

http://www.internic.net/domain-info/internic-domain-6.html

Other domain registrars have similar domain dispute policies.

The following information was submitted by Carl Oppedahl oppedahl@patents.com :

If the jealous party happens to have a trademark registration, it is quite likely that the domain name owner will lose the domain name, even if they aren't infringing the trademark. This presents a substantial risk of loss of a domain name on only 30 days' notice. Anyone who is the manager of an Internet-connected site should be aware of this risk and should plan for it.

See "How do I protect myself from loss of my domain name?" at http://www.patents.com/weblaw.sht#domloss.

For an example of an ISP's battle to keep its domain name, see http://www.patents.com/nsi.sht.

A compendium of information on the subject may be found at http://www.law.georgetown.edu/lc/internic/domain1.html.

Question 2.23. Iterative and Recursive lookups

Date: Wed Jul 9 22:05:32 EDT 1997

Q: What is the difference between iterative and recursive lookups ? How do you configure them and when would you specify one over the other ?

A: (from an answer written by Barry Margolin) In an iterative lookup, the server tells the client "I don't know the answer, try asking <list of other servers>". In a recursive lookup, the server asks one of the other servers on your behalf, and then relays the answer back to you.

Recursive servers are usually used by stub resolvers (the name lookup software on end systems). They're configured to ask a specific set of servers, and expect those servers to return an answer rather than a referral. By configuring the servers with recursion, they will cache answers so that if two clients try to look up the same thing it won't have to ask the remote server twice, thus speeding things up.

Servers that aren't intended for use by stub resolvers (e.g. the root servers, authoritative servers for domains). Disabling recursion reduces the load on them.

In BIND 4.x, you disable recursion with "options no-recursion" in the named.boot file.

Question 2.24. Dynamic DNS

Date: Wed Jul 9 22:05:32 EDT 1997

Q: Bind 8 includes some support for Dynamic DNS as specified in RFC 2136. It does not currently include the authentication mechanism that is described in RFC 2137, meaning that any update requests received from allowed hosts will be honored.

Could someone give me a working example of what syntax nsupdate expects ? Is it possible to write an update routine which directs it's update to a particular server, ignoring what the DNS servers are the serving NS's?

A: You might check out Michael Fuhr's Net::DNS Perl module, which you can use to put together dynamic update requests. See http://www.dimensional.com/~mfuhr/perldns/Update.html for additional information. Michael posted a sample script to show how to use Net::DNS: 

     #!/usr/local/bin/perl -w
     use Net::DNS;
     $res = new Net::DNS::Resolver;
     $res->nameservers("some-nameserver.foo.com");
     $update = new Net::DNS::Update("foo.com");
     $update->push("update", rr_del("old-host.foo.com"));
     $update->push("update", rr_add("new-host.foo.com A 10.1.2.3"));
     $ans = $res->send($update);
     print $ans ? $ans->header->rcode : $res->errorstring, "\n";
Additional information for Dynamic DNS updates may be found at http://simmons.starkville.ms.us/tips/081797/.

Question 2.25. What version of bind is running on a server ?

Date: Mon Mar 9 22:15:11 EST 1998

On 4.9+ servers, you may obtain the version of bind running with the following command:

dig @server.to.query txt chaos version.bind.

and optionally pipe that into 'grep VERSION'. Please note that this will not work on an older nameserver.

Next: UTILITIES .
Back: TO DO / UPDATES.
Return to contents.

Chris Peckham - 16 July 1998

Extracted from comp.protocols.tcp-ip.domains Frequently Asked Questions, Copyright 1998.