4 ms·

I think you're right on the money here. DNS-over-TLS uses port 853, so is trivial to block on a firewall and force fallback to plain-text DNS. DoH is resilien

by kees99 6y ago

I think you're right on the money here. DNS-over-TLS uses port 853, so is trivial to block on a firewall and force fallback to plain-text DNS. DoH is resilient to such an attacker - be it sketchy guy in starbucks trying to steal your cookies, or yourself trying to run pi-hole adblock.

dijit 6y ago
Not sure why you couldn't do TLS over port 53 though, we've had STARTTLS for decades, you can even inform software not to fallback. The downside is, of course, that Starbucks can't redirect you to their "please accept our TOS" portal.
- deleted 6y ago
  [deleted]
- mytailorisrich 6y ago
  Port 53 is already used for UDP and TCP DNS, so trying to use it for TLS (over TCP) on top of that would impact existing DNS infrastructure. The idea of these new transports is not to impact existing DNS.
- iso1631 6y ago
  Either way, as a network admin, DoT is easy to block -- you simply redirect all port 53 traffic to your own DNS. DoT will either fail, or fallback to plain text. Can't easily block all port 443 traffic (may as well not give any service), and as servers grow maintaining a blacklist of DoH would be problematic - especially when the DoH server is hidden behind normal sites on cloudflare etc. Of course a sysadmin can always establish a VPN on any port to any IP with TCP, UDP, ICMP, or even running a VPN over unencrypted DNS, and bypass all that network work other than very specific IP whitelisting. As a network admin and a sysadmin, I want to be able to control my systems from my network without losing control. I like the idea of DoH, I just don't want to have to reconfigure my DoH server everytime I want to connect to a split-brain network, or have an alternative PTR server, and I certainly don't want my browser using a different source for DNS to my other applications.
  - dijit 6y ago
    I'm also a network/server admin. I don't see things as you do. Specialised protocols are better than generalised ones because they have understandable failure modes. If DNS goes down, name resolution fails. But if DoH goes down, it could still be DNS, it could be TLS Suites, it could be incorrect headers, it could be mishandling of the proxy (or the proxy forwarding garbage), it could be anything. that's why we consider DNS to be Layer 6 and not Layer 7, as things on Layer 7 may depend on it.
    - iso1631 6y ago
      So DNS is easier to debug? So are many protocols. It doesn't mean we should still be using http, rlogin, or snmpv1. There are significant benefits to the end user of DoH in bypassing malicious networks. It's out there, it's not going away. I'd like it to integrate well in a situation where I am the user, sysadmin and netadmin.
      - dijit 6y ago
        rlogin -> ssh. unless you're saying we should replace SSH with HTTP. And yes, DNS is easier to debug than HTTP if HTTP depends on HTTP.
        syshum 6y ago
        Well at this rate HTTP will simply eat all other things
        iso1631 6y ago
        The problem is that DoT has almost all the drawbacks of DNS from ability to block (and thus fall back to non-TLS dns which can be manipulated), and almost all the drawbacks of DoH (harder to debug). It's the worst of both worlds.
livre 6y ago
>or yourself trying to run pi-hole adblock. If you are smart, at this point you'd have already switched to a DoH server using your own certificate (I use a local AdGuard Home instance for that). You can then point not just your browser (either using its configuration page or group policies) but also the operating system and secure the whole thing. After that your only threat is the same as it has always been, a device bypassing your local server, it is safe to assume those are compromised and should be put behind a firewall or disconnected from the network (it is also safe to assume that a firewall rule to capture and modify its DNS queries has never been a 100% reliable solution). DoH already happened, there's no point in arguing against it like it's the end of the world as we know it. It's now time to adapt and update (or replace) the blocking mechanisms we are used to using. This may mean the end of pi-hole should they fail to add a DoH server to the default installation but we already have alternatives.

by kees99 6y ago

dijit 6y ago

Not sure why you couldn't do TLS over port 53 though, we've had STARTTLS for decades, you can even inform software not to fallback. The downside is, of course, that Starbucks can't redirect you to their "please accept our TOS" portal.

deleted 6y ago
[deleted]
mytailorisrich 6y ago
Port 53 is already used for UDP and TCP DNS, so trying to use it for TLS (over TCP) on top of that would impact existing DNS infrastructure. The idea of these new transports is not to impact existing DNS.
iso1631 6y ago
Either way, as a network admin, DoT is easy to block -- you simply redirect all port 53 traffic to your own DNS. DoT will either fail, or fallback to plain text. Can't easily block all port 443 traffic (may as well not give any service), and as servers grow maintaining a blacklist of DoH would be problematic - especially when the DoH server is hidden behind normal sites on cloudflare etc. Of course a sysadmin can always establish a VPN on any port to any IP with TCP, UDP, ICMP, or even running a VPN over unencrypted DNS, and bypass all that network work other than very specific IP whitelisting. As a network admin and a sysadmin, I want to be able to control my systems from my network without losing control. I like the idea of DoH, I just don't want to have to reconfigure my DoH server everytime I want to connect to a split-brain network, or have an alternative PTR server, and I certainly don't want my browser using a different source for DNS to my other applications.
- dijit 6y ago
  I'm also a network/server admin. I don't see things as you do. Specialised protocols are better than generalised ones because they have understandable failure modes. If DNS goes down, name resolution fails. But if DoH goes down, it could still be DNS, it could be TLS Suites, it could be incorrect headers, it could be mishandling of the proxy (or the proxy forwarding garbage), it could be anything. that's why we consider DNS to be Layer 6 and not Layer 7, as things on Layer 7 may depend on it.
  - iso1631 6y ago
    So DNS is easier to debug? So are many protocols. It doesn't mean we should still be using http, rlogin, or snmpv1. There are significant benefits to the end user of DoH in bypassing malicious networks. It's out there, it's not going away. I'd like it to integrate well in a situation where I am the user, sysadmin and netadmin.
    - dijit 6y ago
      rlogin -> ssh. unless you're saying we should replace SSH with HTTP. And yes, DNS is easier to debug than HTTP if HTTP depends on HTTP.
      - syshum 6y ago
        Well at this rate HTTP will simply eat all other things
      - iso1631 6y ago
        The problem is that DoT has almost all the drawbacks of DNS from ability to block (and thus fall back to non-TLS dns which can be manipulated), and almost all the drawbacks of DoH (harder to debug). It's the worst of both worlds.

livre 6y ago

>or yourself trying to run pi-hole adblock. If you are smart, at this point you'd have already switched to a DoH server using your own certificate (I use a local AdGuard Home instance for that). You can then point not just your browser (either using its configuration page or group policies) but also the operating system and secure the whole thing. After that your only threat is the same as it has always been, a device bypassing your local server, it is safe to assume those are compromised and should be put behind a firewall or disconnected from the network (it is also safe to assume that a firewall rule to capture and modify its DNS queries has never been a 100% reliable solution). DoH already happened, there's no point in arguing against it like it's the end of the world as we know it. It's now time to adapt and update (or replace) the blocking mechanisms we are used to using. This may mean the end of pi-hole should they fail to add a DoH server to the default installation but we already have alternatives.