Technical Field
The present invention relates to a system and method for classifying an Internet Protocol address, that is particularly useful for determining if the address corresponds to a server of a server farm.
Description of the Related Art
In a typical networked computing environment, a user may have a computer which connects via a local network (e.g. LAN or WAN) and a local network server to the Internet. In some environments, a proxy server (which may be coincident with the local network server) intercepts and interprets commands being transmitted between the Internet and a client, e.g. an e-mail client or MUA (Mail User Agent) running on a user's computer. The proxy server may monitor the Internet Protocol (IP) addresses being accessed by the client for the purposes of, for example: security filtering; or providing the client with access to files in a local cache rather than on an external server (i.e. a server accessible only via a network such as the Internet).
Many large service providers have a farm of external servers providing a given service, which although only a single server name is published, might have addresses as follows:
When attempting to communicate with a server in a server farm, a client will start with only the published server name, e.g. ‘pop.mailsp.com’. This server name is resolved by the Domain Name Service (DNS) into one of the IP addresses in the server farm. A proxy server monitoring the IP addresses being accessed by the client may not recognize the particular IP address as belonging to a server farm; for example, the proxy server may not recognize that an IP address corresponds to an external email server if the external email server is part of a server farm, and therefore has multiple potential IP addresses. If the proxy server does not recognize the IP address, it may fail to function desirably: for example, a proxy server may fail to realize the IP address corresponds to a particular email server or perform access restriction.
It is desired to address the above, or at least provide a useful alternative.
In accordance with one embodiment, there is provided a system for classifying an Internet protocol (IP) address, including:
One embodiment provides a method for classifying an Internet protocol (IP) address, including:
One embodiment provides a method performed by a proxy server, including:
Embodiments are hereinafter described, by way of example only, with reference to the accompanying drawings in which:
The proxy server 102, as shown in
The client 108 is connected to the proxy server 102 when requesting access to data on the external network 106. The proxy server 102 is configured with client profile data in the client profile store 304, and the client profile data may have been previously provided through communication between the client 108 and the proxy server 102, or via manual configuration of proxy server 102.
The processor 302 of the proxy server 102 performs an access event process described below with reference to
The IP address classification process 408, as shown in
At step 506, the proxy server 102 performs a reverse DNS lookup process, as described in the Internet Engineering Task Force (IETF) RFCs 1035 and 2317 (http://www.ietf.org/rfc.html), to determine the server name corresponding to the resolved IP address and the server name corresponding to the stored IP address of the client profile data. If the suffix of the server name (e.g. ‘mailsp.com’) returned using the resolved IP address matches the suffix of the server name returned using the stored address at step 508, the IP addresses are held to be in the same server farm. If the suffixes do not match at step 508, the proxy server may truncate the suffixes to compare only the right most portions of the server names (e.g. mailsp.com or melbuni.edu.au) at step 510; if the truncated suffixes of the server names match, it is possible the IP addresses are from the same server farm. If, however, even the truncated suffixes of the server names do not match, then the proxy server concludes in step 512 that the IP addresses are not referring to the same server farm. The comparison and truncation steps (508, 510) may be configured to reach an arbitrary level of truncation, or an arbitrary length of the suffix; other examples of suffixes may be: public.mailsp.com, mail.dhs.nsw.gov.au, or even .au (although short suffixes will be less likely to identify a single server farm).
The classification process is not constrained by the size of the server groups, the nature of the protocols supported. Furthermore, the process is not dependent on the proxy 102 being able to intercept any protocol other than that which it was designed to intercept, e.g. it is not dependent on being able to intercept DNS traffic.
The classification process 408 can be illustrated using an example of a search for an email server ‘pop5.mailsp.com’ that lies in a server farm. The client 108 is configured to retrieve email from an external server 104 with the server name: ‘pop.mailsp.com’ using the POP3 protocol. The proxy server 102 has a stored client profile, including the client's username, password and IP address of its email server, which is ‘11.11.11.14’. Furthermore, the server farm containing the email server has a number of IP addresses, including the following which are listed in the memory of proxy server 102: 11.11.11.11, 11.11.11.12, 11.11.11.13 and 11.11.11.14.
Unknown to the proxy server 102, the DNS currently resolves the following server names to the following IP addresses, all corresponding to the ‘pop.mailsp.com’ server farm:
In this example, the client 108 attempts to access ‘pop.mailsp.com’. The client uses the DNS to resolve ‘pop.mailsp.com’ (for this given request), to 11.11.11.15. When the proxy server 102 detects that client 108 is trying to access IP address 11.11.11.15 using the POP3 protocol, it attempts to match this resolved address with the stored address of the client profile data (i.e. ‘11.11.11.14’)—at step 502 in
At the next step, 506, the proxy server 102 performs reverse DNS lookup to find a server name corresponding to the resolved IP address. In this case, the reverse DNS process, returns ‘pop5.mailsp.com’. At the following step 508, the suffixes of the two names are then compared; in this case, ‘mailsp.com’ is the suffix in both cases, so the names are found to match, and the proxy server 102 treats the request from client 108 as if it were for the external server 104 that is normally used (whether this match identifies a server farm match depends on the selected comparison of the proxy server and the configuration of the server farm). The client profile stored on the proxy server is updated to reflect that the IP address of its email server is now ‘11.11.11.15’. Furthermore, the IP addresses for this server farm, listed in the memory of the proxy server, is amended to include the IP address ‘11.11.11.15’.
An example of the control flow and the data used is provided in the accompanying Appendix.
The processes performed by the proxy server 102, as described herein, can advantageously be used when the proxy server 102 is configured so as to form a proxy server as described in the patent specification of the International (PCT) patent application entitled “Proxy Server” filed by the Applicant on the same day as this application (and which is herein incorporated by reference).
The various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the embodiments in light of the above-detailed description. In general, in the following claims, the terms used should not be construed to limit the claims to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. Accordingly, the claims are not limited by the disclosure.
Number | Date | Country | Kind |
---|---|---|---|
2006903547 | Jun 2006 | AU | national |
Number | Name | Date | Kind |
---|---|---|---|
6332158 | Risley | Dec 2001 | B1 |
6470389 | Chung et al. | Oct 2002 | B1 |
7418507 | Kruse | Aug 2008 | B2 |
20010006523 | Kriens | Jul 2001 | A1 |
20020143918 | Soles et al. | Oct 2002 | A1 |
20020156875 | Pabla | Oct 2002 | A1 |
20040133688 | Takamatsu | Jul 2004 | A1 |
20050111384 | Ishihara et al. | May 2005 | A1 |
20050259654 | Faulk, Jr. | Nov 2005 | A1 |
20060026177 | Howell | Feb 2006 | A1 |
20060031319 | Nelson | Feb 2006 | A1 |
20060031385 | Westerdal | Feb 2006 | A1 |
20060056418 | Rizzuto | Mar 2006 | A1 |
20070160033 | Bozinovski et al. | Jul 2007 | A1 |
20080016233 | Schneider | Jan 2008 | A1 |
20090254658 | Kamikura | Oct 2009 | A1 |
Number | Date | Country |
---|---|---|
1489069 | Apr 2004 | CN |
Entry |
---|
Eidnes, H., et al., “Classless IN-ADDR.ARPA delegation,” IETF RFC 2317, Mar. 1998, http://www.ietf.org/rfc/rfc2317.txt?number=2317. |
Dai, G. et al., “Design and Implementation of DNS-based Load Balance Technology,” Computer Engineering 28 (4):78-79, 147, Apr. 2002. |
Mockapetris, P., “Domain Names—Implementation and Specification,” IETF RCF 1035, Nov. 1987, http://www.ietf.org/rfc/rfc1035.txt?number=1035. |
Shaikh, A. et al., “On the Effectiveness of DNS-based Server Selection,” Proceedings of IEEE INFOCOM 2001—Twentieth Annual Joint Conference of the IEEE Computer and Communications Societies, vol. 3, pp. 1801-1810, Anchorage, AK, Apr. 22-26, 2001. |
Wang, Y. et al., “The Algorithms of the DNS-Based Load Balancing System”, Computer Engineering and Application, No. 4, 3 pages, Feb. 28, 2002. |
Number | Date | Country | |
---|---|---|---|
20090248790 A1 | Oct 2009 | US |
Number | Date | Country | |
---|---|---|---|
Parent | PCT/IB2007/001968 | Jun 2007 | US |
Child | 12341835 | US |