# Enhancing the Privacy of Network Services through Trusted Computing
## 4 Experimental Results  
To test the feasibility of DoTT, we carried out some experiments to compare DoTT with other DNS enhancement methods based on TLS. We test the performance of the proposed framework in accessing different domain names on the prototype system developed using the C++ language based on SGX SDK. The characteristics of methods in DNS encryption are further compared. We evaluate the latency details of the DNS query using a modified DNS benchmarking tool BIND. The DNS query delay is calculated by averaging the DNS query. All of our evaluations are performed on an Intel Core i7-7700 CPU @3.60 GHz with 16 GB RAM. We first test the performance of DoTT on a normal host and a host that supports SGX features. As shown in Figure 3, the Plain DNS had the highest performance since no security enhancements were adopted. While DoTT (Non-SGX) indicates the performance of DoTT running on a normal host. There are two reasons why DoTT performance is weaker than the Plain DNS: (i) one is the loss due to the use of TLS encryption; (ii) the other is the extra function calls resulting from the refactoring of the original code to allow two sets of runtime libraries to be generated from the same set of code. However, the loss from direct function calls is still less than the loss from ECALL/OCALL in the DoTT running in a host enabling the SGX feature. As shown in Figure 4, we run the benchmark using 6 threads and keep the number of active DNS queries varying from 1000 to 10,000. We gradually increase the concurrency of DNS queries to simulate an increasing number of resolved requests. The baseline is a plain DNS resolver that only relays DNS queries and responses. The average latency for processing requests in DoTT is about the same as that of a plain DNS resolver. We also use a symmetric secret key to ensure the privacy of the result. With the hardware acceleration of SGX, although our method has an additional layer of encryption to ensure privacy, the response rate is equivalent to that of DNSSEC. For other TLS-based methods, it brings performance degradation for the handshake and exchange of secret keys. Although our method also uses a modified Sigma protocol [44], due to SGX coming with hardware encryption instructions, we can archive a higher response rate. Figure 3: The latency of response among the plain DNS, DoTT (Non-SGX), and DoTT (SGX) resolvers. To test the performance of enabling TLS connections in DNS on the address resolution, one way is to establish a TLS connection for each connection. The other is to establish a TLS connection in advance and reuse this connection in the next resolving request. When testing, we can control the client stub and resolving server at the same time, and this change is invisible to the user program. We use the curl tool to initiate domain name resolution requests. In order to expand the test coverage, we selected 10 well-known websites as target domain names. As shown in Figure 5, if the TLS connection is reestablished every time, the latency overhead of DoTT is 18% higher than that of DoT. If the TLS connection is maintained, the overhead of DoTT is only 8% higher than that of DoT. In practice, DNS clients and resolving servers often reuse TLS connections until a TTL expires. If we consider the overhead of TLS in a larger scope; that is, the goal of initiating domain name resolution is to request web resources, then the TLS connection of DNS will have less influence on the whole resource request process. Note that we have not tested the performance of TLS between the resolution server and the domain name server since DoTT and DoT both use the traditional untrusted domain name resolution process at this stage. Figure 4: Performance evaluation among kinds of secure DNS resolvers. Figure 5: Performance evaluation of establishing TLS connections between DoT and DoTT. (**a**) Establishing TLS connections for each new request, and (**b**) reusing the existing connections for new requests.