DNSSEC ?
so you make a query over TLS and can not verify the answer....
mandating DNSSEC as part of the spec is the only solution otherwise your just changing the attack surface not solving the problem
As the DNS-over-HTTPS (DoH) secured domain querying draft creeps towards standardisation, Mozilla has run a test to see if applying encryption brings too heavy a performance penalty. One somewhat-surprising outcome: for some queries, performance improved using DoH. As Mozilla discusses here, run-of-the-mill DNS requests over …
Run DNSSEC through unbound on my home router but DNSSEC is not an ideal solution for grandma imo. Too easy for her to assume her internet is broken instead of there being a misconfigured domain or her ISP doing some MITM shenanigans (insert ads, etc). Granted you or I would want to know but many people don't care and just want their internet to always work. DNS not resolving can be frustrating even if you are an IT nerd (ie try using dnsmasq to do dnssec back a few years ago, aka bring the pain). Terrifying to the normals.
TLS of course, no one ever forgets to renew their certificates. Given that most non technical people automatically 8.8.8.8 then all their DNS queries are captured. As it is possible to determine which page on a web site is visited by the DNS queries made on that page, DNS is important
Using DNSSEC you can easily spot when DNS tampering takes place, you can also verify the CA public certificate that signed a server certificate and the server certificate by including them as TLSA records. Putting DNS over TLS does not stop a CA issuing a certificate (either due to social engineering, hacking or by accident) which compromises DNS over TLS traffic.
The question that must be asked is what makes DNS more secure, DNSSEC which was specifically designed to secure DNS, or DNS over TLS which is designed to obscure your DNS queries?
Switching to DNSSEC with DANE allows DNS to become a global certificate authority, with DANE type 2 certificate allowing the registration of your CA for your domain(s). If the client trusts DNSSEC and DANE certification then a secure connection can be created, this does not stop a malware domain from using the same technology but you can block the domain using RPZs.
Your DANE type 3 allows for your own CA signed server certificates to be placed in a TLSA record and signed. Oops, I do not have to buy global CA certificates now if everyone uses DNSSEC/DANE or do I use DNS over TLS and keep buying certificates?
Given that most non technical people automatically [use] 8.8.8.8
Huh? Most non technical people use whatever default their ISP sets for them, and don't know DNS from TCP. Does anyone actually choose 8.8.8.8? It isn't the fastest (at least not for me) so even without Google's data slurping it doesn't seem to be the choice other than being easy to remember.
Though, 9.9.9.9 is just as easy to remember, and 1.1.1.1 is arguably more so. And both win huge bonus points because "they aren't Google".
DNS over HTTPS to 1.1.1.1 with their Linux "Cloudflared" applet works flawlessly too, once you account for the slightly incorrect installation (at least on my Ubuntu-based PCs). I don't remember exactly what the issue was or what I did to fix it, only that it required a little fiddling to get the service installed correctly and working. I'm no Linux pro, but I managed to figure it out!
From the article sidebar:
That opens privacy and security gaps: intermediaries can track which servers you connect to, and responses can be spoofed (for example, to pipe a connection through a hostile server).
Er, isn't that just a fundamental problem with packet switched networks in general? That is you've no idea where your packets actually travel via on their way to/from a server, and thus you have to implicitly trust all routers on the way to not log, inspect, or monitor your traffic? Just hoovering up DNS into some other protocol that masks it doesn't mean that the subsequent browsing traffic is also similarly masked - that requires a VPN. All it means is that DNS servers can't see what you're doing. That's not the whole potential snooping picture. This is, at best, a partial "solution" to a "problem" that's effectively unsolvable on an open, packet switched network. You'd need circuit switched + a ton of trust decisions, or Tor, to do it any differently.
If we want an Internet that doesn't require us to implicitly trust every single server and router out there simply to be able to talk to the servers we want to browse, then packet switching is the wrong sort of network.
isn't that just a fundamental problem with packet switched networks in general? That is you've no idea where your packets actually travel via on their way to/from a server, and thus you have to implicitly trust all routers on the way to not log, inspect, or monitor your traffic?
Yes, and that's what TLS protects you against, by encrypting your traffic.
We're talking about DNS-over-HTTPS, which is DNS-over-HTTP-over-TLS.
Then if you use DNS-over-HTTPS combined with HTTPS for web browsing, the amount of logging/inspection which can be done is pretty minimal. The remaining big hole is Server Name Indication.
If we want an Internet that doesn't require us to implicitly trust every single server and router out there simply to be able to talk to the servers we want to browse, then packet switching is the wrong sort of network.
And circuit switching is better how, exactly?
The real elephant for... No that's not fair. It certainly improves the level of privacy and reduces the attack surface. The real reason for why DoH is no silver bullet for domain name resolution is noted in the IETF draft.
"HTTPS connection provides transport security for the interaction between the DoH server and client, but does not provide the response integrity of DNS data provided by DNSSEC. DNSSEC and DoH are independent and fully compatible protocols, each solving different problems. The use of one does not diminish the need nor the usefulness of the other."
If you wanted to see globally who was visiting where it would be easier to compromise the 8 DOH end points than to get into the thousands of ISPs all around the world. NSA, GCHQ, ... must be rubbing their hands in anticipation.
However if you live under a repressive regime having the NSA/... spying on you might be preferable to your own government. But expect $REPRESSIVE_REGIME to force their Mozilla users to use their own DOH end points.
Who do you trust least ?
break the DNS intercept that millions of commercial networks rely on in order to redirect browsers to login pages, terms of use pages, pay-voucher systems etc? Or is that catered for by way of a fallback timeout system? And doesn't it also rely on SOAs being uncompromised in the the first place? I mean, it's all well and good encrypting the response so it can travel unmolested, but you can encrypt bad stuff as well as good stuff.
Doesn't this break the DNS intercept that millions of commercial networks rely on in order to redirect browsers to login pages, terms of use pages, pay-voucher systems etc?
Yes it does and that's the point.
The DNS Intercept is really a crude MIM hack and needs to die a horrible death.
Back in the day, there used to be a few ISP's who intercepted a DNS Call to say Google and re-directed it to their DNS system. They wanted you to only use their tainted DNS system.
Not sure if these practices still exist or not.
"Yes. In the slip of paper where you have printed the AP name and the password for the day, you print the Uri that the guest must visit to sign in."
And if you're legally prohibited from posting such a notice? Or the area covered is too large or otherwise too difficult to post such a notice? Or you're already getting complaints because it's too difficult and you're under threat of losing customers to the competition?
Set up your own local recursive DNS resolver, point to it.
Have it use DoH in its recursive resolution. It can cache the results of DNS lookups. So if you've looked up a site you've looked up before within its cache timeout, it never leaves your network to do the resolution, instead pulling it out of its cache.
If you are on satellite, I'm surprised you aren't already doing this with standard DNS.
Missed edit window after thinking about this a bit more...
If you are on satellite you probably don't want your own recursive resolver, as that means it'll do the heavy lifting of following the DNS tree until it gets the answer, which means rather than sending one request-response, it'll be sending multiple as it traverses the tree.
So you'd want a I guess a cacheing forwarder (?) for the network, so it receives all requests from anyone on your local network, forwards the request to one of the DoH DNS servers to let them 'walk the tree' and respond with the final resolution, so you do send a single request-response. However, your local forwarder caches the results of the DNS lookup, so next time any device on the local network needs that same address, it returns it from the local forwarder (if within the cache TTL) rather than going out to the external DNS server.
...and still nobody notices the damned thing. While SNI is still sent in the clear, you can obfuscate your DNS queries all you like, they're still going to log and store that first header. TLS1.3 should have dealt with this but, as usual, it's just too difficult to re-implement SNI over a secure channel now world+dog's httpd is happily using the current SNI implementation. It would require something like a DNS fingerprint of the hosting IP's default virtual and then a process to get the wanted certificate fingerprint for the domain after the request is transmitted over a secure channel to the host httpd. Not an easy task and adds a lot to the initial handshake where TLS1.3's focus was on trimming that down.
While this is still an issue, DoH is still a false sense of security.
BTW, DNSSEC != encryption. DNSSEC is simply a hierarchical method of verifying the records haven't been intercepted and changed. The data is still sent in the clear.
This is horrible bloat.
Like the bloatware on PCs, that has forced continual upgrades of RAM/etc? Well, up to a point.
But then, if you still have a 30-year-old PC with a 286 processor and half a meg of RAM, you can still run old apps on it. A perfectly good word processor and home/small biz spreadsheet. Email and most of the useful parts of the web - so long as you cut down on the fluff.
Whereas if you're on a net of even just half that age - the information dirt-track - you're going to be struggling. You really need the efficiency designed into the early 'net, not today's money-and-resources-no-object bloat.
Do we know how many people will be locked out in practice if we foist DNS-over-HTTP (let alone HTTPS) on them? I think not: they're the invisible excluded.
I remember my time on the information dirt track. I was effectively locked out of more online resources in 1998 than in 1988, because of the bloat that started with the modern Web in the mid-90s. It won't be me this time, but others out there will suffer.