WO2009005433A1

WO2009005433A1 - Dns manager

Info

Publication number: WO2009005433A1
Application number: PCT/SE2007/050504
Authority: WO
Inventors: Tero Aleksanteri Kauppinen; Martti Kuparinen; Heikki Mahkonen
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2007-07-05
Filing date: 2007-07-05
Publication date: 2009-01-08

Abstract

The present invention relates to a host computer system (210) having a plurality of network interfaces (231-233) and where said host (210) communicates with a plurality of Domain Name System, DNS servers (221-223). A problem when communicating with more than one DNS server (221-223) is that resolution requests from the host (210) may be directed to the wrong DNS server (221-223). This because the DHCP protocol overwrites in the resolver configuration file (114) data related to one DNS server (221) with data related to another DNS server (222). This problem is solved by the current invention by introducing a DNS manager (216) where all resolution requests initially are sent to and where said DNS manager (216) is designed to ensure that all resolution requests are forwarded to the correct DNS server (221-223).

Description

DNS MANAGER

TECHNICAL FIELD OF THE INVENTION

The present invention relates to a host computer system designed for communicating with a plurality of Domain Name System, (DNS) servers.

DESCRIPTION OF RELATED ART

Computers attached to the Internet use IP addresses to locate and connect to each other. For people however, who want to access a home page on the web from their computer, IP addresses are cumbersome to use and difficult to remember. It is easier to use and to remember a host name (such as www.company.com) than the corresponding IP address. A DNS server has a database that translates the user friendly host names into numeric IP addresses. When the user for example wants to access a home page on the web, he types the host name in a field in the web browser. This host name is sent from the web browser (the user client) via the operating system to the DNS server. In order to find the DNS server, the IP address to the DNS server itself must have been defined beforehand, either manually by the user or automatically e.g. by using the DHCP protocol. The IP address to the DNS server is stored in a resolver configuration file. In a Unix/Linux operating system this corresponds to the {etc/resolv. conf file whole other operating systems may use other names. When the DNS server receives the host name it makes a look-up in a database and returns the IP address associated with the provided host name. The received IP address is then used to route IP packets to the application server that is hosting the home page the user is interested in. This translation process (also called address resolution) is almost instant and is completed without the user ever notices any delay. Often the resolver caches the information it receives when it resolves queries. These cached responses can then be used to answer subsequent queries for the same information. The cached data, however, has a limited lifetime specified in the Time to Live (TTL) parameter returned with the data.

The basic concept of the Domain Name System, DNS has been described in the Internet specification RFC1034.

The Dynamic Host Configuration Protocol (DHCP) is a standard protocol that has been described in the Internet specification RFC2131. For IP networks implemented with IP version 6 (IPv6) , a corresponding standard has been described in RFC3315.

SUMMARY OF THE INVENTION

A problem with the allocation of the IP address to the DNS server when using DHCP occurs when a host computer system

(especially a mobile node as a laptop, a PDA, a mobile telephone) need to send address resolution requests to different networks through different network interfaces. An example on such a scenario is where a video distribution to the mobile node is done over a WLAN (Wireless LAN) interface whereas web browsing is done over a GPRS or 3G interface. Having different interfaces to different networks may require that different DNS servers have to be interrogated as one single DNS server may not be reachable from all the network interfaces. Moreover the mobile often needs to communicate with different DNS servers simultaneously. When using the DHCP protocol, it will happen that each new update to the address resolution file (e.g. /etc/resolv. conf) relating to one DNS server overwrites an earlier update related to another DNS server. This will have the negative effect that some address resolution requests are directed to the wrong DNS server.

Another problem is that in a situation where one DNS server actually can be reached over say two network interfaces and where one interface goes down or becomes unavailable, address resolution requests intended to be sent over the unavailable interface can not reach the DNS server even if there is a second available interface over which the DNS still can be reached.

These problems have been solved in the current invention by introducing a DNS manager in the host computer system. The DNS manager analyzes an address resolution request originating from one of the user clients and to pass this request to one of the DNS servers over one of said network interfaces. The invention further comprises a first resolver configuration file that is arranged to store the address to the DNS manager and a second resolver configuration file arranged to store the addresses to the plurality of DNS servers and the identities of the network interfaces.

An advantage with the current invention is that a multitude of address resolution requests can be performed simultaneously and without interfering with each other.

Another advantage is that if one network interface fails (or becomes unavailable due to the host is moving) , it is possible to access a DNS server through another network interface .

Yet another advantage is that existing resolver interfaces are kept intact enabling compatibility with legacy applications in the host.

The objective with the current invention is therefore to enable a multi-interface host to simultaneously access different networks having different DNS servers without the resolution requests are interfering with each other.

The invention will now be described in more detail and with preferred embodiments and referring to accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram showing a known host computer system (such as a PC) connected to a DNS server.

Figure 2 is a block diagram showing a first embodiment of the current invention.

Figure 3 is a block diagram showing a second embodiment of the current invention.

Figure 4 is a flow chart illustrating the method to perform address resolution according to the current invention.

Figure 5 is a flow chart illustrating the method of updating the first and second resolver configuration files in the current invention.

DETAILED DESCRIPTION OF EMBODIMENTS

A commonly known host computer system (such as a PC) , is illustrated in Figure 1. This computer system 110 is designed to access a DNS server 120, a DHCP server 130 and an application server 140. The computer system 110 comprises for example two user clients where in Figure 1 one is a web browser client 111 and the other is a mail client 112. The computer system 110 does also comprise an address resolver

113. The resolver 113 is a set of software routines that provide access to the DNS server 120.

The computer system 110 does also comprise a first resolver configuration file 114. This file 114 in a Unix/Linux operating system corresponds to the /etc/resolv. conf file located in the /etc directory. Other operating systems may have other names. The resolver configuration file 114 contains configuration settings that are read by the resolver such as the IP address of the DNS server that can translate received host names into IP addresses for a node in the network. The computer system 110 further comprises a DHCP (Dynamic Host Configuration Protocol) client 115 which is designed to communicate with the DHCP server 130 using the DHCP protocol. The DHCP server 130 has a pool of available IP addresses in a database. The DHCP server 130 distributes these IP addresses and other configuration settings (like subnet masks etc) to the DHCP client 115. When a user boots up his computer 110, the DHCP client 115 sends a BOOTP (Bootstrap Protocol) request to the DHCP server 130 which offers an IP address from the pool of IP addresses. This IP address is then used as the IP address to the mail- or web browser client 111,112. The DHCP server 130 is also designed to automatically inform the DHCP client 115 in the computer system 110 about the IP address to the DNS server 120. This IP address is stored in the resolver configuration file 114. The DHCP client 115 is also designed to update the resolver configuration file 114 when any IP addresses and/or other configuration settings change .

Figure 2 illustrates a host computer system 210 according to the current invention having a plurality of network interfaces 231-233. In addition to the user clients 111,112, the resolver 113 and the first resolver configuration file 114 known from Figure 1, two new entities have been introduced, a DNS manager 216 and a second resolver configuration file 217. At least one modified DHCP client 215 has also been introduced. Each modified DHCP client 215 is run for each network interface 231-233. As an option, one DHCP client 215 can be run for every network interface 231- 233.

The DNS manager 216 is designed to handle resolution requests from a plurality of the user clients 111,112 towards a plurality of DNS servers 221-223 over the plurality of network interfaces 231-233. Each DNS server 221-223 may belong to different networks 241-243 respectively. The DNS manager 216 is also designed to read and write the content in the first resolver configuration file 114 and in the second resolver configuration file 217.

The modified DHCP client 215 is designed to communicate with the DHCP server 130 and is designed to receive an IP address to the DNS server 221-223 from the DHCP server 130 and to store this address as a part of the configuration settings in the first resolver configuration file 114. The modified DHCP client 215 is also in contrast to traditional DHCP clients 115 designed to store the identity of the corresponding network interface 231-233 in said first resolver configuration file 114.

The second resolver configuration file 217 is in contrast to the first resolver configuration file 114 designed to comprise configuration settings related to all DNS servers 221-223 and the corresponding network interfaces 231-233.

The DNS manager 216 is further designed to monitor all changes to the first resolver configuration file 114 and whenever the content in the first file 114 is changed (by the DHCP client 215), the DNS manager 216 stores this new content as a part of the configuration settings in the second resolver configuration file 217. When the new content is stored in the second file 217, the DNS manager overwrites the content in the first file 114 with the IP address to the DNS manager 216 itself which also is the default configuration settings in said first file 114.

The DNS manager 216 is further designed to monitor all network interfaces 231-233. If for example any of the network interfaces 231-233 becomes unavailable, this is detected by the DNS manager 216 and the second resolver configuration file 217 is updated accordingly. When an interface 231-233 is disabled, the associated DNS data in the DNS manager 216 is also disabled. When a configuration setting (also called an entry) related to a particular DNS server 221-223 in any of the resolver configuration files 114, 217 does not include the identity of the network interface 231-233, then the information is stored as so called global DNS entry. That is that the particular DNS server 221-223 can be reached over any of the network interfaces 231-233. The global DNS entry is optionally associated with a timer Tl supervised by the DNS manager 216. If the entry has not been accessed during a predetermined time period, that is when timer Tl triggers, the entry is removed. The timer Tl is reset each time the entry is accessed. Optionally the entry is removed when a certain number of failed attempts has been reached.

The DHCP client 215 is shut down if the interface 231-233 it was started for goes down. When the DHCP client 215 is shut down it should remove the DNS server 221-223 and other settings it configured. This to avoid unnecessary resolution requests trough the specific network interface 231-233. For this purpose, the DHCP clients 215 add information to the first resolver configuration file 114 with a special null interface. This will result in that DNS manager 216 removes the specified entries from the second resolver configuration file 217.

In Figure 3, another embodiment of the current invention is illustrated. In this embodiment, a same DNS server4 321 can be accessed from a plurality of network interfaces such as interfaces 331 and 332. DNS server4 321 belongs to a network 341 whereas a DNS server5 322 that is accessed from a network interface 333 belongs to a network 342.

Figure 3 illustrates another embodiment of the current invention. Compared to Figure 2, the DNS manager 216 has three network interfaces 331-333 where network interfaces 331 and 332 are connected to a DNS server, DNSserver4 321 and the network interface 333 is connected to a DNS server, DNSserverδ 321. This embodiment shows how the reliability between the host system 210 and the DNS servers 321,322 can be increased. If the network interface 331 for some reason becomes unavailable 339, resolution requests to DNS server4 321 will be ^Λre-routed' over network interface 332 instead.

Optionally, if both interfaces 331 and 332 are available, a load sharing mechanism for the resolution requests to the DNS server4 321 is implemented.

The same interface can also access a plurality of DNS servers 321,322. In this case identities of all DNS servers 321,322 are added to the first resolver configuration file 114. The identities are stored in an arbitrary order and the first server 321 in the list is used first and if it doesn't work the next server 322 is tried.

Figure 4 is a flow diagram illustrating the resolution process in the current invention. A resolution request in step 401 (comprising a host name to a desired application server 140) from any of the user clients 111,112 is received by the resolver 113. The resolver 113 determines in step 402 a first IP address IPl by interrogating the first resolver configuration file 114. In file 114 this first IP address IPl (the address to the DNS manager 216) is stored. This first IP address IPl could for example be the IP address of the host 210 itself. The resolution request comprising the host name is passed further in step 403 to the DNS manager 216. The DNS manager 216 analyses the resolution request and determines in step 404 a second IP address IP2 (the address to the DNS server 221-223) by interrogating the second resolver configuration file 217. In the second resolver configuration file 217 the second IP address IP2 is stored together with the identities of the corresponding network interfaces 231- 233. After the analysis by the DNS manager 216, the resolution request is passed in step 405 to the relevant DNS server 221-223 over the corresponding network interface 231- 233. The DNS server 221-223 translates the host name to a third IP address IP3 and returns a response with the translated third IP address IP3 which is received in step 406 by the DNS manager 216. The DNS manager 216 further forwards the response to the user client 111,112 which in turn uses the received third IP address IP3 to access the desired application server 140.

Figure 5 is a flow chart illustrating the method of updating the first and second resolver configuration files 114, 217.

Whenever the first resolver configuration file 114 is updated in step 501 by the DHCP client 215, these updates are detected in step 502 by the DNS manager 216 and are copied and stored in step 503 to the second resolver configuration file 217. Detection in step 502 of changes to the first resolver configuration file 114 can be implemented in at least two ways. One is to have the DNS manager 216 adapted to regular poll the first resolver configuration file 114.

Another way is to use more sophisticated methods such as ^Λinode' based directory notifications for monitoring possible changes, thus making it possible to keep track of changes without actively polling a storage location.

If the updated information regarding a particular DNS server 221-223, does not include any identity of a corresponding network interface 231-233 then the information is stored as so called global DNS information in the second resolver configuration file 217. That is that particular DNS server 221-223 can be reached over any of the network interfaces 231-233.

After storing in step 503 the updated information in the second resolver configuration file 217, the DNS manager 216 overwrites in step 504 the content in the first resolver configuration file 114 with the first IP address IPl, i.e. the IP address to the DNS manager 216 itself. By this last step 504, it is ensured that any following resolution request from any of the user clients 111,112 is directed to the DNS manager and the analysis of this following resolution request is performed in the same way as described above.

Claims

1. A host computer system (210) comprising an address resolver (113) and at least one user client (111) said system (210) characterized by:

- a plurality of network interfaces (231) arranged to access a plurality of DNS servers (221) ;

- a DNS manager (216);

- a first resolver configuration file (114) that is arranged to store the address to the DNS manager (216) ;

a second resolver configuration file (217) arranged to store the addresses to the plurality of DNS servers (221) and the identities of the network interfaces (231) and

that the DNS manager (216) is designed to analyze an address resolution request originating from one of the user clients (111) and to pass this request to one of the DNS servers (221) over one of said network interfaces (231) .

2. A host computer system (210) as in claim 1 wherein the DNS manager (216) is further designed to read the content in said second resolver configuration file (217) and to select the network interface (231) over which the address resolution request is to be sent.

3. A host computer system (210) as in claim 2 further comprising at least one DHCP client (215) adapted to communicate with a DHCP server (130) and to update (501) the first resolver configuration file (113) with addresses to the plurality of DNS servers (221) and with the identities of the network interfaces (231) .

4. A host computer system (210) as in claim 3 wherein the DNS manager (216) is further designed to detect (502) each update of the first resolver configuration file (114) and to store (503) this update in the second resolver configuration file 217) .

5. A host computer system (210) as in claim 4 wherein the DNS manager (216) is further designed to overwrite (504) each update to the first resolver configuration file (114) with the address to the DNS manager (216) itself.

6. A host computer system (210) as in any preceding claim wherein the DNS manager (216) is further designed to monitor the status of the network interfaces (231) .

7. A host computer system (210) as in claim 6 wherein the DNS manager (216) is further designed to update the second resolver configuration file (217) when the status of the network interfaces (231) changes.

8. A host computer system (210) as in any preceding claim wherein at least one of the network interfaces (231) is a wireless interface.

9. In a host computer system (210) having at least one user client (111) a method for performing address resolution characterized by the steps of:

- receiving (401) a host name from the user client (111);

- determining (402) a first IP address IPl to a DNS manager (216);

- passing (403) the host name to the DNS manager (216) ,

- determining (404) a second IP address IP2 to a DNS server (221) and the identity of a corresponding network interface (231);

passing (405) over the corresponding network interface (231) the host name to the DNS server (221) having the second IP address IP2; - receiving (406) from the DNS server (221) a third IP address IP3 corresponding to said host name.

10. A method for performing address resolution as in claim 9 where the step of determining (402) the first IP address IPl is done by interrogating a first resolver configuration file (114) .

11. A method for performing address resolution as in claim 10 where the step of determining (404) the second IP address

IP2 is done by interrogating a second resolver configuration file (217) .

12. A method for performing address resolution as in claim 11 further comprising the step of updating (501) the first resolver configuration file (114) from a DHCP server (130) .

13. A method for performing address resolution as in claim 12 further comprising the step of detecting (502) the updates to the first resolver configuration file (114) and storing (503) these updates in the second resolver configuration file (217) .

14. A method for performing address resolution as in claim 13 further comprising the step of overwriting (504) the updates to the first resolver configuration file (114) with the address to the DNS manager (216) .