Blog

Using BreakingPoint to Test DNS over HTTPS (DoH) Services - Part 1

September 27, 2019 by Vincent Du

Introduction

The DNS over HTTPS (DoH) protocol aims to address vulnerabilities found in existing DNS services, providing privacy and further avoiding internet censorship via DNS resolving. Google, Mozilla, CloudFlare, etc. have already published DoH services for the public to use.

For example, https://dns.google (8.8.4.4) is Google’s test DoH project. Developers can use two different URIs to access it:

  • RFC8484 uri: https://dns.google/dns-query? (GET and POST)
  • JSON API uri: https://dns.google/resolve? (GET)

The RFC8484 uri uses wire format DNS data as the query and response; and the JSON API uri returns a more user-friendly JSON object as the DNS response.

Ixia’s BreakingPoint system now can emulate network activities of both types of DoH services, with these four superflows: 

  • DNS over HTTPS
  • DNS over HTTPS(JSONAPI)
  • DNS over HTTP2
  • DNS over HTTP2(JSONAPI)

Setting up back-to-back DoH tests (2-armed) with these Superflows is easy. With some extra effort, we were able to create a 1-armed test where BreakingPoint acts as a DoH client to request DNS service from an actual DoH server. Here we’d like to share our approaches.

Network Neighborhood and Test Setup

For DoH ClientSim to work, one interface of BreakingPoint must have a route to the target DoH server host, in our case, it must be connected to the internet. A Network Neighborhood (NN) like this willallow the “Interface 1” behind gateway 10.36.128.1 to communicate directly with dns.google (8.8.4.4)

1

Next, create a test with “Client Simulation” using this NN:

2

Create a load profile, load one of the DoH Superflows, then modify the native 2-armed DoH Superflow by removing all the actions originated from the server since it will be a ClientSim.

In the “Start TLS” action, some parameters need to be correctly set. It seems dns.google requires an ECDHE cipher, so include one like “TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”, otherwise the TLS handshake will not succeed. Make sure the “Server Name Indication” field is set to the DoH service host also.

3

Lastly, reserve the single interface that has a connection to the target DNS host and make sure the Component Tags are set properly:

4

This test can now run and finish successfully.

5

From the packet capture, we can see that BreakingPoint has successfully finished the TLS handshake with the DoH host, and exchanged some messages with it.

6

The question now is, how do we know the encrypted TLS application data from the DoH server are the desired DNS query result? Also, due to the fact that an ECDHE cipher is used in the encryption, decryption with a MITM proxy becomes difficult.

In part 2 of this blog, I will introduce a method to allow viewing the server response in cleartext. 

Superflows associated with DoH are available from Ixia’s Application and Threat Intelligence (ATI) subscription service in the 2019-18 Update on September 24.

7

Read more in part 2 of this blog.