05/04/2022 | Press release | Distributed by Public on 05/04/2022 07:44
2022-05-04 | 10 min read
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 -
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 (so when I say DNS request is encrypted in https, it means 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
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 -
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
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 1above.
IxLoad client configuration
IxLoad server configuration
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 UPDATE1release, 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.