Analysing the Costs of DNS, DoT and DoH for the Modern Web

Unbound
1

I thought Unbound users may like to have a read of this paper…

https://arxiv.org/pdf/1907.08089.pdf

2

Great job, great paper, there is a lot of info no one known.

But, there is some mistakes, like in page 2, column 2:
“DoH is similar to DoT, but uses HTTP as the transport protocol instead of TCP.”

HTTP is not even on the same layer as TCP.
TCP is a transport-layer protocol, and HTTP is an application-layer protocol.
You need at least TCP, UDP or some way to transmit data, then you can made HTTP protocol things.

Get a read here and in the comments
https://www.quora.com/What-is-the-difference-between-HTTP-protocol-and-TCP-protocol

I stop reading because the “Recursor Default” vs others.

3

I don’t think that is necessarily the error that you think it is.

The text (to my eye) does not suggest that HTTP and TCP are equivalent, but rather that they are both transport protocols of DNS, which I think is a reasonable assertion. In the derivative cases of DoH and DoT, both are wrapped with TLS. I do not share your interpretation that there is an inference that HTTP and TCP are somehow equivalent.

I have not fully digested the paper and all of its observations, but that (above) to my mind is not a reason to stop reading.

Joe

4

Sorry, I not mean to be bad in the words.
I thought it was some project, research or school and that he needed some help.

Text interpretation is unique. Each interpletes as it sees fit.
In this case, I understood that he made a comparison, and then explained the difference.

As you said, DoH and DoT are wrapped with TLS.

Then both are wrapped in TCP.

As to complement the paper, there is a simple doc about DoH at https://developers.google.com/speed/public-dns/docs/dns-over-tls

When using a strict privacy profile, stub resolvers establish a DNS-over-TLS connection with the following steps.

  1. The stub resolver is configured with the DNS-over-TLS resolver name dns.google.
  2. The stub resolver obtains the IP address(es) for dns.google using the local DNS resolver.
  3. The stub resolver makes a TCP connection to port 853 at the one those IP address.
  4. The stub resolver initiates a TLS handshake with the Google Public DNS resolver.
  5. The Google Public DNS server returns its TLS certificate along with a full chain of TLS certificates up to a trusted root certificate.
  6. The stub resolver verifies the server’s identity based on the certificates presented.
    . If the identity cannot be validated, DNS name resolution fails and the stub resolver returns an error.
  7. After the TLS connection is established, the stub resolver has a secure communication path between to a Google Public DNS server.
  8. Now the stub resolver can send DNS queries and receive responses over the connection.