RFC 6677 DNS Transport over TCP – Implementation Requirements (2016)

3. Terminology

o Pipelining: the sending of multiple queries and responses over a single TCP connection but not waiting for any outstanding replies before sending another query.

o Out-of-Order Processing: The processing of queries concurrently and the returning of individual responses as soon as they are available, possibly out of order. This will most likely occur in recursive servers; however, it is possible in authoritative servers that, for example, have different backend data stores.

6.1. Current Practices

Other more modern protocols (e.g., HTTP/1.1 [RFC7230], HTTP/2 [RFC7540]) have support by default for persistent TCP connections for all requests. Connections are then normally closed via a 'connection close' signal from one party.

6.2.1. Connection Reuse

To amortise connection setup costs, both clients and servers SHOULD support connection reuse by sending multiple queries and responses over a single persistent TCP connection.

When sending multiple queries over a TCP connection, clients MUST NOT reuse the DNS Message ID of an in-flight query on that connection in order to avoid Message ID collisions. This is especially important if the server could be performing out-of-order processing (see Section 7).

6.2.1.1. Query Pipelining

In order to achieve performance on par with UDP, DNS clients SHOULD pipeline their queries.

It is likely that DNS servers need to process pipelined queries concurrently and also send out-of-order responses over TCP in order to provide the level of performance possible with UDP transport.

DNS servers (especially recursive) MUST expect to receive pipelined queries. The server SHOULD process TCP queries concurrently, just as it would for UDP. The server SHOULD answer all pipelined queries, even if they are received in quick succession. The handling of responses to pipelined queries is covered in Section 7.

7. Response Reordering

Authoritative servers and recursive resolvers are RECOMMENDED to support the preparing of responses in parallel and sending them out of order, regardless of the transport protocol in use.

In order to achieve performance on par with UDP, recursive resolvers SHOULD process TCP queries in parallel and return individual responses as soon as they are available, possibly out of order.

[HTTP/1.1 pipelining can only do ordered responses]

Yes, but doesn't IPv6 also increase the "maximum safe UDP packet size" from 512 bytes to 1280?

> Existing deployments of DNSSEC [RFC4033] have shown that truncation at the 512-byte boundary is now commonplace. For example, a Non-Existent Domain (NXDOMAIN) (RCODE == 3) response from a DNSSEC-signed zone using NextSECure 3 (NSEC3) [RFC5155] is almost invariably larger than 512 bytes.

This has been a flagged issue in DNSSEC since it was originally considered. This was a massive oversight on their part and was only added because DNSSEC originally made it quite easy to probe entire DNS trees and expose obscured RRs.

> The MTU most commonly found in the core of the Internet is around 1500 bytes, and even that limit is routinely exceeded by DNSSEC-signed responses.

> Stub resolver implementations (e.g., an operating system's DNS resolution library) MUST support TCP since to do otherwise would limit the interoperability between their own clients and upstream servers.

Fair enough but are network clients actually meant to use DNSSEC? Isn't this just an issue for authoritative and recursive DNSSEC resolvers to and down the roots?

Austin Hounsel, Kevin Borgolte, Paul Schmitt, Jordan Holland, and Nick Feamster

https://arxiv.org/pdf/1907.08089

"On the lossy 4G network, DoT grows increasingly faster than Do53, and DoH begins to close the gap."

"We discovered that current DNS clients do not utilize part of the DNS Internet Standard that could improve client performance and user experience. Unfortunately, the three public recursors we measured violate the standard [27] by not supporting queries with more than one question (QDCOUNT > 1). Cloudflare and Quad9 do not respond, and Google only responds to the first question."

[RFC 1035 (1987) mentions queries with multiple questions in a single packet. AFAIK there have never been any DNS servers that can read and respond to multiple questions in a single packet. But recently there is a practicable workaround, 29 years later: DoT pipelining (multiple question in a single TCP connection). IME, after about 10 years of use, the speed of DoT blows away DoH]

A Comprehensive Study of DNS-over-HTTPS Downgrade Attack (2020)

Qing Huang, Deliang Chang, Zhou Li

https://www.usenix.org/system/files/foci20-paper-huang.pdf

"The fundamental reason is that all browsers enable Opportunistic Privacy profile by default, which allows DoH fall backs to DNS when DoH is not usable."

[DoT/DoH outside the browser generally does not have this problem

As will see Dot/DoH research generally

(a) is browser-centric

(b) assumes the only way to obtain DNS data is by letting a browser retrieve it piecemeal from remote servers automatically

(c) assumes the popular graphical browser is the only application that uses DNS data, and

(d) fails to consider other ways to retrieve and use DNS data that can actually speed up www information retrieval and increase "privacy", but do not necessarily work well with advertising and tracking]

Large Scale Measurement on the Adoption of Encrypted DNS (2021)

Sebastin Garca, Karel Hynek, Dmtrii Vekshin, Tom Čejka

https://arxiv.org/pdf/2107.04436

Organization 2

"The amount of DoH traffic is in average 35 times smaller than DoT."

"DoT Trends. DoT traffic seems to be much larger in the ISP (Organization 2) than in the other organizations. Showing a non-stationary growth in this organization. However, it shows an actually decrease in Organization 2 on mid-January 2021. The absolute number of DoT flows is larger than DoH in all the traffic captures combined."

"DoT traffic seems to be growing in some organizations and has a large volume of traffic considering all absolute numbers. It probably produces more global traffic than DoH."

Can Encrypted DNS Be Fast? (2021)

Austin Hounsel, Paul Schmitt, Kevin Borgolte, and Nick Feamster

https://link.springer.com/content/pdf/10.1007/978-3-030-7258...

"We note that queries for DNS and DoT are sent synchronously, i.e., they must each receive a response before the next query can be sent. On the other hand, DoH queries are sent asynchronously, functionality that is enabled by the underlying HTTP protocol [if it's HTTP/2]"

"Interestingly DoT lookup times are close to those of conventional DNS."

"Interestingly, for X and Y, we find that DoT performs 2.3 ms and 2.6 ms faster than conventional DNS, respectively"

"DoH experienced higher response times than conventional DNS or DoT, although this difference in performance varies significantly across DoH resolvers."

"DoT Can Meet or Beat Conventional DNS Despite High Latencies to Resolvers, Offering Privacy Benefits for no Performance Cost."

"DoH Performs Worse Than Conventional DNS and DoT as Latencies To Resolvers Increase."

[Authors apparently not aware that DoT queries can be sent asynchronously. I do this outside the browser. Nor did authors acknowledge that alternative to using HTTP/2, DoH can be sent synchronously, using HTTP/1.1 pipelining. I do this outside the browser when ports 53, 853 are being redirected by the ISP

"Table 5: Supported HTTP versions by the resolvers found in our Internet scan.

HTTP Version support Number of servers

Only HTTP/1 45 (4.9 %)

Only HTTP/2 86 (9.2 %)

HTTP/1 and HTTP/2 800 (85.9 %)"

Source: https://arxiv.org/pdf/2107.04436]

Domain Name Encryption Is Not Enough: Privacy Leakage via IP-based Website Fingerprinting (2021)

Nguyen Phong Hoang, Arian Akhavan Niaki, Phillipa Gill, and Michalis Polychronakis

https://arxiv.org/pdf/2102.08332

"Our technique exploits the complex structure of most websites, which load resources from several domains besides their primary one."

[What if not using browser. I only retrieve resources from the primary domain, or an "API" domain if that is where the content comes from. Despite "the complex structure of most websites" this works really well for me. The "complex structure of most websites" is mostly ads and tracking. As for "mitigation" why not self-hosting a remote forward proxy]

If this were the default on DNS servers, then DNS amplification attacks would be nearly impossible. They rely on spoofing a DNS request from the victim, and amplify because the response may be many times larger than the request. If TCP were required to be used before UDP responses can be received, then the victim would have to be first tricked into making a DNS request over TCP to each public DNS server.

The DNS Cookies standard (RFC 7873) doesn't do much to stop this, since it is impractical to fail queries from non-cookie clients.

DNS over TCP is supposed to be supported, so implementing this will push firewall admins in the right direction (allow both TCP/UDP outbound on 53).

Spoofing/amplification attacks are already a problem, no?

    s/6677/7766/