22 ms·

DNS-over-HTTPS Policy Requirements for Resolvers

140 points by jvehent 7y ago

EvanAnderson 7y ago
I hadn't been paying much attention to DNS-over-HTTPS, but I recently listened to a talk that Dr. Paul Vixie (of BIND fame) gave that where DNS-over-HTTPS was discussed: https://youtu.be/OxFFTxJv1L4?t=2799 https://youtu.be/OxFFTxJv1L4?t=2799 After hearing Dr. Vixie discuss DNS-over-HTTPS from a network operator perspective I'm a lot more wary of the protocol.
- josteink 7y ago
  After seeing every implementation of DoH giving a flying fuck about your actual network settings, I’ve decided it’s a technology I want nothing to do with. I’ve actually actively blocked DoH for the major providers on my router, by writing some custom iptables rules. Hopefully there will be a simple to use OpenWrt-package which you can install to do this automatically in the future.
  - mike-cardwell 7y ago
    Could you share those iptables rules please?
    - topranks 7y ago
      The real difficulty as time goes on is to update the list.
    - josteink 7y ago
      I'll have to correct myself. It seems I gave up on the iptables-approach due to having some correctness errors. Instead I ended up with these lines in /etc/config/firewall: config rule option target 'ACCEPT' option name 'Allow router to perform DNS' option family 'ipv4' option src_ip '192.168.1.1' option dest_port '53' option src '*' option dest '*' config rule option src 'lan' option name 'Disallow Google DNS from LAN' option family 'ipv4' option dest_ip '8.8.8.8' option target 'REJECT' option dest 'wan' config rule option src 'lan' option name 'Disallow Google DNS from LAN (2)' option dest 'wan' option family 'ipv4' option dest_ip '8.8.4.4' option target 'REJECT' config rule option src 'lan' option name 'Disallow Cloudflare DOH from LAN' option dest_ip '1.1.1.1' option dest_port '443' option target 'REJECT' option proto 'tcp' option family 'ipv4' option dest 'wan' config rule option src 'lan' option name 'Disallow Cloudflare DOH from LAN (2)' option proto 'tcp' option dest 'wan' option dest_ip '1.0.0.1' option dest_port '443' option family 'ipv4' option target 'REJECT' config rule option src 'lan' option name 'Disallow Cloudflare DOH from LAN (3)' option dest_ip '104.16.249.249' option family 'ipv4' option dest 'wan' option target 'REJECT' Pretty much as basic as you'd think. Router itself acts as a DNS-server via dnsmasq, and is allowed to do anything I decide I want. On my network I have a pi-hole instance which then forwards queries to the router, so it also intercepts/looks up local LAN names correctly. All clients on the network are provided the pi-hole as the canonical DNS-server to use via DHCP options. Works for me.
- flarex 7y ago
  His main argument seems to be that the network operator should have control over DNS requests for safety reasons. Control and monitoring. This is the antithesis of privacy and encryption. I wouldn't be surprised if he was pro http over https either.
  - DaniloDias 7y ago
    If an iot device in your home network is exfiltraring data about you, it becomes much harder to identify with dns over https. Dns over https creates more problems than it solves for 99% of end users.
    - flarex 7y ago
      The argument that because encryption can be used for nefarious purposes it should not be offered by DNS providers at all does not add up. ISPs can block, redirect and sell DNS traffic and many are already doing some or all of these.
      - JohnFen 7y ago
        I don't think anybody is arguing that DNS lookups shouldn't be encrypted. The issue is doing DNS lookups via HTTPS.
        DaniloDias 7y ago
        I’m specifically arguing that dns lookups should not be encrypted. Dns can be descriptive: ntp.example.com sounds like an Ntp server. Oh- this pcap shows an ntp flow afterwards. Probably synchronizing time. Oh- adnetwork.example.com. Probably serving up ads. Oh Agrrvxdrgkndzzzvbbhydsxxjjj.net.org.com. Probably botnet related. Vs I need to look at every protocol flow and sort by IP? Who in their right mind blindly trusts all computers like this? If you ever want to troubleshoot your network, your job becomes way more tedious if dns requests are encrypted.
  - cremp 7y ago
    Because they should! Think a corporate network. If I as a sysadmin set our DHCP options to give out our own resolvers, I expect that every machine on the domain to use ours. DoH breaks that completely; and hence the network operator should have the final say. As a sysadmin myself, if browsers are overriding the basic model of top down, and it hurts me, because when something is wrong, I cant just look on my machine, I have to check which browser they use... that is the antithesis of the problem, because when DoH doesn't work but normal DNS does, then I'm flat out of options. This is why I choose not to use Firefox or any of the DoH mainline providers (Cloudflare,) and I go out of my way to make sure users cant do it.
- move-on-by 7y ago
  Without a doubt, DNS-over-HTTPS introduces some major concerns from a network operator and security perspective. But I'm also very privacy focused, and am conflicted on the issue. >[Mozilla] believe that they need to build technology that will accommodate a hostile network operator who is going to replace your DNS with things pointing to their advertising servers or is going to monitor what you do and send it off to some human rights violation team somewhere and so rather than tell you to use VPNs or tell you to use tor they decided to build DNS into the web Requiring the average Joe to use a VPN service just so they can have some reasonable attempt at privacy isn't really an option, as we have seen. Privacy shouldn't be a luxury reserved only for those who can afford it. What I would really like to see is our lawmakers step up and make modern privacy laws with respect to technology and the data that results of it, but that clearly isn't happening. Unfortunately, DNS-over-HTTPS will very likely be used against the consumer in the long-run. Instead of using a pi-hole with port 53 blocked, I can see many devices will start using DNS-over-HTTPS to bypass those restrictions. Chromecast, rokus, and other devices already have hard-coded DNS addresses built-in, it won't be a very large step for them to switch to DNS-over-HTTPS to bypass my own network policies.
  - roca 7y ago
    The thing is, those devices are going to do that even if Mozilla drops DoH, the RFCs are burned and everyone responsible shot. So the options are: * Make DoH illegal somehow * Take advantage of it as best we can
- majke 7y ago
  (full disclosure: I'm affiliated to Cloudflare, but opinions here are my own of course) Thanks for posting this. I knew Paul is against DoH, but never understood his specific arguments. He has great comment about DoT (dns over TLS) couple of minutes before the linked youtube (I agree with him on that). Personally I'm not an "owner" of the networks I'm connecting to. My home router is managed by my ISP, I don't run pi-hole. Network at work is managed by yet-someone-else. I often use my mobile carrier (LTE tethering), and often use WiFi at coffee shops. For all of these cases I would prefer to not expose my DNS traffic. Heck, I'm 100% sure that my dns traffic today is being re-sold! I have couple of unique domain names that I have open in my browser which have unique and non-guessable DNS names, which are crawled by some bots today. Even though I never shared them in any way with anyone! The only way they could be exposed for crawling is by my DNS provider leaking the DNS traffic to some shady third-party. Many DNS people are opposed DoH, but I think this train has passed. As a user of the internet I really do want encrypt everything these days. https://tools.ietf.org/html/rfc8404 https://tools.ietf.org/html/rfc8404 If my corporate boss, or my ISP can mine less data about the malware I'm running - so be it. For me this is an acceptable cost of measurably improved privacy.
  - zzzcpan 7y ago
    Your ISP doesn't really need DNS traffic to know things about you, IP addresses alone leak a lot of information, add to that SNI, response sizes, active probing, clear text traffic, etc. and you should realize that the only thing DoH does is letting one extra party to know what you are doing in addition to your ISP. DoH is net negative for privacy. You need at least a VPN to get to net positive, so that your ISP can't get that much data.
    - wbl 7y ago
      How is DoH a net negative? ESNI is coming soon. Also ISPs do all sorts of other badness with DNS like NXDOMAIN interception.
      - zzzcpan 7y ago
        If you can't trust your ISP, leaking all of your DNS traffic to another party still doesn't let you trust your ISP, but now you have to trust that other party too, hence net negative. To avoid trusting your ISP you need at least a VPN.
localhostdotdev 7y ago
pretty cool, I wished chrome did that. firefox is probably going to choose cloudflare (1.1.1.1). I wonder how this plays out with local DNS (e.g. my ISP has some custom domains for me to use, and internal company network addresses)
- afiori 7y ago
  You can set firefox to use the normal DNS as a fallback
  - teddyh 7y ago
    One could reasonably wonder why “normal” should be a fallback.
    - afiori 7y ago
      I have two reason to like DoH: public wifi blocking sites and ISPs blocking sites. I understand that it is "wrong" from the perspective of a network stack, but for my use case that is far from being even a weak issue.
    - gpm 7y ago
      Because "normal" = "insecure and not private"? "Legacy" might be a better name for it in the near future.
AnaniasAnanas 7y ago
Still no explanation on why dns-over-https rather than the already widespread dnscrypt or the lesser known dnscurve, dns-over-quic, and dns-over-tor.
- hannob 7y ago
  DoH has already more adoption than all previous approaches combined. (Note: I don't think DNS-over-QUIC is really any different from DoH. QUIC is just another way of transmitting HTTPS, so you can just do DoH over QUIC.)
  - AnaniasAnanas 7y ago
    > DoH has already more adoption than all previous approaches combined Are you sure? My experience so far has shown that only dnscrypt is widely supported. Nevertheless, surely they must had some kind of issue with the existing solutions when they started working on it. As for DNS over QUIC, I was under the impression that said solution did not make use of HTTP.
    - judge2020 7y ago
      > As for DNS over QUIC, I was under the impression that said solution did not make use of HTTP. I believe it's possible to do both direct DNS over QUIC and ((DNS over HTTPS) over QUIC).
    - darkhorn 7y ago
      Android 9 has build in DoH support. https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html?m=1 https://android-developers.googleblog.com/2018/04/dns-over-t...
- pas 7y ago
  DNScrypt is easy to block, therefore it can't further the privacy-for-all cause.
  - 7y ago
slim 7y ago
tl;dr Firefox will ignore your DNS settings and use his own (DoH)
- bzbarsky 7y ago
  Nothing in the article says anything about that. The article talks about Firefox behavior when DoH is enabled. It's not enabled by default. The article doesn't say it's getting enabled by default, or under what conditions it might get enabled by default.
  - JohnFen 7y ago
    At the very start of the linked article, it says this: "Over the past few months, we’ve been experimenting with DNS-over-HTTPS (DoH), a protocol which uses encryption to protect DNS requests and responses, with the goal of deploying DoH by default for our users."
    - bzbarsky 7y ago
      That's correct, but the requirements that need to be met for it to be enabled by default are still being determined.
  - topranks 7y ago
    They have already stated they will be switching it on by default: https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZiU91v6hLw https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZ... “4. The user will be informed that we have enabled use of a TRR and have the opportunity to turn it off at that time, but will not be required to opt-in to get DoH with a TRR.”
    - bzbarsky 7y ago
      Yes, I'm aware. Again, the conditions that need to be met for this to happen are still being determined, including the timeframe and the exact behavior.
nykolasz 7y ago
Glad that they allowed resolvers that filter content based on the user request in there. So good news that Quad9 and CleanBrowsing will be able to make the list.
nykolasz 7y ago
I replied sub-thread, but adding here to give some more visibility to some of the issues DoH is causing and will cause: I work at a k12 school and I am involved on many k12 IT communities. Some schools already removed Firefox from the students computers because it was being used as a "VPN" by some elementary students to access porn - at school. Guess what this VPN was? Just DNS over HTTPS. There is a fine line between protecting yourself from your ISP and local network operators that NEED to apply some security policies to their traffic. Even Google offers "Safe Search" for schools and libraries that removes porn content. Unfortunately, on our school network, we also allow BYOD (students with their own laptops and ipads), so we will have to have some strict rules to block DoH, the same way we block proxies and vpns. The only other option is going to full HTTPS MITM, forcing a root SSL cert to all computers that use our network, which is the last thing that anyone wants to do. Summary: This may lead to more HTTPS MITM or schools forbidding BYOD AND removing Firefox from their computers.
- threatofrain 7y ago
  Ultimately we cannot secure content without being able to look at it (encryption is the problem). We need to be able to look at what the kids are looking at if we want to control what information gets to them. DNS is a band-aid solution with side effects.
  - nykolasz 7y ago
    Band-aid solution that worked pretty well. Very cheap to implement, widely supported and used by many schools. Our student's data was still private (no emails or passwords being decrypted) and we did the filtering only based on the domain name. It also didn't require an expensive appliance that would be need if did the filtering based on SNI.
    - rndgermandude 7y ago
      A student who really wants to see "the bad" on the internet isn't scared off by blocking some DNS/VPN/proxy traffic. This is wishful thinking. The easiest work-around for students who want to show their mates some "cool porn" is to just save it at home. Or connect to the free wifi of <random shop> in reach.
zelly 7y ago
No data collection? Watch 8.8.8.8, 1.1.1.1, etc. suddenly end their services.
- ionised 7y ago
  I'm totally supportive of that.
subwindow 7y ago
This has negative implications for security. For instance, one reason why DNS resolvers might block or modify requests is to blacklist domains used for malware operation (botnet C&C domains). Other things like DNS sinkholing and poisoning are also frequently used as tools to disrupt malware communication. In addition, collection and analysis of below-the-recursive DNS traffic is one of the primary ways in which security researchers discover the infrastructure of botnet networks. Overall DoH is probably a net positive, but I don't see downsides like this being discussed.
- judge2020 7y ago
  You can currently customize the trr address in firefox, so assuming you trust a network box's single HTTPS certificate, it can also run a DoH server.
- darkhorn 7y ago
  > This has negative implications for security. Yeah, Erdoğan won't be able to block oppositions' web sites. That is a very big threat! /s
3xblah 7y ago
"To that end, today we are releasing a list of DOH requirements, available on the Mozilla wiki, that we will use to vet potential resolvers for Firefox. The requirements focus on three areas: 1) limiting data collection and retention from the resolver, 2) ensuring transparency for any data retention that does occur, and 3) limiting any potential use of the resolver to block access or modify content." I sometimes use a local resolver bound to localhost that blocks ads by pointing to a custom root. If someone aiming to be on the TRR list sets up a remote resolver that blocks ads (or replaces them with blank images) perhaps using the same technique, it could allow Firefox users to get ad blocking by default, by using DOH. I wonder if that would violate Mozilla's requirements? Are ads considered "content"? There is of course precedent for blocking undesirable content via DNS as a "service". Third party DNS service, for example the famous one that starts with "O", has been used to block certain content, e,g, at schools. This was offered as a fee-based service. If I remember correctly they also offered "free" service which was subject to redirection of NXDOMAIN to paid placement "search" results/ads.
- tlrobinson 7y ago
  This is talking about requirements for resolvers that will be included by default: We have implemented DNS over HTTPS [RFC8484] and would like to deploy it by default for our users. We intend to select a set of Trusted Recursive Resolvers (TRRs) that we will use for DoH resolution. https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZiU91v6hLw https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZ... Presumably you can still configure your machine to use whichever resolver(s) you want.
- kodablah 7y ago
  > I wonder if that would violate Mozilla's requirements? The real question is if you're allowed to use your own resolver that conforms to your requirements if they differ from Mozilla's, even if a bit buried from the default list,
- topranks 7y ago
  I’d be fairly certain this would be against Mozilla’s requirements.
kodablah 7y ago
> Our plan is to select a set of Trusted Recursive Resolvers (TRRs) that we will use for DoH resolution in Firefox. Those resolvers will be required to conform to a specific set of policies that put privacy first. So can I manually set one myself to my local pi-hole instance? I have already been setting the TRR about:config values (ala [0]), will that remain? I am wary of Mozilla becoming the arbiter of acceptable DNS providers for me, so I should be able to override it if I want. 0 - https://blog.stackpath.com/serverless-dns-over-https-at-the-edge-doh https://blog.stackpath.com/serverless-dns-over-https-at-the-...
- foobarbazetc 7y ago
  Think of this more like which CA roots browsers include by default instead of a nefarious plan to stop you from doing whatever you want.
  - EvanAnderson 7y ago
    It's not a nefarious plan to stop me from doing what I want in a FOSS browser on a PC where I can compile and run what I want. It will be used that way, however, on locked-down devices users pay for but don't actually own.
    - shawnz 7y ago
      Then don't buy such a device which clearly doesn't meet your needs. Why should every personal computing device on the planet be tailored to your requirements, at the cost of safety for the majority of other users? Most people don't use PiHole, they use Adblock or uBlock which are not affected by this. It's not as though they are taking away your ability to use adblocking technology.
      - EvanAnderson 7y ago
        Macro-level view: The Mozilla Foundation may think that DNS-over-HTTPS is about "safety", but they're unwittingly furthering the agenda of those who would profit from the Internet not being decentralized. A decentralized Internet filled with devices that end users can control, should they choose, is a good thing for society, I'd argue. DNS-over-HTTPS is another piece of technology that can be used to eliminate that. It is not necessary to hand over freedom in exchange for "safety" or "security". Micro-level view: I'm a sysadmin for my Customers, my family, and some of my friends. Inevitably I will have to deal with these awful devices. So will countless other sysadmins. I'm dreading having to deal with devices that invade my users' privacy, thwart my attempts at detecting bad actors on the network, and that just generally act like the person who paid for them doesn't actually own them.
bluejekyll 7y ago
I’ve begun to think that differences of opinion on the benefits and/or negatives of DoH come from two different perspectives on what DNS is for. What I perceive from the debate is generally that people who dislike DoH tend to perceive it as a network plane protocol, one that is designed for network operations and nothing more (layer 3/4 if you will). Whereas people who tend to want privacy and the other features of DoH, perceive it as an application level concern (layer 7). In this context connectivity and discoverability of services is the aim, and knowing that the information for establishing connections to those services is correct is important to the foundations and guarantees of applications being built to utilize DNS. In the application and services context, you may not even want a single set of recursive resolves or authorities for the system. And the reasons are to help ensure the data is focused on what you need in different contexts. I believe that the network level concerns over DoH are a little disingenuous, and this is because there are many ways to circumvent DNS, DoH isn’t necessary, you don’t even need DNS to establish layer3/4 connections. Fighting over DoH for security that can’t truly be enforced in DNS, seems misguided.
- tlrobinson 7y ago
  I can think of 3 main use-cases for DNS blocking on a network level: 1. content policies: blocking porn, censorship, etc (already easily circumvented by changing DNS or using a VPN) 2. preventing malware command and control: blocking domains that malware phones home to (already easily circumvented by including their own resolver, etc) 3. preventing malware infection: blocking domains serving malware (you might lump "ads" in this category too, e.x. Pi-hole) IMHO the 3rd is the only use-case worth trying to solve with DNS blocking, because the user isn't actively trying to circumvent it. Applications using their own resolvers do make that difficult to do. It seems like it would be best if operating systems implemented DoH at the system level, including DHCP support, so devices could use the network's DoH resolver which might do malware blocking. Applications like Firefox could fall back to their own DoH resolver if they had a way to detect the system was not using DoH. This would also encourage network operators to support DoH.
  - bluejekyll 7y ago
    3 is reasonable. I think you stated that well, "the user isn't actively trying to circumvent it", though I might expand that to include the application isn't actively trying to circumvent it. For passive mitigation of standard browsing as a means of helping protect yourself, yes, but even there, it won't take long for systems to figure out a way to circumvent that.
rmdoss 7y ago
Note that with DoH on Firefox, your intranet domains do not work. Had issues with it before and had to disable DoH just to access our company printer. Also causes issues with DC. That goes into the argument that DNS (domain name lookup) should be a system and network-level setting, not an App-based setting.
- MayeulC 7y ago
  That's not entierely true. If the domain doesn't resolve via DoH, Firefox will fallback to the system DNS server. network.trr.mode Needs to be set to 2 (fallback), 1 (pick faster), or 0 (dissable DoH) for this to happen. 3 disables the system resolver.
  - protomyth 7y ago
    So, the internal domain names leak to Mozilla unless I disable this totally?
    - cpeterso 7y ago
      Not to Mozilla, but to whichever DoH service Firefox is configured to use, by default or by the user. Mozilla isn't running a DoH service.
      - protomyth 7y ago
        What is the default?
        moosingin3space 7y ago
        Cloudflare 1.1.1.1 is the default.
        protomyth 7y ago
        So, when the user types in internal.mydomain.com, it gets sent to Cloudflare then they query my public domain server which doesn't have the entry so it falls back to checking the DNS the system has listed. Is Firefox going to cache the IP like the OS does?
tptacek 7y ago
Notice something they're not requiring? Mozilla will trust resolvers that don't check DNSSEC. Stick a fork in DNSSEC.
lazylizard 7y ago
I hope it can respect nsswitch?
LinuxBender 7y ago
Has anyone started contributing lists of all the public DoH resolvers on any of the block-lists? e.g. [1] [2] [1] - https://iplists.firehol.org/ https://iplists.firehol.org/ [2] - https://github.com/firehol/blocklist-ipsets https://github.com/firehol/blocklist-ipsets
- topranks 7y ago
  Someone has a list here: https://github.com/curl/curl/wiki/DNS-over-HTTPS https://github.com/curl/curl/wiki/DNS-over-HTTPS
protomyth 7y ago
What is the justification for an app to resolve domain names differently than the services the operating system provides? I am really curious why this is a thing.
- darkhorn 7y ago
  Windows doesn't provide privacy when it comes to DNS queries. It still uses old fashion, plain text DNS. Firefox is trying to protect its users from prying eyes.
  - protomyth 7y ago
    Then complain to Microsoft, ship VPN software like Cloud Flare, and quit doing things in the browser that aren't browsing. This attitude that "I can suck functions into the browser" that do not take into account all the scenarios that OS vendors already have to deal with is a pain in the butt.
kylek 7y ago
(It's been a long time since I've actually set up a DNS server and am pretty fuzzy on some details - so I'm going to state this like a real nooby to hopefully get an ELI5 answer) If I were to set up my own DoH server, would its queries to upstream (root??) servers (and subsequent recursed servers) be encrypted? (Simpler: does running a DNS server "on-premise", or even in the cloud, actually protect you from anything?)
- topranks 7y ago
  No, DoH only deals with client to resolver encryption. Recursive lookups from the resolver to authoritative DNS servers from the root down are not encrypted. Really what you are doing is switching between telling your ISP all the domains you look up to telling Google/Cloudflare. Except your ISP can still see SNIs so you’re really just telling Google/Cloudflare in addition to your ISP.
  - kylek 7y ago
    Seems all for not :| I don't suppose there are any proposals to replace how SNIs are transmitted? (sans-vpn/tor, that is) Does QUIC/HTTP[23] do anything different?
darkhorn 7y ago
Also you can encrypt SNI in Firefox, just enable network.security.esni.enabled https://blog.cloudflare.com/encrypt-that-sni-firefox-edition/ https://blog.cloudflare.com/encrypt-that-sni-firefox-edition...

140 points by jvehent 7y ago

I hadn't been paying much attention to DNS-over-HTTPS, but I recently listened to a talk that Dr. Paul Vixie (of BIND fame) gave that where DNS-over-HTTPS was discussed: https://youtu.be/OxFFTxJv1L4?t=2799 https://youtu.be/OxFFTxJv1L4?t=2799 After hearing Dr. Vixie discuss DNS-over-HTTPS from a network operator perspective I'm a lot more wary of the protocol.

josteink 7y ago
After seeing every implementation of DoH giving a flying fuck about your actual network settings, I’ve decided it’s a technology I want nothing to do with. I’ve actually actively blocked DoH for the major providers on my router, by writing some custom iptables rules. Hopefully there will be a simple to use OpenWrt-package which you can install to do this automatically in the future.
- mike-cardwell 7y ago
  Could you share those iptables rules please?
  - topranks 7y ago
    The real difficulty as time goes on is to update the list.
  - josteink 7y ago
    I'll have to correct myself. It seems I gave up on the iptables-approach due to having some correctness errors. Instead I ended up with these lines in /etc/config/firewall: config rule option target 'ACCEPT' option name 'Allow router to perform DNS' option family 'ipv4' option src_ip '192.168.1.1' option dest_port '53' option src '*' option dest '*' config rule option src 'lan' option name 'Disallow Google DNS from LAN' option family 'ipv4' option dest_ip '8.8.8.8' option target 'REJECT' option dest 'wan' config rule option src 'lan' option name 'Disallow Google DNS from LAN (2)' option dest 'wan' option family 'ipv4' option dest_ip '8.8.4.4' option target 'REJECT' config rule option src 'lan' option name 'Disallow Cloudflare DOH from LAN' option dest_ip '1.1.1.1' option dest_port '443' option target 'REJECT' option proto 'tcp' option family 'ipv4' option dest 'wan' config rule option src 'lan' option name 'Disallow Cloudflare DOH from LAN (2)' option proto 'tcp' option dest 'wan' option dest_ip '1.0.0.1' option dest_port '443' option family 'ipv4' option target 'REJECT' config rule option src 'lan' option name 'Disallow Cloudflare DOH from LAN (3)' option dest_ip '104.16.249.249' option family 'ipv4' option dest 'wan' option target 'REJECT' Pretty much as basic as you'd think. Router itself acts as a DNS-server via dnsmasq, and is allowed to do anything I decide I want. On my network I have a pi-hole instance which then forwards queries to the router, so it also intercepts/looks up local LAN names correctly. All clients on the network are provided the pi-hole as the canonical DNS-server to use via DHCP options. Works for me.
flarex 7y ago
His main argument seems to be that the network operator should have control over DNS requests for safety reasons. Control and monitoring. This is the antithesis of privacy and encryption. I wouldn't be surprised if he was pro http over https either.
- DaniloDias 7y ago
  If an iot device in your home network is exfiltraring data about you, it becomes much harder to identify with dns over https. Dns over https creates more problems than it solves for 99% of end users.
  - flarex 7y ago
    The argument that because encryption can be used for nefarious purposes it should not be offered by DNS providers at all does not add up. ISPs can block, redirect and sell DNS traffic and many are already doing some or all of these.
    - JohnFen 7y ago
      I don't think anybody is arguing that DNS lookups shouldn't be encrypted. The issue is doing DNS lookups via HTTPS.
      - DaniloDias 7y ago
        I’m specifically arguing that dns lookups should not be encrypted. Dns can be descriptive: ntp.example.com sounds like an Ntp server. Oh- this pcap shows an ntp flow afterwards. Probably synchronizing time. Oh- adnetwork.example.com. Probably serving up ads. Oh Agrrvxdrgkndzzzvbbhydsxxjjj.net.org.com. Probably botnet related. Vs I need to look at every protocol flow and sort by IP? Who in their right mind blindly trusts all computers like this? If you ever want to troubleshoot your network, your job becomes way more tedious if dns requests are encrypted.
- cremp 7y ago
  Because they should! Think a corporate network. If I as a sysadmin set our DHCP options to give out our own resolvers, I expect that every machine on the domain to use ours. DoH breaks that completely; and hence the network operator should have the final say. As a sysadmin myself, if browsers are overriding the basic model of top down, and it hurts me, because when something is wrong, I cant just look on my machine, I have to check which browser they use... that is the antithesis of the problem, because when DoH doesn't work but normal DNS does, then I'm flat out of options. This is why I choose not to use Firefox or any of the DoH mainline providers (Cloudflare,) and I go out of my way to make sure users cant do it.
move-on-by 7y ago
Without a doubt, DNS-over-HTTPS introduces some major concerns from a network operator and security perspective. But I'm also very privacy focused, and am conflicted on the issue. >[Mozilla] believe that they need to build technology that will accommodate a hostile network operator who is going to replace your DNS with things pointing to their advertising servers or is going to monitor what you do and send it off to some human rights violation team somewhere and so rather than tell you to use VPNs or tell you to use tor they decided to build DNS into the web Requiring the average Joe to use a VPN service just so they can have some reasonable attempt at privacy isn't really an option, as we have seen. Privacy shouldn't be a luxury reserved only for those who can afford it. What I would really like to see is our lawmakers step up and make modern privacy laws with respect to technology and the data that results of it, but that clearly isn't happening. Unfortunately, DNS-over-HTTPS will very likely be used against the consumer in the long-run. Instead of using a pi-hole with port 53 blocked, I can see many devices will start using DNS-over-HTTPS to bypass those restrictions. Chromecast, rokus, and other devices already have hard-coded DNS addresses built-in, it won't be a very large step for them to switch to DNS-over-HTTPS to bypass my own network policies.
- roca 7y ago
  The thing is, those devices are going to do that even if Mozilla drops DoH, the RFCs are burned and everyone responsible shot. So the options are: * Make DoH illegal somehow * Take advantage of it as best we can
majke 7y ago
(full disclosure: I'm affiliated to Cloudflare, but opinions here are my own of course) Thanks for posting this. I knew Paul is against DoH, but never understood his specific arguments. He has great comment about DoT (dns over TLS) couple of minutes before the linked youtube (I agree with him on that). Personally I'm not an "owner" of the networks I'm connecting to. My home router is managed by my ISP, I don't run pi-hole. Network at work is managed by yet-someone-else. I often use my mobile carrier (LTE tethering), and often use WiFi at coffee shops. For all of these cases I would prefer to not expose my DNS traffic. Heck, I'm 100% sure that my dns traffic today is being re-sold! I have couple of unique domain names that I have open in my browser which have unique and non-guessable DNS names, which are crawled by some bots today. Even though I never shared them in any way with anyone! The only way they could be exposed for crawling is by my DNS provider leaking the DNS traffic to some shady third-party. Many DNS people are opposed DoH, but I think this train has passed. As a user of the internet I really do want encrypt everything these days. https://tools.ietf.org/html/rfc8404 https://tools.ietf.org/html/rfc8404 If my corporate boss, or my ISP can mine less data about the malware I'm running - so be it. For me this is an acceptable cost of measurably improved privacy.
- zzzcpan 7y ago
  Your ISP doesn't really need DNS traffic to know things about you, IP addresses alone leak a lot of information, add to that SNI, response sizes, active probing, clear text traffic, etc. and you should realize that the only thing DoH does is letting one extra party to know what you are doing in addition to your ISP. DoH is net negative for privacy. You need at least a VPN to get to net positive, so that your ISP can't get that much data.
  - wbl 7y ago
    How is DoH a net negative? ESNI is coming soon. Also ISPs do all sorts of other badness with DNS like NXDOMAIN interception.
    - zzzcpan 7y ago
      If you can't trust your ISP, leaking all of your DNS traffic to another party still doesn't let you trust your ISP, but now you have to trust that other party too, hence net negative. To avoid trusting your ISP you need at least a VPN.

localhostdotdev 7y ago

pretty cool, I wished chrome did that. firefox is probably going to choose cloudflare (1.1.1.1). I wonder how this plays out with local DNS (e.g. my ISP has some custom domains for me to use, and internal company network addresses)

afiori 7y ago
You can set firefox to use the normal DNS as a fallback
- teddyh 7y ago
  One could reasonably wonder why “normal” should be a fallback.
  - afiori 7y ago
    I have two reason to like DoH: public wifi blocking sites and ISPs blocking sites. I understand that it is "wrong" from the perspective of a network stack, but for my use case that is far from being even a weak issue.
  - gpm 7y ago
    Because "normal" = "insecure and not private"? "Legacy" might be a better name for it in the near future.

AnaniasAnanas 7y ago

Still no explanation on why dns-over-https rather than the already widespread dnscrypt or the lesser known dnscurve, dns-over-quic, and dns-over-tor.

hannob 7y ago
DoH has already more adoption than all previous approaches combined. (Note: I don't think DNS-over-QUIC is really any different from DoH. QUIC is just another way of transmitting HTTPS, so you can just do DoH over QUIC.)
- AnaniasAnanas 7y ago
  > DoH has already more adoption than all previous approaches combined Are you sure? My experience so far has shown that only dnscrypt is widely supported. Nevertheless, surely they must had some kind of issue with the existing solutions when they started working on it. As for DNS over QUIC, I was under the impression that said solution did not make use of HTTP.
  - judge2020 7y ago
    > As for DNS over QUIC, I was under the impression that said solution did not make use of HTTP. I believe it's possible to do both direct DNS over QUIC and ((DNS over HTTPS) over QUIC).
  - darkhorn 7y ago
    Android 9 has build in DoH support. https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html?m=1 https://android-developers.googleblog.com/2018/04/dns-over-t...
pas 7y ago
DNScrypt is easy to block, therefore it can't further the privacy-for-all cause.
- 7y ago

slim 7y ago

tl;dr Firefox will ignore your DNS settings and use his own (DoH)

bzbarsky 7y ago
Nothing in the article says anything about that. The article talks about Firefox behavior when DoH is enabled. It's not enabled by default. The article doesn't say it's getting enabled by default, or under what conditions it might get enabled by default.
- JohnFen 7y ago
  At the very start of the linked article, it says this: "Over the past few months, we’ve been experimenting with DNS-over-HTTPS (DoH), a protocol which uses encryption to protect DNS requests and responses, with the goal of deploying DoH by default for our users."
  - bzbarsky 7y ago
    That's correct, but the requirements that need to be met for it to be enabled by default are still being determined.
- topranks 7y ago
  They have already stated they will be switching it on by default: https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZiU91v6hLw https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZ... “4. The user will be informed that we have enabled use of a TRR and have the opportunity to turn it off at that time, but will not be required to opt-in to get DoH with a TRR.”
  - bzbarsky 7y ago
    Yes, I'm aware. Again, the conditions that need to be met for this to happen are still being determined, including the timeframe and the exact behavior.

nykolasz 7y ago

Glad that they allowed resolvers that filter content based on the user request in there. So good news that Quad9 and CleanBrowsing will be able to make the list.

nykolasz 7y ago

I replied sub-thread, but adding here to give some more visibility to some of the issues DoH is causing and will cause: I work at a k12 school and I am involved on many k12 IT communities. Some schools already removed Firefox from the students computers because it was being used as a "VPN" by some elementary students to access porn - at school. Guess what this VPN was? Just DNS over HTTPS. There is a fine line between protecting yourself from your ISP and local network operators that NEED to apply some security policies to their traffic. Even Google offers "Safe Search" for schools and libraries that removes porn content. Unfortunately, on our school network, we also allow BYOD (students with their own laptops and ipads), so we will have to have some strict rules to block DoH, the same way we block proxies and vpns. The only other option is going to full HTTPS MITM, forcing a root SSL cert to all computers that use our network, which is the last thing that anyone wants to do. Summary: This may lead to more HTTPS MITM or schools forbidding BYOD AND removing Firefox from their computers.

threatofrain 7y ago
Ultimately we cannot secure content without being able to look at it (encryption is the problem). We need to be able to look at what the kids are looking at if we want to control what information gets to them. DNS is a band-aid solution with side effects.
- nykolasz 7y ago
  Band-aid solution that worked pretty well. Very cheap to implement, widely supported and used by many schools. Our student's data was still private (no emails or passwords being decrypted) and we did the filtering only based on the domain name. It also didn't require an expensive appliance that would be need if did the filtering based on SNI.
  - rndgermandude 7y ago
    A student who really wants to see "the bad" on the internet isn't scared off by blocking some DNS/VPN/proxy traffic. This is wishful thinking. The easiest work-around for students who want to show their mates some "cool porn" is to just save it at home. Or connect to the free wifi of <random shop> in reach.

zelly 7y ago

No data collection? Watch 8.8.8.8, 1.1.1.1, etc. suddenly end their services.

ionised 7y ago
I'm totally supportive of that.

subwindow 7y ago

This has negative implications for security. For instance, one reason why DNS resolvers might block or modify requests is to blacklist domains used for malware operation (botnet C&C domains). Other things like DNS sinkholing and poisoning are also frequently used as tools to disrupt malware communication. In addition, collection and analysis of below-the-recursive DNS traffic is one of the primary ways in which security researchers discover the infrastructure of botnet networks. Overall DoH is probably a net positive, but I don't see downsides like this being discussed.

judge2020 7y ago
You can currently customize the trr address in firefox, so assuming you trust a network box's single HTTPS certificate, it can also run a DoH server.
darkhorn 7y ago
> This has negative implications for security. Yeah, Erdoğan won't be able to block oppositions' web sites. That is a very big threat! /s

3xblah 7y ago

"To that end, today we are releasing a list of DOH requirements, available on the Mozilla wiki, that we will use to vet potential resolvers for Firefox. The requirements focus on three areas: 1) limiting data collection and retention from the resolver, 2) ensuring transparency for any data retention that does occur, and 3) limiting any potential use of the resolver to block access or modify content." I sometimes use a local resolver bound to localhost that blocks ads by pointing to a custom root. If someone aiming to be on the TRR list sets up a remote resolver that blocks ads (or replaces them with blank images) perhaps using the same technique, it could allow Firefox users to get ad blocking by default, by using DOH. I wonder if that would violate Mozilla's requirements? Are ads considered "content"? There is of course precedent for blocking undesirable content via DNS as a "service". Third party DNS service, for example the famous one that starts with "O", has been used to block certain content, e,g, at schools. This was offered as a fee-based service. If I remember correctly they also offered "free" service which was subject to redirection of NXDOMAIN to paid placement "search" results/ads.

tlrobinson 7y ago
This is talking about requirements for resolvers that will be included by default: We have implemented DNS over HTTPS [RFC8484] and would like to deploy it by default for our users. We intend to select a set of Trusted Recursive Resolvers (TRRs) that we will use for DoH resolution. https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZiU91v6hLw https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZ... Presumably you can still configure your machine to use whichever resolver(s) you want.
kodablah 7y ago
> I wonder if that would violate Mozilla's requirements? The real question is if you're allowed to use your own resolver that conforms to your requirements if they differ from Mozilla's, even if a bit buried from the default list,
topranks 7y ago
I’d be fairly certain this would be against Mozilla’s requirements.

kodablah 7y ago

> Our plan is to select a set of Trusted Recursive Resolvers (TRRs) that we will use for DoH resolution in Firefox. Those resolvers will be required to conform to a specific set of policies that put privacy first. So can I manually set one myself to my local pi-hole instance? I have already been setting the TRR about:config values (ala [0]), will that remain? I am wary of Mozilla becoming the arbiter of acceptable DNS providers for me, so I should be able to override it if I want. 0 - https://blog.stackpath.com/serverless-dns-over-https-at-the-edge-doh https://blog.stackpath.com/serverless-dns-over-https-at-the-...

foobarbazetc 7y ago
Think of this more like which CA roots browsers include by default instead of a nefarious plan to stop you from doing whatever you want.
- EvanAnderson 7y ago
  It's not a nefarious plan to stop me from doing what I want in a FOSS browser on a PC where I can compile and run what I want. It will be used that way, however, on locked-down devices users pay for but don't actually own.
  - shawnz 7y ago
    Then don't buy such a device which clearly doesn't meet your needs. Why should every personal computing device on the planet be tailored to your requirements, at the cost of safety for the majority of other users? Most people don't use PiHole, they use Adblock or uBlock which are not affected by this. It's not as though they are taking away your ability to use adblocking technology.
    - EvanAnderson 7y ago
      Macro-level view: The Mozilla Foundation may think that DNS-over-HTTPS is about "safety", but they're unwittingly furthering the agenda of those who would profit from the Internet not being decentralized. A decentralized Internet filled with devices that end users can control, should they choose, is a good thing for society, I'd argue. DNS-over-HTTPS is another piece of technology that can be used to eliminate that. It is not necessary to hand over freedom in exchange for "safety" or "security". Micro-level view: I'm a sysadmin for my Customers, my family, and some of my friends. Inevitably I will have to deal with these awful devices. So will countless other sysadmins. I'm dreading having to deal with devices that invade my users' privacy, thwart my attempts at detecting bad actors on the network, and that just generally act like the person who paid for them doesn't actually own them.

bluejekyll 7y ago

I’ve begun to think that differences of opinion on the benefits and/or negatives of DoH come from two different perspectives on what DNS is for. What I perceive from the debate is generally that people who dislike DoH tend to perceive it as a network plane protocol, one that is designed for network operations and nothing more (layer 3/4 if you will). Whereas people who tend to want privacy and the other features of DoH, perceive it as an application level concern (layer 7). In this context connectivity and discoverability of services is the aim, and knowing that the information for establishing connections to those services is correct is important to the foundations and guarantees of applications being built to utilize DNS. In the application and services context, you may not even want a single set of recursive resolves or authorities for the system. And the reasons are to help ensure the data is focused on what you need in different contexts. I believe that the network level concerns over DoH are a little disingenuous, and this is because there are many ways to circumvent DNS, DoH isn’t necessary, you don’t even need DNS to establish layer3/4 connections. Fighting over DoH for security that can’t truly be enforced in DNS, seems misguided.

tlrobinson 7y ago
I can think of 3 main use-cases for DNS blocking on a network level: 1. content policies: blocking porn, censorship, etc (already easily circumvented by changing DNS or using a VPN) 2. preventing malware command and control: blocking domains that malware phones home to (already easily circumvented by including their own resolver, etc) 3. preventing malware infection: blocking domains serving malware (you might lump "ads" in this category too, e.x. Pi-hole) IMHO the 3rd is the only use-case worth trying to solve with DNS blocking, because the user isn't actively trying to circumvent it. Applications using their own resolvers do make that difficult to do. It seems like it would be best if operating systems implemented DoH at the system level, including DHCP support, so devices could use the network's DoH resolver which might do malware blocking. Applications like Firefox could fall back to their own DoH resolver if they had a way to detect the system was not using DoH. This would also encourage network operators to support DoH.
- bluejekyll 7y ago
  3 is reasonable. I think you stated that well, "the user isn't actively trying to circumvent it", though I might expand that to include the application isn't actively trying to circumvent it. For passive mitigation of standard browsing as a means of helping protect yourself, yes, but even there, it won't take long for systems to figure out a way to circumvent that.

rmdoss 7y ago

Note that with DoH on Firefox, your intranet domains do not work. Had issues with it before and had to disable DoH just to access our company printer. Also causes issues with DC. That goes into the argument that DNS (domain name lookup) should be a system and network-level setting, not an App-based setting.

MayeulC 7y ago
That's not entierely true. If the domain doesn't resolve via DoH, Firefox will fallback to the system DNS server. network.trr.mode Needs to be set to 2 (fallback), 1 (pick faster), or 0 (dissable DoH) for this to happen. 3 disables the system resolver.
- protomyth 7y ago
  So, the internal domain names leak to Mozilla unless I disable this totally?
  - cpeterso 7y ago
    Not to Mozilla, but to whichever DoH service Firefox is configured to use, by default or by the user. Mozilla isn't running a DoH service.
    - protomyth 7y ago
      What is the default?
      - moosingin3space 7y ago
        Cloudflare 1.1.1.1 is the default.
        protomyth 7y ago
        So, when the user types in internal.mydomain.com, it gets sent to Cloudflare then they query my public domain server which doesn't have the entry so it falls back to checking the DNS the system has listed. Is Firefox going to cache the IP like the OS does?

tptacek 7y ago

Notice something they're not requiring? Mozilla will trust resolvers that don't check DNSSEC. Stick a fork in DNSSEC.

lazylizard 7y ago

I hope it can respect nsswitch?

LinuxBender 7y ago

Has anyone started contributing lists of all the public DoH resolvers on any of the block-lists? e.g. [1] [2] [1] - https://iplists.firehol.org/ https://iplists.firehol.org/ [2] - https://github.com/firehol/blocklist-ipsets https://github.com/firehol/blocklist-ipsets

topranks 7y ago
Someone has a list here: https://github.com/curl/curl/wiki/DNS-over-HTTPS https://github.com/curl/curl/wiki/DNS-over-HTTPS

protomyth 7y ago

What is the justification for an app to resolve domain names differently than the services the operating system provides? I am really curious why this is a thing.

darkhorn 7y ago
Windows doesn't provide privacy when it comes to DNS queries. It still uses old fashion, plain text DNS. Firefox is trying to protect its users from prying eyes.
- protomyth 7y ago
  Then complain to Microsoft, ship VPN software like Cloud Flare, and quit doing things in the browser that aren't browsing. This attitude that "I can suck functions into the browser" that do not take into account all the scenarios that OS vendors already have to deal with is a pain in the butt.

kylek 7y ago

(It's been a long time since I've actually set up a DNS server and am pretty fuzzy on some details - so I'm going to state this like a real nooby to hopefully get an ELI5 answer) If I were to set up my own DoH server, would its queries to upstream (root??) servers (and subsequent recursed servers) be encrypted? (Simpler: does running a DNS server "on-premise", or even in the cloud, actually protect you from anything?)

topranks 7y ago
No, DoH only deals with client to resolver encryption. Recursive lookups from the resolver to authoritative DNS servers from the root down are not encrypted. Really what you are doing is switching between telling your ISP all the domains you look up to telling Google/Cloudflare. Except your ISP can still see SNIs so you’re really just telling Google/Cloudflare in addition to your ISP.
- kylek 7y ago
  Seems all for not :| I don't suppose there are any proposals to replace how SNIs are transmitted? (sans-vpn/tor, that is) Does QUIC/HTTP[23] do anything different?

darkhorn 7y ago

Also you can encrypt SNI in Firefox, just enable network.security.esni.enabled https://blog.cloudflare.com/encrypt-that-sni-firefox-edition/ https://blog.cloudflare.com/encrypt-that-sni-firefox-edition...