IN A COMMUNICATIONS NETWORK

TECHNICAL FIELD

Embodiments presented herein relate to preventing access to a service on a server, and particularly to a method, a network node, a computer program, and a computer program product for preventing access to a service on a server.

BACKGROUND

In communication networks, there is always a challenge to obtain good performance and capacity for a given communications protocol, its

parameters and the physical environment in which the communication network is deployed.

One component associated with operation of the communications network relates to handling requests for a service from an end-user terminal (such as a mobile phone, a smartphone, a tablet computer, a laptop computer, or a desktop computer) to a server in the communications network.

For examples, some applications running on the end-user terminal may be configured to directly (i.e., without explicit input from or involvement of an end-user of the end-user terminal) interact with the application servers (hereinafter simply denoted as servers). When these servers are unreachable, the application as run on the end-user terminal may repeatedly try to connect to the server until such a connection is successful. Such repeated attempts to connect to the server may occur with increasing frequency. Such a behavior of the application may thus drain the battery of the end-user terminals. Further, since every new attempt to access the server will not only wake up the end- user terminal, but also require network resources, this behavior will also increase the signaling load in the packet core network part of the

communications network. If an application is simultaneously run on a large amount of end-user terminals (such as smartphones) and the server (or servers) that the application tries to access is (are) unavailable (for example due to network issues where network cables may be broken or network equipment such as routers may be malfunctioning, or power outage), the signaling in the communications network may increase drastically and the communications network may be loaded more than dimensioned for, both regarding signaling, packet core resources and radio resources.

The above noted requests for a server may trigger activation of a bearer.

However, there is currently no way for the packet core network part of the communications network to identify why an end-user terminal is requesting a bearer to be activated. This makes it cumbersome to proactively limit the signaling in the communications network when a server outage occurs and drastically increases the usage of the network resources. Hence, issues relating to connectivity issues, load handling issues, etc. may arise when an end-user terminal requests access to a server. Since the consequences of unavailability of a server for the application run on the end- user terminal may have impact on the availability of the communications network, the impact may pull down the availability of the communications networks as the communications networks are not dimensioned for such coordinated and simultaneous use of the network resources.

Hence, there is still a need for an improved handling of network traffic in communications networks.

SUMMARY

An object of embodiments herein is to provide improved handling of network traffic in communications networks.

The inventors of the enclosed embodiments have realized that it may be beneficial to identify requests that should not be granted, and thereby reduce the network traffic. A particular object is therefore to improve handling of network traffic in communications networks by analysing the requests for access to servers in the communications networks.

According to a first aspect there is presented a method for preventing access to a service on a server. The method is performed by a network node. The method comprises receiving a domain name system (DNS) request from an end-user terminal. The DNS request relates to access of a service on at least one server by an application running on the end-user terminal. The method comprises determining whether the service associated with the DNS request is accessible or not by the end-user terminal at any of the at least one server. The method comprises, in a case the service associated with the DNS request is determined not accessible, responding to the DNS request with a DNS response comprising an address local to the end-user terminal, thereby preventing the end-user terminal from accessing the service.

Advantageously this enables improved handling of network traffic in communications networks.

Advantageously this enables improved handling of requests for access to a server in communications networks.

Advantageously, this enables prevention of queries for services that are not accessible to (or available for) the end-user terminal and thereby enables signaling in the communications network to be decreased.

Advantageously, this may improve radio resource utilization in the

communications network.

Advantageously, this may reduce unnecessary battery usage in the end-user terminal, thus prolonging the uptime of the end-user terminal and thus improving the end-user experience.

According to a second aspect there is presented a network node for

preventing access to a service on a server. The network node comprises a processing unit and a non-transitory computer readable storage medium. The non-transitory computer readable storage medium comprises instructions executable by the processing unit. The network node is operative to receive a domain name system (DNS) request from an end-user terminal. The DNS request relates to access of a service on at least one server by an application running on the end-user terminal. The network node is operative to determine whether the service associated with the DNS request is accessible or not by the end-user terminal at any of the at least one server. The network node is operative to, in a case the service associated with the DNS request is determined not accessible, respond to the DNS request with a DNS response comprising an address local to the end-user terminal, thereby preventing the end-user terminal from accessing the service.

According to a third aspect there is presented a computer program for preventing access to a service on a server, the computer program comprising computer program code which, when run on a network node, causes the network node to perform a method according to the first aspect. According to a fourth aspect there is presented a computer program product comprising a computer program according to the third aspect and a computer readable means on which the computer program is stored.

It is to be noted that any feature of the first, second, third and fourth aspects may be applied to any other aspect, wherever appropriate. Likewise, any advantage of the first aspect may equally apply to the second, third, and/or fourth aspect, respectively, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings. Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which:

Fig la is a schematic diagram illustrating a communication network according to embodiments;

Fig lb is a schematic diagram illustrating parts of the communication network of Fig la according to prior art; Fig lc is a schematic diagram illustrating parts of the communication network of Fig la according to embodiments;

Fig 2a is a schematic diagram showing functional modules of a network node according to an embodiment;

Fig 2b is a schematic diagram showing functional units of a network node according to an embodiment;

Fig 3 shows one example of a computer program product comprising computer readable means according to an embodiment; and

Figs 4 and 5 are flowcharts of methods according to embodiments.

DETAILED DESCRIPTION

The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed lines should be regarded as optional.

Fig la shows a schematic overview of an exemplifying communications network na where embodiments presented herein can be applied. The communications network na comprises a base station (BS) 13 providing network coverage in a cell (not shown). An end-user terminal (T) 12 positioned in a particular cell is thus provided network service by the base station 13 serving that particular cell. As the skilled person understands, the communications network 11a may comprise a plurality of base stations 13 and a plurality of end-user terminals 12 operatively connected to at least one of the plurality of base stations 13.

The base station 13 is operatively connected to a core network 14. The core network 14 may provide services and data to the end-user terminals 12 operatively connected to the base station 13 from an external Internet Protocol (IP) packet switched data network 15. An end-user terminal 12 may further have a wired connection to the external IP packet switched data network 15. The IP network 15 comprises at least one server (S) 18. The at least one server 18 hosts a service which an application 12a running on the end-user terminal 12 is requesting access to. The communications network 11a further comprises a network node 16.

Further details of the network node 16 will be disclosed below.

At least parts of the communications network 11a may generally comply with any one or a combination of W-CDMA (Wideband Code Division Multiplex), LTE (Long Term Evolution), EDGE (Enhanced Data Rates for GSM

Evolution, Enhanced GPRS (General Packet Radio Service)), CDMA2000 (Code Division Multiple Access 2000), WiFi, microwave radio links, HSPA (High Speed Packet Access), etc., as long as the principles described hereinafter are applicable. Examples of base stations 13 include, but are not limited to, base transceiver stations (BTS), Node Bs, Evolved Node Bs (eNodeBs), and wireless access points (APs).

Examples of end-user terminals 12 include, but are not limited to end-user equipment such as mobile phones, smartphones, tablet computers, laptop computers, and stationary computers. In general terms, an end-user terminal 12 as herein disclosed may have either a wireless connection, or a wired connection, or both a wireless connection and a wired connection to the IP packet switched network 15. Hence the communications network 11a may comprise any combinations of purely wirelessly end-user terminals 12, purely wired connected end-user terminals 12, and end-user terminals with both wireless and wired connections.

Fig lb schematically illustrates a part lib of the exemplifying

communications network 11a. In more detail, Fig lb is showing a simplified infrastructure for handling Domain Name System (DNS) requests with DNS servers and DNS caches according to prior art (hence, without the herein disclosed network node 16). According to the example illustrated in Fig lb, entries of the end-user terminal DNS cache 12c, the infrastructure DNS cache 15a, and the domain DNS cache 15b are cached at most 3600 s (i.e., the cache entries have a time to live (TTL) of at most 3600 s after that a DNS request is forwarded to the next DNS handling unit (e.g., from the end-user terminal DNS cache to the infrastructure DNS cache). Each DNS handling unit is arranged to decrease the TTL in its issued DNS response according to the TTL left. Fig lc schematically illustrates a part 11c of the exemplifying communications network 11a. In more detail, Fig lc is showing a simplified infrastructure for handling DNS requests with DNS servers and DNS caches, where in addition to Fig lb, a network node 16 has been added to the core network 14. Fig lc schematically illustrates how the DNS responses may be changed when a server failure is detected (i.e., when a service associated with a DNS request from an end-user terminal 12 is not accessible by the end-user terminal 12 at any of the servers 18) and when the server 18 is available again (i.e., when the service associated with a DNS request from an end-user terminal 12 is accessible by the end-user terminal 12 from at least one of the servers 18). Further details of operation of the part 11c of the exemplifying

communications network 11a will be disclosed below.

The embodiments disclosed herein relate to preventing access to a service on a server 18. In order to obtain prevention of access to a service on a server 18 there is provided a network node 16, a method performed by the network node 16, a computer program comprising code, for example in the form of a computer program product, that when run on the network node 16, causes the network node 16 to perform the method.

Fig 2a schematically illustrates, in terms of a number of functional modules, the components of a network node 16 according to an embodiment. A processing unit 22 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate arrays (FPGA) etc., capable of executing software instructions stored in a computer program product 31 (as in Fig 3), e.g. in the form of a storage medium 24. Thus the processing unit 22 is thereby arranged to execute methods as herein disclosed. The a storage medium 24 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The network node 16 may further comprise a communications interface 23 for communications with other devices in the communications network 11a. As such, the

communications interface 23 may comprise one or more transmitters and receivers, comprising analogue and digital components and a suitable number of ports for such communications. The processing unit 22 controls the general operation of the network node 16 e.g. by sending data and control signals to the communications interface 23 and the storage medium 24, by receiving data and reports from the communications interface 24, and by retrieving data and instructions from the storage medium 24. Other components, as well as the related functionality, of the network node 16 are omitted in order not to obscure the concepts presented herein.

Fig 2b schematically illustrates, in terms of a number of functional units, the components of a network node 16 according to an embodiment. The network node 16 of Fig 2b comprises a number of functional units; a receive unit 22a, a determine unit 22b, and a respond unit 22c. The network node 16 of Fig 2b may further comprises a number of optional functional units, such as any of a compare unit 22d, and a provide unit 22e. The functionality of each functional unit 22a-e will be further disclosed below in the context of which the functional units may be used. In general terms, each functional unit 22a-e may be implemented in hardware or in software. The processing unit 22 may thus be arranged to from the storage medium 24 fetch instructions as provided by a functional unit 22a-e and to execute these instructions, thereby performing any steps as will be disclosed hereinafter. Figs 4 and 5 are flow chart illustrating embodiments of methods for preventing access to a service on a server 18. The methods are performed by the network node 16. The methods are advantageously provided as computer programs 32. Fig 3 shows one example of a computer program product 31 comprising computer readable means 33. On this computer readable means 33, a computer program 32 can be stored, which computer program 32 can cause the processing unit 22 and thereto operatively coupled entities and devices, such as the communications interface 23 and the storage medium 24 to execute methods according to embodiments described herein. The computer program 32 and/or computer program product 31 may thus provide means for performing any steps as herein disclosed.

In the example of Fig 3, the computer program product 31 is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 31 could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory. Thus, while the computer program 32 is here schematically shown as a track on the depicted optical disk, the computer program 32 can be stored in any way which is suitable for the computer program product 31.

Reference is now made to Fig 4 illustrating a method for preventing access to a service on a server 18 according to an embodiment. The method is performed by the network node 16.

It is assumed that an application 12a running on an end-user terminal 12 requests access of a service on at least one server 18. This request results in the end-user terminal 12 sending a domain name system, (DNS) request. The processing unit 22 of the network node 16 is therefore arranged to, in a step S102, receive a DNS request from an end-user terminal 12. The DNS request relates to access of a service on at least one server 18 by an application 12a running on the end-user terminal 12.

The network node 16 then investigates whether or not the service is accessible by the end-user terminal 12. Particularly, the processing unit 22 of the network node 16 is arranged to, in a step S104, determine whether the service associated with the DNS request is accessible or not by the end-user terminal 12 at any of the at least one server 18. As will be further disclosed below, this may involve determining whether there are connectivity issues or not in the communications network 11a. This determination may be achieved by supervising the access to different IP addresses and servers 18 in the communications network 11a. Supervision may be performed by keeping statistics for the destinations and domains.

If it has been determined that the service is not accessible by the end-user terminal 12 the network node 16 responds to the DNS request with an address that is local to the end-user terminal 12. The processing unit 22 of the network node 16 is arranged to, in a step S106, if determined that the service associated with the DNS request is not accessible by the end-user terminal 12 at any of the at least one server 18, respond to the DNS request with a DNS response comprising an address local to the end-user terminal 12. The end- user terminal 12 is thereby prevented from accessing the service, since the DNS response comprises the local address and not the address of the at least one server 18 requested by the DNS request in step S102.

Once the service associated with the DNS request is accessible by the end- user terminal 12 at the at least one server 18, such DNS requests may again be responded to with the address of the server 18.

Embodiments relating to further details of preventing access to a service on a server 18 will now be disclosed.

There may be different examples of addresses local to the end-user terminal 12. For example, the address local to the end-user terminal 12 may be an Internet protocol (IP) address of the end-user terminal 12. For example, the address local to the end-user terminal 12 may be an Internet protocol (IP) address of a device in a local network of the end-user terminal 12. For example, the address local to the end-user terminal 12 may be a loopback address.

Reference is now made to Fig 5 illustrating methods for preventing access to a service on a server 18 according to further embodiments. In a case at least one server 18 is accessible by the end-user terminal 12, forwarding of the DNS request to non-accessible server(s) 18 may be prevented. Particularly, according to an embodiment the processing unit 22 of the network node 16 is arranged to, in an optional step S108, and in a case it has been determined that the service is accessible by the end-user terminal 12 on at least one server 18 of the at least one server 18 associated with the DNS request, prevent forwarding of the DNS request to any server 18 associated with the DNS request and not accessible by the end-user terminal There may be different ways to, as in step S104, determine whether the service associated with the DNS request is accessible or not. Different embodiments relating thereto will now be described in turn.

For example, the actual server 18 may be down. The server 18 may be down for a number of reasons; the server 18 may have a power outage. According to an embodiment the processing unit 22 of the network node 16 is therefore arranged to, in an optional step Si04a, determine that the service is not operating. As a technical effect, lowering the load on the servers 18 that are down (by preventing DNS requests being forwarded to such servers 18) could imply that it could be easier to get the servers 18 up and running again.

For example, the connection to the server 18 may be down. The connectivity to the server 18 may be lost for a number of reasons; a cable to the server 18 may be broken, etc. According to an embodiment the processing unit 22 of the network node 16 is therefore arranged to, in an optional step Si04b, determine that there is no operable network connection to the at least one server 18.

For example, during heavy load in the communications network 11a (e.g., with signaling levels close to maximum capacity in at least one of the access network, the core network, and the IP network), DNS requests (or DNS queries) for selected servers 18 may result in a device-local address being returned as in step S106. This would decrease signaling load in the

communications network 11a at the cost of loss certain services for the end- user terminal 12. The selection of which server 18 or servers 18 are accessible or not by the end-user terminal 12 may depend on the content of the service as hosted by the server 18. The content may be associated with a level of priority. Hence different services may be associated with different levels of priority. This may enable that for one end-user terminal 12 an emergency service is available whilst a gaming service is not available. Hence, the application 12a may be associated with a priority value. According to an embodiment the processing unit 22 of the network node 16 is arranged to, in an optional step S104I, determine that the service associated with the DNS request is not accessible by the end-user terminal 12 by determining a network load of a network through which the at least one server 18 is connectable by the end-user terminal 12 to be higher than a predetermined threshold value associated with the priority value. For example, the end-user terminal 12 may be associated with a user account. The user account may be associated with a pre-paid quota and hence be a so- called pay-as-you-go, pay-as-you-talk, pay and go, prepaid wireless, or prepay und-user terminal. A prepaid end-user terminal 12 being out of quota would not be able to access prepaid service on a server 18, but the application 12a running on the end-user terminal 12, may still try to connect to the service by sending DNS requests. According to an embodiment the processing unit 22 of the network node 16 is arranged to, in an optional step Si04m, determine that the service associated with the DNS request is not accessible by the end- user terminal 12 by determining the user account to be out of quota for accessing the service.

For example, the end-user terminal 12 is associated with a user account which in turn may be associated with a subscription service. The subscription may only have a limited set of destinations/services allowed. According to an embodiment the processing unit 22 of the network node 16 is arranged to, in an optional step Si04n, determine that the service associated with the DNS request is not accessible by the end-user terminal 12 by determining the user account not to have a subscription to the subscription service.

For example, connectivity problems may be identified by supervising access statistics to often contacted IP addresses (or servers 18) in the

communications network 11a. Statistics may be kept over the most frequent domains queried by name lookups towards the DNS servers, so as to identify a frequency of occurrence of requests on IP level to a particular server 18 (or address). The statistics may thus indicate that connectivity to a server 18 is down. According to an embodiment the processing unit 22 of the network node 16 is therefore arranged to, in an optional step S104C, compare the DNS request to stored data. The stored data comprises statistics over frequently requested network domains. The processing unit 22 of the network node 16 may further be arranged to, in an optional step Si04d, determine that the service is not accessible by the end-user terminal 12 in a case the statistics indicate that the service is associated with a network domain being requested more often than a predetermined threshold limit.

There may be different ways to determine a cause for a server 18 to be unavailable or not accessible by the end-user terminal 12. Different embodiments relating thereto will now be described in turn.

For example, the frequency of data towards the IP addresses pointed to by the DNS request may be measured. According to an embodiment the processing unit 22 of the network node 16 is thus arranged to, in an optional step Si04e, determine that the service associated with the DNS request is not accessible by the end-user terminal 12 by determining a frequency of occurrence of DNS requests towards IP addresses pointed to by the DNS request to be higher than a predetermined threshold value.

For example, the rate between the number of requests and the amount of data transferred per request in the communications network 11a may be monitored. That is, the average data delivery per request may be monitored. Measurements of such monitoring may vary over time, but if the average data volume per request suddenly drops to close to zero for most users using the same server domain (address or domain name), then a server failure can be anticipated. According to an embodiment the processing unit 22 of the network node 16 is thus arranged to, in an optional step Si04f, determine that the service associated with the DNS request is not accessible by the end- user terminal 12 by determining a ratio between the number of DNS requests transmitted to the at least one server 18 and the amount of data transferred from the at least one server 18 per DNS request to be higher than a

predetermined threshold value.

For example, the above disclosed monitoring may be performed on a transmission control protocol (TCP) level alone. For example, if packets are more often flowing in uplink than in downlink, then the destination server 18 may be classified as not accessible. According to an embodiment the processing unit 22 of the network node 16 is thus arranged to, in an optional step Si04g, determine that the service associated with the DNS request is not accessible by the end-user terminal 12 by determining a ratio between the number of TCP packets towards IP addresses pointed to by the DNS request and the number of TCP packet from IP addresses pointed to by the DNS request to be higher than a predetermined threshold value.

For example, if the cause for radio service requests to a server 18 may be correlated with a lower average traffic volume from the server 18, this can be used as and indicator that the server 18 is down. According to an

embodiment the processing unit 22 of the network node 16 is thus arranged to, in an optional step S104I1, determine a correlation between the number of DNS requests and the traffic volume in the communications network 11a. Identification of the likely cause of a service request can be done by

identifying the top destinations (and servers 18 related thereto) in the communications network 11a and if the frequency of these in the packets received shortly after a service requests increases drastically, then it may be assumed that the destination has a service availability issue. For example, results from hypertext transfer protocol (HTTP) requests for the servers 18 may be monitored. Such monitoring may indicate a server 18 not to be accessible. According to an embodiment the processing unit 22 of the network node 16 is thus arranged to, in an optional step Si04j, determine that the service associated with the DNS request is not accessible by the end- user terminal 12 by determining the number of failed HTTP requests to the at least one server 18 to be higher than a predetermined threshold value.

For example, a per flow uplink/downlink traffic ratio for the first few seconds after the bearer has been established may be used as a way of identifying issues for that flow. If suddenly a predetermined amount of flows during a predetermined time-frame, such as 1 to 5 minutes) to the same server 18 has the same issue, then the service on the server 18 is unreachable and hence not accessible by the end-user terminal 12. According to an embodiment the processing unit 22 of the network node 16 is thus arranged to, in an optional step Si04k, determine that the service associated with the DNS request is not accessible by the end-user terminal 12 by determining a ratio between uplink traffic and downlink traffic on a bearer during a predetermined amount of time after activation of the bearer, where the bearer is used for the DNS request.

Further details regarding how to handle DNS caching in the end-user terminal 12 will now be disclosed. Reference is now again made to Fig lc. In general terms, the end-user terminal 12 is arranged to cache DNS responses according to their ITL (time to live) value. This means that the owner of a domain has set a certain time interval that a DNS entry is valid. This certain time interval may be in the range of hours to days. Typically, when the configuration of the application 12a run by the end-user terminal 12 needs to be changed, the TTL is lowered to seconds or minutes for rapid propagation of the new configuration. This may be performed at least as much time in advance as the old TTL configuration to work as intended.

The DNS response may thus comprise a TTL value determining a DNS cache time in the end-user terminal 12. Different embodiments relating to how to determine this TTL value will now be described in turn.

For example, the TTL value may be changed if it is deemed too high or too low as such. According to an embodiment the processing unit 22 of the network node 16 is arranged to, in an optional step Sio6a, determine the TTL value of a network DNS server of the at least one server 18 to be different from a desired value; and if so, in an optional step Sio6b: provide the end- user terminal 12 with a predetermined TTL value being different from the TTL value of the network DNS server. For example, the TTL value of the network DNS server of the at least one server 18 may be higher or lower than desired. For example, the TTL value of the network DNS server may be 3600 s and the predetermined TTL value provided to the end-user terminal 12 may be either 1200 s or 4200 s.

For example, the TTL value may be lowered or increased when failure occurs (i.e., when the service associated with the DNS request is not accessible by the end-user terminal 12 at any of the at least one server 18). Particularly, according to an embodiment the network node 16 is associated with two different TTL values; a first TTL value and a second TTL. The first TTL value relates to the service being available and the second TTL value relates to the service being unavailable. The DNS response comprises the second TTL value in a case the DNS request is not accessible by the end-user terminal 12 at any of the at least one server 18. The second TTL value may be lower than the first TTL value, or vice versa.

For example, the TTL values in in the DNS response (see, e.g., step S106) may need to be shortened so that the network node 16 can receive DNS requests (see, e.g., step S102) from the end-user terminal 12 often enough in order to be able to change the TTL values included in the DNS response to the end- user terminal 12 when the requested service is not accessible by the end-user terminal 12.

For example, the network node 16 may be arranged to change the TTL value in DNS responses resulting from DNS request for the most frequent sites (server 18s) in the communications network 11a. This can be achieved by analyzing the DNS responses from the network DNS servers and lower the TTL values before sending the DNS response to the end-user terminal 12. A DNS response TTL value of in the order of, say, five minutes may allow the entire communications network 11a to have recovered from an outage only five minutes after the problem has been identified. If assumed that the poll rate of the application 12a triggering the DNS request is fifteen minutes, then most of the end-user terminals 12 will not even experience the network outage. l8

In general terms, in the example schematically illustrated in Fig IC, a name belonging to the domain handled by the domain DNS 15b is queried (i.e. requested, as in step S102) for at time ti=o (seconds). This query populates the infrastructure DNS server 15a and the DNS cache 12c. The network node 16 is arranged to reduce the TTL from 3600 s to 1200 s, as this is assumed to be the desired maximum time for a device to stop using the IP address of a failed server 18. This TTL value is therefor also what is cached in the device DNS cache 12c. At time t2=2500 s the service is detected to be unavailable, or at least not accessible by the end-user terminal 12 (which then may have been identified by monitoring flows from other end-user terminals, or this end- user terminal 12). Any DNS query from any end-user terminal from this time on will now through the operation of the network node 16 populate the device DNS cache 12c with a TTL=6oo s and an IP address local to the end-user terminal 12, in the present example: 127.0.0.1. The TTL=6oo s is in this case chosen to give a maximum recovery time for the application 12a of 10 minutes after the server 18 (or at least its service) has become available again. At t3=2700 s the server 18 (or at least its service) is detected as recovered (which may have been done by allowing a few end-user terminals try to connect to the service just to get new server statistics). The network node i6may then be arranged to respond to the end-user terminal 12 with the actual IP addresses of the server/service and an updated TTL value. Acording to the present example the updated TTL value will be 900 s, which is less than the 1200 s configured in the network node 16. This is a result of the TTL value aging and this is the result from the query to the DNS server 15a. The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the appended patent claims. For example, although described in an IPv4 context, the herein disclosed embodiments are not limited to or dependent on IPv4 signalling and are agnostic to the IP version used and hence applicable to any IP-like protocol based on features as disclosed herein. For example, although placed in the core network 14, the herein disclosed network node 16 is not dependent on signalling in the core network 14 and may alternatively be located in the IP network 15, or yet alternatively in the base station 13.