7 ms·

Chrome uses opportunistic DoT - it uses your system configured resolver, and if it supports DoT, it will use DoT, if not, it will fall back to 53/udp. I like C

Chrome uses opportunistic DoT - it uses your system configured resolver, and if it supports DoT, it will use DoT, if not, it will fall back to 53/udp. I like Chrome's approach much better; it doesn't force you to statically configure DNS server - it is a PITA, especially when roamining and you want to resolve hostnames available only in local networks.

ignoramous 7y ago
> ...it is a PITA, especially when roamining and you want to resolve hostnames available only in local networks. Not really. If you're not blackholing traffic at the dns-layer via DoH, set Firefox's trr.mode to 2. Per documentation, at the cost of additional latency incurred, system-level / network-level resolvers should pick up the slack, provided they've been set as appropriate via DHCP or otherwise. Ref: https://wiki.mozilla.org/Trusted_Recursive_Resolver#network.trr.mode https://wiki.mozilla.org/Trusted_Recursive_Resolver#network....
- dmix 7y ago
  Considering the amount of people using library or Starbucks internet that needs you to use the local DNS (at least once you initially connect), maybe #2 should be the default? Or is there some risk in doing so?
  - dylanh 7y ago
    If your OS doesn’t already detect the captive portal, Firefox will.
    - dmix 7y ago
      Perfect
- mooman219 7y ago
  If I sit any family member down in front of this comment, their eyes would glaze over. Not only is what you mention a PITA, it's impossible for most people.
  - ignoramous 7y ago
    AFAIK, when one turns on DoH, Firefox's trr.mode defaults to 2. And that's the default behaviour most would want except for the ones using pi-hole et al.
    - vetinari 7y ago
      Not sure about that; it will still send query to the open Internet first and only when it fails, it will query local resolver. You have leaking internal hostnames there. To be fair, it is difficult to make all parties satisfied there. I think that a bit more honesty during discussion would help.
    - bscphil 7y ago
      In general, yes, that solves the problem for local domains. But anyone who needs to do anything at all complicated is going to have trouble with this, not just Pi-Hole users. For example, take your average John Doe who uses Firefox. Not particularly technically competent. A new version of Firefox comes out, and all the Archive.is domains break. Who does he blame for that, and how does he solve the problem? What's happening behind the scenes is that Firefox switched his DNS address on him without warning. And Cloudflare (the DNS endpoint used by Firefox by default) returns incorrect IP addresses for the Archive.is domains (because the admin of these domains returns fake addresses to Cloudflare from their authoritative DNS server). Most people are using DNS provided by their ISP, so they haven't seen this problem before. I know about the problem, and my resolver (Unbound) is set to use Cloudflare over TLS for most requests, but sends Archive.is domains to Google's DNS instead. This solves the problem for me. Firefox switching to Cloudflare by default not only breaks sites like this for the average user, it even breaks my workaround that fixes the problem. (I can't currently reproduce the problem, so maybe Archive.is caved and started sending working IP addresses. But it's the sort of problem that can happen when you start messing around with DNS. Your users will blame you if a site doesn't load in your browser, but works in other ones.)
      - mrpopo 7y ago
        > the admin of these domains returns fake addresses to Cloudflare from their authoritative DNS server Why?
Polylactic_acid 7y ago
Firefox has no issues with local domains and DoH. It makes a DoH request first and when that returns nothing it tries regular DNS.
- teknopaul 7y ago
  That is an issue. Apart from the wait. Spaff hostnames to cloudflare, fail, then try harder. Users expect hosts: files,dns Admins expect dns to work. FireFox should not be fscking with network config. If they do, they should try not to break users first. Firefox is borken. Security is not improved. My DNS requests never leave the LAN.
  - Polylactic_acid 7y ago
    Half of your comment doesn't make any sense but for the rest of it, its just incorrect. The change in firefox hasn't broken anything, security is certainly improved in combination with other efforts like encrypted SNI. And yes, your dns requests always leave your lan at least once. You can run your own DNS server locally but that dns server has to ask other servers for the data since it can't store a local copy of the entire dns system. A local dns server is just a cache but with a few users its likely not doing any more than your browser cache.
    - teknopaul 7y ago
      DoH breaks anything that is going on in your BIND or NSD server. It bypasses them, it has broken that. If it does DNS first, then if that fails does /etc/hosts, its broken that too. If I, or my company, or ISP has anything special in hosts or DNS, e.g. load balancing, name mapping, breaking facebook.com, things like that get bypassed. DoH over HTTPS is slower than a lookup to /etc/hosts, and probably slower than a lookup to a locally cached DNS resolver. Security is not improved by FireFox bypassing my network admins DNS rules. Most DNS queries do not go over the Internet, unless you have DoH or have set special DNS servers. My ISP provides IP access to the Internet and DNS, like almost all ISPs. It not to do with local caching (which does add security), if I query foo.com that query goes to my ISP, not via the Internet, my ISP knows I asked for foo.com and then then the routes my IP packets there. My ISP has to lookup DNS on the Internet to resolve them if it is not in caches but that lookup is not associated to me. When I connect to a corporate network all my DNS goes over VPN if any information is required from the Internet again that is not associated to me. Cloudflare might be running a more secure DNS resolver at the other end than my ISP, but it might not, its rules have to apply to the whole world so they cannot be tuned for me and my security preferences. After DoH, all DNS goes over the Internet, even quires that eventually are resolved locally. Cloudflare now know I'm going to foo.com and so does my ISP, or VPN provider, I don't see how security has improved. Its just sending information to a commercial partner of Mozilla's in addition to my ISP. Some informationits getting that before my ISP did not get. Plus HTTPS is not infallible. DoH is more secure than DNS in plain text over the Internet, but that is very rarely the case. DNS is also not a significant risk to browser users. I have never had a DNS response faked, to any HTTPS site it would not work, so why bother. There isn't much risk, its not more secure, and it breaks stuff.
all_blue_chucks 7y ago
Opportunistic security that can be disabled by attackers is not really security.

ignoramous 7y ago

> ...it is a PITA, especially when roamining and you want to resolve hostnames available only in local networks. Not really. If you're not blackholing traffic at the dns-layer via DoH, set Firefox's trr.mode to 2. Per documentation, at the cost of additional latency incurred, system-level / network-level resolvers should pick up the slack, provided they've been set as appropriate via DHCP or otherwise. Ref: https://wiki.mozilla.org/Trusted_Recursive_Resolver#network.trr.mode https://wiki.mozilla.org/Trusted_Recursive_Resolver#network....

dmix 7y ago
Considering the amount of people using library or Starbucks internet that needs you to use the local DNS (at least once you initially connect), maybe #2 should be the default? Or is there some risk in doing so?
- dylanh 7y ago
  If your OS doesn’t already detect the captive portal, Firefox will.
  - dmix 7y ago
    Perfect
mooman219 7y ago
If I sit any family member down in front of this comment, their eyes would glaze over. Not only is what you mention a PITA, it's impossible for most people.
- ignoramous 7y ago
  AFAIK, when one turns on DoH, Firefox's trr.mode defaults to 2. And that's the default behaviour most would want except for the ones using pi-hole et al.
  - vetinari 7y ago
    Not sure about that; it will still send query to the open Internet first and only when it fails, it will query local resolver. You have leaking internal hostnames there. To be fair, it is difficult to make all parties satisfied there. I think that a bit more honesty during discussion would help.
  - bscphil 7y ago
    In general, yes, that solves the problem for local domains. But anyone who needs to do anything at all complicated is going to have trouble with this, not just Pi-Hole users. For example, take your average John Doe who uses Firefox. Not particularly technically competent. A new version of Firefox comes out, and all the Archive.is domains break. Who does he blame for that, and how does he solve the problem? What's happening behind the scenes is that Firefox switched his DNS address on him without warning. And Cloudflare (the DNS endpoint used by Firefox by default) returns incorrect IP addresses for the Archive.is domains (because the admin of these domains returns fake addresses to Cloudflare from their authoritative DNS server). Most people are using DNS provided by their ISP, so they haven't seen this problem before. I know about the problem, and my resolver (Unbound) is set to use Cloudflare over TLS for most requests, but sends Archive.is domains to Google's DNS instead. This solves the problem for me. Firefox switching to Cloudflare by default not only breaks sites like this for the average user, it even breaks my workaround that fixes the problem. (I can't currently reproduce the problem, so maybe Archive.is caved and started sending working IP addresses. But it's the sort of problem that can happen when you start messing around with DNS. Your users will blame you if a site doesn't load in your browser, but works in other ones.)
    - mrpopo 7y ago
      > the admin of these domains returns fake addresses to Cloudflare from their authoritative DNS server Why?

Polylactic_acid 7y ago

Firefox has no issues with local domains and DoH. It makes a DoH request first and when that returns nothing it tries regular DNS.

teknopaul 7y ago
That is an issue. Apart from the wait. Spaff hostnames to cloudflare, fail, then try harder. Users expect hosts: files,dns Admins expect dns to work. FireFox should not be fscking with network config. If they do, they should try not to break users first. Firefox is borken. Security is not improved. My DNS requests never leave the LAN.
- Polylactic_acid 7y ago
  Half of your comment doesn't make any sense but for the rest of it, its just incorrect. The change in firefox hasn't broken anything, security is certainly improved in combination with other efforts like encrypted SNI. And yes, your dns requests always leave your lan at least once. You can run your own DNS server locally but that dns server has to ask other servers for the data since it can't store a local copy of the entire dns system. A local dns server is just a cache but with a few users its likely not doing any more than your browser cache.
  - teknopaul 7y ago
    DoH breaks anything that is going on in your BIND or NSD server. It bypasses them, it has broken that. If it does DNS first, then if that fails does /etc/hosts, its broken that too. If I, or my company, or ISP has anything special in hosts or DNS, e.g. load balancing, name mapping, breaking facebook.com, things like that get bypassed. DoH over HTTPS is slower than a lookup to /etc/hosts, and probably slower than a lookup to a locally cached DNS resolver. Security is not improved by FireFox bypassing my network admins DNS rules. Most DNS queries do not go over the Internet, unless you have DoH or have set special DNS servers. My ISP provides IP access to the Internet and DNS, like almost all ISPs. It not to do with local caching (which does add security), if I query foo.com that query goes to my ISP, not via the Internet, my ISP knows I asked for foo.com and then then the routes my IP packets there. My ISP has to lookup DNS on the Internet to resolve them if it is not in caches but that lookup is not associated to me. When I connect to a corporate network all my DNS goes over VPN if any information is required from the Internet again that is not associated to me. Cloudflare might be running a more secure DNS resolver at the other end than my ISP, but it might not, its rules have to apply to the whole world so they cannot be tuned for me and my security preferences. After DoH, all DNS goes over the Internet, even quires that eventually are resolved locally. Cloudflare now know I'm going to foo.com and so does my ISP, or VPN provider, I don't see how security has improved. Its just sending information to a commercial partner of Mozilla's in addition to my ISP. Some informationits getting that before my ISP did not get. Plus HTTPS is not infallible. DoH is more secure than DNS in plain text over the Internet, but that is very rarely the case. DNS is also not a significant risk to browser users. I have never had a DNS response faked, to any HTTPS site it would not work, so why bother. There isn't much risk, its not more secure, and it breaks stuff.

all_blue_chucks 7y ago

Opportunistic security that can be disabled by attackers is not really security.