DNS communication protocol based on privacy protection technology

The Domain Name System (DNS) is an Internet basic service and an important entry point for Internet access. Domain name privacy protection is a hot topic in DNS security research. This paper proposes an encryption method for user privacy protection in DNS transmission based on the User Datagram Protocol: DNSDEA. This method integrates the PKI encryption system with the DNS protocol, which not only solves the problem of domain name privacy protection, but also is compatible with the traditional DNS system, maintaining the simple and efficient technical characteristics of the DNS system.

[[267166]]

The Domain Name System (DNS) is one of the important basic services of the Internet. It mainly identifies and locates servers and service entrances on the Internet through mapping and conversion between domain names and Internet Protocol addresses (IP) and other basic Internet resources. DNS is a relatively mature global distributed database that provides efficient and stable Internet identification resolution services for the Internet.

In 1983, Mockapetris proposed the DNS architecture, which has been continuously evolving and optimizing since then. At the beginning of the design, the domain name system did not consider a complete security mechanism in the domain name protocol. In 1999, the DNS security extension protocol (domain name system security extensions, DNSSEC) was proposed, which can effectively reduce the risk of man-in-the-middle attacks and ensure the integrity of DNS transmission data, thereby improving the security service capabilities of the DNS system. In 2010, the root service of the Internet domain name began to deploy DNSSEC services, marking the beginning of the domain name service towards security services. DNS has also developed from a simple name-address conversion service to a complex, trusted resolution service. The transport layer security protocol DANE (DNS-based authentication of named entities) is based on the DNSSEC protocol to issue digital certificates through DNS services to ensure that the certificates come from a specific certificate authority.

With the continuous increase in the popularity of the Internet and its continuous penetration into production and life, people have become increasingly dependent on the Internet. The current Internet is not only a way to obtain and share information, but has also become the basic carrier of most traditional industry business systems. Therefore, privacy issues have become an important issue that needs to be urgently resolved on the Internet. DNS mainly uses the user datagram protocol (UDP) protocol plain text transmission method for name-address conversion. Although the DNSSEC protocol increases the difficulty of data tampering, it still uses plain text to provide resolution services. As an Internet basic service, DNS still shows vulnerability to user privacy protection. At present, few DNS security issues have been truly resolved, and the privacy issues have become the focus of industry attention and have gradually received attention. On the one hand, the industry uses query minimization to reduce the risk of privacy theft and uses data minimization to reduce the collection of personal privacy information by DNS authoritative services; on the other hand, in response to the problem of privacy leakage during DNS resolution services, the international organization Internet Engineering Task Force (IETF) established the DNS PRIVate Exchange (DPRIVE) working group in 2014 to discuss and formulate the DNS privacy protection protocol, hoping to achieve DNS privacy protection by using data encryption transmission. Based on this background, this paper proposes an encryption method for user privacy protection in DNS transmission based on UDP.

Research status

Currently, most DNS services and terminals exchange data (mainly including requests and feedback) in plain text and in an unencrypted manner, which will expose user privacy in Internet communications. The vulnerability of privacy will be exploited by hackers. For example, hackers can collect user access traces (query time, access content, user IP address, etc.) and other information to analyze user habits. To address this issue, there are currently two main methods to protect user privacy during DNS queries.

DNS data message encryption

Dempsky proposed the DNSCurve method, which is based on the existing DNS architecture and uses Curve25519 to exchange keys between the client and server and provide authentication and data encryption. The server's public key is stored in the "NS" record and sent to the client, so using DNSCurve to encrypt DNS messages does not cause additional query delays. DNSCrypt is a well-known implementation of DNSCurve and has been widely deployed on OpenDNS services to solve the privacy protection issues of end users. Similar ConfidentialDNS also uses the DNS extension mechanism to add encryption functions to the DNS protocol. It proposes a new resource record type "ENCRYPT" to transmit the public key of the DNS server to the client. The client then uses the server public key to encrypt the DNS query request and the client public key to encrypt the DNS response, thereby encrypting and protecting the DNS request and feedback data. Although these two solutions can effectively solve the vulnerability problems caused by DNS plaintext transmission, they need to deploy and install plug-ins (or upgrade the parsing software) on both ends of the DNS communication to achieve the goal of DNS communication from plaintext to ciphertext. The promotion cost is relatively high, so they are not widely used at present.

DNS communication link encryption

TLS (transport layer security) is a security protocol that provides data confidentiality and integrity for network communications. It encrypts network connections at the transport layer. Currently, the most common application of TLS is the HTTPS protocol, which uses public key encryption to authenticate websites and symmetric encryption to encrypt data transmission. TLS requires the TCP protocol to ensure reliable transmission of the channel and cannot be directly used to encrypt and protect UDP protocol data. If DNS wants to use TLS encryption to protect data, it must use the TCP protocol. However, the current situation is that most DNS queries use the UDP protocol. Switching to the TCP protocol is a long process and is very costly. Therefore, at this stage, DNS-over-TLS is not a feasible privacy protection solution.

DTLS (datagram transport layer security) is an extension of the TLS architecture that supports the UDP protocol. DTLS makes it possible to directly encrypt DNS query messages of the UDP protocol. The DNS-over-DTLS proposed in the IETF draft describes in detail how to use DTLS technology to encrypt DNS messages.

DNS-over-TLS and DNS-over-DTLS use Internet standard protocols TLS and DTLS to implement DNS encrypted communication. Both methods use the TLS protocol to improve DNS, but this method requires a series of complex network communications such as handshakes and authentication before communication. This puts forward high network overhead and performance requirements for DNS services with huge traffic and relatively low overhead.

The above two methods both pose great challenges to the latency-sensitive, high-throughput Internet basic service DNS.

DNS ciphertext communication method

A new DNS encryption communication method DNSDEA (DNS data encryption algorithm) is proposed. This method uses asymmetric encryption algorithm to communicate in ciphertext under the existing DNS architecture and message format. The client's public key is transmitted through DNS query to reduce the overhead of establishing links based on TLS and other methods and reduce query delay. At the same time, its stateless characteristics are used to improve the concurrency of the server.

Message structure

1) Encryption flag. To mark whether a DNS message is an encrypted message, the first byte after the DNS message header is positioned as the encryption flag. For a normal unencrypted DNS message, this byte indicates the length of the first segment of the query domain name. According to the Internet protocol standard (request for comments, RFC), the length should be less than 64. This byte is expanded to an encryption flag. If the byte is less than 64, it means that the DNS message is a non-encrypted message. If it is greater than 64, it means that the message is an encrypted message.

2) Key format. DNSDEA uses asymmetric encryption to generate communication key pairs (including public and private keys) independently on the DNS terminal and DNS server. The public key of the DNS server is issued through the existing certificate authority infrastructure. Customers using the DNS server need to manually configure the public key. The key used by the DNS client is temporarily generated during the query overflow. Considering factors such as query efficiency, the DNS client key can be reused for a period of time.

The client's public key is added by the client in the additional section of the DNS message in the EDNS0 format and sent to the DNS server through a DNS query. The specific format is shown in Figure 1.

Figure 1 Transmitting PKI public key and private key in EDNS0 format

The specific content of the key is stored in the above option data, where the first two bytes are the algorithm flag bits, identifying the encryption algorithm used by the key, the next two bytes are reserved flag bits, and the last part is the specific public key data. The specific format is shown in Figure 2.

Figure 2 Key format

3) Encrypted message format. The header of the encrypted DNS message is consistent with the ordinary DNS message. The last byte of the header is the encryption mark. The two bytes after the mark are the length of the encrypted data, and the last part is the encrypted data. The specific format is shown in Figure 3.

Figure 3 Encrypted DNS message format

Encrypted query method

When using the DNSDEA method, the DNS terminal needs to manually configure the public key of the DNS server. The public key of the server can be verified through the PKI system. When the DNS terminal sends a query request to the DNS server, the public key of the DNS server is used to encrypt the request resource record (RRset), the public key of the DNS terminal is made into RRset and encrypted with the public key of the DNS server, and the DNS message format data is generated and transmitted to the DNS server.

The DNS terminal will send the generated DNS query message to the DNS server in accordance with the DNS protocol requirements. The DNS server will use its own private key to decrypt and restore the domain name record to be queried and the public key information of the DNS terminal, search for the query result according to the DNS query logic, and use the restored DNS terminal public key to encrypt the query result and send it to the DNS terminal.

After receiving the response message, the DNS terminal uses its private key information to decrypt the response resource record (RRset) of the response message and processes it according to the DNS protocol.

The specific process is shown in Figure 4. Taking the query of www.example.com as an example, the implementation of the encrypted query method is mainly divided into the following steps: (1) The server publishes the public key through PKI, and the client manually configures the server public key; (2) The client generates a key pair; (3) The client constructs a query packet for www.example.com, adds the client's public key to the additional segment of the query packet, encrypts it with the server's public key, and sends the query packet to the server; (4) The server receives the encrypted query packet, decrypts it with the server's private key, and obtains the DNS query content and the client's public key; (5) The server constructs a response packet for www.example.com, encrypts it with the client's public key, and sends the response packet to the client; (6) The client receives the encrypted response packet, decrypts it with the client's private key, and obtains the response content of www.example.com.

Figure 4 Encrypted DNS query process

Experiment and analysis

To test the feasibility of DNSDEA, relevant experiments were conducted to compare DNSDEA with DNS queries based on TLS and DTLS encryption methods to verify the feasibility of DNSDEA and its low latency advantage over the currently popular encryption methods.

Experimental methods

Since DNS queries are mainly transmitted via UDP, the experiment focuses on the DNS query packet latency under DNSDEA and DTLS-based encryption methods. The experiment tests the performance of different-sized data packets using the two encryption methods using RSA and ECC algorithms, calculates the DNS query latency under each method by taking the average value by initiating multiple DNS queries, and compares the characteristics of the two methods in the use of DNS encryption.

The experiment uses openssl-0.9.8 and crypto++5.6.5 encryption libraries to implement RSA and ECDSA encryption, and simulates the software behavior of the DNS server and client under the two encryption methods through programming. Client DNS queries are all implemented through script timing loop calls, so queries based on DTLS encryption trigger new DTLS connections each time, and historical sessions are not used. The experimental operating environment is CentOS 5.7, and the server and client are deployed on different nodes in Beijing.

Experimental results and analysis

1) Comparison of fixed communication byte delay. Using 10-bit communication data and different key strengths for testing, the experimental results are shown in Figure 5.

Figure 5 Latency comparison of two DNS encryption methods

From the experimental results, when the key length is equal, the overall delay of DNS query based on DTLS encryption is greater than the DNS delay under the DNSDEA method due to the long time-consuming key negotiation during the connection establishment process. Under the RSA encryption algorithm, the smaller the encryption strength, the shorter the key. Compared with the DTLS method, the performance of DNSDEA is 2.79 times that of the DTLS method (the acceleration ratio is defined as the ratio of the DTLS method to the DNSDEA delay. The higher the ratio, the lower the DNSDEA delay and the faster the speed); as the RSA key length increases to 2048 bits, since DNSDEA needs to encrypt the client's key and transmit it to the server through the DNS message, the encryption time increases significantly, but the total delay is still lower than the DTLS encryption method (Figure 6 (a)).

Figure 6 Speedup ratio of two DNS encryption methods under ECDSA algorithm

When using the ECDSA encryption algorithm, when the key length is 112, 160, and 256 bits, the overhead of DNSDEA for key encryption is less than the communication overhead of DTLS key negotiation, so the overall network delay is better than the DTLS method. However, as the encryption strength increases to 521 bits, the overhead of DNSDEA for encrypting the key itself increases significantly, which is significantly greater than the communication overhead of DTLS key negotiation, causing a sharp increase in the encrypted DNS query delay. Under ECDSA 512, the performance is lower than the DTLS method (Figure 6(b)).

2) Comparison of delays with fixed key lengths. Using the RSA algorithm and selecting a key length of 1024 bits, we tested the delays of DNS messages of different lengths in the DNSDEA and DTLS methods. The experimental results are shown in Figure 7.

Figure 7 Latency comparison of RSA with 1024-bit key length

Since DTLS uses symmetric keys to encrypt data after successful key negotiation, the delay of the DNS encryption method based on DTLS does not increase significantly as the size of the DNS message increases. However, the transmission delay of DNSDEA increases significantly when the DNS message is large (Figure 8).

Figure 8 Speedup of DTLS and DNSDEA with 1024-bit key length

The experiment shows that under the condition of 1024-bit key encryption, the overall transmission delay of DNSDEA is significantly lower than that of the DNS encryption method based on DTLS.

In summary, when the key length and the transmission message are small, the DNSDEA delay is significantly lower than the DTLS method; the DTLS encryption method uses symmetric key encryption after the connection is established, so the increase in time consumption is smaller than that of DNSDEA; since the size of most DNS messages is generally within 200 bytes, DNSDEA can significantly reduce the DNS encryption transmission delay compared to the DTLS method. In addition, DNSDEA is based on DNS transmission, and its stateless characteristics can also significantly improve the concurrency of the server.

As Internet privacy issues gain more attention, DNS privacy leakage issues will become more prominent. This paper analyzes the existing technologies for DNS privacy issues and proposes a new DNS encryption communication method based on the existing technical solutions: DNSDEA. Compared with traditional methods, this method uses asymmetric encryption algorithms to communicate in ciphertext under the existing DNS architecture and message format. It not only completes DNS privacy protection, but also improves the parallel granularity of the core algorithm for domain name resolution, reduces the communication overhead between the DNS terminal and the DNS server, and effectively maintains the low latency characteristics of DNS.

Experiments were conducted on encryption algorithms such as RSA and Elliptic Cryptography (ECC) in order to provide some reference for subsequent research on communication encryption applications and parallelization of DNS security resolution, and to further explore the extension of the DNSDEA method to the DNSSEC TLSA protocol to improve the security level of encrypted communications. In the future, the improvement and impact of the DNSDEA method on network social networking and big data exchange will be studied in depth to further reduce the risk of Internet privacy leakage.

Authors: Zhang Haikuo, Lu Zhonghua, Chen Wenyu, Chen Liandong, Zuo Peng, Wang Jue, Xu Yanzhi

Author profile: Zhang Haikuo, Computer Network Information Center of the Chinese Academy of Sciences, University of the Chinese Academy of Sciences, China Internet Network Information Center, doctoral student, research direction is computer system structure; Chen Wenyu (corresponding author), Computer Network Information Center of the Chinese Academy of Sciences, University of the Chinese Academy of Sciences, China Internet Network Information Center, senior engineer, research direction is computer system structure.