back to article Chrome devs tell world that DNS over HTTPS won't open the floodgates of hell

Chrome devs have had a little rant about "misinformation", repeating that DNS-over-HTTPS (DoH) will be supported but won't necessarily be automatically used in upcoming builds of the browser. In a blog post published last night, Google's Chrome product manager insisted it was not going to "force users to change their DNS …

  1. Anonymous Coward
    Anonymous Coward

    Of course it won't

    all your HTTPS requests will be routed via Google who will naturally keep a record of all those domains you are browsing.

    You didn't think that they'd do this out of the kindness of their heart did you?

    1. A.P. Veening Silver badge

      Re: Of course it won't

      Only one solution, run your own recursive DNS server(s), preferably in combination with a Pi-Hole.

      1. JohnFen Silver badge

        Re: Of course it won't

        That doesn't really help with DoH, though, except for specific well-behaved applications that graciously allow you to disable their use of it, or to specify what DoH server to use. Malicious applications and scripts are unlikely to be so accommodating.

        1. Charles 9 Silver badge

          Re: Of course it won't

          "Malicious applications and scripts are unlikely to be so accommodating."

          In which case you're already screwed as they're probably not using DNS in any event. It's not like this uses any kind of new technology. DNS tunnelling and hardcoded IP lists have been a thing for years (thus why you can't easily block Windows 10's telemetry--it doesn't use DNS).

          IOW, anyone who doesn't want to use DNS can do what you say already.

          1. rg287 Silver badge

            Re: Of course it won't

            (thus why you can't easily block Windows 10's telemetry--it doesn't use DNS).

            Bits of it do. Various MS telemetry domains appear at the top of my Pi-Hole's "most blocked" list.

            As you say though, they tend to fall back to hardcoded IPs if the domain doesn't resolve and some elements just use IPs by default anyway.

          2. JohnFen Silver badge

            Re: Of course it won't

            If an adversary isn't using domain names, that makes blocking them even easier, as I can simply block the IP addresses directly. Attackers typically use domain names rather than raw IP addresses to avoid such trivial blocking. This is especially true when the attackers are advertiser-related.

            1. Charles 9 Silver badge

              Re: Of course it won't

              UNLESS the adversary is using a multi-homed IP address and using a way other than SNI to get through to the actual server versus what normally is there. Until encrypted SNI becomes the norm, a DoH lookup still results in a connection and a sniffable SNI packet. Once eSNI is the norm, or the client uses another system to say which server to serve, you'll need to find another way.

              1. JohnFen Silver badge

                Re: Of course it won't

                Sure.

                I feel the need to be more clear about my stance with DoH. I am not saying that it's without security value. It certainly has that. However, it also comes with a security cost, just from a different direction. For my purposes, the cost is greater than the value, and so I am very concerned that it presents a security hole that I cannot plug without engaging in extreme countermeasures.

                All that said, there is no panacea here, whether DoH is used or not. Security is a perpetual game of give-and-take and requires constant vigilance and adjustment of defenses.

                1. Charles 9 Silver badge

                  Re: Of course it won't

                  Problem is, you're on the defensive end of a siege. Long-term, sieges always favor the attackers because, unlike you, they can work outside the box to find a way no amount of planning can stop. An end-to-end-encrypted link using a key you can't discover seems to be the equivalent of dealing with an adversary able to tunnel through bedrock.

        2. cmaurand

          Re: Of course it won't

          You could deploy powerdns's dnsdist in front of your own recursor. it does dns over https and you can set that in chrome's preferences. dns over https is bs

      2. LDS Silver badge

        "in combination with a Pi-Hole"

        Those pesky slurp+ads killers are also the in Google blacklist of services to be terminated by DoH...

      3. big_D Silver badge

        Re: Of course it won't

        That is the problem. I have a Pi-Hole, which blocks around 2.5 million tracking, malware and malvertising sites, including all Facebook properties.

        But my Fire tablet insisted on using its own DNS server, ignoring my local settings. I had to manually re-configure the settings to force it to use the DNS server it was told to use by DHCP.

        The situation will only get worse, when individual applications start ignoring DNS settings.

        On public wi-fi or over mobile data, fine. In my house, where I have my own filtered DNS? No!

        The only solution is to put in firewall rules to block HTTPS to the Google, CloudFlare etc. DNS servers. But that is beyond most home users.

      4. Anonymous Coward
        Anonymous Coward

        Re: Of course it won't

        Your recursive name server will have to query upstream name servers every time you connect to a new website and also regularly when the TTL times out. The upstream name server still knows what websites you visit, although not exactly at what times and how often.

    2. NATTtrash

      Re: Of course it won't

      Still surprised that the automatic assumption is that my local (Icelandic, Swiss and German, depending on work) services per definition are worse than some (dodgy) US (law compliant) operator...

      News flash: there are some regions in the world that might be higher up the ladder than the US (gasp!) All this probably says more about the person/ organisation making the assumption than about the IRL essentials of the issue...

  2. Anonymous Coward
    Anonymous Coward

    Citation needed

    I'm afraid that I find it increasingly difficult to take any pronouncement coming out of Google at face value.

  3. JohnFen Silver badge

    Missing the point

    "Chrome devs have had a little rant about "misinformation", repeating that DNS-over-HTTPS (DoH) won't yet be introduced by default in upcoming builds of the browser."

    This response, much like Mozilla's defense of DoH, completely misses the point.

    How, or whether, a browser supports DoH is irrelevant. The fact that it exists at all in a standardized form is the problem, because malicious actors (including the adtech world) can use it regardless of browser support -- and there isn't a thing that ordinary users can do about it aside from blocking the execution of JS in the browser. In other applications, you're just hosed unless you're OK with blocking HTTPS access from that app.

    The damage has been done, and the only defense against it that I'm aware of is to man-in-the-middle all HTTPS traffic to find and deal with (drop, in my implementation) the DoH requests.

    Also, I doubt I'll ever be able to forgive Mozilla for its role in this.

    1. Graham Cobb

      Re: Missing the point

      Malicious actors aren't well known for caring much about standards. The problem, if any, is that someone has thought of it - not standardisation, or implementing in Chrome or Firefox.

      In fact, now that it has been thought of, implementing it in browsers and providing switches to control it is a very good thing: it reduces the number of bad actors who will roll-their-own and allows control over their use of it. It makes MITM them easier, if that is really what you want to do, and it makes providing your own DoH server under your control easier (if allowed by the controls).

      Now it has been thought of, I am glad it has been standardised. My concern is to make sure that software providers provide controls so I can tell all my software to use my DoH server, not Google's, Cloudflare's, my ISP's or anyone else's.

      1. JohnFen Silver badge

        Re: Missing the point

        "Malicious actors aren't well known for caring much about standards."

        True, but the fact that it's standardized means that it takes less work and resources to leverage it, because malicious actors can just use the mainstream DoH resolvers rather than roll their own. Also, that malicious actors can use mainstream resolvers means that their activities are even harder to detect and prevent.

        "browsers and providing switches to control it"

        Browsers providing the means to control it is good, but that won't affect malicious actors at all. The browser can only change how the browser itself uses DoH -- it has no control over programs that engage in DoH lookups without using the browser-provided mechanisms.

        My objection to DoH is that it abuses port 443, effectively removing its activities from my own ability to control. Thus the need to MITM HTTPS connections -- that's the only way to claw control of my own systems back and regain some of the security that DoH removes from me.

        1. Charles 9 Silver badge

          Re: Missing the point

          "My objection to DoH is that it abuses port 443, effectively removing its activities from my own ability to control. Thus the need to MITM HTTPS connections -- that's the only way to claw control of my own systems back and regain some of the security that DoH removes from me."

          But that's the exact problem. If it uses its own port as DoT does, then the port itself can be hijacked, if not by you, then by anyone upstream. And if the MITM presents itself as the authoritative server complete with keys, there's no way to distinguish between them.

          Put it this way. The tool YOU need is the exact same tool BIG BROTHER needs, too.

          1. JohnFen Silver badge

            Re: Missing the point

            "The tool YOU need is the exact same tool BIG BROTHER needs, too."

            Indeed. But the fact that that's true doesn't eliminate my need -- that's why all the existence of DoH means is that I have to man-in-the-middle all HTTPS traffic on my own networks. I hate having to do that, but there it is.

            1. Charles 9 Silver badge

              Re: Missing the point

              Which simply means they'll switch to using other protocols like VPN tunneling (which is ALSO open-source, hello OpenVPN). At which point you'll have to ask yourself if you're willing to go all Chinese to save your network.

      2. Immenseness

        Re: Missing the point

        MITM won't work when we get to the end game.

        I already have an Internet of shite device that tries to phone home, no matter what I do. I even tried to MITM it, but it is hard coded to look for a specific certificate on the other end and if it can't connect to that server (port 443), or connects to a MITM certificate, it shuts up shop and won't play anymore.

        Now imagine connections to ad servers behaving the same way when built into set top boxes etc, not just browsers. Pi hole won't help and setting up your own dummy service won't work. This is the end game for Google, I am convinced of it. Apart from this, I don't see what problem DOH is meant to fix.

        1. Charles 9 Silver badge

          Re: Missing the point

          Wholesale port hijacking by Big Brother ISPs, which is already happening now?

        2. Charles 9 Silver badge

          Re: Missing the point

          It MUST leave the option open, or it'll lose support for deployment in enterprise and other large-scale settings where the DNS is internalized for sanity's sake.

        3. vtcodger Silver badge

          Re: Missing the point

          Apart from this, I don't see what problem DOH is meant to fix.

          What problem? !!!ADVERTISEMENTS ARE BEING BLOCKED!!! You and I may not view that as a problem, but Google's customers are advertisers. It seems probable that THEY view ad-blocking as a problem.

          1. cmaurand

            Re: Missing the point

            If adblockers would take delivery of the ad and spill it out on the floor instead of displaying it, then they wouldn't know you're blocking ads.

            1. Charles 9 Silver badge

              Re: Missing the point

              But it still costs bandwidth for you. Plus if the ad is active in nature, it may expect a pingback before registering it as served.

        4. JohnFen Silver badge

          Re: Missing the point

          I'm not worried about any of that, because I don't buy or use such devices.

          1. Claptrap314 Silver badge

            Re: Missing the point

            So, you don't have a personally owned vehicle to replace ten years from now?

            This tech, these methodologies, are going to be endemic unless governments get clueful enough to ban them all.

            Not holding my breath.

      3. Claptrap314 Silver badge

        Re: Missing the point

        Like anything else, crackers come in various skill levels. To anyone involved with professional, engineering-level actors, DoH is just another application of anything-can-go-over-anything. As I mentioned when this first came out, if I wanted to, I could implement DNS-over-SQL on a standard port.

        But the fully-competent actors are never going to be the only threats worth defending against. For a majority of operators, nation-state actors probably don't even hit the list of reasonable concerns. Script kiddies are.

        And DoH makes it much, much easier for the script kiddies. And the "adtech" companies.

        And then there is the whole issue of Google itself acting very much as a bad actor in a number of ways, and DoH feeds directly into some of that.

  4. Marty McFly
    Childcatcher

    How to take out the competition....

    ISP tracking their customers is in direct competition with Google. Killing off the ISP's DNS sure seems like a good way to whack the competition.

    Of course, it is all for the greater good, save the children, protect the whales, etc.

  5. Nate Amsden

    Won't be used in upcoming builds..

    "[..] but won't necessarily be automatically used in upcoming builds of the browser"

    I'd wager the time frame Chrome devs work with and most of the rest of the world are very far apart. when someone says the above statement I'd have an expectation of that time frame being at least 2+ years, perhaps even 5 years. I'd be quite surprised if within the next 12 months they don't have it on by default(or at least to the same extent firefox has it on anyway). Google and Moz seem to be quite aggressive at pushing this kind of stuff. (Disclosure I bailed on firefox for my main browser at v37 I think it was, on Palemoon since, I do have firefox installed and use it very casually but not my main browser and I don't use Chrome).

    For me, as someone who has run DNS for more than 20 years, am still waiting to see non service provider implementations(stuff that I can run myself for my own recursive resolver and is reliable at least) of this DoH -- not that I am in any rush. I checked a few months ago and there wasn't much of anything, checking again now and I don't see anything obviously new in this area.

    1. JohnFen Silver badge

      Re: Won't be used in upcoming builds..

      "am still waiting to see non service provider implementations(stuff that I can run myself for my own recursive resolver and is reliable at least) of this DoH "

      If you're interested in running your own DoH resolver, and you're running Linux, then dnscrypt-proxy is the easiest way forward. It can act as a DoH server.

      Also, check out the DoH RFC (https://tools.ietf.org/html/rfc8484) -- the DoH protocol itself is not complex and could be easily implemented if you can code (although there are several security gotchas involved). Here's a simple implementation written in PHP: https://github.com/NotMikeDEV/DoH/blob/master/dns.php

      1. Nate Amsden

        Re: Won't be used in upcoming builds..

        thanks for the info that does look interesting and has not turned up on my searches before. However I don't think it does what I'd like to think it does. It seems to just be a proxy to forward DoH requests to another DoH host.

        according to https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry

        "It responds to standard DNS queries, and can be thus configured in network settings in place of your router's or your ISP's resolver.

        But when it receives a query, it will encrypt and authenticate it before sending it to upstream servers able to understand the encrypted protocol."

        key point being "upstream servers able to understand the encrypted protocol".

        Unless it can handle DoH and hand it off to a local DNS running regular old DNS on port 53 (should be just as secure as the "insecure" traffic is just going to localhost at that point from the proxy.

        also looked at https://wiki.archlinux.org/index.php/Dnscrypt-proxy

        and it referenced cloudflare as well, no obvious indication it can handle DoH -> regular DNS (which would allow someone to run a local DoH system).

        I could be misunderstanding the docs I just spent a couple minutes looking

        1. JohnFen Silver badge

          Re: Won't be used in upcoming builds..

          dnscrypt-proxy is a proxy, but it can respond to DoH requests and proxy them to any other DNS resolver, whether encrypted, using DoH, or standard. I'm not sure if this is the best configuration guide, but here's one: https://www.aaflalo.me/2018/10/tutorial-setup-dns-over-https-server/

      2. cmaurand

        Re: Won't be used in upcoming builds..

        check out dnsdist by powerdns. high availability proxy for dns that answers dns over https queries. use that in combination with their recursive dns server. done.

    2. Anonymous Coward
      Anonymous Coward

      Recursive DNS

      Wouldn't Pi-Hole and unbound (your choice of OS) solve this for you?

  6. Martin Gregorie Silver badge

    Unintended(?) side effects

    I wonder what, if any, impact DoH will have on spam filters.

    These all depend, to some extent, on black/grey/whitelist providers such as Spamhaus and most of these use DNS queries to interrogate blacklists. In fact the earliest blacklist servers used standard DNS server software and populated their A records with the names and IPs of blacklisted hosts instead of hosts which the DNS is authoritative for.

    Since it would appear that obvious DoH implementations, such as ISPs replacing their DNS servers with DNS->DoH translators to handle outgoing DNS queries, would interfere with e-mail blacklisting services I'm a little surprised that this doesn't seem to be mentioned at all amongst the DoH ballyhooing and razzamatazz.

    1. JohnFen Silver badge

      Re: Unintended(?) side effects

      I don't think that DoH will have any adverse impacts on spam filters. In the end, it's just a DNS lookup and as near as I can tell, all the usual filtering methods will work with DoH.

      1. katrinab Silver badge

        Re: Unintended(?) side effects

        Also, if your browser uses DOH, that doesn't in any way change how your smtp server does its DNS lookups.

        1. Martin Gregorie Silver badge

          Re: Unintended(?) side effects

          Surely that depends on what application issues DoH requests. I agree that it will have no effect on applications in general if DoH is only used by web browsers. However, that implies that either:

          - NO other applications will use DoH unless they are modified to use DoH queries in place of the current plaintext DNS queries

          or

          - somebody or something, i.e. your ISP, your router, some translation process you installed, intercepts outgoing DNS queries, converts them to DoH queries before passing them on and does the reverse translation to DoH responses.

          I'm pointing this out because, if DoH takes off, it is unlikely to to remain a browser-only option and, as its going to need configuration files, security certs, etc, it would seem unlikely that it will get built into every program that currently does DNS lookups, hence my original worry that we'll end up with yet another system process to support the DoH query API and that this will impact applications using DNS queries that those pushing DoH have never thought about.

          Last but not least, the DoH API had better operate asynchronously, i.e. must NOT wait for for a response before issuing the next query, oy it will simply be a bigger and better bottleneck on throughput.

  7. MatthewSt

    It'll be interesting how they're detecting which service you're using, as (aside from the 90+% of the UK on the default) I reckon most will be using their router rather than change the config on each device.

  8. Anonymous Coward
    Anonymous Coward

    Just give me control.

    I want to set my own DoH configuration. A checkbox to enable it and an address field to configure it to use the provider I want to use. No messing about detecting whether my DNS provider is on their approved list.

  9. Chris Hills

    Optional... for now

    When it reaches critical mass and websites start breaking without it, Google will inevitably make DoH mandatory.

    1. katrinab Silver badge

      Re: Optional... for now

      What about internal websites? I have various websites - Exchange OWA, NextCloud, etc, that resolve to local addresses on my LAN, and to my reverse proxy from outside. Work has similar for its LAN.

      If it gets the external address from inside the LAN, it is not going to work.

    2. JohnFen Silver badge

      Re: Optional... for now

      "Google will inevitably make DoH mandatory."

      How would Google do that?

  10. Jamie Jones Silver badge

    DNS blacklisting is NOT how the IWF blacklist operates

    I posted a big post here, but cloudflare said my posting was blocked.

    EDIT: I give up. It seems cloudflare is sensoring posts mentioning cloudflare :-)

    Basically, see subject, or view following link:

    Here's my post http://www.welshgit.net/misc/dns_blacklisting_is_not_how_the_IWF_blacklist_operates.html

  11. EnviableOne Bronze badge

    I hate how the argument has become DoH or DNS,

    DoH is not the best way to secure DNS, its fraught with issues, like web filters etc

    DNS over TLS is just as secure, and when combined with DNSSEC no-one you ont want to will see your DNS queries.

    1. Jamie Jones Silver badge
      Thumb Up

      Hark at you with your sensible points! :-)

    2. JohnFen Silver badge

      I frequently forget that many people aren't aware of these solutions and assume they're common knowledge. My bad.

    3. Charles 9 Silver badge

      What's stopping them just hijacking the port wholesale like many ISP's do for regular DNS? As for DNSSEC, it's not implemented widely enough to ensure it can't be bypassed or disguised.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019