Connection-Oriented DNS to Improve Privacy and Security

Abstract

The Domain Name System (DNS) seems ideal for connectionless UDP, yet this choice results in challenges of eavesdropping that compromises privacy, source-address spoofing that simplifies denial-of-service (DoS) attacks on the server and third parties, injection attacks that exploit fragmentation, and reply-size limits that constrain key sizes and policy choices. We propose T-DNS to address these problems. It uses TCP to smoothly support large payloads and to mitigate spoofing and amplification for DoS. T-DNS uses transport-layer security (TLS) to provide privacy from users to their DNS resolvers and optionally to authoritative servers. TCP and TLS are hardly novel, and expectations about DNS suggest connections will balloon client latency and overwhelm server with state. Our contribution is to show that T-DNS significantly improves security and privacy: TCP prevents denial-of-service (DoS) amplification against others, reduces the effects of DoS on the server, and simplifies policy choices about key size. TLS protects against eavesdroppers to the recursive resolver. Our second contribution is to show that with careful implementation choices, these benefits come at only modest cost: end-to-end latency from TLS to the recursive resolver is only about 9% slower when UDP is used to the authoritative server, and 22% slower with TCP to the authoritative. With diverse traces we show that connection reuse can be frequent (60-95% for stub and recursive resolvers, although half that for authoritative servers), and after connection establishment, experiments show that TCP and TLS latency is equivalent to UDP. With conservative timeouts (20 s at authoritative servers and 60 s elsewhere) and estimated perconnection memory, we show that server memory requirements match current hardware: a large recursive resolver may have 24k active connections requiring about 3.6 GB additional RAM. Good performance requires key design and implementation decisions we identify: query pipelining, out-of-order responses, TCP fastopen and TLS connection resumption, and plausible timeouts.

PDoT

“…DNS-over-TLS protects privacy of DNS queries and prevents man-in-the-middle (MiTM) attacks against DNS responses. [39] also demonstrated the * Work done while visiting University of California, Irvine, as a US-UK Fulbright Cyber Security Scholar. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page.…”

“…We do not consider Denial-of-Service (DoS) attacks on RecRes, since these do not help to achieve either adversary's goal of learning clients' DNS queries. Connection-oriented RecRes-s can defend against DoS attacks using cookie-based mechanisms to prevent SYN flooding [39].…”

“…In 2015, Zhu et al [39] proposed a DNS design that runs over Transport Layer Security (TLS) connections [13]. DNS-over-TLS protects privacy of DNS queries and prevents man-in-the-middle (MiTM) attacks against DNS responses.…”

Pretty Bad Privacy

“…According to the design, TLS should be used between the client and the recursive resolver (scenario (2) in Figure 1) or, if the recursive DNS resolver is not trusted, then for end-to-end security, between the client and the name server (scenario (1) in Figure 1). The main difference between the two proposals is that [32], integrated into unbound, uses a non-DNS port for secure connections, and does not support out of order processing of the DNS requests; the technical report, [35], contains more details on the evaluation and implementation.…”

“…In this work we focus on the proposals which aim to provide privacy to DNS packets by employing encryption, [3,4,8,21,27,32,34,35]. These proposals are on a standardisation track of the IETF and are already supported by some DNS resolvers software, e.g., unbound, [31], and by the public DNS operators, e.g., OpenDNS [28].…”