4 ms·

> UDP at this day and age? Come on I assume this is a joke, since DoH3 (DNS over HTTP/3) uses QUIC which is UDP based.

deleted 2y ago
[deleted]
tsimionescu 2y ago
If DNS were running a full session-based encrypted protocol over UDP, like QUIC does, then no one would complain. But running anything that isn't streaming over plain UDP is basically a bad idea.
- zeta0134 2y ago
  I feel like you've conflated "UDP" with "unencrypted." This is false; you can perfectly well encrypt data transmitted over UDP, and you can also perfectly well run connections "in the clear" over TCP, which is the thing you generally use instead of UDP. What you don't get with UDP is guaranteed packet delivery, which generally means the application layer is in charge of acknowledgements and retransmits. It's great for game servers where low latency is highly important.
  - tsimionescu 2y ago
    Let me put it like this: for a modern day protocol that should be deployed widely over the internet, the protocol should be expected to have (1) encryption, and (2) session management. Ideally, dedicated protocols should be used for these, for proper separation of concerns, but doing it at the application layer directly can also be acceptable. Deploying an application protocol that does neither, such as DNS, directly over UDP is a bad idea. If you were to run DNS over DTLS (TLS over UDP), that would be a different beast, and probably ok. And to clarify, encryption is important to prevent tampering and preserve users's privacy. Session management is important to protect agains redirect attacks with spoofed source IP, or session hijacking.
    - zeta0134 2y ago
      Okay, but DoH is DNS over HTTPS, which itself runs over TCP/IP, which *does not implement encryption.* (The TLS part of HTTPS is doing that.) You're still mixing the layers here :) I'm not against the core part of your argument, just against the blaming of a particular choice of transport layer, which is fundamentally irrelevant. Encryption is great. Meanwhile DNS doesn't really need the concept of a session, does it? At the end of the day it's just a single lookup which can very well be fire and forget. That we're encrypting the request (ideally) and also the response (ideally) is no reason to add in loads more complexity.
      - tsimionescu 2y ago
        DoH means running DNS over HTTP over TLS over TCP. TCP does session management, TLS does encryption, HTTP is there just for "plausible deniability". DoH3 means running DNS over HTTP over QUIC over UDP. Here QUIC does both session management and encryption. In both cases, we are running a simple application protocol (DNS) over other protocols that handle the Internet-level problems I raised, so all is good. The problem is with running your application protocol directly and strictly over UDP and nothing else. And related to sessions, there are two things. For one, in reality today, you typically do a whole host of DNS requests even to load a single site (many common sites have upwards of 20 domains they use, and that's before loading any ads). So having a persistent session to send all of those requests on would not change much, even if it's not technically necessary. Secondly, even if you really want to avoid sessions, you then still need some other mechanism to prevent source IP spoofing. Any protocol which allows a host to send a small request to a server and cause that server to send a large response to the src IP of that request is a major problem for the health of the internet. Requiring a handshake to solve this is one simple way to avoid the problem entirely. DNS implementations have had to find all sorts of other mitigations to address this (I believe they now typically don't allow responses more than a factor of 1.something larger than the request, or something like that? Which of course brings in all sorts of extra problems and unnecessary traffic)
    - kelnos 2y ago
      > If you were to run DNS over DTLS (TLS over UDP), that would be a different beast, and probably ok. Yes, and the person you're replying mentioned that it was perfectly possible to encrypt data over UDP. Presumably they meant DTLS. So what's your concern?

deleted 2y ago

[deleted]

If DNS were running a full session-based encrypted protocol over UDP, like QUIC does, then no one would complain. But running anything that isn't streaming over plain UDP is basically a bad idea.

zeta0134 2y ago
I feel like you've conflated "UDP" with "unencrypted." This is false; you can perfectly well encrypt data transmitted over UDP, and you can also perfectly well run connections "in the clear" over TCP, which is the thing you generally use instead of UDP. What you don't get with UDP is guaranteed packet delivery, which generally means the application layer is in charge of acknowledgements and retransmits. It's great for game servers where low latency is highly important.
- tsimionescu 2y ago
  Let me put it like this: for a modern day protocol that should be deployed widely over the internet, the protocol should be expected to have (1) encryption, and (2) session management. Ideally, dedicated protocols should be used for these, for proper separation of concerns, but doing it at the application layer directly can also be acceptable. Deploying an application protocol that does neither, such as DNS, directly over UDP is a bad idea. If you were to run DNS over DTLS (TLS over UDP), that would be a different beast, and probably ok. And to clarify, encryption is important to prevent tampering and preserve users's privacy. Session management is important to protect agains redirect attacks with spoofed source IP, or session hijacking.
  - zeta0134 2y ago
    Okay, but DoH is DNS over HTTPS, which itself runs over TCP/IP, which *does not implement encryption.* (The TLS part of HTTPS is doing that.) You're still mixing the layers here :) I'm not against the core part of your argument, just against the blaming of a particular choice of transport layer, which is fundamentally irrelevant. Encryption is great. Meanwhile DNS doesn't really need the concept of a session, does it? At the end of the day it's just a single lookup which can very well be fire and forget. That we're encrypting the request (ideally) and also the response (ideally) is no reason to add in loads more complexity.
    - tsimionescu 2y ago
      DoH means running DNS over HTTP over TLS over TCP. TCP does session management, TLS does encryption, HTTP is there just for "plausible deniability". DoH3 means running DNS over HTTP over QUIC over UDP. Here QUIC does both session management and encryption. In both cases, we are running a simple application protocol (DNS) over other protocols that handle the Internet-level problems I raised, so all is good. The problem is with running your application protocol directly and strictly over UDP and nothing else. And related to sessions, there are two things. For one, in reality today, you typically do a whole host of DNS requests even to load a single site (many common sites have upwards of 20 domains they use, and that's before loading any ads). So having a persistent session to send all of those requests on would not change much, even if it's not technically necessary. Secondly, even if you really want to avoid sessions, you then still need some other mechanism to prevent source IP spoofing. Any protocol which allows a host to send a small request to a server and cause that server to send a large response to the src IP of that request is a major problem for the health of the internet. Requiring a handshake to solve this is one simple way to avoid the problem entirely. DNS implementations have had to find all sorts of other mitigations to address this (I believe they now typically don't allow responses more than a factor of 1.something larger than the request, or something like that? Which of course brings in all sorts of extra problems and unnecessary traffic)
  - kelnos 2y ago
    > If you were to run DNS over DTLS (TLS over UDP), that would be a different beast, and probably ok. Yes, and the person you're replying mentioned that it was perfectly possible to encrypt data over UDP. Presumably they meant DTLS. So what's your concern?