"Network service providers...will be allowed to signal that certain capabilities like content filtering would be adversely affected by DoH'
That will be all of the ones that make money by selling your data or by user typos.
On Friday, Mozilla said it plans to implement the DNS-over-HTTPS (DoH) protocol by default in its Firefox browser, with a slow rollout starting in late September. Under development since 2017, DoH transfers domain-name queries – which try to match domain names with server IP addresses – over a secure, encrypted HTTPS …
Yeah, (today) Firefox appears to be one of the good guys. Yeah, I trust my government (US) more than I trust my ISP (Comcast) when it comes to abusing my traffic data. But you know who I trust more? My own **** self. _I_ set my DNS resolver. And anyone who subverts that is NOT acting with any level of respect for me. And _even if_ they are genuinely acting in my best interests, that depends entirely their accurate assessment as to what those interests are.
I know that there are a lot of scenarios where this would be a GOOD THING. Today. But crossing the layers like this creates entirely new attack surfaces.
I only disagree on your last point -- I don't see where this is ever a good thing! DoH breaks a lot. It only protects against one phantom menace, that your current DNS provider or ISP is spying on your queries. But they're not. (There is enough other spying that DNS is not worth the effort.) Instead, it feeds your browser queries to Mozilla's spy, er, DNS engine, where it can spy on all of your browsing, override all of your DNS-based filtering, and put your DNS queries into your browser cache where they can be spied upon more easily. It's just a rotten idea that fails to die. Users should be advised to turn it off if it is activated, and to abandon an otherwise good browser if it becomes mandatory.
"It only protects against one phantom menace, that your current DNS provider or ISP is spying on your queries. But they're not."
AFAICS, the only reason that Comcast for example wouldn't be spying on user DNS queries would be that doing so requires a certain amount of intelligence -- historically not Comcast's strong point. I'm sure that the same is true of many other ISPs.
But overall, this sounds like a dubious idea. Why not let the user (me) decide if they want to "secure" their DNS queries? And default to "the way it's always worked" rather than "The way we think is good for you."
> Yeah, Comcast is a multi-billion dollar company because they are dumb. Nailed it.
Don't be naive. Comcast is "a multi-billion dollar company" because they have (at least near-) monopoly power in many of their markets.
And a gaggle of well-paid politicians making sure it stays that way.
Less smarts are required when the game is rigged in your favor.
I was annoyed to recently discover a chromebox continually connecting to 188.8.131.52:853 although I run my own DNS servers which are specifically configured everywhere: statically, dhcp4, ip6 slaac/RA .
As an aside, I'm also annoyed that the only way to have fine grained control of IP6 on android>5 , and chromeos appears to be to munge/spoof slaac responses because there is no apparent other way to configure it.
But yeah, DNS over TLS/https could potentially lead people into a false sense of security - standard consumer dns configuration could only potentially leak information to the ISP. If the ISP is relying on their DNS to filter, they are doing it wrong. And if they wanted to gather info on your usage, they would largely not need DNS to do it, and could only really be blocked from getting what information they can if you use a VPN, and in that case the whole issue is moot anyway, as a properly configured VPN won't expose DNS information to the ISP (just the dodgy vpn provider you trust!)
Yes, normal DNS lookups are not encrypted, and unless DNSSEC is used, not secure against tampering, but there is worse to worry about than your dns lookups, which get diluted with the dns traffic from other isp customers.
And this is before going into geolocation issues...
I'm little suprised you've gone to the effort of setting up you own DNS Server, yet dont understand the basic principle of dns lookup i.e. the CLIENT decides where to go to get its dns from. All a DNS server does is say "hey i can do your dns for you if you cant. But if the client has it set, then it will use that first.
"Sorry, when you're inside my network I decide what is allowed and what is not."
This. I still think this is a long term attempt being engineered by advertisers under the thin disguise of security to stop pi-hole like setups from preventing a lot of the phoning home and tracking.
I too have seen more and more hard coded 184.108.40.206 in Internet of shite devices that think they have the right to connect to wherever they want, download and run whatever they want, and to send whatever data they want to about my network to whoever they like, whenever they like, and using my bandwidth to do so.
It wouldn't even be so bad if their code was not so badly written. For a recent example - a logitech harmony hub that if it can't get a response form 220.127.116.11 it tries thousands of times a second to do so until it can, trashing the network in the meantime for everyone else. That is now disconnected in a drawer. It is the arrogance that "there must be a connection and therefore this device must have a right to use it however the manufacture thinks fit, including purposes outside of those which the device was bought for"
Is it beer o'clock yet? Have one on me!
My point was not the fact that I can get around it, or even that there may or may not be some hidden option somewhere to actuall tell it to use what you tell it to (I don't know chromeboxes) - my point was that despite it having it's ip4 and dns configured statically, and despite dhcp and RA on the network pointing to my servers something on this chromebox (whether the whole box, or one app, I haven't yet looked) was using 18.104.22.168 off its own bat.
For MY network, MY DNS specifies domains differently for "inside the net" vs "outside the net".
Is their "DoH" gonna be able to FIGURE THAT ONE OUT correctly? or will CLOUDFLARE attempt to RESOLVE MY INTERNAL ADDRESSES ???
http://badmachine/ -> link hijack page
http://my-internal.lan --> link hijack page
icon because, 'DoH' !!!
"I'm little suprised you've gone to the effort of setting up you own DNS Server, yet dont understand the basic principle of dns lookup i.e. the CLIENT decides where to go to get its dns from. All a DNS server does is say "hey i can do your dns for you if you cant. But if the client has it set, then it will use that first."
I'm a little surprised you've gone to the effort to make that post when it clearly shows you don't know what you're talking about.
Now, we all have holes in our knowledge; we all make mistakes; but it's particularly important to make sure you're bloody right when you attempt to correct someone in such an arrogant way.
Just some friendly advice.
And now the obnoxious bit: I have been running my own authorative nameservers for over 20 years, and over 25 years ago, was responsible for the DNS at the site I worked at, and was so much involved in helping the national networks team (Hello ICL, STE04, Stevenage) that it had been arranged for me to train the staff on how to run DNS properly (for the 100 odd locations across the country, although BRA04 seemed to be knowledgable, and were doing their own thing, and must have been annoyed at the corpoprate DNS system too)
As it happens, I left the company in 2001 before this happened, but have been involved in dns/ip4/ip6 networking for almost 30 years.
In the UK, the larger ISPs hijack all DNS requests (to port 53) regardless of the resolver one might set.
That happened to me when I had NTL (now part of Liberty Global); I had tried setting up OpenDNS as the resolver, but the requests were never being sent there - turns out the ISPs use DNS
hijacking monitoring to implement the IWF list.
I rather object to the ISP deciding whether I can actually use my preferred DNS provider, so in some circumstances DoH might be useful.
> Plusnet don't, and if you use different DNS servers, you can access those sites. I would imagine BT works the same way as Plusnet.
The short answer is, it depends.
If you've got BT's parental filtering turned on, and then try and use a non-BT DNS server, all your connections will be intercepted and interrupted with a blockpage (you must use our servers yada-yada-yada).
If you don't have that enabled on your account, though, the queries will be passed through to the main provider, for the most part. Certain blocked domains will continue to be blocked though (with nothing obvious as to what differentiates them).
But, in any case, relying on the fact a provider doesn't do it now isn't really sufficient, they can change that trivially at any point.
The majority of ISPs across the globe, in my experience, do intercept queries meant for 3rd party DNS servers though (particularly in countries more openly censorious than our lot)
The fact that it's going through CLOUDFLARE is what bothers me...
Might as well go through Google's 22.214.171.124 resolver, which is better than an ISP "spelling error hijacker" resolver, which is better than a zillion other possibilities, BUT INFERIOR TO DOING THE QUERY YOURSELF FROM THE ROOT SERVERS.
This isn't REAL privacy. For that, you need TOR. And even THEN, it's STILL subject to MITM and hijacking.
None of this makes any sense.
I have content filtering set up at home at network level by pointing DHCP-supplied resolver settings at OpenDNS where I have various categories blacklisted.
If the family member web browsers start ignoring the host resolver settings and instead going to Mozilla's pre-determined DoH caches, then that completely subverts my own DNS-based filtering setup since the browser is completely unaware of this.
And no please don't tell me I should have a Mozilla account set up for each family member. I have spent years discouraging my kids from signing up to accounts on the internet.
You can do one of two things:
1: Block all HTTPS traffic at the firewall, get the kids to use their own provider and take their own legal responsibility. Bonus effect is Tor would work out of the box.
2: MITM all HTTPS traffic and block DoH queries. This one is increasingly common, and will only become more common while law continues to ban ideas (making legal owner of that connection criminally liable for some actions the users take on the network, like visiting banned pages) and idiots at the browser companies think taking away the tools needed to keep the network owner legally safe is a good idea.
Somehow I think the widespread acceptance of MITM *or* a dedicated Internet connection per person (think mobile phone; great for tracking, horrendous for privacy) is a step backward from where we are today. And yes, following the money it does look like it's designed to strengthen large American companies' stranglehold on the data of the world.
I somewhat disagree. In most countries there is specific legislation that compels them to hand over data. Since Mozilla (or whomever is the DNS provider of choice) wouldn't be considered to be an ISP, it would be much more difficult to compel them to handover data.
I would much rather take a chance on an organisation that can't be compelled to handover data than one that definitely can.
I think that's the point of DoH.
The same applies to VPN use. Yeah you still have to trust them, but there is considerably less legislation that forces them into handing anything over.
It changes the legal playing field.
I load dns block list from winhelp2002.mvps.org, pgl.yoyo.org adservers, hosts-file.net adservers, adaway.org, someonewhocares.org, and hostsfile.org on my router.
What this change means to me is that I will start seeing adverts!...
For the average person it will be a win. For the tech-aware types out there then it will be a pain in the bottom.
I am sure that they will allow you to change in the future to some of the main providers, but Honestly I don't like it at all. While it will be nice to remove that attack vector, it will also be horrible as now it's moving in a direction that we will find it impossible to detect something going on wrong just by DNS request.
Interested to know whether the DoH server will be configurable (presumably not by DHCP though). If so, you could potentially carry on running your own DNS, just now it’s going to have to include an awful lot more cruft. This is my primary reason for disliking DoH so much. Given many people run DNS servers on relatively low powered machines (home routers being a classic example), why would you select a protocol that involves wrapping every transaction in plaintext HTTP? Resulting in not only the inclusion of an SSL / TLS server, but a seemingly completely unnecessary HTTP one too. I can see why Mozilla might prefer it, but why is anyone else going along with it?
> If so, you could potentially carry on running your own DNS, just now it’s going to have to include an awful lot more cruft.
I already do, it's really not that bad to set up, and the overhead isn't that massive either (at the server end, I don't mean HTTPS vs DNS).
TBH the main reason I set it up, though, was originally so I'd have explicitly configured a service I trust rather than letting a default kick in.
With pi-hole behind it, and Intra on my phone, it means that my phone can never resolve the manufacturer's Telemetry domain, even when I'm out and about, so doesn't send them god knows what either. It tries to resolve that name rather a lot.
"I am sure that they will allow you to change in the future to some of the main providers..."
"Interested to know whether the DoH server will be configurable..."
You can already configure which DoH provider you use, Mozilla even suggested alternatives to their preferred partner in the original blog post announcing the feature. You can also set different levels of 'enabled' which include fallback to standard DNS in event of failure.
This is Mozilla, not MS, Google, Apple, etc.
And how is this implemented? To encrypt DNS and decrypt DNS requests, there has to be a ‘man in the middle’ that can ‘read’ your DNS requests. Thus to make this work for all major vendors, we all need to get another (root)certificate that encrypts and sends our DNS requests to our preferred DNS server, there it gets decrypted and forwarded, only to have the answer encrypted back to the user and gets decrypted in the browser to get redirected to the requested website.
Thus as I read it; we either encrypt the DNS requests and have our favourite browser vendor be a man in the middle that can decrypt _everything_ after that... OR we just accept that our DNS requests are unencrypted, but ALL traffic afterwards is unable to read for ANY other party (As it is now).
I know which one I would choose...
It's somewhat worse than that, even. While the DNS system itself is decentralised, in that each domain may use its own servers and each client may use its own resolvers, caches, and forwarders, nothing will save you from the root servers. Not DoH, not running your own resolver, nothing. If you run your own resolver, then the root server operator can build a database of every 2LD you query against your own IP address. If you use a bulk resolver service like Cloudflare or Google, then that operator can do the same. If you use DoH, then your DoH endpoint (the HTTPS-to-DNS gateway, really) can do it.
There is really no way around this as the system was designed. You could even try scattering requests over dozens of third-party resolvers, but each one would still have a database of that subset of your queries, and there are only so many such services. Likewise, you could operate dozens of your own resolvers, but the data collectors can easily determine that you own all of them and reassociate the disparate records with your name.
If you want privacy, you'll need to get an up to date copy of the Internet-wide "hosts" file, the name resolution technology used before DNS came along. Good luck with that. There are ways to solve this, but they require a great deal of engineering work not to mention a disruptive and challenging global rollout. Not only do few people have the appetite, but all the large players have strong incentives to make sure it never happens.
Yay! What a wonderful world.
No, that's not how it works.
Firstly, *not* running your own recursive server *is* a way to stop intermediate authoritative servers (including the root servers) from knowing who you are, as all the DNS requests they receive will be from the DNS server (typically your ISP) that you forward requests too.
And if you do use a recursive nameserver, the roots would only traditionally get to know the very first fqdn you lookup in a certain top-level domain.
e.g. lookup for fred.com followed by a lookup for bloggs.com - only the first request would go to root servers, the second request would go to the .com servers.
And now, with DNS Query Name Minimisation ( https://tools.ietf.org/html/rfc7816) they won't even get that, as instead of the first lookup speculatively sending the full FQDN, it will only ask for the information regarding the delegated nameservers for the zone.
I.e. the root servers will only know that you've looked up a .com, or a .uk etc. address, and never what address within that domain.
Same principal follows as you moved down the dns tree.
In practice however, doing a recursive query, i.e going through the root servers for the TLD’s and get sent down for each and every subdomain is fscking slow, so in practice noone ever configures that. I think 98% of all DNS queries over the Internet is not recursive, but just bounced off from Authoritive Zone server to the next.
And also, after rereading your comment, I think you got recursive requests confused just the other way around, since recursive starts at the root servers (with all TLD’s), trickling down to all respective authorative servers, while “normal” DNS just asks its configured DNS server for a record, DNS server does not know, forwards to next “configured” server etc.. up until no answer is given and just THEN a recursive query is done
In practice however, doing a recursive query, i.e going through the root servers for the TLD’s and get sent down for each and every subdomain is fscking slow, so in practice noone ever configures that.
That's exactly how DNS servers are setup in your ISP, in companies, all over the place. In general, domestic users simply have a caching DNS that forwards to the ISPs recursive server. Office environments will typically have a recursive server per lan/site (depending obviously on the number of clients), which the host computers are configured to use directly.
Of course, in most big companies, the root server will be internal, not the internet servers, but the configuration principle is the same.
And the whole point is its *distributed* - when my server looks up anything under .co.uk, it remembers (until cache timeout) the nameserver details for .co.uk and for all subsequent requests goes there. In other words, the requests only go to the root for the initial request for a zone. All paths down the DNS tree are remembered, so they aren't walked every time.
(The flattening of dns names encouraged by marketing types obviously concentrates the load on specific zone servers, which is against the way DNS was designed to be used - however there's no escaping this issue whether you use a forwading server, or your own recursive)
I think 98% of all DNS queries over the Internet is not recursive, but just bounced off from Authoritative Zone server to the next.
You're wrong. Firstly, yes, most consumer dns setups are caching forwarding servers that use the recursive servers of the ISP. In operation, that's really no different than simply using the ISPs nameservers directly, but you have the advantage of local caching, which helps with repeated lookups, and also if another client on your home network attempts to resolve the same address as another one did, the cache helps there too.
ALL the ISP servers will be recursive. It's possible they in turn could be configured to forward elsewhere, but it's very rare for that to happen, and is only useful in a very small number of special cases.
As for "bouncing from one server to the next", authoritative servers don't look up zones on the behalf of the calling dns - that's what recursive servers do (and whilst an authoritative server can also be a recursive server, you don't want to do that, and will rarely see it)
If by "bouncing", you mean the authoritative server refers the calling DNS to a more relevant server in the DNS tree, then yes, that's what happens - that's what recursive lookups are!
And also, after rereading your comment, I think you got recursive requests confused just the other way around, since recursive starts at the root servers (with all TLD’s), trickling down to all respective authoritative servers, while “normal” DNS just asks its configured DNS server for a record, DNS server does not know, forwards to next “configured” server etc.. up until no answer is given and just THEN a recursive query is done
That is how recursive servers work, yes, but that's how dns works. Your local forwarding server delegates the request to your isps server, but that DOES NOT blindy forward it to another server. How would that be configured? How would its parent be configured? and its parent?
No, it does a recursive lookup. From the top. Gathering and caching new zone data on the way down.
(It's possible that if an ISP has more than one recursive server, which they should!, then the servers could share caches, but that's not seen often, and even then, it's not relevant to what we're discussing.)
P.S. For the pedants, I use the term "ISP" loosely - in an academic or business, "computer department", or "IT crowd" would be more appropriate!
P.P.S. I didn't downvote you - I think your downvoters are basically saying "I think you're wrong, but I can't be arsed to reply"!
And now, with DNS Query Name Minimisation ( https://tools.ietf.org/html/rfc7816) they won't even get that, as instead of the first lookup speculatively sending the full FQDN, it will only ask for the information regarding the delegated nameservers for the zone.
While interesting, that is not a standard even under consideration. As per that document itself:
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.So it isn't even a proposal, it's an RnD document, years away from proposal status let alone formal acceptance.
Which is a pity, as it sounds interesting. Will have to see if there are any DNS servers/proxies that are looking into this, as I already run my own recursive resolver.
> So it isn't even a proposal, it's an RnD document, years away from proposal status let alone formal acceptance.
It's in active use all over the internet.
Whether it should be, given it's not yet a formal standard is something else, but it is very much in use in the wild.
Unbound definitely supports it, I believe BIND and pdns do too
I'd say it is being used as a logical and sensible "technique" that many different people have stumbled upon independently, as it makes sense. And that's probably what kicked off the experimental RFC, that it was noticed several independent implementations were already doing this, therefore it might as well be standardised.
Yeah, that's the thing. As it doesn't require any protocol or design changes it doesn't need any sort of format declaration, it will be compatible with all nameserver already that follow the spec correctly, and as Ben says, is already in widespread use...
Are you sure your own recursive nameserver isn't using this already? Mine is (unbound), and I don't recall setting that specifically. (Interestingly, it uses shortened 'A" rather than "NS" lookups, presumably to get around some of the issues with broken nameservers mentioned in the rfc)
"Firstly, *not* running your own recursive server *is* a way to stop intermediate authoritative servers (including the root servers) from knowing who you are, as all the DNS requests they receive will be from the DNS server (typically your ISP)"
Right, in which case your ISP (or whatever recursive server you use) gets all your queries to associate with your IP address (and of course your name and address, etc). Which was my point -- you get a limited choice as to *who* gets this, but you can't prevent *someone* from getting it.
"And if you do use a recursive nameserver, the roots would only traditionally get to know the very first fqdn you lookup in a certain top-level domain."
So what? That's going to be most of what anyone wants to know. Which hostname or subdomain of a porn site or "unapproved" news site you asked for is of little interest. Practically speaking, the operators of servers supplying NS records in com. know exactly what you're doing. And, as above, if they don't, then your ISP does. Or Google, or Cloudflare, or whomever. Again, that's the point: there is no way to prevent *someone* from knowing what you're browsing (and it's not just browsing, either, of course, but that's what this article is about).
Yes, that is how it works. I understand perfectly well how the system was designed, and I stand by my assertion that it is fundamentally incompatible with privacy. DoH does nothing to change that.
You are muddling up replies to different people, but attributing everything to me.
Either write separate replies directly to each post you are replying to (i.e. use the reply button on each post you want to reply to), or attribute in your post the topic/quote you are replying to correctly.
That being said, of course at any point someone knows what you are accessing. You know what you are accessing, and the site you are accessing the materials on knows what you are accessing. The point is to minimise that list of "someone's" as much as possible, to minimise the number of people that could retaliate directly against you vs those who don't give a flying fuck because they are 10k kilometres away in another country who doesn't have jurisdiction - even if they did care - over you.
I am more concerned about my local ISP tracking and monitoring my activities. Building up a user profile, inserting ads they think I am interested in due to that tracking, selling complete packages of the data they are collecting on me to third parties like Cambridge Analytica, and so on.
If you use your ISP's DNS server, that means that the ISP itself, local law enforcement and security agencies (and just busybodies in your government who are neither) can get access to the history. If you use a DNS server located in a foreign country and don't use DoH or any other sort of transport encryption (VPN, IPSec, whatever - traditional DNS) then the previously mentioned bodies can still see what you are requesting. If you toss in some sort of transport/data encryption into the mix, then that is no longer the case - or, at the very least, harder.
I, personally, am more concerned about my local authorities being able to access my browsing/DNS history than I am some foreign government who has jurisdiction over the encrypted DNS server I am hitting. It's unlikely that foreign government is going to have any interest in personally repressing me (e.g. filtering content the government in its wisdom has decided I am too delicate to be able to handle), that is more likely to be the domain of my own own nations government. I mean, I doubt Ukraine's government cares whether I, a non-Ukrainien, access 2 girls 1 cup, whereas my local religious fundamentalist government, who have armed police at their beck-and-call just a few kilometres down the road, would be highly offended and would want to "re-educate" me for accessing that material. I doubt the Canadian government would care I was accessing material about gay rights, whereas my local fundamentalist government would want to have a word to me about that.
You said "nothing will save you from the root servers". That was your point. It was wrong."Firstly, *not* running your own recursive server *is* a way to stop intermediate authoritative servers (including the root servers) from knowing who you are, as all the DNS requests they receive will be from the DNS server (typically your ISP)"Right, in which case your ISP (or whatever recursive server you use) gets all your queries to associate with your IP address (and of course your name and address, etc). Which was my point -- you get a limited choice as to *who* gets this, but you can't prevent *someone* from getting it.
Of course, if you use the ISPs resolver, they get to see it, but unless you are encrypting your traffic, they get to see whatever they want anyway.
"And if you do use a recursive nameserver, the roots would only traditionally get to know the very first fqdn you lookup in a certain top-level domain."So what? That's going to be most of what anyone wants to know. Which hostname or subdomain of a porn site or "unapproved" news site you asked for is of little interest. Practically speaking, the operators of servers supplying NS records in com. know exactly what you're doing.
"So what?"? - You were talking about the root servers. The root servers won't know, however much you repeat yourself. "com." is not a root-zone.
And, as above, if they don't, then your ISP does. Or Google, or Cloudflare, or whomever. Again, that's the point: there is no way to prevent *someone* from knowing what you're browsing (and it's not just browsing, either, of course, but that's what this article is about).
Yes, that is how it works. I understand perfectly well how the system was designed, and I stand by my assertion that it is fundamentally incompatible with privacy. DoH does nothing to change that.
"So what?" - I never claimed otherwise.
You made a number of errors. I simply corrected them, and the justification in your response has absolutely nothing to do with what I said. Not once did I mention any form of overall privacy.
Or to use your logic, "I understand perfectly. I stand by my assertion that the sun rises in the east"
[quote]If you want privacy, you'll need to get an up to date copy of the Internet-wide "hosts" file, the name resolution technology used before DNS came along. Good luck with that. There are ways to solve this, but they require a great deal of engineering work not to mention a disruptive and challenging global rollout. Not only do few people have the appetite, but all the large players have strong incentives to make sure it never happens.[/quote]
I can very easily make my DNS servers think they are the top root servers and have never get any request leave my network. But as you stated, it would be a helluva job to make google or el reg available to my users without forwarders
There's some difference between querying several DNS systems, and querying a single one - the latter sees *all* of your query and can easily build a profile, while it would be much more difficult when the queries are spread over many different DNS systems run by different entities.
ISPs and systems like Google/Cloudflare are in a much better position to collect data and correlate them with others.
ISPs cold still extract data from unencrypted DNS queries - but it could be illegal, and when caught, they could face consequences.
To make things more clear (doing a simple ssl handshake, but explaining the loophole afterwards);
Alice and Bob want to talk about their secret shit. Alice calls Bob through a BT land line and says; hey Bob, gonna send you a message. To do that, I need your public key to encrypt my message. (Lets assume there is a spy on this land line). So Bob tells Alice his public key to encrypt the message so he can decrypt the message with his own private key. However, since we have a spy on the line who knows that Alice will send Bob a message that is encrypted with his public key, our spy could think; right, I will send a message in name of Alice with the public key of Bob encrypting the message and Bob can decrypt it with his private key. So we need some verification. To make sure Alice sent the message, she SIGNS the final message with her private key. So when Bob uses Alice’ public key, he can make sure that Alice sent the message.
Now... what this article is implying, is as follows; Mozilla (Jasper) says; dude! You are yelling that you want to reach Alice, but instead of yelling, I could be the one that silently tells Alice that you want to reach her. However, for Alice to know that I am not lying; I need to resign your “shout out” with my own ciphers. To do this I need to resign your original message with my own keys though. When you get contact with Alice and all is mighty fine, but you keep exchanging messages through me (Jasper). I can read your (Bob’s) messages, I encrypt them for you, Alice reads it, sends messages back, but all in all I can still read all messages between you (Bob) and Alice.
So.. would you rather have people hearing that you as Bob want to talk to Alice and encypt messages after when you do a ‘handshake’, or move the “Hey Alice” shoutout to a middle man that will see all your messages in between afterwards?
I'm afraid your description is not accurate. You have described encryption of content correctly, but that's not going anywhere. Your statement "move the “Hey Alice” shoutout to a middle man that will see all your messages in between afterwards" is incorrect because that middleman only informs you how to contact Alice; future messages between you do not go anywhere near the middleman and remain encrypted using the old protocol. This is a better parallel:
Alice and Bob want to call each other and exchange encrypted messages. They can exchange public keys if only they can get a phone line. But neither knows the phone number of the other. Alice could call directory inquiries and ask for Bob's number. If she does this, she must trust that service to provide her the correct number, and she must accept that someone might overhear her request. In addition, someone might have intercepted her call to directory inquiries and be pretending to be them, but she could not tell. With DoH, she has a secure connection to the particular system she trusts. She must still trust that they are giving correct information, but her request to them cannot be intercepted or overheard. Once she has the number, things proceed as before.
That's the good version, explaining the positive aspects. However, DoH also has some downsides. It prevents someone else from tampering with the DNS data, but it also prevents you from tampering with the DNS data. Sometimes, you would like to edit that, whether it be for faster caching or content blocking or internal system redirection. That's why DoH must run alongside rather than replace normal DNS. If it becomes mandatory on something, I will no longer use that thing. It's not, as some claim, a security risk in and of itself--if malware can be detected by a DNS request, the malware can also be changed to use one of a number of alternatives for finding an IP address including having one hardcoded in it. But it does allow circumvention of many tools that are quite important. In most corporate environments, it should probably be disabled and made explicitly against company policy.
It prevents someone else from tampering with the DNS data, but it also prevents you from tampering with the DNS data. Sometimes, you would like to edit that, whether it be for faster caching or content blocking or internal system redirection.
DoH doesn't prevent that at all -- it just makes it a bit harder than it is at present (while also giving you the advantages that you listed). It's not rocket science to set up your own DoH proxy server (a sort of friendly MitM) that filters and redirects in any way you choose (and which is entirely under your control) and then re-encrypts the result using your own DoH key.
So long as Mozilla are going to let you specify the DoH server you use (and its keys) and not send you directly to Cloudflare without passing "Go" you have lost none of the flexibility you currently enjoy. It's just a little more effort -- in return for a little more security.
All correct, but you're missing the biggest drawback: metadata. The trusted directory service knows that the caller is Alice and that she wants to reach Bob. Leaving aside the corporate overlords who want to snoop or filter using DNS (which doesn't actually work, but that's another can of worms), the main argument is that even if we trust the directory service to supply correct answers -- and it's not clear that we should -- we don't trust it not to record and use (i.e., sell) the metadata.
To make it more concrete, the mere fact that someone called a particular phone number can land that person in prison or the morgue. Even if that number was in fact the correct one, and even if what was said over the line is not known. Plenty of agents have been blown this way, and it's a fairly routine means of oppression in totalitarian systems (i.e., all modern governments) that lack the facilities to record every call but have a direct tap into call records. There's absolutely no reason to imagine that DoH or any other centralised non-anonymous DNS implementation will be any different. The metadata is centralised, it is toxic to privacy, and it will always end up in exactly the wrong hands. The mere fact that centralising the service also makes it an enormously valuable target for silent intrusion and poisoning (even selective poisoning!) would also be sufficient to rule this out.
The objections that have been raised are important as well, but these are the big ones. That this makes it more difficult to filter out crap is really secondary and can be easily fixed by adding features to the client code (or better yet, providing a DoH OS resolver module so that the existing prioritisation of lookups controlled by nsswitch.conf or similar mechanisms will work as intended). Unfortunately that won't fix either of the real problems.
Actually, in this case they do add the extra bloat of HTTP to the process. This isn't just DNS over TLS on it's own port, this is DNS over HTTP over TLS using port 443.
That is, it's every bit as bad a design as you could hope for (actually not quite, they could cook it all up as a SOAP transaction to get some real bloat going).
As already pointed out this (DoH) is every bit as bad as DNS over HTTP over TLS.
There is a competing standard DoT which is running DNS over TLS skipping the whole HTTP thing. But for some reason Google and Mozilla (organisations that deal primarily on the web, and in web technologies) don't appear to recognise that the internet is more than just the web and so everything needs to http(s) for them.
The truth of the matter is that all they care about is bypassing firewalls.
Everybody that uses a browser tends to get universal tcp/443 access, and using a new port for dns over tls would require cooperation from IT admins to work on any corporate network and could easily be messed with by ISP and 'others'.
Whatever their motivations the fact of the matter is that they are making "the web" more secure at the expense of "the internet" that carries it. DoH is not the correct solution for anything other than the web, although in that narrow context it is an improvement, but for everything else that uses the internet DOT and/or DNSSEC provide better solutions.
"although in that narrow context it is an improvement"
I'm having a REALLY hard time seeing a central bloatware cloud bank, one that uses TCP+HTTPS+TLS, as an _IMPROVEMENT_ , over even hitting the root servers to look up the domain server and then sub-domains [as needed], as compared to the somewhat simple mechanism of CACHING DNS SERVERS (with UDP requests) which have been used since the very early 90's as I recall...
So please explain, HOW this improves things?
DoH is designed to fix a very narrow problem for web users who might be getting their traffic snooped on (note that it only works for pure web traffic). That problem is that the domains they lookup through DNS are typically in plain text. So the snooper knows what they are (ignoring for now the fact SNI headers are not yet encrypted) DoH protects that information. So in that very narrow use case DoH is an improvement.
DoT also solves that problem, and doesn't tie the hiding of DNS traffic to web traffic, but it's detractors argue it can be blocked more easily.
Because the port is known, fixed, and dedicated. That means the bad guys know exactly where to look. They can just hijack ALL traffic from that port, wholesale, and be able to become a MiTM. The only way to block wholesale port hijacking is to obfuscate using an already-widely-used port. You can't get much more widely-used than 443.
True, it's harder to block DNS lookups that use DoH, but it's not impossible, and there exist valid reasons for wanting to control the DNS information available on a network.
Similarly there are valid reasons for wanting to bypass those controls.
My issue with DoH is that it is only a valid solution to a very narrow subset of the issues affecting DNS that also affect the web. DoT isn't that much better on it's own, but it at least acknowledges the internet is more than just the web. DoH is also skirting into the realm of "technical solution to non-technical problem" and that never really works.
I'd like to know how you're going to block DoH without blocking HTTPS wholesale? Both use the same port and the same encryption protocols, adding obfuscation. Thus the power of the big providers' "I dare you.": about the only way to block DoH through them is to block THEM: breaking a lot of stuff along the way.
By blocking HTTPS wholesale. You appear to be assuming that isn't a valid network configuration. Believe it or not many large corporate networks do so, and use web proxies to allow connection to websites (including HTTPS sites, some with MitM corporate certs, some not) and those proxies whitelist access based upon the domain you try to connect to, and route that traffic for you.
"You appear to be assuming that isn't a valid network configuration."
In the days of the Chinese Cannon and other modify-cleartext-in-transit attacks, that's going to depend. Plus, if you're set up that way, it probably wouldn't be too much effort to have application whitelists and to add DoH capability to your internal DNS resolver.
DNS runs on either udp port 53 (classic configuration) or tcp port 53 needed due to longer records that couldn’t fit in a standard packet.
Neither of which uses http as the transport mechanism.
This idea of Mozilla’s doesn’t play well in corporate environments. The proxy server will now have to be able to figure out where to send dns requests to?? How is it going to deal with the local dns to resolve internal ip addresses and then kick out to the internet for other requests.
It also appears that support for this protocol is lacking from suppliers.
Windows dns server doesn’t support it
Infoblox recommend you block it
It would certainly break Cisco Umbrella.
Just google, cloudflare and Mozilla seem to want it.....
Dnssec on the other hand is a better well supported protocol
"Dnssec on the other hand is a better well supported protocol"
from what I've read about it, yes. Still imperfect and NOT being supported by the root servers (last I heard/checked) but who knows, put AS MUCH EFFORT into getting DNSSEC to work properly, and UNIVERSAL SUPPORT at the client end, and now you have a reliable system that's not easily hijacked and still has decent performance... [from what I recall, reading about these things].
I should look at DNSSEC again, with my own server. The lack of wide support kept me from messing with it before. Maybe now it'll b better?
No, it's a brain burp on our end. We meant unprotected DNS queries, not HTTP. HTTP on the mind. It's fixed.
Don't forget to email email@example.com if you see anything wrong, and we'll fix it up right away. It's hard to spot requests for clarifications buried in the comments hours after publication: there's so much for us to go through while we're trying to get articles out the door.
Default behaviour in Firefox is to fallback to the OS configured DNS if the DoH resolution fails (fail including NXDOMAIN here). The behaviour is set by network.trr.mode
What it might do, though, is break any split horizon DNS you might be doing. My approach to that was to run my own DoH servers and split-horizon them (i.e. dns.bentasker.co.uk is 192.168.1.1 or whatever at home, and points to my public infra when resolved from the net)
This post has been deleted by its author
You guys have to remember that although in the UK and other western countries your ISP's DNS lookups are generally not interfered with, (although the pr0n filters put in place in the UK by some ISPs do block what websites you can access by DNS filtering) in some more authoritarian countries your DNS queries are all logged and monitored and even intercepted so that websites and services that the government doesn't like will be sink holed and a list of IPs trying to access them logged.
If you wanted to you could create your own DOH server using a cheap VPS rather than use the cloudflare services, so you know that your DNS requests were not being logged, there are several tutorials online on how to set one up and you can even run Pi-hole on the same server as well to filter ads.
I mean you don't know for sure if you can trust the DNS resolver of your ISP or even your own DNS resolver. There is always a chance that some one broke into your house and bugged it.
With DoH over Cloudflare you can finally be sure that the NSA will store and archive each one of your DNS requests. After all that's the main point about using it.
you can always set up your own DNS that does queries directly from the root servers...
DNS is what the internet is framed around. Without it, the internet BREAKS. Mozilla is attempting to do a hijacking of the internet's basic functionality. What makes them (and Cloudflare) *FEEL* so powerful? This change wasn't agreed upon, it wasn't proposed, it wasn't voted on etc.. There may have been documents submitted at one time but if MICROSOFT or GOOGLE were to do this, what would the reaction be?
How about "from now on all windows operating systems will do DNS 'like what WE want' and invoke Microsoft's DNS servers". Would *THAT* go over well? I doubt it.
WORST! FEATURE! CREEP! EVAR! [even worse than 2D FLATTY]
If you're worried that your ISP is monitoring/recording your DNS lookups, what exactly do you think you gain by running your own DNS?
You won't be in the ISP's DNS servers logs, that's about it. They can still quite easily pull the qname's out of your queries (or if your server is on your LAN, your server's upstream queries).
If they want to interfere, they can trivially redirect every one of those queries to their own infra and have it answer it.
Your suggestion doesn't, for a second, resolve even one of the issues that DoH is intended to address. It's like worrying that the ISP might be monitoring your HTTP connections, so running a squid cache at home for your computer to talk to first
Firefox, has no business doing its own DNS
Although, strictly speaking, it isn't "Mozilla's own" DNS, I do agree with the point you make. Especially on the "roll out for everybody, tweaked by the tech savvy" approach. There should maybe be the realisation that (please forgive the seemingly popular phrase) nothing is absolute, all is relative, and that ones own (== Mozilla) reality/ bubble might not apply to the rest of the world. For example: as far as I understand this DoH will run through Cloudflare. They state they are committed to privacy. Which I'm sure they are. But they're also subject to US law. And use Google services (126.96.36.199).
And this "switched on silently for convenience" configuration is claimed to be allegedly better/ more trusted than the current DNS all FireFox users use currently. Like for example the DNS of my current Icelandic ISP. Really? And my work (Swiss university) DNS is worse than the Cloudflare/ Google default?
So yes, maybe it is much better for some (average US?) users, because the US environment is build on a different philosophy. But why assume the US is the guiding golden standard here? Or the UK? Or anywhere else? Would Mozillas approach with a default "one size fits all roll out" DoH really be better for all FireFox users?
Data channel locked down with https, DNS locked down with DOH, content locked down with DRM. Emails rejected unless they come from one of the big providers. Barriers to entry erected. Only Big Business allowed to play soon.
It's not the internet any more Toto, it's Cable TV Mk2, with a credit card reader as a viewing card.
Paranoid? Maybe. True? We'll see...
What is the difference between passing off ALL of my DNS queries to Cloudflare (a US company) and using Google's 188.8.131.52 DNS, also a US company?
In both cases data about what I do online gets exported to a country where privacy protection is at best stated intention, so what am I missing?
This post has been deleted by its author
If by "using Google's 184.108.40.206" you mean just configuring it on your router/PC, then the main difference is that your ISP (and everyone on the path) can see your queries, as well as redirect them to their own infra in order to respond.
That's also true if you "just" configure 220.127.116.11 (Cloudflare) on your router
Where DoH differs is that the queries are sent over an encrypted (and harder to block) channel. You can configure that to go to Cloudflare, Google or some other server if you want. Your ISP can no longer redirect to their own infra (they won't have a valid cert) and can't see query or response.
DoT provides similar privacy, without the HTTP overhead. But, it's easier for the ISP to block as it uses a dedicated port - TCP 853 - so they can block that to force (most) clients to fallback to plain DNS on UDP 53.
I don't understand the complaints. Your browser will still send a packet asking for content from 123.234.345.456 the IP will still see the address in the packets, they will still be able to monitor where you're fetching content from. Where and how your browser translates "foo.bar.zim" into 123.234.345.456 is irrelevant.
Because 123.234.345.456 might be hosting thousands of different websites under lots of different hostnames so just knowing the ip isn't sufficient to target you. Knowing what you've just resolved to get the IP is a cheap and easy way to find out. For HTTP connections they could just look at the Host header, and even HTTPS connections they can look at the SNI header (which isn't encrypted) to find it out but that's more expensive and alternatives to SNI might be widely available at some point.
No, eSNI isn't part of TLS 1.3 yet.
Cloudflare came up with a eSNI implementation, so it is supported in some places, but isn't technically part of TLS1.3 yet.
What TLS1.3 *does* do is encrypt the cert exchange in the handshake. They decided it was stupid to block improvements on the basis of "but SNI" so encrypted the certs on the basis that eSNI could follow later.
How the hell am I supposed to know what cert gets returned by the server and which client cert was picked by the browser if the certs are going to be encrypted? this means I'll have to log into the server and extract the server cert and log into the client and extract the client cert in order to be able to to troubleshoot cipher overlap (specifically lack-there-of) problems.
I wonder how much taller Mozilla is going to make the error pages...I already have to scroll down to see everything on our wonderful 16x9 monitors...
I notice 18.104.22.168 sometimes fails to resolve some really basic stuff for random lenghts of time, I wonder if their over-optimisation or whatever snazzy anycast they have in place is not as reliable as they think. I've found quad9 much better and that can already be used in Android for 'private dns' which seems to work, instead of being shown my mobile provider's landing page for content blocked I just get timed out connections - meaning that at least my provider is properly blocking network access to that content rather than just the domain names, which leads me to think what's stopping other content blockers to just work on network level like that. If they know and update what a domain points to and block traffic to those addresses you'd still wont be allowed to connect to the servers no matter how you resolved the domains to those same IPs.
Daniel steinberg, determined to set the world on fire and just dismiss people's objections as haters and luddites.
Meanwhile some people really are appreciating the modern new world.
How can you be sure your ISP isn't spying on you on the quiet? Remember Verizon's Supercookie? Notice all the ISP-emblazoned pages when a DNS fails (even when you change the DNS IPs, meaning the ISP MUST be hijacking port 53 wholesale, something DoT doesn't fix because it's on a fixed port and ISPs can ALSO just hijack wholesale)?
I don't like my ISP but I have more trust in them than Cloudflare. I rather have my ISP track me than that US super spy Cloudflare.
Mozilla changing the default behaviour of DNS, handing all tracking info to 1 giant slurp corporation from the US causes a lot of questions about Mozilla intend. Yes it's customizable but who does that?!
(I do but it doesn't matter, most won't)
>DNS is the backbone of the internet.
Can't help thinking that DoH is a means to both control and reduce the number of DNS resolvers on the Internet. Be interested in knowing just how much money gets thrown at DNS resolvers . It would not surprise me that as a result of DoH the amounts being received by a handful of majors represent 90% of such revenues- just like ad revenues.
> I doubt Cloudflare will be able to respond faster to my dns requests than my local ISP.
Try it, you may very well be surprised. Your ISP almost certainly has cloudflare boxes on-net, and (depending on the ISP) the DNS infra on them is probably better looked after than the ISPs.
None of this is a reason to give your data to a US corporation, it's only the claim that they'll not be faster that I'm objecting to.
I'll immediately stop using Firefox if this can't be disabled.
I know The Reg is a Cloudflare customer, but Cloudflare also has quite a reputation for criminal bulletproof hosting. When you get a spam for a fake commerce site, odds are that Cloudflare is the bandwidth for it. And no, Cloudflare will not stop providing services simply because it's blatantly illegal, phishing for credit cards, and spoofing another business. I've phoned their abuse department and they said they told me to file a police report. (I did many times - hopefully enough to be a PITA to them)
ok so theres a lot of people confusing the protocols:
encryption - making ure only the other end sees your request - DoT (DNS Over TLS - port 853) and DoH(DNS over HTTP over TLS)
authentication - making sure the other end is who they say they are - DNSSEC
Personally i prefer DoT to DoH as it does just what you want it to encrypt the content of the DNS request, and still allows the service to be managed independantly.
I trust CLoudflare a lot more than i trust any ISP, as they have most of the data anyway as a cdn and they have a good policy on privacy etc. plus they have chops funding privacy protection research like K-Annonymity
"Personally i prefer DoT to DoH as it does just what you want it to encrypt the content of the DNS request, and still allows the service to be managed independantly."
Not necessarily if the port is hijacked wholesale (DNS and DoT both have this issue). The only way to prevent this is to either use random ports or piggyback a ubiquitous port (and as DoH uses the HTTPS port of 443, this puts ISPs in a bind).
Tell me if i'm wrong...
What's to stop me putting all the DoH serving domains in my pihole blacklist, thereby forcing fallback to traditional DNS resolution? it 'seems' to work OK, in the same way that blackholing a domain name works for http & https, failing that, any guidance in setting up a local DoH server that would use my pihole as it's authoritative DNS?
Biting the hand that feeds IT © 1998–2020