<div dir="ltr"><div class="gmail_default" style=""><font face="courier new, monospace">Sorry, I not mean to be bad in the words.</font>

<font face="courier new, monospace"><br>I thought it was some project, research or school and that he needed some help.<br></font><font face="courier new, monospace"><br>Text interpretation is unique. Each interpletes as it sees fit.<br>In this case, I understood that he made a comparison, and then explained the difference.<br></font><font face="courier new, monospace"><br>As you said, DoH and DoT are wrapped with TLS.<br><br>Then both are wrapped in TCP.<br><br>As to complement the paper, there is a simple doc about DoH at </font><a href="https://developers.google.com/speed/public-dns/docs/dns-over-tls">https://developers.google.com/speed/public-dns/docs/dns-over-tls</a>  <font face="courier new, monospace"><br><br>When using a strict privacy profile, stub resolvers establish a DNS-over-TLS connection with the following steps.<br><br>1. The stub resolver is configured with the DNS-over-TLS resolver name dns.google.<br>2. The stub resolver obtains the IP address(es) for dns.google using the local DNS resolver.<br>3. The stub resolver makes a TCP connection to port 853 at the one those IP address.<br>4. The stub resolver initiates a TLS handshake with the Google Public DNS resolver.<br>5. The Google Public DNS server returns its TLS certificate along with a full chain of TLS certificates up to a trusted root certificate.<br>6. The stub resolver verifies the server's identity based on the certificates presented.<br>  . If the identity cannot be validated, DNS name resolution fails and the stub resolver returns an error.<br>7. After the TLS connection is established, the stub resolver has a secure communication path between to a Google Public DNS server.<br>8. Now the stub resolver can send DNS queries and receive responses over the connection.<br><br><br><br></font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter, 6 de ago de 2019 às 00:08, Joe Abley <<a href="mailto:jabley@hopcount.ca">jabley@hopcount.ca</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr"><div>On Aug 5, 2019, at 20:44, Luiz Fernando Softov via Unbound-users <<a href="mailto:unbound-users@nlnetlabs.nl" target="_blank">unbound-users@nlnetlabs.nl</a>> wrote:<br></div><div><br></div></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><div class="gmail_default"><font face="courier new, monospace">Great job, great paper, there is a lot of info no one known.<br><br>But, there is some mistakes, like in page 2, column 2:</font></div><div class="gmail_default"><font face="courier new, monospace">"DoH is similar to DoT, but uses HTTP as the transport protocol instead of TCP."<br></font></div></div></div></div></blockquote><div><br></div><div>I don't think that is necessarily the error that you think it is.</div><div><br></div><div>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.</div><br><div>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.</div><div><br></div><div><br></div><div>Joe</div></div></blockquote></div>