[go: up one dir, main page]

WO2002039699A1 - Extensions de systeme de nom de domaine destinees a supporter des operations de mandataires inverses et des reacheminements de couche 7 - Google Patents

Extensions de systeme de nom de domaine destinees a supporter des operations de mandataires inverses et des reacheminements de couche 7 Download PDF

Info

Publication number
WO2002039699A1
WO2002039699A1 PCT/US2000/042125 US0042125W WO0239699A1 WO 2002039699 A1 WO2002039699 A1 WO 2002039699A1 US 0042125 W US0042125 W US 0042125W WO 0239699 A1 WO0239699 A1 WO 0239699A1
Authority
WO
WIPO (PCT)
Prior art keywords
dns
reverse proxy
client
address
proxy servers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2000/042125
Other languages
English (en)
Inventor
John M. Scharber
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cacheflow Inc
Entera Inc
Original Assignee
Cacheflow Inc
Entera Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cacheflow Inc, Entera Inc filed Critical Cacheflow Inc
Priority to PCT/US2000/042125 priority Critical patent/WO2002039699A1/fr
Priority to AU2001232699A priority patent/AU2001232699A1/en
Publication of WO2002039699A1 publication Critical patent/WO2002039699A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1021—Server selection for load balancing based on client or server locations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1038—Load balancing arrangements to avoid a single path through a load balancer

Definitions

  • the present invention relates to a scheme for supporting the use of reverse proxies and application-layer redirection within computer networks, such as the Internet, that utilize a domain name system for identifying network resources.
  • the Internet is a vast and expanding network of networks of computers and other devices linked together by various telecommunications media, enabling all these computers and other devices to exchange and share data.
  • Sites on the Internet provide information about a myriad of corporations and products, as well as educational, research and entertainment information and services. Many millions of people worldwide use the Internet today, with even larger numbers predicted to be on the "net” in a matter of years.
  • a computer or resource that is attached to the Internet is often referred to as a "host ' Examples of such resources include conventional computer systems that are made up of one or more processors, associated memory (typically volatile and nonvolatile) and other storage devices and peripherals that allow for connection to the Internet or other networks (e.g., modems, network interfaces and the like).
  • the hosting resource may be embodied as hardware and/or software components of a server or other computer system that includes an interface, which allows for some dialog with users thereof.
  • a server will be accessed through the Internet (e.g., via Web browsers such as Netscape's NavigatorTM and CommunicatorTM and Microsoft's Internet ExplorerTM) in the conventional fashion.
  • an Internet user desires to establish a connection with a host (e.g., to view a Web page located thereat) the user might enter into a Web browser program the URL (or Web address) corresponding to that host.
  • a URL or Web address
  • the first element of the URL is a trapsfer protocol (most commonly, "http” standing for hypertext transfer protocol, but others include “mailto” for electronic mail, "ftp” for file transfer protocol, and "nntp” for network news transfer protocol).
  • the remaining elements of this URL in this case, "www” standing for World Wide Web—the Internet's graphical user interface-and
  • Each fully qualified domain name in its most generic form, includes three elements. Taking “computer.host.com” as an example, the three elements are the hostname ("computer”), a domain name (“host”) and a top-level domain (“com”). Further, each fully qualified domain name is unique throughout the Internet and corresponds to a numerical Internet Protocol (IP) address. IP addresses facilitate communications between hosts and clients in the same way that physical addresses (e.g., 123 Main Street, Anytown, Anycity) facilitate correspondence by regular mail. Each IP address is made up of four groups of numbers separated by decimals. Thus, in the case of the hypothetical host "computer.domain.com", the corresponding IP address might be 123.456.78.91. A given host looks up the IP addresses of other hosts on the Internet through a system known as the domain name service (DNS). It should be recognized that DNS is a logical mapping and may not return a one-to-one association between hosts and addresses.
  • DNS domain name service
  • DNS Global System for Mobile communications
  • RFC 1034 Domain Names - Concepts and Facilities
  • P. Mockapetris, RFC 1035 Domain Implementation and Specification
  • November 1987 both available from the Internet Engineering Task Force at www.ietf.org.
  • the goal of DNS is to provide a mechanism for naming resources in such a way that the names are usable in and by different hosts, networks, protocol families, internets, and administrative organizations.
  • domain names may be passed as arguments in a query to a local agent, called a resolver, which then retrieves information (e.g., IP addresses) associated with the domain name.
  • the database that makes up the domain space i.e., the database of domain names
  • DNS servers names servers
  • a resolver processes a user query it asks a known name server for the requested information; in return, the resolver either receives the desired information or a referral to another name server. Using these referrals, resolvers learn the identities and contents of other name servers.
  • Name servers manage two kinds of data: authoritative and non-authoritative that may be cached. Answers from authoritative serves are considered trusted.
  • Authoritative data is held in sets called zones; each zone is the complete database for a particular "pruned" sub-tree of the domain space.
  • Each name server periodically checks to make sure that its zones are up to date, and if not, obtains a new copy of updated zones from master files stored locally or in another name server.
  • Cached data is data acquired by a local resolver. This type data may be incomplete, but improves the performance of the retrieval process when non-local data is repeatedly accessed.
  • Cached data is eventually discarded by a timeout mechanism.
  • a host can participate in the domain name system in a number of ways, depending on whether the host runs programs that retrieve information from the domain system, name servers that answer queries from other hosts, or various combinations of both functions.
  • One common configuration is shown in Figure 1.
  • User programs 10 interact with the domain name space through resolvers 12; the format of user queries 14 and user responses 16 is specific to the host and its operating system.
  • the resolver 12 and its cache 18 may be part of the local host 20 operating system. Less capable hosts may choose to implement a resolver as a subroutine to be linked in with every program that needs its services. Indeed, this seems to be the most common implementation today.
  • Resolvers 12 answer user queries 14 with information they acquire via queries 22 to foreign name servers 24 and the local cache 18.
  • the resolver 12 may have to make several queries to several different foreign name servers to answer a particular user query 14, and hence the resolution of a user query may involve several network accesses and an arbitrary amount of time.
  • the queries 22 to foreign name servers 24 and the corresponding responses 26 have a standard format described in the above-cited RFCs.
  • a name server 24 could be a stand alone program on a dedicated computer system or a process or processes on a large timeshared host. As shown, a simple configuration might allow for a name server 24 to acquire information about one or more zones by reading master files 28 from a local file system, and answers queries 22 about those zones that arrive from resolvers 12.
  • the DNS zones can be made redundant by having more than one name server.
  • Designated secondary servers can acquire zones and check for updates from the primary server using the zone transfer protocol of the DNS.
  • the name server 24 periodically establishes a virtual circuit to another name server 30 to acquire a copy of a zone or to check that an existing copy has not changed.
  • the maintenance messages 32 and 34 sent and received for these activities follow the same form as queries and responses, but the message sequences are somewhat different. It should be recognized that the system depicted in Figure 1 is not meant to be fully descriptive of the Internet's
  • DNS rather it is used merely to identify relevant components thereof.
  • Reverse proxy is the name for certain alternate uses of a proxy server.
  • proxies can be used outside a firewall to represent a secure content server to outside clients, preventing direct, unmonitored access to that server's data.
  • Proxies can also be used for replication (i.e., caching); that is, multiple proxies can be attached in front of a heavily used server for load balancing or distributed at various geographical sites to mirror content available at an origin server. The goal of such geographic distribution is to ease the burden on an origin server and reduce network congestion due to multiple client requests for similar content.
  • the proxy servers act as go- betweens for client requests to the real server.
  • the proxy servers cache the requested documents and, if there is more than one proxy server, DNS can route the requests among the proxies using, for example, a "round-robin" selection of their IP addresses.
  • DNS can route the requests among the proxies using, for example, a "round-robin" selection of their IP addresses.
  • the various clients use the same URL each time, but the route the request takes might go through a different proxy each time.
  • Layer-7 referring to the application layer of the open systems interconnect model for networks
  • redirection is an attempt to divert client requests to proxies based on application-layer criteria.
  • One example is the attempt to direct requests to that proxy which is geographically closest to the requesting client.
  • a DNS server can attempt to determine the shortest path distance between an RPS and the last resolving server, however, identity of that client is hidden from the name server; the only information that may be provided is some network topology information identifying a route that the client request took to get to the name server.
  • the RPS may or may not be geographically close to the requesting client, so any attempt to redirect the client to a geographically close proxy can only be as good as the underlying assumption that the name server is close to the client ⁇ an unknowable proposition.
  • closest proxy server involve transmitting messages from the name server to the identified proxy servers and measuring the response time from those proxies.
  • the proxy with the fastest response time is assumed to be the closest and the client request is resolved to the address of that proxy.
  • This method again assumes that the client is geographically close to the name server that is making the time measurements, and will not ensure that the client is always directed to the closest proxy.
  • a domain name system for a computer network (e.g., the Internet) that includes a record resource (RR) type that identifies one or more reverse proxy servers for a specified host within the network.
  • the host may be specified according to a network address, for example an Internet Protocol (IP) address.
  • IP Internet Protocol
  • the host may be specified according to its fully qualified domain name.
  • the reverse proxy servers are also specified according to their fully qualified domain name, or other identifying characteristics.
  • the DNS may also include a second RR type that identifies one or more origin servers from which content may be requested.
  • one or more reverse proxy servers for a network host are identified through a domain name system resource record (RR) that may be returned in response to a name query.
  • RR domain name system resource record
  • the reverse proxy servers are identified by their Internet Protocol (IP) addresses.
  • IP Internet Protocol
  • the host for which the reverse proxy servers act may be identified according to its fully qualified domain name.
  • Another embodiment provides a domain name system (DNS) resource record (RR) that includes entries for a network host and its reverse proxy servers.
  • DNS domain name system
  • RR resource record
  • the host is specified in terms of its fully qualified domain name or Internet Protocol address and the reverse proxy servers are specified in terms of their Internet Protocol addresses.
  • Still another embodiment provides a domain name system (DNS) resource record (RR) that includes entries for a network hosts configured to act a source for specified content.
  • DNS domain name system
  • RR resource record
  • the hosts may be specified in terms of their fully qualified domain names or Internet Protocol addresses.
  • the RR includes a weight factor for each host, the weight factors defining an order in which the hosts should be contacted and/or load-balancing characteristics for the hosts.
  • the weight factor for each host may be dynamically generated, for example based on geographic location.
  • a domain name query that includes a requesting client Internet Protocol (IP) address as part of a data field is transmitted.
  • IP Internet Protocol
  • the requesting client may then be directed to one of a number of reverse proxy servers according to the client's geographic proximity to that reverse proxy server, as determined using the requesting client's IP address.
  • the requesting client's IP address is used to direct a location query request to the requesting client and geographic location information from the reverse proxy servers are gathered, prior to directing the requesting client to the closest of the reverse proxy servers.
  • a client request may be redirected to one of a number of available reverse proxy servers by determining geographic location information for the client making the request through the use of an Internet Protocol (IP) address of the client transmitted as part of a name query by the client and subsequently directing the client to the physically closest of the available reverse proxy servers.
  • IP Internet Protocol
  • the available reverse proxy servers are preferably identified through a name service resource record type. Prior to directing the client to the physically closest of the available reverse proxy servers, the geographic location of the client is determined by transmitting a location query using the client's IP address.
  • Figure 1 illustrates an example of a network that includes a name server configured to operate according to the domain name system.
  • RR resource record
  • RPS a list of IP addresses that should act as reverse proxy servers for a specified IP address.
  • OCS a list of origin content servers from which content can be retrieved.
  • proxy servers are provided with the ability to build a reverse proxy map to dynamically determine whether they should act as a reverse proxy for an incoming client request, and, if so, where to retrieve the requested content from.
  • the map may also include static relationship information defined outside of the DNS.
  • RRs are specifications for a tree structured (i.e., hierarchical) name space and data associated with the names.
  • each node and leaf of the domain name space tree names a set of information, and query operations are attempts to extract specific types of information from a particular set.
  • a query names the domain name (i.e., node) of interest and describes the type of resource information that is desired. For example, queries for address resources return IP host addresses.
  • Every RR has the following attributes: (i) owner (the domain name where the RR is found; often this is implicit); (ii) type (an encoded 16-bit value that specifies the type of the resource in the subject resource record, for example, "A" might identify a host address, "NS” might identify the authoritative name server for the domain, etc.); (iii) class (an encoded 16-bit value which identifies a protocol family or instance of a protocol, for example "IN” might identify the Internet system); (iv) TTL (the time to live of the RR, which describes how long an RR can be cached before it should be discarded); and (v) RDATA (the type and sometimes class dependent data that describes the resource, e.g., for the IN class, a 32-bit IP address).
  • the type, class and TTL fields of a RR are fixed portions of a header, while the RDATA field is a variable length field that fits the needs of the resource being described.
  • RRs is carried as a combination of binary strings and domain names.
  • the domain names are frequently used as "pointers" to other data in the DNS.
  • RRs are typically represented in binary form in the packets of the DNS protocol, and are usually represented in highly encoded form when stored in a name server or resolver. In this format, most RRs are shown on a single line, although continuation lines are possible using parentheses.
  • the start of the line gives the owner of the RR. If a line begins with a blank, then the owner is assumed to be the same as that of the previous RR. Following the owner are listed the TTL, type, and class of the RR.
  • the resource data or RDATA section of the RR is given using knowledge of the typical representation for the data.
  • Address RRs use a standard IP address format to contain a 32-bit Internet address.
  • the RR "RPS" defines a list of IP addresses that should act as reverse proxy servers for a specified IP address.
  • the format of the RPS type is:
  • CLASS is the IP address or fully qualified domain name that is configured to use a reverse proxy
  • TTL is the IP address or fully qualified domain name that is configured to use a reverse proxy
  • IP is the IP address(es) of a reverse proxy.
  • CLASS will be IN (following the standard DNS protocol) and to define a group of five servers to act as reverse proxies for the host www.computer.com one might create a configuration that looks like the following:
  • a client makes a request for the host www.computer.com. This request is received at a server capable of providing reverse proxy services (e.g., it has an available cache to store requested content) and having an associated name server.
  • a server capable of providing reverse proxy services (e.g., it has an available cache to store requested content) and having an associated name server.
  • the response should include the RPS RR above.
  • this RPS RDATA format allows the proxy server to dynamically determine whether it should act as a reverse proxy for the specified host. Because this is a request from an RPS, as an optimization the DNS server may return a lost of one RPs; that of the RPS performing the query. In general, if the proxy finds its own IP address in the list returned by the name server, it will then add the mapping to its internal mapping table (generally stored in memory) until the TTL reported in the RPS RR has expired. During this time, any client requests for www.computer.com that are received at the server are intercepted and the requested content is played out of the server, acting as a reverse proxy for the origin server (www.computer.com).
  • the reverse proxy server only adds entries to its internal list as traffic for a site is generated, the internal list can be significantly smaller than the total list of sites that reverse proxy services are available for. In general, the improved efficiency of list processing should more than compensate for having to perform additional DNS queries.
  • the RPS RDATA format is combined with the WKS (well known server) data format to determine what protocols can be reverse proxied on a given server.
  • WKS well known server
  • the WKS data may be appended to the original RPS request to specify the type of content being requested, and the list of servers that should act as reverse proxies may be modified based on this information.
  • the second new RR type is the OCS (origin content server) RDATA format. This format is used to define a list of servers from which the actual content can be retrieved. It also provides support for load balancing and fail-over operations.
  • OCS oil content server
  • hostname is the IP address or fully qualified domain name that is configured to use a reverse proxy and must be the same as that used in the RPS configuration
  • TTL and "CLASS” have the meanings discussed above
  • WEIGHT is a field that defines the order in which servers in the list should be tried (if two or more servers in the list have the same WEIGHT, then a client should load balance between them, e.g., using a round- robin load balancing procedure)
  • IP is a field listing the available servers from which the content can be retrieved.
  • the WEIGHT parameter may be dynamically generated by a name server, for example based on geographic location.
  • an example of an OCS entry with a single primary and secondary server may resemble:
  • the RPS and OCS attributes are used together to build a reverse proxy map. If the server has an entry in the RPS table, then the server should send an OCS query to discover which origin server can accommodate the request.
  • the WEIGHT factor may be any value in a range 0 - 255, although the use of 0 may be reserved for special functions. Within this range, in one embodiment a WEIGHT of 1 is given the highest priority and 255 the lowest priority, with intervening WEIGHT factors having appropriate priorities according to this scale. Given this range, it is possible for a client to adjust the WEIGHT factors of given servers based on actual response time, error statistics, through put, and the like. Many different schemes for gathering such data can be used and the specific implementation is not critical of the present invention.
  • the OCS RDATA format can be combined with the WKS data format to determine what protocols can be reverse proxied on a given server.
  • Servers performing Layer-7 redirection may compare the WKS information from both the OCS and RPS to ensure that client requests are redirected to a proxy capable of accommodating all of the expected content types (specified by the WKS data).
  • the WKS data is appended to the original OCS request to improve performance. If there is more than one RPS, then the WKS record may follow its associated RPS, for example: RPS I WKS I RPS I WKS
  • the PRS should support all the requested WKS(s) specified to act as a reverse proxy server.
  • a name server directing traffic to an RPS should not redirect traffic to an RPS that either does not contain a WKS record or cannot accommodate all the required WKS data types of the OCS.
  • the present scheme also contemplates including the IP addresses and/or geographic locations of clients and/or reverse proxy servers within DNS queries.
  • DNS queries and responses are carried in a standard message format.
  • the message format has a header containing a number of fixed fields which are always present, and four sections which carry query parameters and
  • RRs One field in the header is a four-bit field called an opcode which distinguishes between different types of queries. For example, a specific opcode is used to identify a so-called "standard query”.
  • the four sections of a DNS query are:
  • a standard query specifies a target domain name (QNAME), query type
  • the QTYPE and QCLASS fields are each 16-bits long, and are a superset of defined types and classes.
  • the QTYPE field may contain:
  • ⁇ any type> matches just that type, (e.g., A, PTR).
  • MAE B matches all mail box related RRs (e.g. MB and MG).
  • the QCLASS field may contain:
  • ⁇ any class> matches just that class (e.g., IN, CH).
  • the name server looks for matching RRs.
  • the name server may return RRs that point toward a name server that has the desired information or RRs that are expected to be useful in interpreting the relevant RRs.
  • a name server that doesn't have the requested information may know a name server that does; a name server that returns a domain name in a relevant RR may also return the RR that binds that domain name to an address.
  • the present scheme modifies DNS queries to include the originating client's IP address. Either of two approaches may be used to implement this feature.
  • a new opcode e.g., opcode 16
  • This new opcode will alert a name server that the associated query includes information allowing for true geographic-based redirection in accordance with the present invention.
  • a new opcode also allows for backwards compatibility with current implementations of the DNS in as much as if the name server does not support opcode 16 functionality, it can return an error message to the requesting server, which server can then retransmit the query and a standard query (opcode 0), without the client-identifying information.
  • the requesting client IP address can be appended to the end of the QCLASS portion of a standard query and then decoded by the name server. With this second approach, care must be taken to ensure that any un-initialized data in the answer section that follows the query is not erroneously interpreted as a client IP address.
  • RDATA format of the LOC RR includes fields for the latitude, longitude and altitude of an identified host, network or subnet.
  • the name server successfully retrieves the LOC parameters of the requesting client, it can then retrieve (either using an LOC query or from a cache) the LOC parameters of the available RPSs (identified using the RPS records) and determine the true geographically closest RPS to the requesting client. It should be noted that there are many possible methods for optimizing the internal structure and retrieval of this information and the details of such a search are not critical to the present invention.
  • OCS WEIGHT field may be to dynamically determine the weight based on geographic considerations. For example, if there was a global content provider that had already replicated its main content server at several locations throughout the world, it would be desirable to return the OCSs back in an order that represented geographic proximity to a requestor. For example, if OCS servers A, B and C are available in Europe, North America and Asia, respectively, and each OCS has three associated RPSs, it would be desirable to return OCS A for all PRSs in Europe.
  • each primary/backup server combination may be associated with three PRSs, each.
  • the resulting configuration file may resemble the following:
  • the weight 10 servers would represent the load-balancing servers for Europe, the weight 20 servers for North America and the weight 30 servers for Asia- Pacific.
  • weight ranges for different geographic locations e.g.,

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un système de nom de domaine destiné à un réseau informatique (par ex. Internet), comportant un premier type de ressource d'enregistrement identifiant un ou plusieurs serveurs mandataires inverses pour un hôte spécifié dans le réseau en fonction de son adresse réseau, par exemple son adresse IP (Protocole Internet) et/ou son nom de domaine entièrement qualifié. Ledit système de nom de domaine peut également comporter un deuxième type de ressource d'enregistrement identifiant des serveurs d'origine dont le contenu peut être demandé. De préférence, le deuxième type de ressource d'enregistrement comporte un champ de facteur de pondération, les facteurs de pondération définissant un ordre dans lequel des hôtes devraient être contactés et/ou des caractéristiques de compensation de charge pour les hôtes. Dans certains cas, le facteur de pondération de chaque hôte peut être créé dynamiquement, par exemple sur la base de la position géographique. Par l'intermédiaire de ces types de ressources d'enregistrement, un client demandeur peut être orienté vers le serveur mandataire inverse le plus proche du client, ledit serveur étant déterminé au moyen de l'adresse IP du client demandeur. Pour simplifier cette opération, l'adresse IP du client demandeur sert à envoyer une requête de demande de position au client demandeur, et des informations de position géographique des serveurs mandataires inverses sont réunies avant orientation du client demandeur vers le serveur mandataire inverse le plus proche.
PCT/US2000/042125 2000-11-09 2000-11-09 Extensions de systeme de nom de domaine destinees a supporter des operations de mandataires inverses et des reacheminements de couche 7 Ceased WO2002039699A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/US2000/042125 WO2002039699A1 (fr) 2000-11-09 2000-11-09 Extensions de systeme de nom de domaine destinees a supporter des operations de mandataires inverses et des reacheminements de couche 7
AU2001232699A AU2001232699A1 (en) 2000-11-09 2000-11-09 Domain name system extensions to support reverse proxy operations and layer-7 redirection

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2000/042125 WO2002039699A1 (fr) 2000-11-09 2000-11-09 Extensions de systeme de nom de domaine destinees a supporter des operations de mandataires inverses et des reacheminements de couche 7

Publications (1)

Publication Number Publication Date
WO2002039699A1 true WO2002039699A1 (fr) 2002-05-16

Family

ID=21742202

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/042125 Ceased WO2002039699A1 (fr) 2000-11-09 2000-11-09 Extensions de systeme de nom de domaine destinees a supporter des operations de mandataires inverses et des reacheminements de couche 7

Country Status (2)

Country Link
AU (1) AU2001232699A1 (fr)
WO (1) WO2002039699A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1453279A1 (fr) * 2003-02-28 2004-09-01 Alcatel Ordonnancement d'adresses dans serveur de noms de domaine
EP1441487A3 (fr) * 2003-01-21 2005-12-14 Canon Kabushiki Kaisha Procédé, dispositif et programme de réponse à une requête d'adresse
US20120054235A1 (en) * 2010-08-30 2012-03-01 Sony Corporation Reception apparatus, reception method, transmission apparatus, transmission method, program, and broadcasting system
US8364816B2 (en) 2007-10-12 2013-01-29 Microsoft Corporation Mapping network addresses to geographical locations
WO2019059996A1 (fr) * 2017-09-22 2019-03-28 Microsoft Technology Licensing, Llc Délestage de charge de trafic basé sur un état de charge courant de capacité cible
CN113596187A (zh) * 2021-06-25 2021-11-02 新浪网技术(中国)有限公司 域名配置管理系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0817444A2 (fr) * 1996-07-01 1998-01-07 Sun Microsystems, Inc. Système de résolution de noms, dépendante du contexte

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0817444A2 (fr) * 1996-07-01 1998-01-07 Sun Microsystems, Inc. Système de résolution de noms, dépendante du contexte

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
A. GULBRANDSEN, P. VIXIE, L. ESIBOV: "A DNS RR for specifying the location of services (DNS SRV)", REQUEST FOR COMMENTS: 2782, February 2000 (2000-02-01), pages 1 - 8, XP002176085, Retrieved from the Internet <URL:http://www.faqs.org/rfcs/rfc2782.html> [retrieved on 20010829] *
M. GREEN, B. CAIN, G. TOMLINSON: "CDN Peering Architectural Overview", INTERNET-DRAFT, 20 October 2000 (2000-10-20), pages 1 - 34, XP002176084, Retrieved from the Internet <URL:http://www.alternic.org/drafts/drafts-g-h/draft-green-cdnp-gen-arch-01.txt> [retrieved on 20010829] *
NOTTINGHAM M: "On defining a role for demand-driven surrogate origin servers", COMPUTER COMMUNICATIONS, ELSEVIER SCIENCE PUBLISHERS BV, AMSTERDAM, NL, vol. 24, no. 2, 1 February 2000 (2000-02-01), pages 215 - 221, XP004228463, ISSN: 0140-3664 *
P. MOCKAPETRIS: "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", REQUEST FOR COMMENTS: 1035, November 1987 (1987-11-01), pages 1 - 39, XP002176086, Retrieved from the Internet <URL:http://www.faqs.org/rfcs/rfc1035.html> [retrieved on 20010829] *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1441487A3 (fr) * 2003-01-21 2005-12-14 Canon Kabushiki Kaisha Procédé, dispositif et programme de réponse à une requête d'adresse
US7415536B2 (en) 2003-01-21 2008-08-19 Canon Kabushiki Kaisha Address query response method, program, and apparatus, and address notification method, program, and apparatus
EP1453279A1 (fr) * 2003-02-28 2004-09-01 Alcatel Ordonnancement d'adresses dans serveur de noms de domaine
FR2851867A1 (fr) * 2003-02-28 2004-09-03 Cit Alcatel Ordonnancement d'adresses dans serveur de noms de domaine
US8364816B2 (en) 2007-10-12 2013-01-29 Microsoft Corporation Mapping network addresses to geographical locations
US8788664B2 (en) 2007-10-12 2014-07-22 Microsoft Corporation Mapping network addresses to geographical locations
US20120054235A1 (en) * 2010-08-30 2012-03-01 Sony Corporation Reception apparatus, reception method, transmission apparatus, transmission method, program, and broadcasting system
US10511887B2 (en) * 2010-08-30 2019-12-17 Saturn Licensing Llc Reception apparatus, reception method, transmission apparatus, transmission method, program, and broadcasting system
WO2019059996A1 (fr) * 2017-09-22 2019-03-28 Microsoft Technology Licensing, Llc Délestage de charge de trafic basé sur un état de charge courant de capacité cible
US10812390B2 (en) 2017-09-22 2020-10-20 Microsoft Technology Licensing, Llc Intelligent load shedding of traffic based on current load state of target capacity
CN113596187A (zh) * 2021-06-25 2021-11-02 新浪网技术(中国)有限公司 域名配置管理系统

Also Published As

Publication number Publication date
AU2001232699A1 (en) 2002-05-21

Similar Documents

Publication Publication Date Title
US7225272B2 (en) Method and apparatus for providing name services
JP4592184B2 (ja) 静的な識別子が付され、かつネットワークに断続的に接続される装置へのアクセス方法および装置
US7565407B1 (en) Network proxy apparatus and methods
EP1303109B1 (fr) Résolution de noms virtuels de réseau
US7565450B2 (en) System and method for using a mapping between client addresses and addresses of caches to support content delivery
US6016512A (en) Enhanced domain name service using a most frequently used domain names table and a validity code table
US20030093523A1 (en) Method for associating clients with domain name servers
JP3725376B2 (ja) Ｄｎｓ問い合わせ装置、ｄｎｓ問い合わせ方法、および記録媒体
US20040194102A1 (en) Using virutal domain name service (dns) zones for enterprise content delivery
US20030233423A1 (en) Method and system for tiered distribution in a content delivery network
US20040249971A1 (en) Methods and systems for providing dynamic domain name system for inbound route control
US20020078233A1 (en) Method and apparatus for content distribution network brokering and peering
WO2000014938A2 (fr) Procede et dispositif de traitement en transparence du trafic dns
US20100064047A1 (en) Internet lookup engine
WO1999060459A2 (fr) Procede et appareil de localisation efficace du trafic circulant a travers un systeme de nom par domaine
US7788407B1 (en) Apparatus and methods for providing an application level gateway for use in networks
Wong et al. ClosestNode. com: an open access, scalable, shared geocast service for distributed systems
WO2002039699A1 (fr) Extensions de systeme de nom de domaine destinees a supporter des operations de mandataires inverses et des reacheminements de couche 7
US20020065936A1 (en) Multi-platform application
Bestavros et al. DNS-based internet client clustering and characterization
WO2009012992A2 (fr) Système de noms de domaine averti du demandeur
Akanho et al. African nameservers revealed: Characterizing dns authoritative nameservers
Sirer ClosestNode. com: An Open-Access, Scalable, Shared Geocast Service for Distributed Systems
Patvarczki Q1) A survey of work to distribute requests in a data center (Web cluster) was done by Cardellini, et al in a 2002 ACM Computing Surveys paper [Cardellini et al. 2002]. Briefly outline the primary architectural approaches described in this paper for distributing requests within a data center.
HOWTO DNS

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase