Hacker News Reader

Comment by exabrial | Hacker News Reader

For the love of all that is holy... DNS should be UDP (or eqiv), as most building block protocols of the internet. _that doesn't mean it needs to be unencrypted_. Wasn't there DNSCurve a thing at one point that was the best of all worlds?

View on HN

DNS has always supported UDP and TCP. Traditionally queries used UDP and transfers TCP but this wasn't a requirement of the protocol. With the advent of EDNS and large responses such as those when DNSSEC is involved TCP was increasing being used for queries even before DoT or DoH.

QUIC is UDP based so by being able to handle large responses DoQ reduces the need to use TCP and brings your vision of a UDP only DNS closer to fruition.

DNS has always supported TCP. RFC 1034, published in 1987, made it a requirement. DNS uses TCP when replies exceed 512 bytes(barring EDNS0.) DNS also uses TCP for zone transfers. There's even a bit called the TC(truncate) bit which when set in a response informs the client to use TCP.

CurveDNS, an implementation of a dnscruve forwarder, works great. I use it on the home network. To see an example on the internet, try

   x=$(dq -a a ianix.com 192.5.6.30 |sed -n '/authority/{s/.* NS //;s/\..*//p;q;}')
   dq -a -k $x a ianix.com 104.207.143.9

dnscurve comes from the same author as the underlying encryption used in dnscurve and QUIC (and countless other solutions), and both NaCl and dnscurve predated QUIC. Today, QUIC looks overengineered and has too many privacy issues compared to the original, IMHO. The author of NaCl and dnscurve was not interested in personal data mining and selling advertising services, unlike the corporations behind QUIC. Oh well.

https://github.com/curvedns/curvedns

Assuming downvote means the example is not working. This should work:

   dq -a -k uz5dns1bx64zu3pgn9nm4zfvmh2vy4hpjy7nkjz6qjcu325bg9hzcx a ianix.com 104.248.15.206

whereas using the other nameserver may not work, i.e.,:

   dq -a -k uz5dns2sdrnxskf5lqt46v34cdlfqb9q2lvvmpr95g3l1qh0148sf6 a ianix.com 104.207.143.9

>"Today, QUIC looks overengineered and has too many privacy issues compared to the original, IMHO."

Could you or someone else say what are the privacy issues are with QUIC?

See Section 7 of RFC 9250 that is the subject of this submission.

QUIC is designed by a company that prioritises personal data collection and advertising over user privacy with respect to the company. If compromises have to be made in order to satisfy the company's interests in collecting user data and administering programmatic advertising services that include subjugating user privacy from the company, then what happens. CurveCP and dnscurve do not suffer from such commercial pressures. CurveCP and dnscurve were not designed by an online advertising services provider.

Arguments that doubts the origins and not the technical merits are very poor arguments. That’s a slippery slope that can go to any absurd extreme such as asking what’s the proof that CurveCP is free from nation-state pressure because of author’s citizenship?

QUIC, despite its warts, is an open spec that anyone can review. The cryptography is based off TLS 1.3 and to prevent ossification it is fully encrypted (sans two sequence numbers). It’s really easy to read spec - really, try reading it.

Thanks, this was the first I had heard this mentioned and agree the passage doesn't seems grounded in opinion more than technical merit. I was curious about your comment that:

>"The cryptography is based off TLS 1.3 and to prevent ossification ..."

I thought that the protocol choosing the be encapsulated in UDP was the thing that was addressing protocol ossification since UDP will always be supported by OS's network stacks. Or are you referring to something else?

The transport protocol is UDP however the security layer is basically TLS 1.3.

From a "privacy against companies like Google perspective", QUIC does not have a good track record so far with respect to its use for HTTP. The prioritisation of censorship resistence is evident in its design however a similar prioritisation for resistance to personal data collection and tracking by companies associated with online advertising, such as Google, is not.

https://www.theregister.com/2021/01/30/quic_fingerprinting_f...

https://arxiv.org/pdf/2101.11871

(Non-substantive) discussion: https://news.ycombinator.com/item?id=25969886

As an avid TLS1.3 (with ESNI for all Cloudflare sites) user, I noticed QUIC did not try to avoid sending a hostname in plain text over the wire. They could have, but they did not. There is also the issue of unnecessary HTTP headers such as User-Agent. I filter out unnecessary header in a forward TCP/HTTP proxy. How would one do this if using QUIC.

Privacy issues of ISPs in the modern web

"This is the case of QUIC, designed by Google and implemented in Google Chrome, Android smartphones as well as on Google Web servers. It relies on UDP and provides authentication and confidentiality for HTTP transactions. Nevertheless, the server hostname is transmitted in clear, posing the same privacy issues of TLS. Moreover, QUIC transmits clients User-Agent in clear, unveiling users device type."

https://core.ac.uk/download/pdf/234919911.pdf

Anyway, the potential for tracking was evident early on.

A QUIC Look at Web Tracking Proceedings on Privacy Enhancing Technologies ; 2019 (3):255266

"Our analysis reveals that the protocol design contains violations of privacy best practices through which a tracker can passively and uniquely identify clients across several connections. This tracking mechanisms can achieve reduced delays and bandwidth requirements compared to conventional browser fingerprinting or HTTP cookies. This allows them to be applied in resource- or time-constrained scenarios such as real-time biddings in online advertising."

https://petsymposium.org/2019/files/papers/issue3/popets-201...

The efforts being made to reduce that potential have been unconvincing.

This is not the padding you are looking for! On the ineffectiveness of QUIC PADDING against website fingerprinting

"To provide protection against traffic analysis [. . . ], the working group behind QUIC, the next transport layer standard for the Web, introduced a PADDING frame in the specification [11]. In this work, we demonstrate that defenses solely based on padding QUIC traffic are ineffective against WF attacks."

https://eprint.iacr.org/2015/582.pdf

Now, years later we are presented with the proposition of using QUIC for DNS.

From the Section 7 of RFC 9250 that is the subject of this HN submission:

"The recommendation for TLS 1.3 [RFC8446] is that the capability to use 0-RTT data should be turned off by default and only enabled if the user clearly understands the associated risks. In the case of DoQ, allowing 0-RTT data provides significant performance gains, and there is a concern that a recommendation to not use it would simply be ignored."

The authors of this RFC 9250 claim they refuse to recommend turning off 0-RTT by default because (a) 0-RTT and session resumption provide performance gains and (b) they speculate any such recommendation would be ignored. Neither are adequate justifications. The problem with (a) as a justification is that the tradeoff is not simply between performance and privacy it is between privacy and commercial gain. The later can be achieved by subjugating user privacy in order to perform data collection and tracking to support the commercial interests of companies that profit from the proliferation of online advertising. The problem with (b) as a justification is that 1. it is pure speculation (in fact, there is evidence to the contrary - see below) and 2. the same speculation is not applied to Section 4.5. How does a user verify that a server is following Section 4.5.

Even if we give the RFC authors our absolute blind faith trust that they have DNS user privacy interests as their top priority, it is still clear that they are prioritising performance gains over privacy risks. It stands to reason that they would be motivated to do so because the only legitimate way DoQ can win adoption over the (less risky) alternatives is if it offers better performance.

One to Rule them All? A First Look at DNS over QUIC https://doi.org/10.1007/978-3-030-98785-5_2

"Finally, none of the DoQ-verified resolvers offer support for QUIC 0-RTT. However, the lack of 0-RTT support might be a deliberate choice, as the use of 0-RTT exposes clients to privacy risks."

[The authors recently tested 1,217 DoQ-verified resolvers found on the internet in January 2022.]

https://arxiv.org/pdf/2202.02987

2008: NaCl, CurveCP implementation plus dnscurve design - initial release

2011: NaCl, CurveCP implementation - stable release

2012: QUIC implementation

2022: DNS over QUIC RFC

Well, it was the Daniel Bernstein solution, so I'm sure Bernstein thought it was the best of all worlds but the rest of us not so much.

There are already several other protocols you can ask/ answer DNS queries over.

Reply on news.ycombinator.com