DNS over HTTPS (DoH): Validate your network with DoH

Traditional DNS is unsecure

Standard DNS communications are unsecure (as it in plain text) and vulnerable to man-in-the-middle attacks. Assume you are in a coffee shop, linked to its wifi network. You begin browsing the web and send a DNS request (query) to UDP 53 (default DNS server port), such as www.mywebsite.com. Perhaps there is a service in that coffee shop that has been compromised, and it will provide you with a poor response to your query. As a result, instead of the server's legitimate IP, you're presented with the attacker's malicious IP, which masquerades as www.mywebsite.com and intercepts all subsequent traffic.

A brief background

Domain name system (DNS) maps human-friendly domain names (or FQDN) to machine-friendly numerical IP addresses, and it is a critical infrastructure of the Internet. DNS queries and responses has been transmitted in plain text according to RFC 1035 since the inception of the Internet, making them exceedingly easy to intercept and modify.

Some of the key disruptions to this traditional model are –

• About 16% of all DNS resolution on the Internet is handled by open public resolver services that are not run by ISPs. Examples of open public resolver operators include Google, OpenDNS, 114DNS and more (ref https://github.com/curl/curl/wiki/DNS-over-HTTPS). Such resolvers records DNS-based user behavior and raises security and privacy related concerns related to user data collection.
• DNS requests and responses can now be sent over alternate transport protocols such as HTTPS, TLS, DTLS, and QUIC, thanks to new technical specifications and implementations. Such efforts move away from unencrypted UDP and TCP.
• Browser and other application vendors have an incentive to integrate resolver addresses directly into their applications, circumventing the traditional strategy of using the operating system's resolver(s) and instead creating application-specific resolution behavior.

The confluence of such technologies fundamentally alters some aspects of DNS resolution. As a result, traditional DNS, as we know it, is constantly under attack by network adversaries for surveillance and censorship.

The evolution of DNS over HTTPS

To mitigate these threats and protect DNS’s authenticity, confidentiality and integrity, DNS-over-HTTPS (DoH) was proposed. The DoH RFC, recommends HTTP/2 as the minimum version for use with DoH.

Two things are necessary for DoH to happen: a DoH-compatible app (e.g. a DoH supported client) and a server that supports encrypted DNS. When the client makes the DNS request, it is enclosed in encrypted HTTPS packets (the entire DNS request is encrypted and embedded as part of HTTP payload) and sent to the DoH server, also called a DoH resolver, which processes the request and sends the encrypted response to the app (DoH supported client). As the entire name resolution happens over HTTPS, the conversation is secured.

DoH prevents communication gatekeepers and eavesdroppers from accessing information by encrypting DNS requests. In other words, anyone monitoring DoH traffic will be unable to distinguish between a DNS request and other HTTPS traffic.

The most common DoH rollout has been through web browsers, such as Mozilla Firefox and Google Chrome. Due to collaborations and close ties with CDN operators, who also operate DoH recursive resolvers, they have been able to implement and use this protocol. The agents involved in DoH are the same as those for conventional DNS, but the agent delivering domain name resolution is no longer the ISP and features and characteristics of the service have changed.

Top challenges with DoH traffic in a network

1. DNS over HTTPS/HTTP2 is encrypted. Hence, performance of network infrastructure elements and content aware devices are impacted by the increased level of encryption.
2. DNS transactions are small. This increases the number of new encrypted connections per second (DNS queries per second).
3. DoH exchanges are encrypted and DPI and monitoring is necessary for ensuring network security.

DoH Testing Topologies

Test topology 1\

Test traffic originating from a DoH client passes through an Application Delivery controller (ADC) and goes to a DoH capable DNS resolver. This test can determine the following –

• Performance and scalability impact on the ADC while handling traditional DNS requests vs. DoH as the ADC does TCP termination, filtering, security, etc.
• Measure the latency and delay in the network for handling DoH requests instead of traditional DNS.
• DoH handling capacity of the ADC for application mixes combined with HTTP, HTTP/2, and other IMIX traffic.
• As all modern ADCs generally intercepts the encrypted packets, this test also enables DPI and IPS for DoH packets.

Test topology 2

Test traffic originating from a traditional DNS client hits a proxy device. The proxy device intercepts the DNS requests and converts it to a DoH request for maintaining privacy of the client devices. The DoH response from the resolver is converted to plain DNS response for the client by the proxy. This test can determine the DNS request handling capacity of the proxy devices under such topology.

Test topology 3

Test traffic originating from a DoH client hits a DoH resolver. This scenario would be useful to benchmark performance of DoH servers before making them available into production.

Validate your network with DoH traffic

• Performance benchmarking for DOH servers and ADCs including maximum connections/sec (DNS queries/sec) and concurrent connections.
• HTTP latency measurement like time to first byte (TTFB), time to last byte (TTLB), TCP failures, HTTP failures which translates to the latency in the network and the number of DNS queries responded successfully.
• Performance benchmarking with DoH traffic with various ciphers available with TLS 1.2 like –
  • Bulk encryption ciphers like AES-CBC, AES-GCM.
  • Hashing algorithms like SHA and MD5.
  • ECC curves.
  • Various key sizes for public key exchange and bulk encryption.
• Security testing by intercepting DOH traffic and validating against blacklisted URLs.

Simplify DoH testing with Keysight’s IxLoad

Keysight’s IxLoad provides a comprehensive solution to test DoH, with IxLoad client and IxLoad server, for both functional and performance testing. Below is a sneak peek on how DoH can be configured from IxLoad.

In IxLoad, DoH is implemented as specialized Get and Post commands in the HTTP client and DNS configuration in the HTTP server, with DoH-specific statistics to show the results. As mentioned before, IxLoad DoH implementation can be used for both one-arm (simulating either the DoH client or the DoH server with IxLoad) or two-arm testing (IxLoad DoH client and server are the test endpoionts).

We will demonstrate below a sample configuration where IxLoad can be used for benchmarking CPS (Queries/sec) performance for an NGFW device as described in Topology 1 above.

IxLoad client configuration

• Add an HTTP activity and set the HTTP version to 2.0.
• Enable SSL and select TLS 1.2 and the cipher of your choice.
• Create a new command HTTP2(DoH) under HTTP activity.
• The DoH_client activity sends requests to an ADC which processes the DoH requests and sends it to the IxLoad DoH server for resolution.

• Create a new HTTP2 method profile for DoH with the Host name/ FQDN to be resolved and the type of query for that DNS request. For out example we will have a single GET command which requests resolution for name4.DoH.

IxLoad server configuration

• IxLoad HTTP server introduces a new tab – DNS over HTTPS, where zones can be added/ edited. The configurable DNS server settings for DoH are available here.

Just a few clicks and our test topology is ready!

IxLoad DoH statistics

Next Steps

Start testing your network with DoH traffic using IXLOAD - 9.20 UPDATE1 release, available for download at https://support.ixiacom.com/version/ixload-920-update1.
Learn more about how to use IxLoad in https://www.keysight.com/in/en/assets/7019-0052/application-notes/Application-Delivery.pdf

For more information, please visit our website https://www.keysight.com/in/en/products/network-test/protocol-load-test/ixload.html.\

Related Posts