Advancing DNS Performance Through an Adaptive Transport Layer Security Model (ad-TLSM)

2.1 The domain name system security

DNS security, a strategy aimed at safeguarding the DNS infrastructure from cyberattacks, seeks to maintain its robust and efficient performance. A successful DNS security strategy incorporates a blend of overlapping defenses, which may include the implementation of redundant DNS servers, the application of security protocols such as DNSSEC, and the insistence on comprehensive DNS logging. As with many Internet protocols, the DNS infrastructure was not originally designed with an emphasis on security, resulting in several inherent design limitations. These limitations, when coupled with technological advancements, render DNS servers vulnerable to a wide spectrum of attacks such as Denial of Service, spoofing, amplification, and private data interception.

Given that DNS forms a crucial component of the majority of web requests, it presents an attractive target for attackers. DNS attacks are often executed in conjunction with other cyberattacks, thereby diverting the attention of security teams from the primary target. It is imperative for organizations to swiftly neutralize DNS attacks to avoid being overly preoccupied, thereby leaving them vulnerable to simultaneous attacks from other vectors.

Privacy constitutes another significant issue within DNS security. The lack of encryption for DNS queries, even when the client uses a DNS resolver that does not log their activities, means that these queries traverse the Internet in plaintext. This lack of privacy not only jeopardizes security but also, in certain contexts, infringes upon human rights. The visibility of DNS queries simplifies the task for governments seeking to censor the Internet and for attackers aiming to monitor users' online activities.

Research conducted by Wessels [12] estimated that there are approximately 11.7 million public DNS servers on the Internet. Of these, around 52% permit arbitrary queries due to improper configuration, while approximately 33% allow denial of service attacks or cache poisoning attack, given that their authoritative name servers reside on the same network.

Additionally, the sophistication of attacks targeting DNS has increased, complicating detection and control processes. For instance, the Fast Flux attack swiftly modifies DNS information about the domain to delay or evade detection. Similarly, the conficker worm attacks [13], also known as SQL Slammer, leverage domain names to make network attacks resilient against detection and shutdown. To assist in identifying attacked domains, the Internet Corporation for Assigned Names and Numbers (ICANN) has compiled a list of domains that could potentially be used in such attacks across each Top-Level Domain.

2.2 Adaptive security

Security threats are counter-productive to the functionality, performance, availability, and integrity of Information Technology systems. The goal is to decrease possible security threats to the level wherein Service Level Agreements (SLAs) can still be satisfied; as well as the risk management concept. By timely prevention of an attack, adaptive security attempts to decrease the effect and degree of possible threats.

2.2.1 Characteristics of an adaptive security

de Castro and Timmis [14] identified some characteristics of adaptive security useful in Information Technology systems to include preventing attacks, contain the impact of attacks, and timely responds to attacks. Other characteristics includes:

1) Self-identity: This involve separating and removing what does not belong in line with the governing security policy. This comprises of support for systems communication and information exchange on attacks and threats, preventive measures, security guidelines and policies, and trust relations amongst 3rd party systems.

2) Diversity: This shows itself via diverse control mechanisms such as compartmentalization. This can be achieved through operating system (OS) virtualization or Trusted Platform Module (TPM)-based hardware trust anchors.

3) Autonomy: There are different components that controls the security system function autonomously to prevent attacks and threats. This is required for security and integrity control devices to autonomously function in responding to attacks and threats.

4) Multi-layered: This can be likened to the idea of “defense-in-depth”, where in a properly designed security architecture preserves and employs multiple security measures to subdue the hazard of a compromised single measure.

5) Resilience: The effectiveness of a security system can be decreased by various factors. By maintaining a level of resilience, it can continuously recognize and prevent attacks in spite of reduced capacity.

6) Anomaly detection: This involves supporting the ability to detect and prevent any abnormal behavior or known threats automatically.

2.2.2 Adaptive security capabilities

New approaches in information security techniques have tried to mimic adaptive system so as to be able to fine-tune to continuously developing and varying security threats. The core of Adaptive Security is to serve as the immune system of a system. This is realized by developing an Adaptive Security aimed at containing active attacks and neutralizing possible threat vectors [15]. Adaptive security is defined based on four security abilities:

1) Preventive capability: A set of rules, guidelines and policies that prevents an attack from being successful. Thus, information is protected from illegal alteration, ruin, or exposure, whether unintentionally or deliberately.

2) Detective capabilities: These are controls (including logging of events) intended to recognize attacks, that have eluded the preventive procedures, and decrease the attack magnification. Thus, this provides an outlook into malicious actions, violation and attacks.

3) Retrospective capabilities: These provide a way of reducing the attack area, the attack rate and recovery time. Thus, this provides the procedures necessary to take suitable action in responding to diverse cybersecurity events.

4) Predictive capabilities: These allows attack predictions, security trends analysis and changing to a proactive security from reactive security. Thus, security intelligence is achieved from internal and external events monitoring to recognize attackers, their purposes and approaches before the appearance of the attacks.

2.3 Transport layer security

Transport Layer Security (TLS) is used to secure communications via a consistent transport protocol (such as TCP/IP) between a web server and client using a cryptographic protocol. This allows client-server applications to communicate via a public network, while preventing messages from eavesdropping, altering, and counterfeiting. TLS provides the following security characteristics such as confidentiality, integrity, authentication and non-repudiation of messages. The TLS protocol goals are extensibility, cryptographic security, interoperability and efficiency. There are two main components of TLS protocol: Handshake protocol and Record protocol. Through the handshake, to meet the mentioned security characteristics, algorithms are selected based on availability to both the client and server. This is generally known as TLS negotiation, with the ensuing secured connection called a session. Also, an established TLS session can be renegotiated at the decision of the client or server [16]. Figure 1 depicts the logical description of Transport Layer Security (TLS) architecture.

1.png

Figure 1. Transport layer security architecture [17]

2.3.1 DNS over TLS

This study looks to investigate Domain Name System security such as DNS over TLS (DoT) to find some fact that helps to analyze the problems and capitalizing on them to develop the proposed solution. When initiating a TLS handshake, the client and the DNS resolver negotiate and agree upon a cryptographic algorithm to be used for encrypting and decrypting the data exchanged during the communication. This algorithm is typically selected from a set of available options supported by both the client and the DNS resolver. Figure 2 shows the typical TLS 1.3 handshake process.

During lookups, the client establishes a TCP connection to a selected DoT port TCP/853 on the DoT-enabled resolver. Next, a TLS connection will be established via a typical TLS handshake process to exchange their cryptographic keys. TLS 1.3 uses the “key_share” and “pre_key_share” parameters in the “ClientHello” handshake message for encryption purposes. The “key_share” parameter is used to exchange the end-point’s public key share required to generate secret key at the remote end-point. The “pre_key_share” parameter specifies the index of the presently used shared key for encryption in the list of negotiated shared keys. Then, TLS 1.3 encrypts the server security certificate. Upon successful establishment of the TLS session, the client is able to perform TLS-encrypted DNS lookups through the DoT port TCP/853 on the resolver side. Depending on the configurations of clients and servers, the TLS connections may remain open for further DNS lookups, reducing latency (that is, preventing additional TCP/TLS handshakes for subsequent requests).

The cryptographic algorithm plays a vital role in ensuring the confidentiality, integrity, and authenticity of the DNS query transactions. It determines how the data is encrypted, decrypted, and authenticated, providing protection against eavesdropping, tampering, and spoofing attacks. By using TLS to secure DNS query transactions, sensitive information, such as the domain names being queried, is encrypted and protected from unauthorized access. This helps to prevent malicious actors from intercepting and manipulating DNS queries, thereby safeguarding the privacy and integrity of the communication. TLS is employed in DoT to secure DNS query transactions by selecting an appropriate cryptographic algorithm that ensures the confidentiality, integrity, and authenticity of the exchanged data.

Though DoT is a viable approach for DNS encryption, it faces several performance challenges that may hinder its usage, such as high failure rate due to timeouts (that is, no response within 5 seconds), head-of-line blocking, and computational overhead [7-10].

2.jpg

Figure 2. A typical TLS 1.3 handshake [18]

2.3.2 Security services of cryptography

The essential security objectives of cryptography are to offer the accompanying vital services. According to Willian [19], these vital services are:

1) Confidentiality: It is a security service that keeps the data from an unapproved individual. Cryptography ensures that DNS data remains confidential by encrypting it. With encryption, sensitive information, such as the domain names being queried, is transformed into ciphertext that is unreadable without the corresponding decryption key. This prevents unauthorized parties from accessing and understanding the contents of DNS queries, protecting the privacy of users.

2) Data integrity: It is a security service that deals with perceiving any alteration to the information. Cryptographic algorithms, such as message authentication codes (MACs) and digital signatures, ensure the integrity of DNS data. MACs provide a way to verify that the data has not been tampered with during transmission, as any modifications to the data would result in an invalid MAC. Digital signatures, on the other hand, provide a mechanism for verifying the authenticity and integrity of DNS responses, ensuring that they have not been altered by malicious actors.

3) Authentication: This gives the identity of the message originator. Cryptography enables the verification of the authenticity of DNS data. Digital signatures, for instance, can be used to verify that a DNS response has been generated by a trusted DNS server and has not been tampered with during transit. This prevents attackers from impersonating DNS servers and providing false or malicious responses.

4) Non-repudiation: It is a security service which guarantees an entity cannot reject the ownership of a prior action. Cryptographic mechanisms, such as digital signatures, provide non-repudiation, which means that a party cannot deny their involvement in generating a particular DNS response. This is important in DNS security as it ensures accountability and prevents malicious actors from denying their actions.

2.3.3 Review of related works

It is unknown how much information may be gleaned via traffic analysis on DoT communications, despite the fact that DoT is meant to stop on-path adversaries from observing and manipulating the victims' DNS requests and responses. A DoT fingerprinting technique was proposed by Houser et al. [20] to examine DoT traffic and identify whether a user has visited websites that are of interest to adversaries. When DNS messages are not padded, the suggested approach can detect DoT traffic for websites with a false negative rate of less than 17% and a false positive rate of less than 0.5%. Furthermore, it was demonstrated that even when DoT messages are padded, information leakage is still feasible.

For five months at the start of 2021, this study tracked the adoption of DoH (DNS over HTTPS), DoT (DNS over TLS), and DoQ (DNS over QUIC) by three separate enterprises with worldwide reach. García et al. [5] analyzed the overall numbers, requests made per user, and traffic seasonality in order to determine the potential adoption trends. It was concluded that, despite increasing in 2020, there was statistically substantial evidence that the average volume of Internet traffic for DoH, DoT, and DoQ remained constant throughout the first five months of 2021. However, we discovered that the number of DoH servers that are available for use has increased by a factor of 4. These findings indicate that although the volume of encrypted DNS is not now increasing, there may soon be an increase in connections to unknown DoH servers for both good and bad intentions.

Although DNS over TLS (DoT) was established as an addition to the DNS protocol in 2016, little research has been done on how it performs. Research by Doan et al. [7] used 3.2k RIPE Atlas probes installed in home networks to quantify DoT from the edge and compare its adoption, dependability, and response times to DNS via UDP/53 (Do53). It was found that open resolvers are becoming more supportive of DoT. DoT is still only supported by regional resolvers. However, the reliability of DoT decreased while failure rates rose. Response times, according to DoT, are getting longer. Most failures occur due to timeout, that is no response within 5 seconds, which was suspected to be as a result of the intervening middleboxes on the path that blackhole the connections by dropping packets destined for port 853.

Using Transport Layer Security (TLS) to secure DNS communication has become popular recently. But at least two significant problems continue: (1) How can DNS-over-TLS endpoints be authenticated by clients in a scalable and extendable way? (2) How can clients be confident that endpoints will act as expected? A revolutionary Private DNS-over-TLS (PDOT) architecture was proposed by Nakatsuka et al. [21]. A DNS Recursive Resolver (Rec Res) that works in a Trusted Execution Environment (TEC) is part of PDOT. The study offered an open-source PDOT proof-of-concept implementation and empirically showed that its throughput and latency matched those of the well-known Unbound DNS-over-TLS resolver. The functionality that is available to code that runs within them is constrained, which presented the following major difficulties throughout the design process of PDoT. It also has a little quantity of memory. And applications must move to the non-TEE side if they need functionality that is not provided by the TEE.

Security has been largely handled by Transport Layer Security (TLS). However, the initial handshakes of vanilla TLS send information about the sort of service being accessed in plain-text, possibly disclosing user behavior and jeopardizing privacy. The "Encrypted ClientHello" (ECH), is a TLS 1.3 extension that Khandkar et al. [18] suggested to address the privacy concerns in TLS 1.3 by masking all of the information that may potentially disclose the service type. This study showed that the Encrypted Client Hellos (ECH) TLS 1.3 enhancement does not deliver the desired privacy. This is partly due to the fact that many services continue to use TLS 1.2, whilst ECH only supports TLS 1.3. The limited switchover to TLS 1.3+ECH can fall short of protecting against malicious attacks that throttling/blocking particular internet services, as well as failing to fulfill the stated goals of privacy and anonymity.

The impact of Do53, DoT, and DoH on query response times and page load times was measured, in the study by Hounsel et al. [8], from five different worldwide perspectives. This study discovered that although while DoH and DoT response times are often higher than Do53, both protocols can outperform Do53 in terms of how quickly pages load. However, significant packet loss and latency are introduced when network conditions deteriorate.

Böttger et al. [9] examined the DNS-over-HTTPS environment in this study, paying particular attention to the cost of the added security. And to demonstrate the gains DoH offers over its predecessor, DoT, they examined various secure DNS protocols. It was then determined that head-of-line-blocking affects DoT and DoH/1. This difference in behavior may (at least partially) explain why DoH/2.0 gained traction more quickly than DoT.

According to research by Jonglez [10], DNS-over-TCP performance with few clients is comparable to DNS-over-UDP with only a 30% lag. Performance of DNS-over-TCP decreases as the number of clients rises and stabilizes at a 75% slowness. The performance profile for DoT is comparable to TCP, although there is a 30% to 45% speed impact. However, performance suffers noticeably as the number of clients rises for both TCP and TLS. This was thought to be a result of the kernel's need to manage a large number of TCP connections concurrently.

In this research, Shang and Wills [22] presented a novel approach called an authoritative DNS server (ADNS), that can piggyback resolutions for future queries as part of the response message for an initial query. This exploits the relationships among domain names to improve the cache hit rate for a local DNS server. The approach improves the cache hit rate as well as reducing the total queries and responses. Trace-based simulations show more than 50% of cache misses can be reduced in the best case while straightforward policies, using frequency and relevancy data for an ADNS, reduce cache misses by 25-40% and DNS traffic by 20-35%. However, these percentages improve if focused on the resource records policy with smaller authoritative Time-To-Lives.

Khandkar and Hanawal [23] presented a method called Encrypted TLS/SSL Handshake, to mask the server host identity by encrypting the Server Name Indicator (SNI). This simple method completes the SSL/TLS connection establishment over two handshakes-the first handshake establishes a secure channel without sharing SNI information, and the second handshake shares the encrypted SNI. This method makes it mandatory for fronting servers to always accept the handshake request without the SNI and respond with a valid SSL certificate. However, specific changes in the handshake parameter setting limit the operational viability of the solution.

In this paper, the present state of DNS security architecture was evaluated, and saw clearly that existing DNS security architectures are insufficient to secure DNS data transiting over the network; considering the growing cybersecurity landscape. On this note, Alao et al. [24] propose the need and adoption of a security architecture named Adaptive Security Architecture. Adaptive Security Architecture is devised to guard against identified threats, and anticipate unidentified threats in a manner similar to the immune-response system of human. Basically, mimicking nature’s biodiversity as the fundamental means of effective attack responses. Finally, we conclude by an analysis to prove the need to improve DNS security architecture.

Hounsel et al. [25] studied the performance of encrypted DNS protocols and conventional DNS from thousands of home networks. They found that clients do not have to trade DNS performance for privacy. For certain resolvers, DoT was able to perform faster than DNS in median response times, even as latency increased. Also, there was significant variation in DoH performance across recursive resolvers. Based on these results, it was recommended that DNS clients (such as, web browsers) should periodically conduct simple latency and response time measurements to determine which protocol and resolver a client should use. However, no single DNS protocol nor resolver performed the best for all clients.

Emerging protocols such as DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) improve the privacy of DNS queries and responses. While this trend towards encryption is positive, deployment of these protocols has in some cases resulted in further centralization of the DNS, which introduces new challenges. In particular, centralization has consequences for performance, privacy, and availability. Towards this goal of increased de-centralization and improved flexibility, Hounsel et al. [26] presents the design and implementation of a refactored DNS resolver architecture that allows for de-centralized name resolution, preserving the benefits of encrypted DNS while satisfying other desirable properties, including performance and privacy. The researchers argued for a re-decentralization of the DNS, considering users may prefer one distribution strategy over another. They explored various alternative strategies for resolving and distributing encrypted DNS queries. However, this research provides only a starting point as a proof-of-concept.

In the DNS resolution process, packet losses and ensuing retransmission timeouts induce marked latencies: the current UDP-based resolution process takes up to 5 seconds to detect a loss event. Jonglez et al. [27] explored persistent DNS connections based on TCP or TLS as a possible solution to this problem. Experimentation showed that persistent DNS connections significantly reduces worst-case latency. Thus, a large-scale platform was leveraged to study the performance impact of TCP/TLS on recursive resolvers. The results showed that off-the-shelf software and reasonably powerful hardware can effectively provide recursive DNS service over TCP and TLS, with a manageable performance hit compared to UDP. However, switching to TCP or TLS has an impact on the load of the recursive resolver, which is significant, especially with a large number of concurrent connections.

2.3.4 Limitations of related works

From the literatures reviewed, two research works focused on improving performance of DNS, by piggyback resolutions for future queries as part of the response message for an initial query, and a DNS Recursive Resolver (Rec Res) that operates within a Trusted Execution Environment (TEE) respectively. The outcome of the research works was encouraging but are limited by the additional performance overhead. The first research used an authoritative DNS server to improving DNS performance; however, this is only true for the policies on resource records with smaller authoritative Time-To-Live (ATTL). This means with larger ATTL, performance issues arise. Also, the last research used a novel Private DNS-over-TLS (PDoT) architecture. However, applications requiring functionality that is not available within the TEE must switch to the non-TEE side, this introduces TEE Call-in/Call-out Overhead.

It can be concluded that attempt at improving performance has resulted in additional performance issues. Therefore, the primary purpose of this research is to develop an adaptive Transport Layer Security Model (ad-TLSM) that adapts security in light of DNS contextual features to provide optimum performance; whilst preserving Quality of Service (QoS) constraints. The task is to effectively manage available DNS resources without congestion or breaching client’s QoS constraints.

4.1 Implementation

The experiments were conducted on a Windows 10 system with an Intel Core i5 processor, 16GB RAM, and Apache 2.4. OpenSSL 1.1.1 was utilized by both Apache's TLS module and the proposed solution module. This investigation focuses on the design of the Adaptive Transport Layer Security Model (ad-TLSM) for DNS recursive resolver. Apache's flexibility as an open-source web server makes it a suitable platform for implementing the ad-TLSM design. The ad-TLSM allows for runtime security adaptation based on the contextual features of the DNS recursive resolver. The modular architecture of Apache enables the integration of modules, such as the TLS module, which configures TLS session security using the SSL Cipher Suite directive. Similarly, the proposed solution acts as a module that can be added to existing Apache installations without requiring any modifications to Apache or TLS code. By leveraging these features, security can be adapted at runtime, providing flexibility and enhancing the overall security of DNS sessions. Figure 6 shows the ad-TLSM.

6.jpg

Figure 6. The ad-TLSM

TLS Handshake: To securely connect to a server, a hostname (www.example.com) and a port (433) is required. Based on the implementation, the certificate authority was also added. For instance:

openssl s_client-connect www.example.com: 443-CAfile c:/cacert.pem

Figure 7 to Figure 9 show the TLS handshake using AES-GCM 256, ChaCha20 and AES-GCM 128 respectively.

Once you type the command, diagnostic output is displayed followed by an input prompt. Because when interacting with a server, a request is submitted. Now, the TLS communication layer is working, as request is sent to the server and response received. For a better look at the certificate, Figure 6 to Figure 8 show a self-explanatory information about the TLS Handshake using the available cryptographic algorithm respectively:

The vital information is the protocol version (TLSv1.3) and cipher suite utilized (TLS_AES_256_GCM_SHA 384). It also showed the server has allotted a session ID and a TLS session ticket.

The security policy in the proposed solution consists of condition and SSL Cipher Suite pairings that trigger the renegotiation of the client's security session if the requirements are met and the current session security is not dependent on the chosen SSL Cipher Suite. The conditions, created using the Require directive, are complex Boolean expressions utilizing CGI, Apache, and TLS variables. These conditions are checked in order, and the first matching condition is selected. The Require env provider allows access control based on the existence of an environment variable. By using mod setenvif directives, environment variables can be set based on client request characteristics like User-Agent or HTTP request header fields. This flexibility enables the module to be applied in various applications and data settings at different levels of abstraction.

7.jpg

Figure 7. TLS handshake using AES-GCM 256

8.jpg

Figure 8. TLS handshake using CHACHA20

9.jpg

Figure 9. TLS handshake using AES-GCM 128

The ad-TLSM registers hooks with Apache, seamlessly integrating with existing TLS hooks and assuming control of the TLS renegotiation function. The TLS's SSL Cipher Suite directive is stored for future application when the Security Policy is empty or none of its requirements match the client's request. This ensures that existing or previously applied security remains in control of session security.

A load generator was used to reproduce multiple client requests to a server. New user sessions are created with the server at a specific rate (λ), according to a Poisson process with some mean. Multiple requests (λ_n) can be made by users within each session, according to a typical request rate based on a Poisson process with some mean. Mean user arrival and request rates can be altered during an experimentation, to simulate genuine user load. Each user’s session maintains an exclusive security state. During a session or its creation, exclusive user information stored permits the server to adjust the security for users. Client load was produced utilizing HTTPerf and Autobench.

For the ad-TLSM evaluation, the client activity is as follows:

1) This HTTPerf script generates a total of 10 sessions at a rate of 1 session per 256 seconds. Each session consists of 64 calls that are spaced out by 4 seconds.

2) During the first 500seconds, 10 clients arrive every 3seconds (average request rate at 200req/s).

3) Then, the next 250 seconds, client’s arrival increases at 10 clients every 2.5 seconds (245req/s)

4) And then, reduces to 200req/s for the last 500 seconds.

Furthermore, HTTPerf will use HTTP version 1.0, this requires new TCP connection per request. Also, no reuse of the TLS session ids, so the TLS handshake occurs for each connection. To automate the client workload generation process, The Autobench script repeatedly runs HTTPerf against the host, requesting more connections per second with each run, and extracts the important information from the output, delivering a CSV or TSV format file that can be directly loaded into a spreadsheet for analysis or graphing.

4.2 Evaluation

This section demonstrates the adaptation of security and performance to achieve the objectives of the proposed solution. The Adaptive Transport Layer Security Model (ad-TLSM) design was implemented to maximize security by effectively utilizing available processing resources while considering client Quality of Service (QoS) requirements. Monitoring components collect data on system resources and encryption, which is then used by the adaptation strategy to determine the performance gains of security adaptations based on the gathered information. The ad-TLSM module enables successful runtime security adaptation, ensuring the effective adjustment of security measures.

4.2.1 Security algorithm performance

Table 1 show the default TLS cryptography algorithms performance effect, when 532B file requests are made. This supports the statement [10] that AES is typically very fast and efficient when implemented in hardware and ChaCha20 is efficient in software implementation.

Client arrival rate starts with a set of 10 new clients each 2.5 seconds (240req/s), until the server is overloaded, the client load pattern is followed, with a 0.1 second wait between each group of 10 client arrivals. 90% confidence intervals are <2ms for all response times under 250ms and under 10ms for all response times beyond 250ms.

Table 1. Average number of bytes per second

Figure 10 illustrates that as the client load increases, the DNS recursive resolver can handle approximately 318req/s with AES-GCM 256 before becoming overloaded. By using a different algorithm, it can respond to 15%-25% more requests per second. AES-GCM 128 and ChaCha20 outperformed AES-GCM 256 by approximately 15% and 25% respectively, achieving 333req/s and 343req/s with the same file size and client concurrency level. While the DNS recursive resolver allocates more resources to tasks other than cryptography, the choice of encryption algorithm significantly impacts its throughput. Therefore, using a different security level can increase the number of supported clients by 15%-25%.

10.jpg

Figure 10. Security algorithm performance

4.2.2 Use-case scenario

In the given use-case, we examine the impact of increasing client entries on a DNS recursive resolver using three cryptography algorithms for TLS: AES-GCM 128, AES-GCM 256, and ChaCha20-Poly1305. We demonstrate the effect of these algorithms on the resolver's performance and compare it to the proposed solution's enhancement in security level, considering client Quality of Service (QoS) requirements. The figures display average throughput values over 10-second intervals, while the average number of timed out requests was determined through repeated evaluations.

Based on this scenario, AES-GCM 128 is deemed suitable for protecting the data, ensuring a satisfactory level of QoS for clients who expect timely responses from the resolver.

Figure 11 depicts the DNS recursive resolver throughput when AES-GCM 128 encryption is used. It demonstrates that the resolver can handle client load without any timed-out requests. The experiment was repeated multiple times with consistent results. The graph shows that 10 clients arrive at intervals of 3 seconds during the first 500 seconds, and start leaving the system after 256 seconds. The resolver's throughput stabilizes at 250 requests per second. The subsequent evaluation phases show an increase in client entry as expected. Despite a higher CPU load, the throughput for ChaCha20-Poly1305 is comparable to AES-GCM 128. As shown in Figure 10, ChaCha20-Poly1305 can handle a request rate of 343 requests per second within the 6-second client QoS constraint, with no reported time-outs.

11.jpg

Figure 11. DNS recursive resolver throughput using AES-GCM 128

12.jpg

Figure 12. DNS recursive resolver throughput using AES-GCM 256

Figure 12 illustrates the impact of client activities on the throughput of a DNS recursive resolver using AES-GCM 256 encryption. The bar graph shows the percentage of timed-out requests in each interval. As the client load increases beyond the resolver's capacity, requests start timing out at 500 seconds. With longer response times, clients send fewer queries per second, resulting in a decrease in resolver throughput. The slow request rate leads to extended sessions and an increase in simultaneous sessions as more clients enter. This increase in simultaneous sessions further elevates the total request rate, causing nearly all requests to time out. Even after the arrival of new client requests ceases and current sessions finish, many requests still time out due to the server's ongoing load. New requests are delayed until the server clears its load, potentially leading to additional timeouts. This use-case scenario highlights the performance degradation that occurs in a non-adaptive DNS recursive resolver server when faced with a spike in client arrivals.

4.2.3 Adaptation strategy

This section will illustrate how the ad-TLSM can be utilized to adapt security and performance utilizing available system resources to adapt security with regards to client QoS constraints. In light of the client load patterns, indirect monitoring adaptation strategy was considered. This approach relies on indirectly monitoring of the DNS recursive resolver throughput by identifying that upsurge in throughput infers increased DNS recursive resolver CPU load. Also, CPU load is monitored in the background by the Log file and the information can be utilized by the proposed solution. Thus, effectively utilize available resources, requires the need to know how much resource is free, how much resource is needed or released when the security is adapted.

Figure 13 depicts the performance of the DNS recursive resolver under different levels of encryption, with an average session duration of 256 seconds and varying client arrival rates. The graph demonstrates that the DNS recursive resolver becomes overloaded at different request rates depending on the encryption used. AES-GCM 256 overloads at 230req/s, while ChaCha20-Poly1305 and AES-GCM 128 overload at 296req/s. These findings align with the outcomes in Figure 10 and provide additional insights. It is important to note that a DNS recursive resolver with a CPU load over 90% using AES-GCM 128 should not switch to AES-GCM 256, as it would result in overload. Similar considerations apply to ChaCha20-Poly1305 to AES-GCM 128 (over 70%) and ChaCha20-Poly1305 to AES-GCM 256 (less than 50%). Lowering the security level becomes practical when the CPU utilization reaches 100%. Based on these insights, a security policy was formulated and presented in Table 2. This policy ensures efficient utilization of system resources to enhance security while avoiding DNS recursive resolver overload and maintaining QoS constraints.

By comparing the current CPU load to values in Table 2, this policy determines if the security level needs to be adapted. The current CPU load is evaluated against each value in the security policy reference table. If the CPU load is lower/higher than a specific value, the security may be adapted to the corresponding algorithm.

Table 2. The ad-TLSM security policy reference

13.jpg

Figure 13. CPU utilization under different client loads

To achieve the indirect monitoring adaptation strategy, the following procedure was utilized:

set cpu_load_low=0.5

set cpu_load_meduim=0.7

set cpu_load_high=0.9

set load, crypto_algo, N

for (i=0; i<=N, i++) {

if (load<cpu_load_low)

{

set crypto_algo=1

     }

else if (load>=cpu_load_low && load<=cpu_load_medium)

{

set crypto_algo=0

     }

else if (load>=cpu_load_medium && load<=cpu_load_high)

{

set crypto_algo=0

     }

}

return crypto_algo

end procedure

For example, if the current security is ChaCha20-Poly1305, the CPU load is compared to values in AES-GCM 128 or AES-GCM 256. If the CPU load is 0.5, AES-GCM 256 is selected, or if the CPU load is 0.9, AES-GCM 128 is selected. Similarly, if the current security is AES-GCM 256, the CPU load is compared to values in ChaCha20-Poly1305 or AES-GCM 128. If the CPU load is 0.9, AES-GCM 128 is selected, or if the CPU load is 0.7, ChaCha20-Poly1305 is selected. Lastly, if the current security is AES-GCM 128, the CPU load is compared to values in AES-GCM 256 or ChaCha20-Poly1305. If the CPU load is less than 0.5, AES-GCM 256 is selected, or if the CPU load is 0.7, ChaCha20-Poly1305 is selected.

4.2.4 Evaluation of the ad-TLSM

Every 10 seconds the average CPU load is documented over the preceding 10 seconds and adapts the proposed solution security in light of the indirect monitoring in Subsection 4.2.3.

By utilizing the ad-TLSM, Figure 14 demonstrates effective maximization of security throughout most of the evaluation duration. New clients arriving before 460 seconds and after 720 seconds received security levels that exceeded recommendations while maintaining client Quality of Service (QoS) constraints. The configuration depicted in Figure 14 allowed the DNS recursive resolver to handle client loads successfully. The CPU load steadily decreased as security was adapted to ChaCha20 and then to AES-GCM 128. This occurred twice in a short interval, at 450 seconds and 460 seconds, preventing overloading of the DNS recursive resolver. Once the CPU load reached a safe level below 50% (as shown in Table 3.), AES-GCM 256 and then ChaCha20 were employed for security, observed at 720 seconds and 750 seconds. However, the CPU load began increasing after approximately 780 seconds, prompting the adaptation of security to AES-GCM 128.

Table 3 and Figure 14 demonstrate the adaptation of security measures. While the monitoring mechanism may require additional processing time to gather and analyze data on network conditions, the overhead is minimal due to its efficient and lightweight design. The benefits of the ad-TLSM outweigh the potential impact on throughput, as it enables automatic adjustment to network changes, improving performance and security management. To evaluate the ad-TLSM's performance, we compared its throughput and latency values with those of PDOT [21] using a similar client load pattern, as shown in Table 4. Table 3 shows the ad-TLSM security adaptation.

14.jpg

Figure 14. DNS recursive resolver throughput using ad-TLSM

Table 3. The ad-TLSM security adaptation

Table 4. The ad-TLSM against PDoT based on throughput and latency

Table 4 shows the ad-TLSM against PDoT based on throughput and latency.

The evaluation of the ad-TLSM method demonstrated its superior performance compared to other methods. However, the CPU capacity directly affects the performance of both the ad-TLSM and the DNS recursive resolver. Higher CPU capacity enables more efficient handling of incoming requests, resulting in faster response times and improved overall performance. The ad-TLSM also shows similar throughput values to other methods, indicating efficient handling of requests and a better user experience. Furthermore, the ad-TLSM exhibits better latency values, which can be attributed to its effective adaptation strategy. The satisfactory throughput and latency values of the ad-TLSM are presented in Table 4.

4.3 Security analysis

The section examines the potential risks and vulnerabilities associated with a malicious operator and network adversary in the context of the research on monitoring CPU load of a DNS recursive resolver and applying an adaptation strategy for enhancing performance. This section explores the importance of selecting appropriate encryption algorithms, the need for an adaptive security strategy, the impact on client QoS constraints, and the measures to mitigate overload attacks. It highlights the significance of protecting against malicious actors and ensuring secure communication to safeguard the DNS recursive resolver from potential threats and breaches. In terms of security implications related to a malicious operator and network adversary, the research and evaluation discussed several important factors:

1) Encryption algorithm selection: The choice of encryption algorithm can have significant security implications when dealing with a malicious operator or network adversary. The evaluation showed that different encryption algorithms have varying levels of performance and efficiency. It is important to choose an algorithm that provides strong security against potential attacks, as a malicious operator or network adversary may attempt to exploit vulnerabilities in weaker algorithms.

2) Adaptive security strategy: The research proposed the ad-TLSM strategy to adapt security and performance based on system resources and client QoS requirements. By monitoring the CPU load and dynamically adjusting the security level, the ad-TLSM aims to optimize security without overloading the DNS recursive resolver. This is crucial in defending against malicious operators or network adversaries who may attempt to overload the resolver to disrupt its functionality.

3) Client QoS constraints: The research also emphasized the importance of maintaining client QoS (Quality of Service) constraints while adapting security. This ensures that clients receive timely responses and are not negatively impacted by security adaptations. By considering client QoS requirements, the ad-TLSM strategy aims to strike a balance between security and performance, providing protection against malicious actors while ensuring a satisfactory user experience.

4) Mitigating overload attacks: A malicious operator or network adversary may attempt to overload the DNS recursive resolver by sending a high volume of requests. This can lead to denial-of-service (DoS) attacks and disrupt the resolver's normal operation. The ad-TLSM strategy, by monitoring CPU load and adapting security accordingly, helps mitigate the risk of overload attacks by ensuring that the resolver does not become overwhelmed and can handle the incoming traffic effectively.

5) Secure communication: The use of strong encryption algorithms, such as ChaCha20-Poly1305 and AES-GCM, helps protect against potential attacks from malicious operators or network adversaries. These algorithms provide confidentiality, integrity, and authenticity of the communication, making it difficult for adversaries to intercept or tamper with the data exchanged between clients and the DNS recursive resolver.

6) Privacy: By utilizing encryption algorithms and adaptation strategies, the research aims to prevent unauthorized access to user information, thereby safeguarding privacy. The implementation of robust encryption protocols helps in preventing eavesdropping, data interception, and unauthorized data tampering, thereby enhancing the overall privacy of users utilizing the DNS recursive resolver. Additionally, the research highlights the significance of selecting encryption algorithms that offer strong privacy guarantees, ensuring that user data remains confidential and protected from potential privacy breaches.

4.4 Limitations of the study

Despite the limitations of this research, we believe that our findings provide valuable insights into the impact of DNS on user experience and how different DNS stakeholders can improve it. Achieving a perfect balance between security and performance is challenging, especially considering that our measurements were conducted on the Windows operating system, which may affect the results due to the networking stack and algorithm parameters. However, we expect our findings to be applicable to other operating systems as well, considering the highly optimized nature of networking stacks. Additionally, it is important to acknowledge that the direct monitoring approach assumes file size as a direct indicator of DNS recursive resolver workload, which may not always hold true.