TCP Fast Open (TFO) for DNS-over-HTTPS and backend

[ammnt]

Hello,

please, consider to add TCP Fast Open for DoH and backend himself: https://tools.ietf.org/html/rfc7413

But I'm afraid additional kernel configuration checks will be required🥺

Thank you. Cheers😜

[ainar-g]

Hi, thank you for the request.

It seems like there isn't a lot of support for TFO in the wild. And also that there may be additional privacy/tracking concerns because of the Fast Open Cookies. If we are ever to enable this, we will also need a mechanism to change the cookie whenever the network changes. Which is arguably not a thing that happens to DNS servers often, but still, we need to carefully the impact of this feature.

Some references:

• https://squeeze.isobar.com/2019/04/11/the-sad-story-of-tcp-fast-open/
• https://github.com/curl/curl/issues/3662#issuecomment-471713854
• https://bugzilla.mozilla.org/show_bug.cgi?id=1689604

[DavidOsipov]

BTW, if not TFO, there is kind of similar technology for TLS 1.3 called 0-RTT . It has some troubles with privacy, but I think this technology would be quite beneficial for a DNS server.

This technology would be beneficial in a way:

1. To reduce server load, especially if a server serves many clients with thousands of DNS requests.
2. To reduce time for DNS replies for clients, especially if a server checks DNSSEC.
3. If Adguard Home user is into active web surfing, this technology would reduce TLS handshake time, thus improving surfing experience.

@ainar-g probably it would be even beneficial for your corporate users, who run Adguard Home (www.comss.ru for example), especially because Adguard home is a quite big and powerful piece of software, which requires much computational power and RAM.

[ammnt]

@DavidOsipov, awesome idea! Thank you👍

[DavidOsipov]

But, yeap, as always, there is also a trouble with the 0-RTT like possible replay attacks against it. But it can be mitigated with the correct implementation of the 0-RTT