back to article 'The inmates have taken over the asylum': DNS godfather blasts DNS over HTTPS adoption

The Internet Engineering Task Force (IETF) has formally adopted DNS-over-HTTPS as a standard, and reignited a debate over whether it's a danger to the web's infrastructure. The IETF gave the proposal its blessing late last week by elevating it to Request For Comment (RFC) level as RFC 8484. The idea was to guarantee the …

  1. Paul Crawford Silver badge

    There is more to the internet than web browsers, but here we seem to be seeing a split where the web browser will get https for DNS (adding even more code bloat) and quite probably see a different world to anything else (such as VPN client, SSH, BitTorrent clients, etc) that rely on conventional DNS for name resolution. Bad.

    But equally why has the DNS world not addressed this privacy problem?

    1. Spazturtle Silver badge

      Not really, my system supports DNS over HTTPS revolvers, so if I put in the IP of a DoH server then all my apps will be using DoH.

      1. john.jones.name
        WTF?

        thats not how it works...

        sadly thats not how it works

        your provider intercepts the DNS query (ISP's are required to do so by law US/EU/Asia) to stop child abuse etc and some territories go much much further

        you only have to look at the the chinese or even turkey

        this is the "state sponsored" manipulation and the "strong human rights argument" falls apart for DNS over HTTPS, it basically does not work... one of the reasons is root certificates, there are plenty of compromised issuing certificate authorities and sorting out the bad actors is near impossible you have to throw out the whole lot.

        the secondary reason that you cant escape is even if you have a secure connection to a DNS over HTTPS server the answers that it provides are not signed and so you cant verify them

        regardless people need to start using DNSSEC to actually verify... Mozilla etc have patch's and have done NOTHING

        I wonder why...

      2. eldakka
        Coat

        @Spazturtle

        my system supports DNS over HTTPS revolvers

        Is this the Russian Roulette solution?

    2. pixl97

      >But equally why has the DNS world not addressed this privacy problem?

      Because they are at the crap end of everyone else's equipment....

      Microsoft: We'll look at client DNS security, about 10 years from now.

      Linux: We think this way is the bes(Other Linux: NO, this way is better!)

      Phone makers: Security, buy a new phone if you want that.

      ISP's: Security is a bad idea, we don't want it because then we cannot spy on you, so we're not going to update the massive infrastructure we control.

      Middleware boxes: Duhhhhhh, grunt, moan... Hey Guize, we finally support Http/1.1!

      And this is why Firefox and Google are jamming encDNS over HTTPS.

  2. David Roberts

    The first thing that struck me

    Is that home users nearly always get their DNS from their home router supplied by their ISP as standard.

    To make this work you would have to update the software/firmware on a very mixed bag of routers. You also have the issue of the connections from the LAN to the local router. Patches to the DNS software on PCs (probably IoT devices as well).

    This has the feel of something which will take a decade or more to roll out.

    1. Warm Braw

      Re: The first thing that struck me

      a decade or more to roll out

      Not if the browser uses a different DNS service to other local applications - it could be in the next browser update you download. Of couse, this would potentially result in "split-horizon" problems (try to debug a connectivity issue when your local DNS resolver gives you one answer and the browser is getting another) and it simply trades your vulnerability to interception of your DNS requests in transit for vulnerability to slurpage at their destination.

    2. Anonymous Coward
      Anonymous Coward

      Re: The first thing that struck me

      There are many ways around that 'issue'.

      1) Even ISP supplied routers have an admin panel where the DNS can be changed or DHCP turned off. But regardless, you don't need a mixed bag of routers to be updated just your own one and if you are really concerned you could just purchase another one yourself.

      2) As said by poster above you browser could handle the DoH

      3)Your OS could be updated to allow you to use DoH and then you could ignore the Router sent DNS and put a manual one in on HTTPS

      4)You could redirect port 53 requests over DoH instead using software or another device.

      Substitute DoH for DoT as appropriate.

      1. Anonymous Coward
        Anonymous Coward

        This is great

        2) As said by poster above you browser could handle the DoH

        3)Your OS could be updated to allow you to use DoH and then you could ignore the Router sent DNS and put a manual one in on HTTPS

        4)You could redirect port 53 requests over DoH instead using software or another device.

        So that's potentially three different sources of DoH, as the manual one you set isn't necessarily the one say Chrome will use (its gonna use Google's resolvers by default) and if you redirect that's probably to fix a deficiency elsewhere. Those three don't even include the one set in your router.

        .

        Substitute DoH for DoT as appropriate.

        But wait, here's one or more potential additional sources, since both standards are being deployed!

        DNS troubleshooting is about to get an order of magnitude more difficult.

        1. Anonymous Coward
          Anonymous Coward

          Re: This is great

          "So that's potentially three different sources of DoH,"

          "DNS troubleshooting is about to get an order of magnitude more difficult."

          That's no different to how it is now, your ISP can supply DNS via your router over DHCP, you can mannually override that by using static DNS, you can change your hosts file to run manual static lookups, your browser could do independent DNS lookups, you could tunnel to a different DNS server or you could redirect DNS requests at any point in your network. Most users are already utilising DNS hybrid proxies of some kind without even realising as it's the DNS server that does the proxying transparently.

          It will be completely up to you if you run DoH or DoT - as long as it is supported locally and at the DNS server of your choosing then you join the debate on whichever side you want. If you aren't having any support from router/browser/os and you really want to use secure DNS you can just setup a simple DNS<->DoH software proxy and run your queries through that.

          It is not in any way "magnitudes" more difficult, for most people it will be done automatically without them even noticing at some point in the distant future, until then it will carry on with standard DNS queries and allow 'power users' to change the setting.

          1. Anonymous Coward
            Anonymous Coward

            Re: This is great

            Sure, but that's all kept in one place so it is easy to tell what DNS is being used. With DoH it could be different on a per application basis, with varying defaults (Google apps will look to Google etc.) and different configuration locations since they won't use resolv.conf.

            How will I know what Google Earth does for resolution without looking it up, since it could obey resolv.conf, it could use DoH with some Google default if a config file doesn't override it, or it could use DoT with the same caveats.

            1. Anonymous Coward
              Anonymous Coward

              Re: This is great

              "Sure, but that's all kept in one place so it is easy to tell what DNS is being used. With DoH it could be different on a per application basis, "

              That is false. Any application could choose to use whatever DNS service it wants to. There is absolutely no difference in the DoH service just that it will run secured over a different port. The reason that individual applications don't have their own DNS settings is because there is no point, it just passes the request down to the operating system to look after, but it doesn't have to.

              With DoH there won't suddenly be a raft of applications that are going to try to implement their own networking libraries and DNS resolvers. It will send them straight down to the OS as before to handle.

              If the OS is not ready then the browser could give the option to do secure lookups, IF YOU WANT it to. This is the same as the proxy option that you get in many applications - no proxy, manual proxy, use Window Proxy settings. Pretty much everyone uses no proxy, the rest use the default proxy set up by the OS.

              The idea that this is going to be an administrative nightmare is ridiculous. In an organisation the user won't even have any say.

              1. David Roberts

                Re: This is great

                I've read through the replies but one thing still seems to be ignored.

                As far as I can tell the default behaviour on a PC is to use the underlying OS to resolve DNS queries.

                This in turn uses (again by default) the DNS server details supplied by DHCP running on the local router. In most cases this is the LAN side of the router.

                That router understands DNS as it is today.

                If you wish to switch to negotiating an HTTPS connection on a diffetent port then presumably the DNS code in your home router will have to be updated to do three things. Handle a local HTTPS DNS request and pass that on to the configured ISP (or other) DNS server. Handle an old style DNS request and roll it over into HTTPS. Handle legacy DNS from end to end.

                Otherwise the DNS configuration information given out by DHCP will no longer be any use and you will have to configure on a PC basis or even an application basis instead of just plugging your PC into the local network and having it automatically configured. Which is what the majority of home users do now AFAIK.

                Footnote: if browsers and other pieces of software start running their own encrypted DNS connection that screws up the practice of using your own DNS server to filter DNS queries and deep six Google and Microsoft snooping services.

                1. Anonymous Coward
                  Anonymous Coward

                  Re: This is great

                  "If you wish to switch to negotiating an HTTPS connection on a diffetent port then presumably the DNS code in your home router will have to be updated to do three things. Handle a local HTTPS DNS request and pass that on to the configured ISP (or other) DNS server. Handle an old style DNS request and roll it over into HTTPS. Handle legacy DNS from end to end."

                  This is over-complicating it. The Router doesn't need to care. Just get the router to present the IP of a DoH DNS server and the OS will communicate directly with that. The router will not need to get involved. It's only if your router acts as a DNS proxy and will only present its own address as a DNS server, which you can't change, that it would be affected but you can still put manual DNS in your OS if you want it secured.

                  Port 53 DNS will still be around as long as your router is.

                  RE Footnote: I can't ever imaging that the browser would specify the DNS that you *have* to use. Makes no sense.

    3. Arthur the cat Silver badge

      Re: The first thing that struck me

      Is that home users nearly always get their DNS from their home router supplied by their ISP as standard.

      Is it the customer's router that does DNS, or does the router DHCP DNS information point at a server run by the ISP in order to make caching more coherent? My ISP does the latter, but it's Zen who are usually more competent than most. (I run my own pfSense router and override the settings anyway.)

      1. SImon Hobson Bronze badge

        Re: The first thing that struck me

        Is it the customer's router that does DNS, or does the router DHCP DNS information point at a server run by the ISP in order to make caching more coherent?

        IME many SOHO routers give the router address when there is WAN link (and it hasn't got DNS information from the ISP yet) - then when they get the information from the ISP the DHCP is updated and it gives the ISP provided DNS server list.

        This makes some sense, since some of them also redirect all DNS lookups to themselves so that when offline the user(s) get the router status page regardless of what they try to bring up in the browser. Telling the clueless home user that there is no internet connection is probably OK, but it's a complete flippin PITA in so many situations - particularly screwing up https connections with a barrage of certificate error warnings to the user (and don't get me started on the interaction with browser caching !)

        But as is often the case - "it depends".

        And for good measure, many SOHO routers lack the resources to do timely DNS lookups. I've seen situations where users were complaining about "slow internet", and simply switching the DNS away from the router was enough to fix it. ISP provided routers are built to very tight budgets.

      2. Orv Silver badge

        Re: The first thing that struck me

        Is it the customer's router that does DNS, or does the router DHCP DNS information point at a server run by the ISP in order to make caching more coherent?

        In a lot of cases the router gives its own address out as the DNS server, then passes DNS requests from the client on to the ISP's servers, similar to dnsmasq. (In fact often it literally *is* dnsmasq running on the router.) This also lets them do things like redirect requests to an internal troubleshooting page when the ISP link is down.

        In the past these internal DNS forwarders have sometimes been quite broken, especially for AAAA lookups, so on the whole I'm not a big fan.

        There's no reason DNS *has* to be handled by the router, though, and since the part of the point of DoH is to look like ordinary HTTPS traffic, most routers should pass it on just fine.

  3. Anonymous Coward
    Anonymous Coward

    "He said DoH removes a discriminator that can be used to distinguish DNS"

    Really? I guess it will be very easy to detect and block DoH anyway - especially when you're a state. Running everything over HTTP(S), even if it's appealing to a lot of developers who don't understand anything else, it's not the solution.

    1. Anonymous Coward
      Anonymous Coward

      Re: "He said DoH removes a discriminator that can be used to distinguish DNS"

      Yes, really. By treating DNS as an application and not just "control-plane" traffic, DoH obscures the actual DNS transactions AND the header-level clues that DNS resolution is being requested.

      1. Anonymous Coward
        Anonymous Coward

        "AND the header-level clues that DNS resolution is being requested."

        LOL! There will be several hints and statistical techniques revealing that's a DNS request, as they tend to be repetitive and very much alike each other. You don't need to know what's inside, just to know it has a high probability of being a DNS request.

        The endpoints can be blocked, and do you believe an authoritarian state would have issue in blocking other services if they are mingled?

        But of course form some DNS "providers" it could be a good idea to make far more difficult for users to avoid tracking of their online habits... that's why, for example, I run my own DNS which doesn't depend on any provider DNS - nor my ISP, nor, especially, Google or Cisco.

        1. Spazturtle Silver badge

          Re: "AND the header-level clues that DNS resolution is being requested."

          "I run my own DNS which doesn't depend on any provider DNS"

          Yes it does, it depends on the root DNS servers, and your DNS server will be sending lookups to them unencrypted.

          1. Jellied Eel Silver badge

            Re: "AND the header-level clues that DNS resolution is being requested."

            Yes it does, it depends on the root DNS servers, and your DNS server will be sending lookups to them unencrypted.

            It shouldn't, ie it should depend on some decent DNS resolvers rather than root servers. Which should just tell you who's authoratitive for that domain and send you there to resolve A, PTR records etc etc.

            But unecrytped DNS is useful, like Vixie says. So user sends request (not just HTTP) looking for evil.stuffhere.ru and DNS resolves that back to an IP address. Being a simple, plain text request, it's easy for net/security admins to capture that request, match against security policy and perhaps go have stern words with the requestor.

            Which is how a lot of network monitoring systems work, along with policy blocking systems. Encrypting requests will just make that a whole lot harder, along with trying to restrict access to unauthorised resources. So trying to block by IP address, which will be FUN for things like anything on AWS. So for any kind of security, being able to hide the request attempts is going to be a really bad thing.

            (Unless of course you happen to operate some of the most popular resolvers, and be in a position to 'peek behind the curtain' on those resolvers to determine what the encrypted request contained. Hello, 8.8.8.8 or 8.8.4.4)

            1. LeahroyNake

              Re: "AND the header-level clues that DNS resolution is being requested."

              If you are a network admin you control the DNS that is assigned via DHCP and hopefully locked down the settings so users can't change them.

              You also block every port (allow others as required) and only allow unencrypted DNS from your internal DNS server that blocks and logs requests for nasty stuff.

              Moving DNS to https sounds like a good idea.... It's not... at least for SMB and home users that do not have half decent kit. Inspecting an encrypted packet for a DNS requests is a lot harder than securing your own DNS server and blocking requests that are against your policy.

              This also assumes that users can't use a VPN to carry out the request....

            2. eldakka

              Re: "AND the header-level clues that DNS resolution is being requested."

              @Jellied Eel

              But un-encrypted DNS is useful, like Vixie says. So user sends request (not just HTTP) looking for evil.stuffhere.ru and DNS resolves that back to an IP address. Being a simple, plain text request, it's easy for net/security admins to capture that request, match against security policy and perhaps go have stern words with the requestor.

              Any organisation that cares about it's security for outbound users desktop requests has the following configuration:

              1) firewall blocks by default all outbound requests coming from any source.

              2) firewall is configured to allow known hosts that have a need to connect externally (e.g. non-HTTP/S B2B links, such as direct messaging systems).

              3) it provides its own DNS servers internally, and since a desktop cannot send any request, including DNS, through the firewall, to perform DNS resolution you need to use the organisations DNS servers.

              4) A MITM proxy (HTTP/S, possibly others, FTP, SSH, etc.) that requires user authentication and authorization to use.

              5) as a MITM proxy, it decrypts all traffic (except any on the exception lists, known 'good' sites such as major banks, or government websites) and it establishes a secure session between the client and the server, client <-> (TLS) mitm proxy (TLS) <-> server.

              6) Firewall allows authorized requests from the MITM proxy that have been vetted out to the rest of the world.

              Therefore using DoH, DoT, TLS, whatever doesn't matter if you are on a business/organisation network that cares about its security, as you'll be hitting their DNS/DoT/DoH server which means they get to inspect the unencrypted contents of the DNS request and make the usual decisions on what to do with it - resolve it, block it, redirect it.

              So the only network management layer that cares about whether the DNS (or other) request is encrypted or not are the middleman transport networks, ISPs, Peering providers, and anyone outside the source network and target network that wants to eavesdrop or control the data. The source network and destination network know what's in the packet.

        2. Anonymous Coward
          Anonymous Coward

          @LDS - no there will be no hints and statistical techniques

          Not if you want to prevent them - just include some random garbage of different lengths in the requests, or request stuff you don't care about like SPF records so the return packets are similarly devoid of sizing clues. If the protocol designers really wanted to, it could easily be made impossible to tell apart from real HTTPS traffic.

          The only way a nation state will block it is by something akin to the Great Firewall, which is the encryption endpoint for all HTTPS packets. When you get everything cleartext, you can obviously block whatever you choose.

          1. Jellied Eel Silver badge

            Re: @LDS - no there will be no hints and statistical techniques

            The only way a nation state will block it is by something akin to the Great Firewall, which is the encryption endpoint for all HTTPS packets.

            Be afraid, be very afraid. Nation states block by legislation. So the UK currently requires ISPs (and CSPs) to log all connection requests. As long as those logs contain something slightly meaningful, TPTB will be vaguely happy. If that turns into obfusticated or encrypted stuff, they may legislate to make encryption unlawful. Or give ISPs interesting new challenges around how to comply with current or new legislation.

            The big downside to this proposal is it'll steer traffic towards the usual suspects, ie Google, MS etc who'll still be able to monetise the requests.

            1. SImon Hobson Bronze badge

              Re: @LDS - no there will be no hints and statistical techniques

              The big downside to this proposal is it'll steer traffic towards the usual suspects, ie Google, MS etc who'll still be able to monetise the requests.

              Indeed, it only improves privacy if you trust the single entity you use for your DNS to not treat this new goldmine of information as something valuable to be sold to the highest bidder.

              As I read the RFC, you (or your provider) configures one or more DoH servers and use only those one or two servers for all your requests. In practical terms, that means one server has a complete record of all your DNS activity - so they better be trustworthy. Particularly if you run your own resolver, that information can only be obtained from sniffing the wire (which in practical terms means within your ISP for it to be complete) since your DNS requests get distributed across many authoritative servers.

              I can see authoritarian countries simply blocking all access to an IP that hosts such a DNS server. It'll be easy to check - just analyse https traffic and if anything looks like it might be DoH then test that address with a DoH client. If it responds, then just block the IP - and if that breaks other stuff sharing the IP then tough, the provider shouldn't have shared an IP between DoH and other https traffic.

        3. SImon Hobson Bronze badge

          Re: "AND the header-level clues that DNS resolution is being requested."

          There will be several hints and statistical techniques revealing that's a DNS request

          Lets start with the SNI header !

          But I agree with others - it's going to be one real cluster-duck when it comes to debugging the problems that DO occur on a routine basis.

          1. Michael Wojcik Silver badge

            Re: "AND the header-level clues that DNS resolution is being requested."

            Lets start with the SNI header !

            That channel will be closed soon, if it hasn't already. ESNI is already rolling out, and UAs / servers that participate in DoH are precisely the ones that push new features like ESNI.

            1. brotherelf

              Re: "AND the header-level clues that DNS resolution is being requested."

              And the volatile keys you need for ESNI to work are … :drumroll: in the DNS.

          2. Jamie Jones Silver badge

            Re: "AND the header-level clues that DNS resolution is being requested."

            Lets start with the SNI header !

            To be fair, SNI was designed to solve a different problem - correctly handling certificates for different domains on the same IP.

            As the only working alternative was one-host-per-ip there was no security compromise - before SNI you just sniffed the IP address from the packet headers!

            (I'm not saying you don't know this - I just thought it worth pointing out to any one stupid enough to read my posts!)

    2. GnuTzu

      Re: "He said DoH removes a discriminator that can be used to distinguish DNS"

      I have to wonder how this will work out for organizations with a web proxy. Such organizations typically block HTTP[S] traffic for all but the proxy. And, it just feels odd to think how DoH might end up going through a web proxy. And, then there's SSL intercept/inspection, which does a monkey in the middle thing to look at what's inside the tunnel. It's going to be very interesting to see how this shake out.

      1. DaLo

        Re: "He said DoH removes a discriminator that can be used to distinguish DNS"

        |In an organisation as the firewall owner and the directory administrator you could choose how to do it.

        You could only allow standard DNS requests and then convert them to TLS at your gateway providing oversight locally but not outside your administration or you could stop them altogether.

        It's your choice, you have a root cert on every PC.

        1. GnuTzu

          Re: "He said DoH removes a discriminator that can be used to distinguish DNS"

          @DaLo,

          Well, it's nice to know that the firewall configuration is easy. No offenses, but care to take a turn being responsible for diagnosing proxy issues in an organization in which every unresolvable host name is seen by 80k users as the fault of the proxy?

          1. DaLo

            Re: "He said DoH removes a discriminator that can be used to distinguish DNS"

            "Well, it's nice to know that the firewall configuration is easy. No offenses, but care to take a turn being responsible for..."

            I have run network border security for more users than that. However the number of users - 1000, 10,000, 100,000 doesn't affect your configuration or make it harder. You are also not talking about a firewall if you are talking about a web proxy, they are different things. You may have a UTM with both firewall and Web Proxy included but the configuration of these is pretty standard, not sure why it would be difficult especially when talking about user requests.

            I'm not trying to tell you how to do your role, but if you spend a *lot* of time dealing with users who have to inform you that they can't resolve a hostname and you have to spend any significant time troubleshooting it then I would suggest changing the procedures somewhere.

  4. Jusme

    Another step

    Another step towards handing control of the Internet to the megacorps, with nice high barriers to entry and only a few bums for the authorities to kick.

    (Consider when web browsers insist on using their owners servers for DNS, and by owners I mean google/apple/microsoft...)

    1. Doctor Syntax Silver badge

      Re: Another step

      "by owners I mean google/apple/microsoft"

      So use a better browser: PaleMoon for instance.

      1. DJ Smiley

        Re: Another step

        The rest of the world and I have a differing opinion on 'better'.

      2. Spazturtle Silver badge

        Re: Another step

        PaleMoon is by far the worst choice you could make when picking a web browser. If you don't want to use one of the big browsers then pick something like Waterfox or Brave.

        1. Anonymous Coward
          Anonymous Coward

          Re: Another step

          I'm starting to agree about Palemoon being a sub-optimal browser, I did look at Waterfox but after reading "Webpage data to Google’s SafeBrowsing service:

          Learn more or read Google’s Privacy Policy. Opting out prevents Waterfox from warning you of potentially illegitimate or malicious websites."

          I was reminded of why I went with Palemoon in the first place...

          WRT 'Brave', well i'm not 'brave' enough to allow them to choose and curate my addons for me.

          Oh, Waterfox also has an 'Awesome Bar' - last time I saw one of those, an American was having a drink in it.

          1. Spazturtle Silver badge

            Re: Another step

            ""Webpage data to Google’s SafeBrowsing service:

            Learn more or read Google’s Privacy Policy. Opting out prevents Waterfox from warning you of potentially illegitimate or malicious websites.""

            That's outdated, both Firefox and Waterfox now locally store a copy of the google's safe browsing database and do lockups locally. Or you can disable the feature entirely.

            1. Spazturtle Silver badge

              Re: Another step

              Also far more people have your data with Palemoon given how insecure it is, even the developers have effectively admitted it was a mistake by forking Firefox 56 into Basilisk which contains everything they said was bad (like sandboxing and process isolation) back when they forked Firefox 28 into Palemoon.

    2. teknopaul

      Re: Another step

      Heartily agree. What privacy do we get by using ssl to to dns via 8.8.8.8

      Whoever we use we go to the ip on port 443 shortly after the dns lookup anyway.

      1. mosw

        Re: Another step

        "Heartily agree. What privacy do we get by using ssl to to dns via 8.8.8.8"

        For someone trying to invade your privacy, you reduce the available attack surface by using ssl. If you don't trust Google then find another DNS service. At least you get to decide who you trust rather than having to trust every one along the communications route.

  5. Robert Carnegie Silver badge

    Who needs DNS anyway?

    It's not beyond the wit of a young person to use a literal IP address to look at things their parent doesn't like them seeing... and maybe get into more trouble than if they use DNS for it. I don't think this is the way.

    1. A Non e-mouse Silver badge

      Re: Who needs DNS anyway?

      And what about one IP address hosting multiple websites? If this wasn't an issue, SNI wouldn't have been invented.

      1. Anonymous Coward
        Anonymous Coward

        Re: Who needs DNS anyway?

        Simple put it in your hosts file, do it all the time when tesing.

    2. DJV Silver badge

      Re: Who needs DNS anyway?

      Doesn't work where you have multiple virtual servers all running out of a single IP, which is most of the small to medium sites nowadays.

      1. Bronek Kozicki

        Re: Who needs DNS anyway?

        ... or if you have some kind of CDN, which is most of the large sites (including El Reg) because that relies on DNS directing the user to the nearest datacentre.

        1. Robert Carnegie Silver badge

          Re: Who needs DNS anyway?

          But presumably if I use the IP address for The Register in Hong Kong, it will work.

          Well - maybe not the Hong Kong one.

          I'll give it a go though...

          ...no, on second thoughts, I won't.

    3. Anonymous Coward
      Devil

      "It's not beyond the wit of a young person to use a literal IP"

      Just wait for IPv6 becoming widespread....

      1. Robert Carnegie Silver badge

        Re: "It's not beyond the wit of a young person to use a literal IP"

        I suppose that a "Think of the children!" argument might finally bring about IPv6.

    4. Anonymous Coward
      Anonymous Coward

      Re: Who needs DNS anyway?

      Many ISP's block specific IP's to prevent this. Though it wont prevent VPN circumvention, in some territories having a non-government mandated VPN can garner some attention from the authorities (the types that dont allow you your own legal representation mostly).

      As for who needs DNS, there is a LOT more to DNS than (sensible/memorable^sic)name->ip translation.

    5. Reader2435

      Re: Who needs DNS anyway?

      "It's not beyond the wit of a young person to use a literal IP address to look at things their parent doesn't like them seeing"

      Are you kidding? In my experience, it's beyond the wit of most young people to do anything more technical than click on links in a browser. Having unsuccessfully made significant efforts to interest my kids in the workings of IT, I would be delighted if they started to poke around under the bonnet to bypass my parental controls, especially as they are now at the age where the controls aren't really necessary.

      1. CelineDion69

        Re: Who needs DNS anyway?

        They probably already have by using a different machine. Sometimes you don't have to employ any meddling at all, just be smarter than the parent.

  6. Evil Scot

    Cant trust my UK ISP

    This reminds me of my ISP poisoning the IP address of my ITSP.

    FreeNas Running PI-hole and DHCP. Disable DHCP on cable modem/router.

    1. Mage Silver badge
      Black Helicopters

      Re: Cant trust my UK ISP

      Your own ISP in the UK is more trustworthy than Google. Anyone concerned with privacy shouldn't use any Google managed DNS, no matter how secure the connection. Or Chrome. Android and Chrome OS are obviously problems. Win 10, iOS and MacOS even when calling the mothership are not in the same league of problem as Google, Facebook or nasty dictatorships. Fortunately I've only First World problems, though my wife worries about GCHQ and CIA tracking my searches and other Internet activities. I really needed to know how nuclear munitions are maintained (MADM etc) for "The Fay Child" and all that spy & pistol stuff for "The Solar Alliance." Money Laundering and forgery for "Conspiracies and Rooks".

      1. Arthur the cat Silver badge

        Re: Cant trust my UK ISP

        Your own ISP in the UK is more trustworthy than Google.

        TalkTalk? Virgin? I'd trust Google more than cheap ISPs, because they're more competent and less likely to accidentally leak passwords and account names. If, on the other hand, you want to talk about privacy, that's a whole different conversation. That's why I run my own DNS servers, and web sites, and …

        1. Anonymous Coward
          Anonymous Coward

          Re: Cant trust my UK ISP

          Google may be less likely to be hacked than your ISP, but the consequences if they ever were hacked would be so much worse that it is hard to claim that Google is less of a security issue.

          I think the main thing in Google's favor if they were hacked is that no one has enough storage to download all the personal information they have on everyone, and even if they have a gigabit pipe it would probably take weeks. It would be like breaking into the IRS and trying to figure out which file cabinets full of tax information are worth stealing.

          1. Orv Silver badge

            Re: Cant trust my UK ISP

            My ISP *already* messes with my DNS queries, by redirecting invalid hostnames to their own advertising pages. So I don't consider them especially trustworthy.

  7. Robert Helpmann??
    Coat

    DoH

    That's what Homer Simpson says!

    Mine has a pink glazed doughnut with sprinkles in the pocket.

  8. Paddy Fagan
    Boffin

    For those looking for more background

    I recommend this video from RIPE https://ripe77.ripe.net/archives/video/333/

  9. Anonymous Coward
    Anonymous Coward

    Why over HTTPS? Why not over TLS over TCP using port 443?

    1. Wellyboot Silver badge
      Unhappy

      '000s of UDP & TCP ports

      Lets channel all the protocols through no. '443' it'll make the firewall so much easier to setup.

      Can I use port 80 for sneaking online gaming into work now?

      1. Nick Kew

        Re: '000s of UDP & TCP ports

        And lo, it hath come to pass.

      2. Anonymous Coward
        Anonymous Coward

        Re: '000s of UDP & TCP ports

        The point is that if it's TLS over port 443 then whatever it is it looks like HTTPS traffic to anybody snooping. For simple request/response stuff anyway.

  10. JohnFen

    Paul Vixie is correct

    DoH, while well-intentioned, is a really terrible idea for a whole bunch of reasons, including those that Paul Vixie has stated. Worse, it's totally unnecessary. There are better ways of accomplishing this.

    1. Orv Silver badge

      Re: Paul Vixie is correct

      The thing is, his argument against is "network admins won't be able to snoop." Which is exactly the point. So I don't see much room for a meeting of the minds between people who want to stop snooping and people who think snooping is essential to the Internet's function.

      1. James R Grinter

        Re: Paul Vixie is correct

        The malware authors are gonna love this new feature, as a way of avoiding even their C&C lookups from being seen.

  11. doublelayer Silver badge

    Where do the keys come from?

    I need to read the RFC, but I'm not understanding something important. In your standard use of HTTPS, you request a domain through normal DNS, get an IP, and contact that server. That server has a key that you can verify as belonging to them and authorized by a central authority. You get it by contacting the address that you got.

    Where does the trusted key come from in DOH? Is the key connected to the DNS server itself? In that case, you could identify all contact to the DNS servers even though you couldn't read them and block them just as well as you could block DOT. If the keys are pre-known, you could modify them to poison which servers are available. So why is DOH superior to DOT? They look the same to me.

    1. _Ewan_

      Re: Where do the keys come from?

      "Is the key connected to the DNS server itself? In that case, you could identify all contact to the DNS servers"

      They're not /just/ DNS servers.The provider side of this in practice is a large organisation with a lot of useful stuff being served over https; for example Google or Cloudflare.

      So an attacker can identify that there's an HTTPS request going to Google or Cloudflare, but that's it. And it turns out that most organisations don't want to clock the entirety of Google or Cloudflare, because if you do that then an enormous amount of stuff breaks.

      Very much the point here is to mix the DNS traffic that ISPs etc. want to mess with indistinguishably into something so big and vital that they can't just block it all.

      1. doublelayer Silver badge

        Re: Where do the keys come from?

        But you would still have specific IPs to enter to reach those DNS servers. Those would then send you a key to verify and use. Either of those would be known by other systems, including those of censors. So contact to known addresses that are DNS resolvers or containing a key of a resolver that doesn't censor could be identified. What am I missing?

    2. Nick Kew

      Re: Where do the keys come from?

      They look the same to me.

      Not the same. DOH is a nice big extra overhead: help avoid any prospect of the world's IT infrastructure ever being ample to meet our needs.

  12. Stevie

    Bah!

    There's nothing new here:

    People admit there's a problem.

    People talk up a storm on the internet over the problem for years.

    Some bugger affected by the problem goes and designs a fix for the problem.

    People come out of the woodwork saying that the suggested fix is wrong, all wrong. They don't have a working alternative despite years of yap and yak.

    This is a model of how the internet-enabled IT community works (and by a curious coincidence how the Republican replacement for the Affordable Health Care Act does too).

    Fun story, completely unrelated to issue at hand:

    In Manhattan, a city with no public bogs, a German (I believe) company ran a trial of modular public self-cleaning toilets. They were an unparalleled success, everyone from the politicians in City Hall (Rudy Giuliani's administration if memory serves) to poor buggers needing to pee in a hurry agreeing that these were a perfect answer to a very urgent problem that was not only causing a public health hazard but was adding to the reasons for not visiting the Big Apple.

    But.

    The company didn't make a wheelchair accessible version of the toilet.

    NYC regulations state that if you want to install any public facility funded by taxes, it must be equally available to wheelchair users.

    So the highly successful devices that were a milestone in technology-for-the-masses according to everyone who had any interaction with them could NOT be purchased or installed, and Manhattan still smells of piss.

    As I said, this "nose off to spite the face" story has no relation whatsoever with the issue of encrypted DNS traffic. None at all.

    1. Orv Silver badge

      Re: Bah!

      I have pretty limited sympathy for a company that chooses to deliberately exclude people with disabilities. I've seen lots of portable toilet installations that included a toilet for people in wheelchairs. It's not exactly unobtainable technology. It's mostly just the same thing, but roomier -- which isn't a bad idea anyway given the ever-expanding girth of Americans.

      1. Stevie

        Re: Bah!

        Not the point of the story, Orv. The company didn't suffer much. The people of New York did. S'a metaphor.

        But if you want a wheelchair stupids story, look no further than the Long Island Rail Road, which invested heavily in wheelchair accessible EMUs. Every door opens wide to accommodate a wheelchair, and in order to get this design the cars only seat 80% of the capacity of the M3 cars they replaced.

        But.

        Only one car in each paired unit has a (wheelchair-accessible) bathroom.

        The walkway between the seats is NOT wheelchair accessible.

        The walkway between cars is NOT wheelchair accessible.

        Only one end of each car has folding seats to make accommodation for a wheelchair.

        So, design fail overall on wheelchair accessibility vs seating capacity grounds. There are other problems with the wretched trains too that have nothing to do with wheelchairs.

        Nice generalizing stoutist fat-shaming job on Americans, though. Guarantees you upvotes.

        1. Orv Silver badge

          Re: Bah!

          No fat shaming intended. That Americans are getting larger in the waistline is a simple fact, one that the designers of airline seats and many other public accommodations have yet to allow for.

  13. jb99

    DNS over http

    is an abomination. Everything web people touch seems to be broken and awful.

    1. Throatwarbler Mangrove Silver badge
      Go

      Re: DNS over http

      Fortunately, this is DNS over https.

    2. Christian Berger

      Yes, but why is it so?

      "Everything web people touch seems to be broken and awful."

      The more interesting question is why this is the way it is. My guess is that this is because of the huge influx of inexperienced programmers into the web as a platform. This means that half-baked ideas get adopted rather quickly. This isn't without a precedence BTW, the "Windows Desktop Application" word had the same problem in the 1990s when an influx of new, and therefore inexperienced programmers found employment writing trivial desktop applications. Out of this time brutally bad standards like "OPC" (OLE for Process Control) came, which were based on obscure features inside Windows which seemed "cool" at the time, but are now seen just as toxic as Flash seems to us now.

      Eventually those who were more experienced moved on to other systems, mostly Linux which at that point was based on well though out ideas put into software by comparatively experienced programmers.

      In my opinion its time to start looking for alternatives to the Web. The Web is broken beyond repair. Instead of longing for the past, we should bravely go into the future, shedding the shackles of modern Web design. A better world is possible!

      1. Mark 85

        Re: Yes, but why is it so?

        Instead of longing for the past, we should bravely go into the future, shedding the shackles of modern Web design. A better world is possible!

        Interesting concept and valid except for one thing... the corporates who own and control the web infrastructure like their profits and hate paying for anything "new". Don't forget the TLA's and FLA's who are heavily invested also. A better web and world is something they don't want either.

        1. Christian Berger

          Re: Yes, but why is it so?

          "Interesting concept and valid except for one thing... the corporates who own and control the web infrastructure like their profits and hate paying for anything "new"."

          You mean like the telephone companies hating the Internet back in the 1990s?

    3. Orv Silver badge

      Re: DNS over http

      The thing about technologies designed by "web people" is they exist and get deployed, while the architecture astronauts are still debating what color to paint the bike shed.

  14. Mr D Spenser

    Privacy or Commerce?

    I refuse to believe the argument that the motivating force for this is privacy. With a RFC to support them, browser makers will use this to funnel DNS requests thru their servers and sell the information thereby hijacking the revenue stream that ISPs currently own. Meanwhile, all of our content gets slower because what used to take 2 UDP packets to achieve will now take at least 8.

    Somebody please bring back the original Internet. The current one is a commercial driven dung heap.

    1. Christian Berger

      Well not quite

      ISPs still know what websites you go to by looking at the IP-headers. If you send a packet to an IP address you can just look up who this is registered to and know that the user was talking to that particular company.

      There's only 2 reasons for which this is useful:

      1. Censorship avoidance (until this service is blocked)

      2. Centralizing the DNS infrastructure so it's easier to monitor.

      Considering that both Cloudflare and Mozilla are large companies which could be coaxed into acting for people who would like 2 to happen, I don't think it's a good idea.

      But then again, the RFC is not really a big deal. That puts it onto the same level as "IP over Avian Carriers" (RFC 1149) or "Scenic Routing for IPv6" (RFC 7511).

      1. doublelayer Silver badge

        Re: Well not quite

        Except this isn't a joke, so there is some risk of it being adopted. If this happens, we should hope that it is easy to set up a less centralized version.

  15. Anonymous Coward
    Anonymous Coward

    Puzzlement?

    TLS requires certificate authentication to check that the other end is who they say they are.

    To be completely paranoid one would check revocation information. That part requires domain name resolution to check in with a certificate server's OCSP service, or fetch a list, etc. So how does that revocation check happen securely if I need to already trust the certificate of the DoH server!?!

    1. doublelayer Silver badge

      Re: Well not quite

      The best I can think of is that now you have to enter two IP addresses: the DNS address and the authority address. Either that or you have to enter a DNS address and the key it uses, so you find ones that you trust and don't allow the server to send you one. The latter approach requires you to find a trustworthy key, but if you're going to trust that your contact to the server is going through correctly, the key they announce will only work if it corresponds to the real server. It's certainly more complex now

    2. eldakka

      Re: Puzzlement?

      To be completely paranoid one would check revocation information. That part requires domain name resolution to check in with a certificate server's OCSP service, or fetch a list, etc. So how does that revocation check happen securely if I need to already trust the certificate of the DoH server!?!

      If you are checking a list, i.e. a CRL, for revocation, you already have that list locally, therefore checking against the CRL is entirely local, that's how CRLs work.

      If you are using OCSP, this is why you shouldn't be using 'plain' OCSP (RFC6960). You should be using OCSP Stapling (TLS Certificate Status Request, RFC6066) or TLS Multiple Certificate Status Request (RFC6961), both of which fix the privacy issues with plain OCSP.

  16. This post has been deleted by its author

    1. Jay Lenovo

      Re: Not sure...

      It's a matter of trust...

      VPN or otherwise, your connection requires you to make a trust assumption. Encrypted DNS alone isn't enough to keep you hidden under the sheets.

  17. EnviableOne

    DoH and DoT cover the confidentiality

    DNSSEC covers the Authentication/Non-repudiation

  18. Lewis R

    I'm struck...

    ...by the sheer number of people commenting who do not understand how DNS requests are sent or received, how DNS proxy works, and how zone transfers happen.

    The real security concern for DNS is update security, to ensure that only authorized changes are made to a specific domain's addressing. DoH does nothing to ensure that integrity (neither does DoT, for that matter). True privacy on the net is a myth, so obfuscating lookup traffic is all form over substance. Every intervening router knows from whence the traffic originated and where it is destined. This is like printing phone books in code.

  19. DerekCurrie
    Holmes

    Meanwhile: DNSCrypt is here and now

    DNSCrypt:

    https://en.wikipedia.org/wiki/DNSCrypt

    https://www.opendns.com/about/innovations/dnscrypt/

    I use it 24/7. I was a beta tester for years. Over time it has become increasingly reliable. There are 100+ encrypted servers to choose from located all over the world. It's entirely free.

  20. cmaurand

    This is all BS

    Google and Cloudflare want your dns traffic. That's what this is about. A one stop shop to see what you're looking at and to send you a more targeted set of ads and propaganda. If you don't think that traffic won't be logged, I have a bridge I'd like to sell you in ... They are going to dcrypt that traffic and make normal DNS requests to authoritative DNS servers scattered throughout the world. This solves _nothing_. Google's DNS resolvers are slow and don't take updates very well, either. I've had them return incorrect information for hours even days after the TTL on a record had expired. I run my own hosting servers. The have TLS enabled and they can take requests over TCP. The main security problem that is not liked is that DNS traffic uses UDP and not TCP. UDP can be faked easily. simply moving to a TCP based model instead of a UDP based model. As Paul Vixie said, this problem has already been solved. It's up to each OS vendor's resolver to use the more secure protocol if it's available. At any rate, it's going to slow DNS to a crawl.

  21. herman
    Pint

    D'Oh

    Obviously DOH is best.

  22. XerxesPST

    I guess this bypasses PiHoles and edited hosts files. No wonder Google wants it in their browser. This ensures that users can resolve the ip-address to their ad-servers.

  23. cmaurand

    This is about control

    This is about control and making it easier for corporate and government tracking and getting records for DNS searches without actually raiding someone's machine. Nothing more. DNS over TLS is already defined and solves the problem. Thankfully, there are coming implementations of DNS resolvers other than Google's or Cloudflare's that will do this and changing your browser to user your own or a public one other than Google's or Cloudflare's. Call me paranoid, but I don't trust either company no matter what they say publicly.

    The solution is trying to solve a problem that doesn't exist. Moreover, Google and Cloudflare are going to send out normal un-encrypted udp requests to the root servers and then to the authoritative servers for any domain, then encrypt and return the results. the HTTPS protocol is slow and now we'll have yet another layer to add more latency.

  24. Anonymous Coward
    Anonymous Coward

    Even Xzibit would be scared!

    To even think up routing a basic protocol *over another* basic protocol… only the same batshit insane people who thought having an OS platform (HTML5) *on another* OS platform (your actual OS) was a goos idea, come up with something *that* insane!

    Even Xzibit would tell you to take it down a notch at that point!

    I wonder when JSLinux will become mandatory… browser in a browser included, … and they will route IP, nay, Ethernet over XML/JSON over HTTPS.

    OH WAIT! They already went full retard, err, WebSockets!

    I personally talked to the WhatWG leaders, have my background in neuro-psychology, and I hereby attest that these people need to be put in a mental asylum!

    The harm they do to society as a whole, is on a terrorist group level. A successful one.

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