TECHNICAL FIELD OF THE INVENTION
This invention pertains to the arts of computer networks, addressing of computers on computer networks, and the administration and management of the addressing schemes. In particular, this invention relates to the arts of Internet Domain Name Servers; creation of Universal Resource Locators, Domain and Subdomain names; and management of virtual subdomains.
FEDERALLY SPONSORED RESEARCH AND DEVELOPMENT STATEMENT
This invention was not developed in conjunction with any Federally-sponsored contract.
A microfiche appendix consisting of 70 (seventy) frames on 1 (one) microfiche which was originally submitted with the related patent application is incorporated by reference into this specification.
BACKGROUND OF THE INVENTION
This application is a continuation filed under 37 CFR 1.53(b) of U.S. patent application Ser. No. 09/476,632, filed on Dec. 31, 1999.
The Internet is possibly the greatest advance in information technology since the invention of the Gutenberg movable type printing press. It's impact on society worldwide has truly only been realized to a fraction of its ultimate potential. The Internet is not a single computer network, however, but is a hierarchy of many computer networks, all of which are interconnected by various types of server computers.
Key to success of the Internet is the addressing scheme which was adopted. The addressing scheme allows two types of addressing to be used when one computer transmits data to another computer over the Internet. The first addressing scheme, referred to as the Internet Protocol (“IP”) address, is a numeric address value consisting of four binary octets separated by a period or “dot”, such as AA.BB.CC.DD. Each of the octets is allowed to range in value from 0 to FF hexadecimal, or to 255 decimal. The values towards the left of the address, such as AA and BB, are referred to as network addresses and are used for coarse resolution of the address, while the values towards the right of the address are used for fine resolution of the address, such as CC and DD.
For example, turning to FIG. 1, the Internet backbone (1) is a set of high-speed data transmission facilities which interconnect several key switching and routing centers. Domain servers (2 and 6) may connect directly to the backbone (1), or they may connect indirectly to the backbone through other servers and other networks. For example, the domain server (2) on the right serves the subnetwork (4) on the right, which interconnects one or more client computers (5) to each other and to the Internet. Data or messages to be sent to any of the computers on the right-side network (4) must be properly addressed to be routed to them. For example, the right domain server (2) may be assigned a particular range or set of ranges of IP addresses to serve, such as 155.179.00.XX. A computer on the right-side network (4) may be given an address within this range, such as 155.179.00.213 (in decimal). A second computer on the right-side network (4) may be given an address such as 155.179.00.111. So, the octets towards the right of the IP address are subaddresses of the server's address. This scheme of addressing and subaddressing is well known within the art.
This subaddressing scheme is designed to allow subnetworking as well. For example, as shown in FIG. 1, the left-side domain server (6) may be assigned an IP address range of 98.99.YY.XX (in decimal). Computers directly connected to its subnetwork (8) would receive addresses within this range, as given in the previous example. However, another subnetwork (11), or sub-subnetwork to be literally correct, may be interconnected to the left-side network (8) via another domain server, which may be referred to as a subdomain server (9). This subdomain server may be given a range of IP addresses within the range of IP addresses for the left-side network domain server (6), such as 98.99.192.XX. The internetworking scheme of the Internet is built upon this hierarchical structure of networks and addresses.
The use of the term “domain” with respect to addressing actually implies more than the numeric IP addressing just discussed, in Internet parlance. While computers may deal well with numeric values for addressing, human users do not deal well with long numbers. When the architects of the early versions of the Internet, known as the ARPAnet, considered previous numbering schemes for humans, such as telephone numbers, they recognized this problem. In order to make the Internet more “user-friendly”, a text-based addressing scheme was “overlaid” on top of the numeric IP addressing scheme. Thus, a hierarchy of text-based addresses was defined. At the top of the hierarchy is a domain, which in general a large range of IP addresses or group of addresses. For example, in FIG. 1, the right-side domain server (2) may be assigned an easy to remember domain name such as “uspto.gov”. Under the Internet domain name convention, the extension of the name following the period or “dot” helps to categorize the type of domain. In this example, “gov” refers to government domains. Coupled with the domain name, “uspto”, a particular domain server is addressed. Other extensions, such as “com” for commercial uses, “edu” for educational institutions and “net” for network services companies, are also available.
In order for messages and data to be actually routed to a computer using a domain name, a translation to a numeric IP address must be made. This is done by a number of distributed “domain name servers” (“DNS”), which can be queried by Internet routers to provide the translation. Each domain server maintains records regarding IP-to-domain name assignments for the domains which it serves. This translation technique and the protocol for updating records is described in the Internet Request For Comment (“RFC”) papers, which are public documents available from InterNIC. Of particular interest are:
(a) RFC1033, Domain Administrators Operations Guide
(b) RFC1034, Domain Name—Concepts and Facilities, and
(c) RFC 1035, Domain Name—Implementation and Specification.
These are public documents, and are well known within the art.
Continuing with the analogical structure to numeric IP addressing, domain names may be broken into two types of more resolute addresses. The first type is based upon directory structure of the file system on the server. For example, a subdirectory on the US Patent and Trademark Office's web server which contains general information might be named “gen_info”, and could be addressed as “www.uspto.gov/gen_info”. Subnetworks and virtual subnetworks may be addressed by prefixing the general domain name with a subdomain name or names. For example, a subnetwork which serves only the trademark division of the US Patent and Trademark Office may be given the subdomain name “tm”, allowing the subdomain server (such as 9 in FIG. 1) to be addressed as “tm.uspto.gov”. The two addressing schemes can be combined, such as “tm.uspto.gov/gen_info”, which would access a file named “gen_info.html” located in the root directory of the subdomain server for “tm” under the domain server for “uspto.gov”. Alternatively, if a subdirectory called “gen_info” exists on the subdomain server “tm”, a file named “index.html” may be accessed by a web browser which is pointed to this full address.
Virtual subdomains are special cases of subdomains, which may or may not actually refer to a separate subdomain server from the domain server, but may refer to a directory or other software facility on the domain server. This is referred to as “hosting” the subdomain on the domain server. Later, if the owner of the subdomain desires, a separate subnetwork may be established with a separate subdomain server, and the routing tables on the domain server are updated to reflect a “pass through” routing to the new subdomain server.
The routing tables for domains, subdomains, sub-subdomains, etc., are typically implemented as simple text files stored on the disk subsystem of the various servers, such as the disk subsystems (7 and 3) shown in FIG. 1. To promote the easy interchange and exchange of routing definitions, RFC1033 defines standard formats for a record for each domain name and subdomain name, and recommends that these be stored in flat text files on each domain server's disk subsystem. These records are referred to as “resource records”, or “RR” for short. Special records, referred to as “glue records”, serve as pointers to other name servers which can fully resolve, or translate, a domain-subdomain address to a numeric IP address. These records on each name server define different “zones”, which are subtrees of the address range or tree which the domain name server serves. These are particularly well defined in RFC1034 and RFC1035.
In operation, the address scheme is simple but time consuming to administer. A network administrator, or “webmaster”, is responsible for the manual configuration and maintenance of these records. At first glance, the task to create a new subdomain sounds simple, and is eloquently described as the following three steps on page 11 of RFC1033 Domain Operations Guide:
(1) Setup the new domain server and/or the new zone file,
(2) Add a Name Server record for each server of the new domain to the zone file of the parent domain, and
(3) Add any necessary glue Resource Records.
In reality, this may involve accessing physically or remotely the file systems of several servers, including log-on and password procedures. To be done correctly, some form of traffic engineering should be done to estimate the impact of adding a particular subdomain to the current name server with respect to the additional traffic or number of “hits” it will receive. The architecture implemented by the definitions and combinations of the domains and subdomains on specific server machines ultimately defines the performance and responsiveness of the network. Thus, not only do network administrators create new resource records when creating a new subdomain, but they also must continuously modify these records to optimize for ever-changing traffic patterns. A further drawback of the prior art process is that the creation of real subdomains has to be recognized and propagated by DNS servers throughout the Internet, a process that can take from 1 day to 2 weeks including administrative delays and 18 to 24 hours network propagation delay.
For these reasons, management and administration of subdomain names is quite time consuming in reality even though subdomains are an attractive option in various situations. So, while the addressing scheme is attractive from the user-interface perspective, it can be quite unattractive to the network planners due to the labor-intensive nature of operating the service.
Further, not all subdomain servers require dedicated and static IP addresses associated with their host names. Often, it is desirable to quickly create a sub-domain under the upper-level host domain name hierarchy so that different content can be published on the web which is more relevant to the subdomain name. An example would be “auctions.domain.com” to redirect the user to the “auctions” page under a more popular website called “www.domain.com”. Similarly other areas may also need special and direct attention, such as “shopping.domain.com”.
Therefore, there exists a need in the art for a system to quickly and efficiently create and manage subdomain names without extensive webmaster intervention. There is a need in the art for this system to be realizable on standard hardware and software platforms use for World-wide Web home page and domain name servers. Further, there is a need in the art for this new system and method to allow the virtual subdomains to be remotely located from the actual subdomain name server itself to enable the distribution of network server hardware resources and bandwidth demands.
SUMMARY OF THE INVENTION
The present invention modifies an existing domain name server platform in order to have it intercept all web browser queries to a higher level IP address, such as 157.6.7.xx, where “xx” is any value in the range of 1 - 254, or to any URL which is translated to fall within this IP address range. If the requested IP address or domain name is not recognized by the standard domain name server and the standard DNS database, a server script is launched to dynamically resolve the unknown address rather than returning a standard “Error 404: File Not Found” message to the requesting web browser. The script accesses a database of virtual subdomain names which are mapped in the database to actual subdirectories on the same or a remote server. For example, if a query to http://www.virtualsubdomain.domain.com is received, and virtualsubdomain.domain.com is not recognized as a registered domain name by the standard DNS server, the script will resolve it and map it to http://www.domain.com/subdomain, or any other file on a web server which is actually registered. Using this method, the creation of a virtual subdomain requires only the steps necessary to create a subdirectory. This enables it to be performed rapidly if handled manually, or it can be created automatically by any network client with privileges to create subdirectories on the web server in question.
To manage the virtual subdomains, the special subdomain database (55) can be edited manually using an administrator's interface to the database. Such manual database record creation is well known within the art. However, in order to allow web browser users to dynamically and instantly create virtual subdomains without waiting for official a registration processes to complete, a special virtual subdomain management server (501) is installed on the Internet. This is a standard web server, including hardware platform such as an Intel-based computer, running a web-server package, such as Apache HTTP server, and a suitable OS. It may be integrated with the special virtual subdomain name server (54, 55, and 56), or configured separately. In the preferred embodiment, a Common Gateway Interface (“CGI”) script (502) is used to transmit forms to the web browser (504) via the Internet connection (503) between the virtual subdomain management server (501)and the user's web browser. The forms allow the web browser user to select the name for his or her new virtual subdomain, to enter the domain name with subdirectory to which requests for the virtual subdomain should be redirected, and any other user information necessary to establish an account such as name, e-mail address, billing address, telephone number, etc. Through the CGI interface, the virtual subdomain management server (501) collects the information and creates a new record in the virtual subdomain mapping database (55) through a database application programming interface (“API”) (500). If the virtual subdomain management server is integrated with the virtual subdomain name server, this may be a simple database API call. However, if the virtual subdomain management server is networked to the virtual subdomain name server, a secure protocol to the database should be used to avoid unauthorized modification of the virtual subdomain mapping database.