UMEÅ UNIVERSITET June 5, 2020
Department of Computing Science Version 1.0
Secure DNS transport methods
Name Tony Berglund Email dv17tbd@cs.umu.se
Contents
Contents
1 Introduction 1
1.1 Background . . . 2
1.2 Purpose and Research Questions . . . 3
1.3 Delimitations . . . 4 2 Related Work 4 3 Method 6 3.1 Choice of Method. . . 6 3.2 Data collection . . . 7 4 Results 8 5 Discussion 9 5.1 Interpretation of Results . . . 9
5.2 Conclusions and Recommendations . . . 11
1 Introduction
Abstract
The Domain Name System (DNS) is a large cornerstone in internet traffic. It translates domain names to IP addresses. Standard DNS (Do53) does not encrypt any of its traffic which leads to some security issues. Mainly that others are able to extract information and tamper with the DNS requests and responses. Two promising secure DNS pro-tocols are DNS over HTTPS (DoH) and DNS over TLS (DoT). They use encryption and authentication in the transfer of data to prevent the issues caused by standard DNS. In this paper a study is presented that compares the two mentioned secure DNS protocols along with Do53 in terms of latency in resolving request. The findings show that DoT la-tency is in general higher then DoH under the testing circumstances. Do53 latency is lower then both of the secure protocols except in some edge cases where DoH received the lowest latency from a single request. Included with the finding is also several recommendations on how the testing can be expanded to cover a larger scope of DNS transport meth-ods than the test performed in this study.
1 Introduction
When the internet was first created in 1983 it was used mainly by sci-entist who shared research with each other. In the last decades the internet has become a large number of domains with a vast amount of everyday users. Underlying almost all internet traffic is the Domain Name System (DNS). It is heavily used to locate the IP address of a server to connect to when given a domain name like example.com. Many implementation decisions of DNS was made with focus on min-imizing latency on resolving requests because of the high use of DNS in internet traffic. Standard DNS uses the User Datagram Protocol (UDP) as its data transport method because of its low latency. UDP is sent in the clear which means it is sent unencrypted and thus makes it observable to anyone, this leads to problems such as eavesdropping and data tampering. In recent years a few secure DNS protocols has been
1 Introduction
suggested as an alternative to standard DNS. In this paper a study will be presented that analyses the latency of resolving DNS request using different secure data transport methods that could be used as an al-ternative to the UDP protocol in a DNS service. Secure in this paper means that the connection is authenticated and encrypted. The secure transport methods analysed in this paper are DNS over HTTPS (DoH) [1] and DNS over TLS (DoT) [2]. The two methods has gotten sup-port from several DNS resolvers and also have supsup-port and suggested standards by the Internet Engineering Task Force (IETF).
1.1 Background
DNS is a service that maps a domain name to an IP address and was invented 1983. It consist of a hierarchical structure and is in charge of finding and identifying domains and services connected to the internet. It can be seen as a large database containing all domain names of the internet but is built as a distributed service to handle the large amount of domains and remove a single point of failure. Meaning that if a single entity of the distributed service malfunction, the whole system does not collapse. To get the IP address to a domain a query has to be sent with the domain name to a resolver. A regular home network usually use a recursive resolver given by the internet service provider by default, but it can be changed to different ones. A recursive resolver can send the query to other resolvers if it does not have the response cached. When DNS was first created one of the targeted goals was to resolve request with low latency to enhance user experience. Some security aspect where overlooked or sacrificed for faster query resolving. Standard DNS also known as (Do53) uses the UDP as data transport protocol which does not encrypt messages.
In recent years a demand for a more secure DNS service that does not rely on the UDP protocol as a data transport method has been increasing. The main reason for the demand is privacy, where users do not want their DNS traffic to be readable by others. Another reason is to prevent man in the middle attacks where the data is tampered with. Two promising alternatives that has gotten support by IETF are DoH
1 Introduction
and DoT. They both encrypt their queries to add security to the users but uses different protocols and methods to do so. Both have gotten implemented by some public DNS resolvers. Also some browsers and operating systems have started supporting them to different extent. DoH was first proposed in 2018 by IETF as a alternative to standard Do53. DoH uses the HTTPS and HTTP/2 protocol to establish a con-nection. It is not fully determined exactly how DoH should be im-plemented but there exists some suggested standards. Some companies experiment with those and have created resolvers that supports it. DoH encrypts the data and sends it amongst all other HTTPS traffic on port 853 to make it unreadable to others. DoT uses the Transmission Control Protocol (TCP) to make a connection and the Transport Layer Security (TLS) protocol for encryption and authentication. It was introduced in 2016 and has gotten support from many public resolvers. Every request with DoT uses a distinct port and can be observed by others on the network. The content of the request and response will be encrypted and uninterpretable to others but it does not hide amongst other traffic like DoH.
1.2 Purpose and Research Questions
In this paper a study will be presented that will
compare the DoT and the DoH DNS transport protocol in terms of la-tency in resolving requests.
The purpose of the study is to suggest a secure DNS transport protocol that can be used as an alternative to standard DNS. Added security of-ten increases laof-tency and if the service is to compete against the laof-tency of standard DNS, the one with the lowest latency would be prefered. In addition to comparing the secure transport methods against each other, they will also be compared with standard Do53. The purpose for that comparison is to estimate the trade off between latency and security. If a secure transport method where to be suggested as an alternative to Do53 it also need to have similar latency to be able to handle the amount of traffic that the DNS protocol uses.
2 Related Work
1.3 Delimitations
There are many attributes of the secure transport methods that differ. The DoH protocol sends the request among the encrypted HTTPS traf-fic which makes it in practical terms not identifiable. This can lead to several issues like filters for blocking domains is harder to implement for DoH. A more detailed description of implication associated with the different methods can be seen in [3].
The DoT method will establish a connection on an own port where others observing the network traffic will see that a request is being made. They can not interpret the contents of the request or response but it is observable and blockable by a network administration for example. This difference can be seen as good or bad depending on point of view. A user most likely will not mind that their request is hidden amongst other traffic, they might actually prefer it. A network administrator would likely want more controll over the network and see it as an issue. Some regions of the world have very strict censorship restriction and with DoH they will not be able to reject the requests as easily as they would with DoT.
The study presented in this paper will only focus on latency. Attributes like the ones mentioned above will not be taken into consideration, that is beyond the scope of this paper.
2 Related Work
In this section work related to this paper or parts associated with it will be presented.
Lu et al [4] presented in their paper an end to end large scale measure-ment of different protocols that establishes DNS over encryption. Those are referred to as secure DNS transport methods in this paper. They explain how the protocols work and describe strengths and weaknesses from different vantage points. Their large scale measurement tests sev-eral protocols on many resolvers from different regions of the world.
2 Related Work
They also include an observation of different real world encrypted traf-fic and usage of resolvers. Out of the 5 different secure DNS transport methods that they analysed only DoT and DoH are extensively sup-ported by resolvers. They are the most standardized and supsup-ported protocols to ensure encrypted DNS. In my study I chose to compare these two protocols because of the support they have from public re-volvers and that they are the most likely to get a more usage in everyday DNS traffic. Differences between this paper and the above mentioned one is that it does not take into consideration the different strength and weaknesses mentioned, like TLS Time To Live (TTL) parameter being misused in some cases by services. The DNS traffic that is used in the study is initiated from a controllable testing software and do not use any traffic observed on a network level.
Hounsel et al [5] presented a large study on page load times using Do53, DoT and DoH protocols. They tested the protocols on different DNS resolvers and network conditions from servers in different regions in the world. The main goal of their paper was to analyse how the different protocols can affect user experience under certain circumstances. They concluded that secure protocols like DoT and DoH can load pages faster then Do53 under certain network conditions. Those circumstances can occur when some package loss and timeouts are introduced where such protocols can recover faster with the TCP protocol. Do53 uses UDP that only relies on a timeout. The test they presented depended heavily on the browser used in the test. A lot of web pages uses third party resources, loading such a page requires multiple DNS requests. Other pages only require a single request. The tests presented in the paper showed that different resolvers perform differently efficiently. The meth-ods still compares similarly against each other when sent to the same resolver, but if one method send its message to two different resolvers it could get much lower latency from one of them.
The study in this paper focuses on latency in resolving individual re-quests instead of page load times. It also do not use any browser of any sort. The latency times of the methods is compared against each other and not much consideration is given to the actual latency of the request because it can vary heavily depending on the resolver.
3 Method
3 Method
In this section the choice of method to answer the research questions is presented along with how the data was collected.
3.1 Choice of Method
Implementing and executing a testing software is the method chosen to answer the research question of comparing the two selected secure data transport methods. The software measures the average time it takes for the two secure transport methods and Do53 to resolve DNS requests during a 24 hour test. Along with the average time, the minimum response time and the maximimum response time for each test hour is also measured. This choice is to give an image of how the different methods perform overall and in the extreme cases. There are a lot of factors to take in to consideration that can alter the result of such a test. All the request is sent synchronously after each other in order to not fill the thread pool of the device executing the software. Network conditions can alter depending on the time of day because the majority of users are not as active in the middle of the night as in the day time. The three methods alternate the request they send to give them similar network conditions. The domain names the request use is from a data set gathered from Alexa top 500 global domains [6]. This choice was made to give a decent representation of regular queried domains. Before every time a request is sent with the software it will choose a random domain from the data set. This is to minimize cached responses for the next method. If Do53 send a request for "example.com" and DoT send one right after with the same domain. DoT could probably get a cached response for the domain while Do53 less likely would. The different methods could probably get a decent amount off cached responses anyway because the data set uses top rated domains which could exist in the resolvers cache when it receives the request. How cached responses get retrieved from the resolver is beyond the testing softwares control. Cloudflares anycast DNS resolver was used in the testing because it is one of the most commonly used globally and it has
3 Method
support for all the different secure transport methods. Previous research has shown that the speed of resolving request can vary dramatically depending from where it is sent [5]. All requests sent with the testing software is from a static server in the Netherlands. The requests sent are all to the same resolver from the same regional location which should not give a unfair advantage to any of the different methods. During the test no other non essential software is running on the server so every request have access to all of the servers available resources. If errors that would lead to a request not being resolved, that time will not be included in the measurements. The study focuses on resolving times and a DNS error caused by a busy resolver and connection problems amongst other things is not a resolved request. The amount of errors for each method is still be measured and taken into account when interpreting the results.
3.2 Data collection
with the following specs
The testing software is written in Node.js and uses the "dns" and "doh-dec" library to send DNS requests using the different transport methods. The software takes a timestamp right before a request is being sent and one after it is resolved. Thees times are used to measure the average, minimum and maximum resolve times for the different methods every hour of the test. The server the testing is executed on has the following specs:
Proccessors: Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz Nr of processors: 1
Memory: 1 GB
OS: Ubuntu 18.04.03
The test was initiated at 2020-05-29 15:34 and kept running for 24 hours with the setup described in section 3. Every method was able to send 2101645 request each during the 24 hour test. Do53 was unable to resolve 8 out of the requests sent. DoT failed to resolve 32 and DoH failed to resolve 1 request.
4 Results
4 Results
The results from the testing software described in section 3 can be seen in figures 1-3 and in table 1.
Figure 1: the average latency per hour for the different methods during a 24 hour test
Figure 2: the minimum latency per hour for the different methods during a 24 hour test
5 Discussion
Figure 3: the maximum latency per hour for the different methods dur-ing a 24 hour test
Table 1: variations of resolving times during the 24 hour test in ms
5 Discussion
In this section the results is analysed and interpreted from the results produced in section 4. Recommendations for usage of secure transport methods is presented along with several suggestions for how the test-ing could be extended to cover a larger scope of secure DNS transport methods.
5.1 Interpretation of Results
The acquired data from the testing software clearly shows that DoH has lower latency in resolving requests than DoT on average for every test
5 Discussion
hour. This can possibly be related to the results acquired by Hounsel et al [5] they mentioned that under their test for page loading times that DoT resolved faster than DoH for request below 50ms. If a request took longer time than that, DoH would outperform DoT in the general cases. As mentioned earlier in this the paper, the amount of ms can differ depending on things like network conditions and geographical location. So the 50 ms threshold could be something entirely else in my testing environment. With the lack of description on their testing setup in the paper and the way measurements where taken in my tests, this is just a speculation and can not be known for certain. The difference between the secure transport methods in average is a few ms, but in percentage DoT performed approximately 55% slower throughout the test. Do53 had lower average latency then both of the secure transport methods for every hour during the test. This is not an unexpected outcome because of the additional cost of adding encryption and authentication to DoT and DoH.
The minimum resolving times for the methods were measured every hour. This was to analyse how they perform in the best case scenar-ios. That would most likely be a cached response from the resolver because of the large amount of request being sent and the use of top visited domains in the test. DoT and Do53 got a low variance of mea-sured minimum times for every test hour. The minimum times for DoT where slightly higher than Do53. That is something to be expected from cached responses due to encryption and larger overhead for DoT. The minimum resolving time for DoH are more inconsistent. In most of the test hours it resolved slower then both Do53 and DoT. DoH has a larger overhead than DoT. A higher resolve time in cached responses could be expected when the overhead will be the main difference between them. In three of the test hours DoH has low minimum resolve rates and two out of them is lower then Do53, see Figure 2. With the larger overhead of DoH it was not expected that it would get a lower minimum resolving time then the other methods. A possible explanation can be found in IETF:s documentation [1] DoH can use HTTP caches, something that Do53 and DoT can not. The low minimum resolving rates could be a cause of responses from such caches.
5 Discussion
Figure 3 shows the Maximum resolve time for each test hour for the dif-ferent methods. The graph is very erratic and can have over a hundred ms difference between test hours for the different methods. The max-imum times are most likely obtained very far along the DNS resolver hierarchy. When the request is being sent from resolver to resolver it can be delayed by busy network traffic and is why some request can take a very long time to resolve. Observing the graphs in figures 1-3 one can see that the average latency do not deviate that far from the minimum times in comparison to the maximum times. That implies that although the high latency resolving times do occur it is not as often as the lower ones. The requests that did not resolve for the different methods during the test could be of this character, where the request where sent along until it got canceled by a timeout. It could also be other reasons like connection problems with a resolver amongst other things. DoT failed to resolve most request out of the different methods, where 32 out of 2101645 request did not get a response. Dealing with connections to resolvers, time outs and network conditions that is not something out of the ordinary and was not taken into much consideration when inter-preting the results.
5.2 Conclusions and Recommendations
From the results produced in section 4, DoT has a higher average resolv-ing latency then DoH by approximately 55%. DoT had lower minimum resolving times in general but DoH produced the lowest values during the entire test. In the measured maximum resolving times the different methods varied in a large span where one method could perform better then the other depending on the hour. With this information the se-cure transport method to use in a service instead of Do53 would be DoH because of the significantly lower average time in resolving requests. Do53 in comparison with the secure transport methods performed sig-nificantly better in the average measurements and the minimum mea-surements overall. The DNS system would take on a severely larger load of computation time if one of the secure transport methods were to replace it. A secure transport method can still be used by clients
5 Discussion
when they are in need of it and let the other traffic run with Do53. For a secure transport method to replace Do53 in all cases future improve-ments is most likely needed. Such improveimprove-ments can possibly be made in resolver, protocols and implementation in operating systems. Im-plementation of them in web browser can also be a contributing factor because that is the source of the majority of DNS usage.
5.3 Limitations and Future Work
The testing done in this study is fairly limited. It has a small scope that does not cover all aspects of secure transport methods and the usage of DNS. For future work similar tests should be done with a larger set of domains that is not all top rated domains globally. It is important to see how well the methods perform with odd domains that are not visited that often. The testing could also be done with different resolvers and with the requests being sent from different regions of the world which can have an impact on the result, as shown in Lu et al [4]. In the results produced in this paper, the Maximum times of resolving request were very inconsistent and did not offer much insight when comparing the methods. Another approach could be to also take a measurement that ignore the 5 or 10% edge cases of resolving times. It could give a picture of resolving times in good and bad conditions but with the extreme cases cut out of the measurements.
Acknowledgements
Special thanks to Clavister for providing me with the opportunity and inspiration for this study. They also offered me with guidance and suggestions. I also would like to thank Buster Hultgren Wärn whom performed a closely related study during the same period and was a co contributor for implementing the testing software.
5 Discussion
References
[1] DNS Queries over HTTPS (DoH), P.Hoffman, Internet Engineering
Task Force, October 2018. Retrieved 2020-06-01. Available: https://tools.ietf.org/html/rfc8484 [2] [1] Specification for DNS over Transport Layer Security (TLS), Z. Hu,
L. Zhu, J Heidemann, A. Mankin, D. Wessels and P. Hoffman, Internet Engineering Task Force, May 2016. Retrieved 2020-06-01. Available: https://tools.ietf.org/html/rfc7858
[3] B. Leiba, S. Woolf, J. Abley, T. April, P. Ebersman, O. Filip, G. Huston, W. Kumari, J. Latour, J. Levine, C. Roosenraad, T. Whalen, "SAC109: The Implications of DNS over HTTPS and DNS over TLS,"
ICANN, March 2020. Retrived Retrieved 2020-05-24 . Available: https://www.icann.org/en/system/files/files/sac-109-en.pdf
[4] C. Lu, B. Lui, Z. Li, S. Hou, H. Duan, M. Zhang, C. Leng, Y. Liu Z. Zhang, J. Wu, “An End-to-End, Large-Scale Measurement of DNS-over-Encryption: How Far Have We Come?,” in Proc. of the In-ternet Measurement Conference ’19. IMC, october 2019, pp. 22–35, doi: 10.1145/3355369.3355580.
[5] A. Hounsel, K. Borgolte, P. Schmitt, J. Holland, N. Feamster, “Com-paring the Effects of DNS, DoT, and DoH on Web Performance,” in
Proc. of the Web Conference 2020(WWW’20) febuary 2020, doi: 10.1145/3366423.3380139. [6] Retrieved 2020-04-09 Available: https://www.alexa.com/topsites
[7] T. Böttger, F. Cuadrado, G. Antichi, E.L. Fernadez, G. Tyson, I. Castro, S. Uhlig, “An Empirical Study of the Cost of DNS-over-HTTPS” in Proc. of the Internet Measurement Conference ’19. IMC, october 2019, pp. 15–21, doi: 10.1145/3355369.3355575.
[8] P. Callejo, R. Cuevas, N. Vallina-Rodriguez, Á. Cuevas, “Measuring the Global Recursive DNS Infrastructure: A View From the Edge,” IEEE Access 7:1-1, October 2019, doi: 10.1109/ACCESS.2019.2950325.
