TCP/IP host name resolution for machines on several domains

#TCP/IP has become a predominant communications protocol in the telecommunications world today. It allows users to communicate world-wide using a single protocol over diverse transmission networks. A standard feature of TCP/IP is host address resolution. In host address resolution, the network address, also known as the IP address, of a host is determined from its name. For example, the name joe.raleigh.ibm.com might resolve to the network address 9.67.111.80. Address resolution must be done before a TCP/IP connection can be established with the destination host. The name resolution information may be stored locally in a hosts file on each host, but this approach is not practical for large networks. More commonly, this information is stored in the name resolution master file of a domain name server.

#The terms domain and domain name are used in a variety of contexts in the field of computer networking, but are used here in the same way as described in the Internet standards document "Request for Comments (RFC) 1034". Conformance to RFC 1034 enables the same name space to be used with different protocol families in dissimilar networks and applications.

#TCP/IP host and domain names are of the format label1.label2.label3 wherein each label is a string of alphanumeric characters beginning with a letter and possibly containing embedded hyphens. A domain name consists of a label or of several labels connected by periods. Domain names are organized in a hierarchical tree of subdomains. For example, domain bbbbbb.aaaaaa is a subdomain of aaaaaa, and domain cccccc.bbbbbb.aaaaaa is a subdomain of bbbbbb.aaaaaa. The TCP/IP name space is administered by the Internet Network Information Center (InterNIC). Internet standards direct that all domain names must be registered with this agency so that name conflicts do not occur.

#FIG. 1 shows a typical interconnection of IP networks.

#FIG. 2 demonstrates the prior art flow of a search for a destination host address in a configuration containing multiple IP networks.

#FIG. 3 depicts the logic traversed in locating the address of a destination host in the preferred embodiment of the present invention.

#FIG. 1 shows a typical configuration of multiple IP networks and some representative hosts connected to each of these networks. FIG. 1 displays three hosts 101, 102, 103, although in typical instances of IP networks, each network has hundreds or thousands of hosts associated with it. Host 101, which in the present example has an IP address of 9.67.111.1, is connected to two IP networks, represented in FIG. 1 by 110 and 111. IP network 110 has an IP address of 154.32.0.0 and is served by Domain Name Server (DNS) 115 at network address 154.32.0.110. The other IP network 111 has an IP address of 9.0.0.0 and is served by DNS 116 at network address 9.20.0.111. Host 102, which in the preferred embodiment has an IP address 154.68.0.2, is connected to network 110, and host 103, which in the illustrated configuration is at IP address 9.20.0.3, is connected only to network 111. These connections may be direct physical links, in which case host 101 would be a "multihomed" host directly attached to both networks 110 and 111, but in the general case connections are indirect ones through IP routers. Domain Name Server 115, residing on network 110, can resolve the address of host 102 from its name. Domain Name Server 116, residing on the network 111, can resolve the address of host 103 from its name. Using prior art techniques, DNS 116 cannot resolve the address of host 102, nor can any of the name servers with which DNS 116 communicates. Similarly, DNS 115 and the name servers with which it communicates have no information about host 103. This very common condition may occur when host 101 and host 102 are on different private networks, or when host 101 is on a private network and host 102 is on the Internet. Under the prior art process, a name space search by host 101 for host 102 would proceed as shown in FIG. 2.

#Assume that host 101 is configured to query name server 116 or some other name server in network 111, so that it can communicate with host 103 and other hosts on that network. As demonstrated in FIG. 2 at step 200, an application program on host 101 attempts to establish communication with host 102, and first issues a name server query to name server 116 in order to determine the address of host 102. This causes name server 116 to search its master file for host 102, and (when this fails) to query other name servers as indicated by step 205. Since host 102 is not known to the name servers on network 111, the query fails as shown at step 210 resulting in an "unknown host" reply being returned from domain name server 116 to host 101. Next the name resolution code on host 101 checks to see if there is a local names file on host 101 as indicated by step 215. If there is not, the resolution of the name of host 102 fails and "Unknown host" is returned as shown in step 220. If there is a local names file available for host 101, then a search is made of that file for host 102 at step 225. If someone had manually added host 102 to the names file, this process would resolve the address of host 102; otherwise host 102 would still be unknown. If host 102 is found in the local names file in step 230, then the address of host 102 is returned to the calling program in step 240; otherwise name resolution fails and at step 235 the host is determined to be unknown. It is possible to configure host 101 to use name server 115 instead of 116, in which case it will locate host 102--but if this is done host 101 will not be able to resolve the name of host 103 and other hosts on network 111.

#As is obvious from FIG. 1, there is a communications path between host 101 and host 102, and if host 101 can resolve the address of host 102, the prior art process provides for a way to route data packets between hosts 101 and 102. The problem under the prior art process is that host 101 cannot reliably resolve the address of host 102, except via a configuration change which disrupts communications with the rest of network 111. Also, there is no a priori way to know which domain name server should be used, based on the name to be resolved.