4 ms·

It sounds bad, but the fact that it can’t be blocked is important in terms of censorship. DNS over TLS can be easily blocked by blocking port 853. To block DNS

It sounds bad, but the fact that it can’t be blocked is important in terms of censorship. DNS over TLS can be easily blocked by blocking port 853. To block DNS over HTTPS you need to block the entire HTTPS traffic.

ori_b 7y ago
If that's the concern, you can run a DNS server on port 443. DOH also doesn't help much with censorship: If you look at traffic patterns, you can detect and block DOH servers pretty easily: look for small queries to a constant endpoint that come just before new connections.
- bureaucrat 7y ago
  “You” need to run port 443 DNS server. Instead we can make this mandatory for everyone. Your explained method is nearly impossible to implement for medium to large scale networks.
  - ori_b 7y ago
    Why? I can't imagine it'd make most flow inspecting firewalls and middleboxes break a sweat. If you want extra confirmation before banning, you can fire off a DNS query before killing the connection. Hell, you can go even more trivial with barely any effort: for every new https connection to an unknown server, send a DNS query. If you get a response, block the IP. HTTP adds nothing but complexity.
    - bureaucrat 7y ago
      Oh no no no, it does add security. Think DNS over TLS. Okay. You think $ip:$port is a dns connection. You send query with DoT protocol. You get answers. Bingo! It’s DNS. If it’s DNS over HTTPS, you can’t tell. What domain(dns.quad9.net or cloudflare-dns.com or dns.google or whatever you can imagine) is it? What endpoint and method(/dns-query?url= or whatever you can imagine) is it? You can’t tell. HTTP adds complexity. Complexity adds security.
      - ori_b 7y ago
        If I can't tell, neither can the legitimate users. This makes queries that would out of the box rather hard. And you still have the traffic patterns that will give you the information with sufficient confidence.
        bureaucrat 7y ago
        Why should legit users need to check whether a packet is to a dns server or not? And blocking https packets with mere confidence is impossible.
        ori_b 7y ago
        Well, it's hard to get a DNS response when you aren't talking to a DNS server... So, yeah, I can serve up DOH on my own server with a custom endpoint, custom client configuration, and generate cover traffic. But that's not exactly easy. And http doesn't help: I can do that without http, something like https://github.com/yrutschle/sslh https://github.com/yrutschle/sslh, or using SNI (which, as of TLS 1.3, is encrypted). And merely saying something is impossible doesn't make it so. It doesn't even make it hard.
    - zrm 7y ago
      The primary advantage to HTTP is that you can run the DNS server on the same host as an ordinary HTTP server that serves other pages. And then, especially for the likes of Cloudflare, that makes it harder to block. But what they should have done (and still could) is to have the server use SNI to determine whether it should speak HTTPS or DoT and then let the clients use DoT by providing the relevant server name.
deleted 7y ago
[deleted]

ori_b 7y ago

If that's the concern, you can run a DNS server on port 443. DOH also doesn't help much with censorship: If you look at traffic patterns, you can detect and block DOH servers pretty easily: look for small queries to a constant endpoint that come just before new connections.

bureaucrat 7y ago
“You” need to run port 443 DNS server. Instead we can make this mandatory for everyone. Your explained method is nearly impossible to implement for medium to large scale networks.
- ori_b 7y ago
  Why? I can't imagine it'd make most flow inspecting firewalls and middleboxes break a sweat. If you want extra confirmation before banning, you can fire off a DNS query before killing the connection. Hell, you can go even more trivial with barely any effort: for every new https connection to an unknown server, send a DNS query. If you get a response, block the IP. HTTP adds nothing but complexity.
  - bureaucrat 7y ago
    Oh no no no, it does add security. Think DNS over TLS. Okay. You think $ip:$port is a dns connection. You send query with DoT protocol. You get answers. Bingo! It’s DNS. If it’s DNS over HTTPS, you can’t tell. What domain(dns.quad9.net or cloudflare-dns.com or dns.google or whatever you can imagine) is it? What endpoint and method(/dns-query?url= or whatever you can imagine) is it? You can’t tell. HTTP adds complexity. Complexity adds security.
    - ori_b 7y ago
      If I can't tell, neither can the legitimate users. This makes queries that would out of the box rather hard. And you still have the traffic patterns that will give you the information with sufficient confidence.
      - bureaucrat 7y ago
        Why should legit users need to check whether a packet is to a dns server or not? And blocking https packets with mere confidence is impossible.
        ori_b 7y ago
        Well, it's hard to get a DNS response when you aren't talking to a DNS server... So, yeah, I can serve up DOH on my own server with a custom endpoint, custom client configuration, and generate cover traffic. But that's not exactly easy. And http doesn't help: I can do that without http, something like https://github.com/yrutschle/sslh https://github.com/yrutschle/sslh, or using SNI (which, as of TLS 1.3, is encrypted). And merely saying something is impossible doesn't make it so. It doesn't even make it hard.
  - zrm 7y ago
    The primary advantage to HTTP is that you can run the DNS server on the same host as an ordinary HTTP server that serves other pages. And then, especially for the likes of Cloudflare, that makes it harder to block. But what they should have done (and still could) is to have the server use SNI to determine whether it should speak HTTPS or DoT and then let the clients use DoT by providing the relevant server name.

deleted 7y ago

[deleted]