WO2020052746A1

WO2020052746A1 - Device and method for trusted dns resolution

Info

Publication number: WO2020052746A1
Application number: PCT/EP2018/074591
Authority: WO
Inventors: Avigail Oron; Dan Touitou; Itamar OFEK
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2018-09-12
Filing date: 2018-09-12
Publication date: 2020-03-19
Also published as: CN112655186B; CN112655186A

Abstract

The present invention provides devices for securely resolving domain names. In one embodiment the device for securely resolving domain names comprises a resolver unit 101 and a authenticator unit 102, wherein the resolver unit 101 is configured to resolve a query received from a stub resolver 103 into a plurality of domain name server, DNS, records, wherein the plurality of DNS records comprises DNS records, which are signed with a Domain Name System Security Extensions, DNSSEC, technology, and to provide the plurality of DNS records and DNS validation data required for validating the DNSSEC-signed DNS records to an authenticator unit 102; and wherein the authenticator unit 102 is configured to run in a trusted execution environment, to re-validate the DNSSEC-signed records by using the DNS validation data, and to send the plurality of DNS records to the stub resolver 103 via an authenticated communication channel 104.

Description

DEVICE AND METHOD FOR TRUSTED DNS RESOLUTION

TECHNICAL FIELD The present invention relates to the communications field, and to a device and a method for securing the integrity of records provided by domain name servers to a client.

BACKGROUND

Domain Name Servers are the Internet's equivalent of a phone book. They maintain a directory of domain names and translate them to Internet Protocol (IP) addresses. This is necessary because, although domain names are easy for people to remember, computers or machines, access websites based on IP addresses. However, a fundamental problem with the domain name system (DNS) is the integrity of the results. DNS servers are often a target for attacks manipulating the servers into directing website traffic to malicious servers, which are used for account or credential collection.

Domain Name System Security Extensions (DNSSEC) is a suite of Internet Engineering Task Force (IETF) specifications attempting to secure the integrity of information provided by DNS servers as used in Internet Protocol (IP) networks. DNSSEC enables DNS records to be signed by keys, whose trust can be traced back to the DNS Root servers, thus establishing a chain of trust. Recursive Resolvers (RRs), which support the DNSSEC-technology, can perform this validation and hence ensure the integrity of the results as part of the resolution process as long as the portion of the domain name space or DNS zone, in which the RR operates and retrieves records, is using DNSSEC-technology.

However, there is a problem with this approach. The stub resolver (SR), which is the client requesting an IP address via DNS, is provided with only the answer, namely the required DNS record and a flag stating, whether the result has been DNSSEC-verified. It does not receive any evidence to the fact that the validation has indeed happened, or that this answer is authentic, meaning that it was provided by the recursive resolver and not by a malicious man in the middle (MIM).

The problem regarding uncertainty, if the DNS SEC validation was indeed performed, has a solution called DNSSEC-validation. DNSSEC-validation is a process in which the SR replays the resolution process that was done by the RR, in order to be exposed to all DNS SEC records that are required in the validation process. This way the SR can perform its own recursive authentication and signature validation and determine for itself, if the answer received from the RR is indeed DNSSEC-verified. However, this measure results in double the computation effort and network calls for every name lookup. The problem regarding uncertainty, if the received answer is authentic has been addressed by two solutions, namely DNSCrypt and DNS over TLS.

In DNSCrypt technology the recursive resolver signs the answers with a private key so that any calling stub resolver can verify the authenticity of the result. This measure prevents MIM attacks and hence ensures authenticity but not integrity, since the recursive resolver can still be hacked or hijacked, or its DNSCrypt key can be stolen.

The DNS over TLS security protocol has similar advantages and disadvantages. Instead of a private key a certificate, which is matching a single recursive resolver, is distributed to clients. DNS over TLS also prevents MIM attacks and hence ensures authenticity but not integrity, since the recursive resolver can also be hacked or hijacked, or its certificate can be stolen.

SUMMARY

In view of the above-mentioned problems and disadvantages, the present invention aims to introduce trust between a stub resolver and a recursive resolver. In particular, the present invention has the object to provide a new recursive resolver architecture, which ensures that results from a DNSSEC-signed zone are indeed validated and that false DNSSEC-validated results cannot be fabricated if the RR has been hijacked.

The object of the present invention is achieved by the solution provided in the enclosed independent claims. Advantageous implementations of the present invention are further defined in the dependent claims. The main idea of the present invention consists in a recursive resolver, which ensures validation and integrity of DNS-records either by having the RR run completely in a trusted execution environment (TEE) or by having at least the code handling the authenticated communication with clients (DNSCrypt and/or SSL/TSL) moved to a new component within the RR, the authenticator, which runs in a TEE.

A first aspect of the present invention provides a device for securely resolving domain names, comprising a resolver unit configured to resolve a query received from a stub resolver into a plurality of domain name server, DNS, records, wherein the plurality of DNS records comprises DNS records, which are signed with a Domain Name System Security Extensions, DNSSEC, technology and to provide the plurality of DNS records and DNS validation data required for validating the DNSSEC-signed DNS records to an authenticator unit; and the authenticator unit being configured to run in a trusted execution environment, TEE, to re-validate the DNSSEC- signed records by using the DNS validation data; and to send the plurality of DNS records to the stub resolver via an authenticated communication channel. In order to seamlessly allow the validation unit to perform the task of re-validating DNSSEC- signed records, the resolver unit passes DNSSEC-signed records and associated DNS validation data to the authenticator unit, which does not need to obtain these data by itself.

In an implementation form of the first aspect, the authenticator unit is further configured to re- validate the DNSSEC-signed records by using the DNS validation data comprising DNS record types according to the DNSSEC specification to re-validate a DNSSEC chain-of-trust.

Since the authenticator, which may communicate with clients over authenticated sessions (DNSCrypt and/or SSL/TSL) ensuring authenticity of the communicating partners, is running in a trusted execution environment, it is guaranteed that every result retrieved for a DNSSEC- signed zone is also validated, and only if a chain of trust is established the result will be flagged as DNSSEC-validated.

In a further implementation form of the first aspect, the authenticator unit is further configured to re-validate the DNSSEC-signed records by using a trust anchor ensuring validity of DNS records all along the resolution chain of servers, wherein the trust anchor comprises a certificate of one of a plurality of name servers encountered along the resolution chain of servers. A trust anchor may be a certificate of one of the name servers encountered on the way while resolving a DNS query (be it the root DNS server or a TLD server or just a plain name server). This may be relevant in cases, where the DNS SEC chain is broken, since one link in the chain was not signed by its parent. The trust anchor then may ensure the validity of DNS records along the resolution chain, even if a signature of one of the servers along the chain is missing.

In a further implementation form of the first aspect, the authenticator unit is further configured to flag the validated DNS records as DNSSEC-validated and to send the flagged DNS records to the stub resolver.

In a further implementation form of the first aspect, the authenticator unit is further configured to flag the validated DNS records as DNSSEC-validated with an authenticated data bit according to the DNS SEC specification.

This allows the authenticator to set a flag in the DNS response if the authenticator has successfully re-validated the DNSSEC-signed zone records.

In a further implementation form of the first aspect, the authenticated communication channel to the stub resolver comprises DNSCrypt and/or secure socket layer, SSL, technology.

In order to ensure authenticity of the communicating partners the authenticated communication channel to the stub resolver comprises DNSCrypt and/or secure socket layer, SSL, technology. This measure may avert MIM attacks by ensuring that the DNS results are provided by the recursive resolver and not by a malicious“man-in-the-middle”. In a further implementation form of the first aspect, the TEE is based on instruction codes provided by software guard extensions, SGX, technology.

A trusted execution environment provides a secure area of a main processor. It guarantees that code and data loaded inside are protected with respect to confidentiality and integrity. A trusted execution environment is an isolated execution environment which provides security features such as isolated execution, integrity of applications executing with the TEE, along with confidentiality of their assets. For example, Intel's SGX provides a particular set of CPU instruction codes that allow user-level code to allocate private regions of memory, called enclaves that are protected from processes running at higher privilege levels. A second aspect of the present invention provides a device for securely resolving domain names, configured to run in a trusted execution environment, TEE, to resolve a query received from a stub resolver into a plurality of domain name server, DNS, records, wherein the plurality of DNS records comprises DNS records, which are signed with a Domain Name System Security Extensions, DNSSEC, technology, to validate the DNSSEC-signed records and to send the plurality of DNS records to the stub resolver via an authenticated communication channel.

In this alternative new architecture for a recursive resolver the entire functionality of the RR runs in a TEE and not only the authenticator unit. Running the entire RR in the TEE also provides the desired integrity of DNS records. In this case an authenticator does not have to re- validate the DNSSEC chain of trust, since the resolver part of the RR code is already trusted in properly validating DNS records according to DNSSEC specifications.

A third aspect of the present invention provides a method for securely resolving domain names, comprising the steps of resolving, by a resolver unit, a query received from a stub resolver into a plurality of domain name server, DNS, records, wherein the plurality of DNS records comprises DNS records, which are signed with a Domain Name System Security Extensions, DNSSEC, technology, providing, by the resolver unit, the plurality of DNS records and DNS validation data required for validating the DNSSEC-signed DNS records to an authenticator unit, re-validating, by the authenticator unit, the DNSSEC-signed records by using the DNS validation data, and sending, by the authenticator unit, the plurality of DNS records to the stub resolver via an authenticated communication channel, wherein the authenticator unit runs in a trusted execution environment.

The method of the third aspect can have implementation forms that correspond to the implementation forms described above for the device of the first aspect. Accordingly, the method of the third aspect achieves all advantages and effects described above for the device of the first aspect and its implementation forms, respectively.

A forth aspect of the present invention provides a method for securely resolving domain names, comprising the steps of running a device in a trusted execution environment, TEE, resolving, by the device, a query received from a stub resolver into a plurality of domain name server, DNS, records, wherein the plurality of DNS records comprises DNS records, which are signed with a Domain Name System Security Extensions, DNSSEC, technology, validating, by the device, the DNSSEC-signed records, and sending, by the device, the plurality of DNS records to the stub resolver via an authenticated communication channel.

The method of the forth aspect can have implementation forms that correspond to the implementation forms described above for the device of the second aspect. Accordingly, the method of the forth aspect achieves all advantages and effects described above for the device of the second aspect and its implementation forms, respectively.

A fifth aspect of the present invention provides a computer program product comprising program code for controlling a device according to the first or second aspect, or for performing, when implemented on a processor, a method according to the third or fourth aspect. It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which Fig. 1 shows an architecture of a device according to an embodiment of the present invention.

Fig. 2 shows an execution process of an authenticator according to an embodiment of the present invention.

Fig. 3 shows a device according to an embodiment of the present invention. Fig. 4 shows yet another device according to an embodiment of the present invention.

Fig. 5 shows a method according to an embodiment of the present invention.

Fig. 6 shows another method according to an embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS

Fig. 1 shows an architecture 100 for a device 101 for securely resolving domain names according to an embodiment of the present invention. Since the device comprises the functionality of a recursive DNS resolver, which is known from prior art, the device 101 is also referred to in the following as a“new recursive resolver” or simply“recursive resolver” (RR). The code of the RR 101 according to an embodiment of the invention may be partitioned so that the code handling the authenticated communication with a client 103 commonly referred to as a stub resolver (SR) is moved to a new component - the authenticator 102.

The code of the authenticator or for that matter the authenticator 102 is running in a trusted execution environment (e.g. Intel's SGX enclave) and handles all activities that require trust provided by a client 103 in exchange for integrity of DNS records queried by a stub resolver 103.

A trusted execution environment provides a secure area of a main processor. It guarantees that code and data loaded inside are protected with respect to confidentiality and integrity. A trusted execution environment is an isolated execution environment which provides security features such as isolated execution, integrity of applications executing with the TEE, along with confidentiality of their assets. For example, Intel's SGX provides a particular set of CPU instruction codes that allow user-level code to allocate private regions of memory, called enclaves that are protected from processes running at higher privilege levels.

In order to ensure authenticity of the communicating partners, namely between the RR 101 or particularly the authenticator 102 and the SR 103, said partners may communicate in an authenticated communication channel 104 based on DNSCrypt and/or secure socket layer, SSL, technology. In this embodiment, all answers provided to the SR 103 are to be sent via a section of the authenticator, which handles the authenticated session management 105 on the authenticated communication channel 104, since it may be the only component of the RR 101, which has access to the session^'s key or certificate. This measure may avert MIM attacks by ensuring that the DNS results are provided by the recursive resolver 101 and not by a malicious ‘‘man-in-the-middle’’ .

Another section of the authenticator 102 may be a DNSSEC record validation section 106, which re-vali dates DNS records coming from DNSSEC-signed zones by using DNS validation data. To this end the authenticator 102 requires a resolver unit, which handles the provision of requested DNS records and resides within the RR 101, but outside of the authenticator 102, to provide 108 the authenticator 102 not only with the final result of the DNS resolution (the requested DNS record), but also with all DNSSEC records that are required for the validation process (e.g. DS, RRSIG), if the requested DNS records are with a DNSSEC-signed zone 107 of the internet. This measure allows the authenticator 102 to ensure the authenticity of the DNS result by re-validating the DNSSEC chain-of-trust, before sending the response back to the SR 103. The SR obtains proof to the fact that every received DNS record belonging to a DNSSEC- signed zone has in fact been validated by the DNSSEC record validation section 106, because it is running in the TEE of the authenticator.

Fig. 2 shows a control scheme 200 for securely resolving domain names residing in a DNSSEC- signed zone employing an authenticator 102 according to an embodiment of the present invention. In this method a“stub resolver” establishes an authenticated session with the “authenticator” and sends a query, which provides the necessary parameters as input to a required operation for answering the query, namely“resolve (“example.com”)”. Since the process of resolving may be executed in the resolver unit of the RR, which is not necessarily running in a TEE as has been elaborated upon above, the resolve request is forwarded to the resolver unit, which is named“recursive resolver” in the scheme. The subsequent process of resolving such a DNS request involving the further entities/servers“Root DNS Server”,“DNS TLD Server for‘com’”,“Authoritative Name Server for‘example.com’” is state of the art and will not be explained in detail here. Once the DNS resolution process involving above mentioned entities has been terminated, its results are handed over to the“Authenticator” by the“Recursive Resolver”. Said results not only comprise the requested DNSSEC records for ‘example.com’ but also all collected DNSSEC data that were used in the DNSSEC validation process and are now required for re-validation of the entire trust chain of servers by the authenticator. The authenticator may now re-validate the entire DNSSEC chain-of-trust by using a , trust anchor‘, which is a certificate of one of the name servers it encountered on the way while resolving, be it the root DNS server or a TLD server or just a plain name server. This may be important in cases the DNS SEC chain is broken, since one link in the chain was not signed by its parent. By using said trust anchor, e.g. a DNS Root server certificate, the authenticator validates the records down the trust chain and makes sure that they are valid end- to-end. Only in case the DNSSEC re-validation has passed, the authenticator may reply to the “stub resolver” with the required DNSSEC records, while setting the AD flag in the response to indicate the successful validation. The reply to the“stub resolver” is then authenticated according to chosen protocol - DNSCrypt, TLS, or any other authenticated communication mechanism that was used to establish the authenticated session between the“stub resolver” and the“authenticator”.

Fig. 3 depicts a device 300 for securely resolving domain names according to an embodiment of the present invention. The device comprises a resolver unit 301 and an authenticator unit 302, which are connected to exchange data in order to perform a secure resolution of domain names once a query from a stub resolver (not shown) reaches the device 300, which will also be referred to as a recursive resolver in the following.

The resolver unit 301 is configured to resolve a query received from the stub resolver into a plurality of domain name server, DNS, records, wherein the plurality of DNS records comprises DNS records, which are signed with a DNSSEC technology. As such, the resolver unit 301 may perform a DNS resolution according to standard practice in prior art by translating requested domain names, which may be typed by a user into a browser, into IP addresses. This usual DNS resolution process may also include validation of a subset of DNS records from DNSSEC- signed zones according to DNSSEC specifications. The resolver unit 301 may receive such a query from the authenticator unit 302, which may forward or delegate the query to the resolver unit 301, once it has been received by the authenticator 302 from the stub resolver. The resolver unit 301 is further configured to provide the plurality of DNS records and DNS validation data to the authenticator unit 302, whereby the plurality of DNS records comprises a requested DNS record and the DNS validation data comprises a set of records that were used in the DNSSEC validation process along the chain of servers forming a chain of IP addresses that lead to the requested DNS record.

The authenticator unit 302 is configured to run in a trusted execution environment, TEE, to re- validate the DNSSEC-signed records by using the DNS validation data, and to send the plurality of DNS records to the stub resolver via an authenticated communication channel. Since the authenticator 302 is running in a TEE and re-validates DNSSEC-signed records itself by using the DNS validation data provided by the resolver unit 301, it can guarantee that every result sent for a DNSSEC - signed zone is in fact validated. Due to the re-validation of records within a TEE, the authenticator unit 302 is not only enabled to provide a required DNS record and a flag stating whether the result has been DNSSEC-verified/validated, but more importantly to provide evidence to the stub resolver that the DNSSEC-validation has indeed happened.

In an embodiment of the device 300 the authenticator unit 302 is further configured to re- validate the DNSSEC-signed records by using a trust anchor. The trust anchor may comprise a certificate of one of the name servers encountered along the DNS resolution chain of name servers. Any name server along the DNS resolution path, be it a Root server, a TLD (top-level- domain) server or the authoritative name server for the requested domain name at the end of the resolution path, may be considered an authoritative entity for which trust is assumed (usually only the root server is trusted) and not derived by checking according to DNSSEC specifications, if the provided link is a delegation signer (DS) record and public key record that are signed by a key of the referring name server that resides higher in the DNSSEC hierarchy and so forth up to the root server.

In another embodiment of the device 300 the authenticator unit may be further configured to flag the validated DNS records as DNSSEC-validated, and to send the flagged DNS records to the stub resolver, if the re-validation performed by the authenticator unit was successful. To this end, the authenticator unit may flag the validated DNS records as DNSSEC-validated with an authenticated data bit according to the DNSSEC specification.

Fig. 4 depicts an alternative device 400 for securely resolving domain names according to an embodiment of the present invention. According to this embodiment, the device 400 is configured to run 401 in a TEE, to resolve 402 a query received from a stub resolver into a plurality of domain name server, DNS, records, wherein the plurality of DNS records comprises DNS records, which are signed with a Domain Name System Security Extensions, DNSSEC, technology, to validate 403 the DNSSEC-signed records, and to send 404 the plurality of DNS records to the stub resolver via an authenticated communication channel.

In this alternative embodiment the entire device 400 and not only the authenticator unit 302 of the device 300 runs in a TEE. Since the complete code of the device 400 is running in the TEE, a re-validation as in the device 300 is not necessary, because the section of the RR performing the DNS resolution including the DNSSEC-signed zones is already trusted.

Fig. 5 shows a method 500 according to an embodiment of the present invention, wherein the method comprises the steps of resolving 501, by a resolver unit, a query received from a stub resolver into a plurality of domain name server, DNS, records, wherein the plurality of DNS records comprises DNS records, which are signed with a Domain Name System Security Extensions, DNSSEC, technology, providing 502, by the resolver unit, the plurality of DNS records and DNS validation data required for validating the DNSSEC-signed DNS records to an authenticator unit, re-validating 503, by the authenticator unit, the DNSSEC-signed records by using the DNS validation data and sending 504, by the authenticator unit, the plurality of DNS records to the stub resolver via an authenticated communication channel, wherein the authenticator unit runs in a trusted execution environment. The method 500 may be carried out by the device 300 according to an embodiment of the invention.

Fig. 6 shows a method 600 according to an embodiment of the present invention, wherein the method comprises the steps of running 601 a device in a trusted execution environment, resolving 602, by the device, a query received from a stub resolver into a plurality of domain name server, DNS, records, wherein the plurality of DNS records comprises DNS records, which are signed with a Domain Name System Security Extensions, DNSSEC, technology, validating 603, by the device, the DNSSEC-signed records, and sending 604, by the device, the plurality of DNS records to the stub resolver via an authenticated communication channel. The method 600 may be carried out by the device 400 according to an embodiment of the invention.

The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article“a” or“an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. Device for securely resolving domain names, comprising:

a resolver unit (101) configured to:

resolve a query received from a stub resolver (103) into a plurality of domain name server, DNS, records, wherein the plurality of DNS records comprises DNS records, which are signed with a Domain Name System Security Extensions, DNSSEC, technology; and

provide the plurality of DNS records and DNS validation data required for validating the DNSSEC-signed DNS records to an authenticator unit (102); and the authenticator unit being configured to:

run in a trusted execution environment, TEE,

re-validate the DNSSEC-signed records by using the DNS validation data; and send the plurality of DNS records to the stub resolver via an authenticated communication channel (104).

2. Device according to claim 1, wherein

the authenticator unit is further configured to:

re-validate the DNSSEC-signed records by using the DNS validation data comprising DNS record types according to the DNSSEC specification to re-validate a DNSSEC chain-of-trust.

3. Device according to claim 1 or 2, wherein

the authenticator unit is further configured to:

re-validate the DNSSEC-signed records by using a trust anchor ensuring validity of DNS records all along the resolution chain of servers, wherein the trust anchor comprises a certificate of one of a plurality of name servers encountered along the resolution chain of servers.

4. Device according to any claim above, wherein

the authenticator unit is further configured to:

flag the validated DNS records as DNSSEC-validated; and

send the flagged DNS records to the stub resolver.

5. Device according to claim 4, wherein

the authenticator unit is further configured to:

flag the validated DNS records as DNSSEC-validated with an authenticated data bit according to the DNS SEC specification.

6. Device according to claim 1, wherein

the authenticated communication channel to the stub resolver comprises DNSCrypt and/or secure socket layer, SSL, technology.

7. Device according to any claim above, wherein

the TEE is based on instruction codes provided by software guard extensions, SGX, technology.

8. Device for securely resolving domain names, configured to:

run in a trusted execution environment, TEE;

resolve a query received from a stub resolver into a plurality of domain name server, DNS, records, wherein the plurality of DNS records comprises DNS records, which are signed with a Domain Name System Security Extensions, DNSSEC, technology; and

validate the DNSSEC-signed records; and

send the plurality of DNS records to the stub resolver via an authenticated communication channel.

9. Method for securely resolving domain names, comprising the steps of:

resolving, by a resolver unit, a query received from a stub resolver into a plurality of domain name server, DNS, records, wherein the plurality of DNS records comprises DNS records, which are signed with a Domain Name System Security Extensions, DNSSEC, technology; and

providing, by the resolver unit, the plurality of DNS records and DNS validation data required for validating the DNSSEC-signed DNS records to an authenticator unit;

re-validating, by the authenticator unit, the DNSSEC-signed records by using the DNS validation data; and

sending, by the authenticator unit, the plurality of DNS records to the stub resolver via an authenticated communication channel,

wherein the authenticator unit runs in a trusted execution environment.

10. Method for securely resolving domain names, comprising the steps of: running a device in a trusted execution environment, TEE;

resolving, by the device, a query received from a stub resolver into a plurality of domain name server, DNS, records, wherein the plurality of DNS records comprises DNS records, which are signed with a Domain Name System Security Extensions, DNSSEC, technology; and validating, by the device, the DNSSEC-signed records; and

sending, by the device, the plurality of DNS records to the stub resolver via an authenticated communication channel.

11. Computer program product comprising program code for controlling a device according to one of the claims 1 to 8, or for performing, when implemented on a processor, a method according to claim 9 or 10.