Macs, iPhones, iPads to get encrypted DNS – how'd you like them Apples? Apple this year will boldly go where its peers have gone before by implementing support for encrypted DNS in iOS and macOS. "Starting this year, Apple platforms natively support encrypted DNS," said Tommy Pauly, internet technologies engineer, in a video presentation for Apple's 2020 Worldwide Developer Conference, virtualized …
Better late than never. But, they really need to make it on by default.
I'm using Firefox and when I went to check if I had the option, I found that one of the updates had given me the option and enabled it automatically and, if want or need to, I can disable it.
From a user point of view, this is how it should work.
The problem is it can bypass private DNS servers.
For example, I use a pfsense firewall with DNS which then points to a pihole. This gives me split horizon DNS at the same time as keeping Facebook and the like off my inner networks. If a browser is configured to use DoH then this functionality is compromised.
Obviously what I'm describing is a small home rig but big boys' and girls' networks can be similarly compromised by a software upgrade of a browser.
Cloudflare may have promised to be virtuous and not prat-about with the DNS lookups - but I *want* to block or redirect lookups of certain malicious domains.
The trouble with the increased encryption is that it makes life for everyone a lot harder than it needs to be and most people get very little benefit from it. People have confused the need to know content is not tampered with the need to hid what you are doing. The ill informed mass move to HTTPS makes everything slower because it kills proxies.
Exactly the same issue with DNS and HTTPS - it's a completely stupid idea and what's worse - it's very hard to block. What this does mean is that going forwards my own top level cert will be installed on machines in my local network and all web traffic will be going via active man-in-the-middle proxying (i.e. my web proxy generates fake SSL certs on the fly and decrypts and re-encrypts traffic). This will allow me to block this mess - however I'm now actively breaking the entire SSL security model.
Kids these days - havne't got a clue :(
1) When I'm browsing the BBC new website - I care that the content I get is from them - but it's public content
If you are already willing to generate a cert, get it into the trust stores, and build a device to MITM your traffic, you might as well just disable encrypted DNS queries on the devices instead. I don't know of anything that prevents you from using cleartext DNS. Finding and switching those settings will take less time and processing than building and running an HTTPS-interrupter.
If you also want to block encrypted connections, you can find the addresses of the existing (not very many) DoH servers and create firewall rules that drop traffic going to ports 443 or 853 on them. If you are concerned that some piece of software will refuse to honor your DNS settings and will also use a secret resolver, you probably have more to worry about than how it resolves URLs.
Going "off topic" if you are already using pfsense, I would highly recommend that you investigate using its inbuilt DNS server (DNS Resolver) along with a superb third party add on package (installed from its package manager) called pfBlockerNG-devel (current version 2.2.5_33) which has massively more functionality than PiHole eg can also block IP's by ASN (auto updating).
Handy when you block certain domains, the owners of which then hard code IP's in their code to circumvent DNS blocking - yes Microshaft I am looking at you
I use(d) blockerNG to kill of facebook and youtube, unfortunately its virtually impossible to do, unless you have a complete list of every ASN they use, and in the case of youtube etc ,,, you are likely to kill off the google search engine as well. I don't do this because I am worried about anyone knowing my internet habits, I do it to stop the tories screaming about the kids exposure to unsuitable content, like you tube tory adds!!
" I use a pfsense firewall with DNS which then points to a pihole."
I'm wondering why you do that. PfblockerNG does everything that a pihole does and it integrates with DNS resolver. It also logs natively on your pfsense firewall so that you can see what's going on and get alerts via the web interface. It even uses the same blocklists as pihole.
considering how Micros~1's phone OS has been such an *EPIC* failure, the award for "late to the party" REALLY belongs to Micros~1 !!!
And when you consider that the encrypted DNS providers are probably SNOOPING on everything themselves, it's kinda pointless outside of a public wifi or "behind the filtering firewall" setting. Oh, but you get to CHOOSE who snoops on you! O...K...
1st, i'm using DoH at home, my Pi Hole & Cloud os servers get their dns from cloudflare via a locally hosted DNS -> DoH proxy & dns is dropped on my fw.
2nd i can block normal DNS at my fw, i can't block https unless i wan to break the internet for my household, or install a proxy.
i really don't want my local systems being name checked against the internets dns servers, i also don't want any random IoT crap on my net or apps i install on my laptop/phone being able to do dns look ups to stuff i can't block & without me knowing!
This is good for privacy but terrible for securing your home systems against unfettered outbound comms.
will be migrating to pfsense soon & will need to build a Man In the middle capable proxy to inspect outbound traffic.
Not all of that is as concerning as you imply.
"2nd i can block normal DNS at my fw, i can't block https unless i wan to break the internet for my household, or install a proxy."
You can do a pretty good job if you want to. CloudFlare's resolvers on IPV4 are in the range 1.1.1.1-3. So you can set up a firewall rule: Source: [local_addresses] Destination: 1.1.1.1-3, Port: 443, Packets: drop. Do that for a couple providers and DoH becomes difficult.
"I really don't want my local systems being name checked against the internets dns servers,"
If you do enter a local address into something that sends it to an external resolver, that resolver won't be able to find the address, so you'll instantly know you have to fix DNS for the affected application to point it at the server that will work and will protect your addresses. While I understand that you might not want to send your internal requests by accident because you're concerned that a resolver will leak them, knowing your internal DNS names really shouldn't be very relevant to an attacker without additional access, and with that additional access the attacker can find them out anyway. In addition, the likelihood of an attacker also running a default DoH server is unlikely, and the encryption on that protocol makes it unlikely that someone could steal them from the traffic to that provider.
"i also don't want any random IoT crap on my net or apps i install on my laptop/phone being able to do dns look ups to stuff i can't block & without me knowing!"
I agree wholeheartedly. The problem is that any app sufficiently malicious can already do this. We block the most straightforward way of loading unwanted content. Here are some others, and DoH is not needed for any of them:
1. Hard-code an address into the code. Contact it directly. No DNS request sent at all.
2. Hard-code the address of a DNS server, then use normal DNS to retrieve it, ignoring the network-supplied resolvers. This is the easiest to block if you have set up your network to send all requests on port 53 to your local resolver, but most networks aren't set up that way.
3. Hard-code the address of a resolver which is willing to take requests on a different port. Not hard to set up by the attacker and finding out that it's happening requires inspection of packet payloads.
4. Hard-code an address and use it to find additional addresses via some encrypted and difficult to track mechanism.
5. Use the standard resolver to resolve something that's likely to get through, and host a resource there to allow resolution of other addresses. For example, hosting an encrypted database of addresses on Github.
None of these ways will stand up to a manual analysis with Wireshark, but all will completely bypass the local DNS system without requiring DoH to be operating. In only one of the cases can a simple firewall rule help.
"This is good for privacy but terrible for securing your home systems against unfettered outbound comms."
I really don't think so. If some device on your local network starts contacting a random external IP, will your network allow it or not? If it would allow it, then the only restriction on your outbound comms is trying to prevent the local device from getting the right address. Given how many ways there are of getting an address, that's not a guarantee of anything. If it would not allow it, then it doesn't much matter if the device knows the address to use.
"will be migrating to pfsense soon & will need to build a Man In the middle capable proxy to inspect outbound traffic."
This seems like an overreaction. Unless you are confident that you can create something capable of parsing all that traffic and determining whether you would like it or not, the effort will only create an extra bottleneck for your network.
I've got a similar set up to you, but already using pfSense as my gateway, Pi-Hole for blocking and plugs into Cloudflare's DoH service, and with outbound regular DNS queries all redirected to my Pi-Hole, I also share the same concern for the near future where potentially malicious IoT devices or phone apps start using their own in-built DoH, preventing visibility of what my own devices are doing (disclaimer re: "my own devices: that word may not mean what you think it means, yeah yeah).
Will be looking into later commenters suggestion of blocking DoH traffic to anywhere other than Cloudflare, or limiting DoH traffic to only be allowed to come from the Pi-Hole.
Interesting article entitled “ A New Needle and Haystack: Detecting DNS over HTTPS Usage“ on the SANS Institute here
https://www.sans.org/reading-room/whitepapers/dns/needle-haystack-detecting-dns-https-usage-39160
IMHO for those who like to see what’s going through their networks and the security conscious, it does not make for happy reading ...
Before you go down the pfsense & MITM proxy have a look at Sophos' free offerings which have the functionality already in them - their home use UTM is retricted to 50 IP addresses behind it, whereas the free XG firewall is restricted to some number of cores and memory - you can either spin them up on your preferred virtualisation platform or a small PC as you like.
"Idiot Tax" was amusing at first but it's really really tired now. Ancient recycled old rubbish soon loses its comedy value and makes the writer look lazy.
Other banalities includes: "crysis", "popcorn", "goes up to 11", "rounded corners" and many more. I wonder if the people using these trites imagine that they are being witty and original when they put them into a comment.
"Ancient recycled old rubbish soon loses its comedy value and..."
sells for 3-4 times the price of other kit just because it has an Apple logo on it.
It's hard to write good copy, especially in keeping with your target audience. Do you read every article? No, but someone has to write every one and if the article just said "Apple will enable encrypted DNS", you'd quickly get bored and go elsewhere.
There are thousands of IT news sites out there. I like a little informality. I don't really care about cliche, it doesn't hurt or hinder me. If you're here for original comedy with every article, I really think you've chosen the wrong kind of site.
And I use the words idiot-tax for all kinds of things - parking tickets, speeding tickets, designer gear, etc. etc.
Bit straw-mannish there. Informality is fine, silliness and snark are fine. But the same thing every time... yawn.
you'd quickly get bored and go elsewhere.
That's exactly what happens because of these banalities. In fact it became a turn off about 4 years ago.
If you're here for original comedy with every article
Not asking for that at all. Just not seeing the exact same gag on every article for years on end.
So I can do my own thing if I can build my own apps or have enterprise management etc etc but otherwise it will bypass my network control, ad filters, and slow down my users?
And exactly which DNS providers are they going to force us to use?
Joy.
At least Moz allows a canary domain.
As a small company we don't have the resources to do anything about it eg build apps etc
So we'll just ban all Apple crap. Simples.
Whenever Reg reports on Apple, it has to make some derogatory remark, like idiot tax or 'fanboi', etc.
This really shows a lack of integrity in journalism to be able to report the facts and maybe making some intelligent editorial assessment. But the Register continually fails in this.
That sort of silliness is a fundamental part of the reporting style here; there are other tech news websites you could frequent if you don't like it, but looking through your past comments, it seems this is an axe you grind here quite often. Your life might be more relaxing if you could let it go.
It's jolly nice that Google "supports" it, but what about the intel they draw in by their advertising and even fonts, although that's due to caching more in the nature of so-called "atmospherics" (trends) than fully live data?
I'm singling out Google per sé, they're just the simplest example of "protectors" who are better described as "pretenders". There are a lot of factors that need to be addresses before you can talk of true privacy protection - I'm glad there's one more but I don't think we're quite there yet.
There's a balance to be found somewhere but right now I prefer to use Little Snitch to restrict adverts and tracking via the browser, and then private browsing over VPN as the next layer up. The problem with DNS over TLS or HTTPS is that Little Snitch can't tell me the domain that's about to be visited :-(
As long as it's an option, great. But the moment there's no other option, I (we all of us) need a way to be able to selectively block outgoing traffic - by domain name. Please.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
