3 ms·

This RFC is from 2016, and isn't breaking news, so per HN practice, title should probably have (2016). However, there's a March 2018 RFC 8310: Usage Profiles f

This RFC is from 2016, and isn't breaking news, so per HN practice, title should probably have (2016). However, there's a March 2018 RFC 8310: Usage Profiles for DNS over TLS and DNS over DTLS [1] that describes some privacy implications, deployment scenarios, and DNS authentication mechanisms to be used with the new transports. [1] https://tools.ietf.org/html/rfc8310 https://tools.ietf.org/html/rfc8310

gnode 9y ago
It seems to me that neither TLS or DTLS are appropriate transports for DNS. Both are connection oriented transports, with DTLS simply allowing that connection to be lossy. To maintain the performance of DNS, you'd want a connectionless protocol. Although I'm not sure whether perfect forward security would be possible without adding a round-trip.
- deleted 9y ago
  [deleted]
- fanf2 9y ago
  DNS can work very well over TCP and TLS. It avoids most head-of-line blocking problems, because responses are usually small (a few KB), and they can be returned out-of-order. It's still relatively new for servers to implement DNS-over-TCP well (i.e. handling pipelined queries concurrently, and returning responses out-of-order) - you need BIND 9.11 or `dnsdist`. I did some brief testing yesterday, and in most cases TCP is as fast as UDP or faster. I was using a client based on `adns` which keeps one persistent TCP connection open. Unbound 1.6.0 TCP 8s Unbound 1.6.0 UDP 0.4s BIND 9.11 TCP 0.5s BIND 9.11 UDP 0.5s BIND 9.10 TCP 3s BIND 9.10 UDP 0.5s 1.1.1.1 TCP 0.5s 1.1.1.1 UDP 0.4s 8.8.8.8 TCP 5s # drops connection after 60 queries 8.8.8.8 UDP 220s # it hates me 9.9.9.9 TCP 1s 9.9.9.9 UDP 3s 64.6.64.6 TCP 0.5s 64.6.64.6 UDP 0.5s https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01935.html https://www.ietf.org/mail-archive/web/dns-privacy/current/ms...
  - gnode 9y ago
    I'm aware that this is the case once the connection is established. What I was referring to was the latency of TCP and TLS connection establishment, involving multiple round trips. Maintaining a persistent connection introduces the problem of requiring the DNS server maintain state for each client.
- zrm 9y ago
  > To maintain the performance of DNS, you'd want a connectionless protocol. What you're looking for is DNSCurve. The only reason people are interested in DNS over TLS is the garbage middleboxes that intercept and interfere with DNS (and thereby break DNSCurve or anything like it), which typically don't interfere with TLS. If you could use an arbitrary protocol then it might as well be DNSCurve. If you can't then it has to be TLS. Even DNS over DTLS is people not realizing why TLS was used to begin with. It seems the thing to do is to default to DNSCurve and fallback to DNS over TLS/HTTPS if that fails.

gnode 9y ago

It seems to me that neither TLS or DTLS are appropriate transports for DNS. Both are connection oriented transports, with DTLS simply allowing that connection to be lossy. To maintain the performance of DNS, you'd want a connectionless protocol. Although I'm not sure whether perfect forward security would be possible without adding a round-trip.

deleted 9y ago
[deleted]
fanf2 9y ago
DNS can work very well over TCP and TLS. It avoids most head-of-line blocking problems, because responses are usually small (a few KB), and they can be returned out-of-order. It's still relatively new for servers to implement DNS-over-TCP well (i.e. handling pipelined queries concurrently, and returning responses out-of-order) - you need BIND 9.11 or `dnsdist`. I did some brief testing yesterday, and in most cases TCP is as fast as UDP or faster. I was using a client based on `adns` which keeps one persistent TCP connection open. Unbound 1.6.0 TCP 8s Unbound 1.6.0 UDP 0.4s BIND 9.11 TCP 0.5s BIND 9.11 UDP 0.5s BIND 9.10 TCP 3s BIND 9.10 UDP 0.5s 1.1.1.1 TCP 0.5s 1.1.1.1 UDP 0.4s 8.8.8.8 TCP 5s # drops connection after 60 queries 8.8.8.8 UDP 220s # it hates me 9.9.9.9 TCP 1s 9.9.9.9 UDP 3s 64.6.64.6 TCP 0.5s 64.6.64.6 UDP 0.5s https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01935.html https://www.ietf.org/mail-archive/web/dns-privacy/current/ms...
- gnode 9y ago
  I'm aware that this is the case once the connection is established. What I was referring to was the latency of TCP and TLS connection establishment, involving multiple round trips. Maintaining a persistent connection introduces the problem of requiring the DNS server maintain state for each client.
zrm 9y ago
> To maintain the performance of DNS, you'd want a connectionless protocol. What you're looking for is DNSCurve. The only reason people are interested in DNS over TLS is the garbage middleboxes that intercept and interfere with DNS (and thereby break DNSCurve or anything like it), which typically don't interfere with TLS. If you could use an arbitrary protocol then it might as well be DNSCurve. If you can't then it has to be TLS. Even DNS over DTLS is people not realizing why TLS was used to begin with. It seems the thing to do is to default to DNSCurve and fallback to DNS over TLS/HTTPS if that fails.