Chromium's Impact on Root DNS Traffic(blog.apnic.net) |
Chromium's Impact on Root DNS Traffic(blog.apnic.net) |
Currently, Chrome does the following:
(1) on each network change, send three DNS requests with random hostnames.
(1a) If at least two of the queries resolve to the same IP, store the IP as the "fake redirect address".
(2) on a user search, query the first search term as DNS.
(2a) If the query result is NXDOMAIN or matches the fake redirect address, do nothing. Otherwise, show the "local domain" hint.
Instead, it could do:
(1) on a user search, query the first search term as DNS.
(1a) if the query comes back with NXDOMAIN, don't show the hint and stop. We're done.
(2) otherwise, make two more DNS queries with random domain names to check for fake redirects.
(2a) if the two queries resolve to the same IP as the first one, we have a fake redirect. Don't do anything. Otherwise, show the "local domain" hint.
Results of step (2) could be cached until a network change.
This would only require 2 instead of 3 probe queries and only if the user actually searched for something and if the search term actually caused a DNS match (fake or genuine).
From reading the source, it actually does a HTTP HEAD chasing redirects, and records the origin of the final page, and uses that as the redirect address. So even if two hostnames yield different IPs, if they end up redirecting to same hostname, it will be detected
> (2a) if the two queries resolve to the same IP as the first one, we have a fake redirect. Don't do anything. Otherwise, show the "local domain" hint.
What if an ISP uses multiple IPs in the fake redirect, and alternates over those IPs in each successive response?
Good point. I was wondering how they'd deal with that in the actual implementation.
I think you got the answer though: They match HTTP origins instead of IP addresses - so I imagine, you could do the same in step 2: Do a HTTP HEAD query to the search word and two additional ones to random hostnames, following redirects. If the final origins are the same, there is fakery going on.
A problem with this could be unexpected HEAD requests to actual internal hosts: There is no guarantee an internal host that was never meant to receive HEAD requests would react gracefully or in any way predictable to one.
I'm not sure how they solve this currently. Maybe this could at least be mitigated by only sending the HEAD request to the search word host if there is reasonable suspicion requests are being redirected - e.g. only if the two random hosts resolved and were both redirected to the same origin.
Finally, you could cut all of this short by also connecting to (search word):443 and trying to initiate a TLS session handshake. If the host answers, you know it's probably a genuine internal host that talks HTTPS and you don't need to do any additional probes. (And you can also abort the handshake and don't ever need to send an actual HTTP request to the host)
Maybe, at the risk of over-engineering, additionally cache the results for the last N networks persistently. Something like (gateway, DNS, localip) as key. I could see those three being identical on different networks though... And assuming the article is right and most ISPs globally do not mess with NXDOMAIN, this might not be necessary anymore with this proposal.
- the queries only affect the time after which the "local domain" hint appears. They don't influence the time until the main search results appear.
- if the result is cached, the additional roundtrip is only for the first hostname entered after a network change.
- the two "random hostname" probes can be executed in parallel, so it should not result in more than one additional roundtrip.
And yes, luckily there is a policy to disable it: https://cloud.google.com/docs/chrome-enterprise/policies/?po...
Registry key: Software\Policies\Google\Chrome\DNSInterceptionChecksEnabled
PowerShell: Set-ItemProperty HKLM:\SOFTWARE\Policies\Google\Chrome -Name DNSInterceptionChecksEnabled -Value 0 -Type DWord
If you are managing Chrome via GPO, you should do it via GPO. Templates can be downloaded here: https://chromeenterprise.google/browser/download/
"Buy us out and we'll stop, and you can use the tech on your customers?!?"
One of the boldest business proposals I've been party to. After a few deep breaths and some laughter, the offer was not taken. But that wasn't a one-off event. Spent a lot of time in early 2010's directly trying to protect customers from this stuff. Still do, but it's getting much harder with TLS-everywhere, HSTS, DOH, and many other things. Not impossible though, we can never let up on the pressure to keep the ROI too low for hijacking. The various network operators and ISPs that let these companies put racks in their data-centers to inspect user traffic should be <<insert_your_own_horrible_idea_here>>.
My solution was to assign the Pihole the IP address 8.8.8.8 as well. Then I added a static route in at the router to route 8.8.8.8 to the Pihole. Now every request to dns.google will also be handled by pihole instead of getting timeouts.
nice that you already debunked your thesis
I've got several rules for Google Chrome in Little Snitch that seem to do the trick. Deny outgoing UDP connections, and Deny outgoing TCP connections to port 80 for the IP addresses and domain for my ISP. You can see these if you monitor traffic.
I think the only downside is that you would leak some information about your system clock.
That would still allow ISPs to compute the limited number of domains for which NXDOMAIN would need to be sent at any given point in time.
(Whether they'd do it is another story. The random pattern currently used by Chrome looks like it may still be easily detectable at the DNS-recursor level, so maybe the ISPs really don't bother beyond the simple NXDOMAIN -> portal domain replacement.)
Select a root server at the bottom. Some, but not all, have a "statistics" link. Seems to be stated in qps and message size distribution, but you should be able to derive traffic volume from that.
https://github.com/rssac-caucus/RSSAC002-data
You can also click on the "RSSAC" button on root-servers.org to get the YAML straight from the root server operators themselves.
Most of the root server operators have anycast instances deployed in organizations that host the servers for them. So there's not an easy way to measure bandwidth utilization because many root server anycast instances are hosted in organizations that may not, or could not, report that bandwidth utilization. Look at the map on root-servers.org to see how dispersed around the world these things are.
[1] https://github.com/Eloston/ungoogled-chromium/blob/14fb2b0/p...
[2] https://github.com/bromite/bromite/blob/410fc50/build/patche...
Note that under this crude test of sending queries for unregistered domains, a user who administers their own DNS could be indistingushiable from "DNS interception" by an ISP or other third party.
I administer my own DNS. I do not use third party DNS. These random queries would just hit my own DNS servers, not the root servers.
> Users on such networks might be shown the “did you mean” infobar on every single-term search. To work around this, Chromium needs to know if it can trust the network to provide non-intercepted DNS responses.
Don't know if this is the sole reason.
Reminds me of the story behind "Google Public DNS". Back in 2008/2009, OpenDNS was hijacking "queries" (NXDOMAIN) typed in the address bar to their own search page ("OpenDNS Guide", or some such) on an opendns.com subdomain. In response, Google launched its own open resolver.^1 (OpenDNS was later acquired by Cisco)
Guess what Google' priorities were when they approached that problem.
If I serve fake responses does that turn off searching via the address bar?
Why doesn't Chromium just have a setting that allows a user to turn off the incessant queries for nonexistant names.
No matter how high-profile the environment, eventually, the rubber will hit the road and some human will be in a privileged position to be able to fix a problem.
That is true for every single service out there. Yes. Including Gmail. Including AWS. Including Twitter. Everywhere.
Depending on size and profile of the service it's more or less people in need of jumping through more or less hoops to get there, but this must be true for any service.
Always keep this in mind when you make the decision to move your data to a cloud service.
It's about time for DNSSEC to be available on all TLDs and for browsers to nag if it is broken.
Maybe this "omnibox" doesn't know whether I want to enter a hostname or a search term, but I do.
Even better, spin up a little VM or VPS somewhere in the cloud, install 'unbound' as a recursive resolver and point it to your nextdns.io account/address.
Let's unpack this ... backwards ...
DNS servers out on the Internet are queried by nextdns, which presumably has no PII from you other than your CC number[1] and zip code.
Nextdns receives nothing but queries from some random VPS/EC2/VM IP. Again, presumably a provider that knows (almost) nothing about you.
Your ISP sees nothing ... just encrypted DNS traffic.
It's win, win, win.
You see no ads, since nextcloud.io acts like a pihole and strips/blocks all of the malicious hostname lookups.
[1] Remember, only AMEX verifies cardholder FIRST LAST. Use your VISA/MC. I think my first/last is Nextdns User or whatever ... YMMV if a merchant is enrolled in that weird "verified by visa" service ...
* Type/paste a URL
* Type/paste a search
* Search my browser history (usually to jump to a previous URL)
* Use search engine keywords to do direct searches on some applications I use regularly (eg, "jira P-123" does a search in JIRA directly, which happens to jump to that ticket directly)
Browsers that separate those two drive me a bit crazy, because of the extra thinking required before typing.
(I don't really like this whole "using the first search term as DNS lookup" but that's separate from the UX of single vs separate inputs.)
CTRL-L: focus URL bar, typed text will be navigated to or searched for
CTRL-K: focus URL bar, typed text will be searched for
(same in Firefox, with the distinction that Firefox has two UI elements instead of one)
That’s obviously so, because that’s it’s entire raison d’entre.
The problem is that some ISPs have configured their DNS resolvers to lie and not return NXDOMAIN. Instead redirecting you to some website for marketing purposes. The Chromium workaround is to try and detect if it is using a lying DNS resolver by issuing queries that it knows SHOULD return an NXDOMAIN.
If this concerns you run your own resolver, enable DNSSEC validation, and enable aggressive NSEC caching(RFC 8198).
The question is: does Chromium send the first word I type to my ISP?
The answer appears to be: yes.
I am getting close to moving to a hut in the woods and forgetting all about the internet.
If your ISP forges NXDOMAIN responses, the correct response is to DOH to a provider that doesn't do that. That's a simple networking config change, for which there is UI in every mainstream operating system. The DNSSEC part of this conversation is just silly.
I struggle to understand how DNS can possibly be a performance issue in 2020. In most corporate environments, the "working set" of a typical DNS servers will fit in the L3 cache of the CPU, or even the L2 cache.
The amount of network traffic involved is similarly miniscule. If all 200K of your client machines sent 100 requests per second, each 100 bytes in size, all of those to just one server, that adds up to a paltry 2 Gbps.
If your DNS servers are struggling with that, get better servers. Or networks. Or IT engineers.
Not saying that we should embark on some quest for retribution against Google. It's just sad.
What's crazy about this is that there's a trivial solution to forged NXDOMAIN responses that people can adopt immediately: just DoH to a provider that doesn't forge NXDOMAIN responses (none of the major providers do).
I sometimes wonder whether the vehemence of the anti-DoH advocacy is rooted in concern that it will cause DNSSEC to lose yet another potential motivating use case.
Think about a coordinated effort by top tier DNS providers globally to stop a giant bot network by simultaneously 'hijacking' DNS responses for the command and control server host-names. In classic DNS this is easy, just intercept the requests at the LDNS provider and return a dummy server IP, all good.
That falls apart with DOH and DNSSEC. With DNSSEC you cannot forge a response to a client that strictly expects signed responses for a particular zone. And with DOH, the various corporate IT shops cannot inspect and 'hijack' the responses. Though, the DOH operator can still change the response. But that moves the capability outside of local corporate IT and into a multinational company that might not agree with your request to 'fix' a problem via assisted DNS hijacking.
So all of these new, safer DNS delivery methods do legitimately impact the ability of "good"* operators to protect the Internet. Is the trade off worth it to protect users DNS traffic versus being able to respond to threats? I think that protecting users daily traffic is net-net better as it is a steady state problem and state sponsored actors have the resources to subvert a population via DNS. But I also feel the loss of a tool to protect users at the same time. Things like this are never zero-sum.
Disclaimer: I work for Microsoft and although I don't operate DNS services as part of my job, I have spent a lot of time on this particular topic over the years. These are my opinions, not the companies. I welcome challenges to my opinions, that's how I learn.
*"good" is always a situational thing.
I believe the purpose of this feature is not about detecting hijack requests to valid top level domains. In other words, a well written NXDOMAIN interceptor would not cause a harm to their intended audience, so they didn't bother trying to detect it.
It's about detecting that a "eng-wiki A aa.bb.cc.dd" record it just received from the user's DNS server is actually intended to be eng-wiki served from corp network instead of a stupid ISP page.
Please explain why you hate DNSSEC instead of downvoting things you disagree with.
To me, it's as if DNSSEC has some critical and unfixable security vulnerability, and people who make these decisions decided to stop all work on it, but not reveal the vulnerability because doing so would do too much damage.
This is probably the most comprehensive list of reasons not to use it: https://www.imperialviolet.org/2015/01/17/notdane.html
Chrome's implementation is terrible as it's designed to just funnel you into Google search, and doesn't give you a good idea of how useful it can be.
If I want to search in just my history, I can simply press CTRL-H and type to search in history.
Update: I hide some site of mine from google, I do not care about SE traffic and block any crawler, and I have noticed when I give some people I know a URL from that site, they often tell me that it cannot be found, given google search they use all the time does not list it
If the less tech savvy can't figure out that it does both, then maybe it isn't as intuitive as the browser builders think.
This is not relevant for URL or search bars since they need to be displayed horizontally. Separate bars means less vertical screen space, which is still scarce.
In firefox preferences there still is an option to switch to old layout with two bars. Sadly it does exactly the same thing as adding search bar manually, that is gives you second redundant search bar and does not turn off search support in the original url bar.
(I think the omnibox is the right UI though)
Need? Has anyone tried?
The network operators enable this behavior. It would be next to impossible for it to be useful (ROI wise) if they didn't intentionally support it with access to their networks. It doesn't need to be an arms race, but we refuse to regulate or punish anyone in this space. We waste massive amounts of resources detecting and counteracting the hijacking services. The human (developer) cost is where the big waste is here, not electricity.
and the fight goes on....
But Chrome also falls back to try non-DoH on NX-Domain, so it doesn't really help. I guess they need to do that so internal domains work correctly.
ALT + D: focus URL bar, typed text will be navigated to or searched for
CTRL + E: focus URL bar, typed text will be searched for
(I find those better since they can be used with my left hand only)
Not browsers, just chrome. The rest followed.
-D, --domain-needed
Tells dnsmasq to never forward A or AAAA queries for plain names, without dots
or domain parts, to upstream nameservers. If the name is not known from
/etc/hosts or DHCP then a "not found" answer is returned.* http://jdebp.uk./FGA/dns-name-qualification.html
And the words that you are looking for are "resolving" and "forwarding". A proxy DNS server either does query resolution itself or forwards to another proxy DNS server that does. Both sorts can cache, so whether something is a caching server is not the distinction. dnsmasq is choosing whether to forward the query or to do query resolution itself (using a local data source) according to the number of labels in the domain name. As I said, at this level the idea of domain name qualification does not apply.
You are also mis-using "resolver", incidentally. The actual meaning of "resolver" per RFC 1034 is not what people sometimes think it to be. Avoid using "resolver". The mis-use creates confusion.
Google Chrome (Linux, Mac, Windows) since version 80
Google Chrome OS (Google Chrome OS) since version 80
and as a clarification
When you connect via VPN to the corporate network the DNS queries are not distributes as when you are in the office. You have a X amount of entry points for the VPN which are served by Y DNS servers which is less than the total amount of DNS servers available in the corporate network. Plus the amount of remote users increased vastly, plus the VPN technology used plus the DNS servers used. Not that simple I'm afraid
Also keep in mind that Edge is chromium based now and has the same issue. And is becoming the standard by MS and thus the impact is increased now because of this
No.
The answer appears to be yes if you said "the only word", though.
ctrl l does not force Chrome to resolve the term through DNS, it may still run a Google search. If you want http://mylocalserver you have to include the http:// or Chrome will Google for mylocalserver.
While the single bar is my preference I agree that more choice should be given to the end user. Google is trying to hard to shovel the changes that benefit them than addressing user’s needs (obvious example being AMP).
Let's say that testing it briefly was enough. Editing tilted text works up to around 45 degrees, steeper than that is a strain.
My grandmother doesn't know the difference between an "address bar" or "search bar". Recently she got an email from her insurance company telling her to go to their website www.whateverinsurance.com and click "sign in" and then click "my account" and update her credit card info. The email had the url but it wasn't a link for some stupid reason. She goes to her browser and types in "www .whateverinsurance..com" because her eyesight isn't very good anymore and presses enter. Then instead of giving her an error saying the website doesn't exist and she should re-try entering it, it goes to a Google search page! She clicks "sign in" but her password doesn't work because she's on Google instead of her insurance website. So I get a call and have to figure out why her "insurance isn't working".
When I finally get her to her insurance website, she mistypes her password and presses "log in", and nothing happens. Windows is configured with 175% magnification, which means that the "invalid password" div that appears isn't visible on her screen unless she scrolls to the top of the page!
She originally tried calling her insurance company and updating her credit card number by phone, but she couldn't enter her credit card number fast enough and it timed out and told her to go to the website instead. WHY DON'T THEY TEST THIS STUFF???!?
Sorry, I went on a tangent there. I get irrationally upset by this kind of stuff.
Google Maps is a good example of this. Like the original text box you were shown was searching for an address but enough people typed business search terms that eventually they just implemented that feature.
The Ansible vault is a bad example of this. They have a little command `ansible-vault` that lets you manage encrypted files and strings. If you run `ansible-vault edit ./nonexistent_file` it tells you that you meant `ansible-vault create` and vice versa but doesn't just do it despite the user intent being clear. This ultimately lead me to just patching it to do the right thing.
IMO it's a bit much to decide what "the right thing" is there. Blindly assuming that someone attempting to edit credentials didn't mistype a file name isn't exactly safe and sounds like a great way to cause problems based on believing you updated something you did not in fact update.
A perfectly legitimate answer is to not even try. Per the HTTP spec, sending HEAD is supposed to be harmless. If it causes harm, that’s a violation of the spec. I’m sure some legacy server out there segfaults on HEAD, but that’s not a browser vendor’s problem, and it isn’t up to the browser vendor to do anything to try to prevent it. Browsers (not just Chrome) send HTTP HEAD in other scenarios as well. And I think this problem is relatively rare in practice, since one hears few reports of it actually occurring
I think it's legitimate for a fully internal server on an internal network that only handles internal clients to only implement the parts of the HTTP spec that are relevant to the exchange.
If Google worms its way into that network and starts to talk to random servers, they'd be at fault for causing problems.
I think this holds particularly strong for this case as the requests are not tied to an obvious user action: If I typed "http://dumbo/" into the address bar and the browser's GET request broke the server, I'd be more inclined to view the server's team at fault than if I just searched for "dumbo" and found out the browser broke a server that I didn't even know existed.
Independent of that, it's of course good advice to always build your services as robust as possible - internal or not - and to follow the spec wherever you're able to.
This code has been in Chrome since 2010. When you've been doing something for the last ten years, you aren't changing the status quo, now you are part of the status quo.
> I think it's legitimate for a fully internal server on an internal network that only handles internal clients to only implement the parts of the HTTP spec that are relevant to the exchange.
So, there are two ways of "not implementing HEAD": (1) ways that don't harm the availability of the service or other connections to it (return a HTTP error, abruptly close the connection, etc) (2) ways which do (e.g. crash the whole service upon HTTP HEAD on a single connection)
If a service isn't implementing HTTP HEAD in way (1), then Chrome isn't going to hurt it. If a service isn't implementing HTTP HEAD in way (2), then it is buggy, poorly written, and also insecure (HTTP HEAD becomes a denial of service attack), and that's not Google's problem, that's the problem of whoever maintains that service
In practice, few services which don't implement HEAD in way (2) are even going to exist, because browsers (both Chrome and others) regularly send HTTP HEAD in other circumstances as well (e.g. CORS checks). If HTTP HEAD makes your service crash, your service is going to be crashing a lot even if Google had never implemented this particular feature
Sorry for the rant, but wildcard catchall DNS is a REALLY BAD THING.
This is not universally true. If you generate separate private keys for each server-client pair, compromising one private key will limit the damage to just the one server.
No, you should be using ed25519 keys
> THIS IS ALWAYS A BAD IDEA because once any account is compromised, ALL OTHER ACCOUNTS with locally stored keys ARE ALSO COMPROMISED.
Not if you use passphrases on the key, generally together with an ssh agent, which is the best practice
cd /opt/cisco/anyconnect/bin
sudo sh umbrella_uninstall.sh
That should leave VPN functionality intact, but remove the ridiculous MITM of DNS queries.
>Furthermore if I remember correctly this "feature" in chrome was enabled in a version which was distributed to our clients maybe a month before the lockdowns so there was little time to see the effect while clients were still in the office
Which claims that the feature was rolled out recently.
This FAQ is illuminating: https://www.verisign.com/en_US/domain-names/internet-resolut...
The servers themselves are ordinary 1 RU physical rack mount servers with 1 Gbps or 10 Gbps Ethernet. Nothing special. I'm guessing that most of the load isn't from the root, e.g.: "j.root-servers.net", but from hosting the authoritative DNS servers for .com and .net (b.gtld-servers.net) on the same box. That would surely have more traffic and much more data.
"I don't care about learning, I just want it to work."
"Why do I care again?"
"Just make it do it right."
"Can you come fix the CPU again?" (Speaking about PC, with the difference explained multiple times previously.)
"Can you come fix the computer again?" (Same person speaking about monitor. Difference also explained previously.)
These are all actual quotes from Friends/Family/Co-workers
But I do see your point.
Exactly what I was trying to say. I have no issues if someone is ignorant about something, and is actually trying to learn, even unsuccessfully.
But if someone won't even try, they get no pity from me.
A user who doesn't know what address bar is and types all the things into search engine benefits Google. Therefore, you won't see any changes in Chrome.
Obviously, it's more general topic than bashing the usual IT evils. People take reading and writing for granted, just like they take having electricity and water supply for granted, but it doesn't just magically happen. There is an enormous continuing work. Remember the '80s talks about teaching kids using and programming computers because it was ESSENTIAL FOR THE FUTURE? What has happened? Computers haven't got simpler at all. You still need to teach how to use them, but today it's not a fashionable topic, and everyone pretends it's not their problem. The result of a disparate, self-maintained education is — who would've thought — uneducated people. In addition, the “educated” “specialists” treat users as if they are on a tropical plantation in a cork hat: “Those damn brutes can't learn to do anything properly! Can't argue with nature, stick to whips and simple tasks.”
It is important to remember that the radiance of modern IT sphere has little to do with Jobs' iphone presentation and whatnot. Without old simple-hearted initiatives, long forgotten BASIC listings in hobbyist journals, government programs on educational computers, and local electronics clubs a lot of people would not work there. Everyone was stupid once, there is no exception to that. The focus should be on the process of learning, not the state of being stupid.
In Firefox, it is also possible to set keyword.enabled to false and still search explicitly in the url bar via the keyword search mechanism (they overloaded the terminology a bit :/, the one if you right click on a search box and select "add a keyword for this search"). I've been thinking of trying to just use DDG style ! keywords via the url bar (and s for a default search to make it easier to type, maybe single letters would be easiest in general) rather than a search box. OTOH, the keyword search (the second type :/) seems neglected and I wouldn't be surprised to see it disappear at some point.
DNSSEC has not seen widespread adoption because of complexity in implementing and maintaining DNSSEC and concern over weaknesses in the encryption chosen. The protocol has been around a long time now and the encryption involved is not modern. Some DNS providers are making DNSSEC easier by handling keysigning and rotation with no user involvement. Just check the box that you want it activated.
DANE is the storage and retrieval of certificates via DNS. DANE depends upon DNSSEC to sign the certificate records to determine that haven't been spoofed.
There is no great conspiracy theory needed regarding why DANE has not been implemented in browsers. The browser makers have been pretty open about why they have chosen not to support it. For example code has been written for Chrome but Google has said they haven't shipped it because they don't want to support the 1024-bit RSA required as part of the DNSSEC standard.
My browser should ask my OS to resolve DNS
It's my OS's responsibility to do that - maybe sending a request to a remote server, maybe running it's own resolved, maybe using DoT, DoH, DNSSec or not
What business should it be of browser vendors?
The relation to browser vendors is that DNSSEC allows DNS to verify/validate certificates for TLS connections, which can be used by web browsers (and other applications, but web browsers would be the main users).
The future seems to be HTTPS with domain-validated certificates over insecure DNS, or even dnssec but doing the http challenge over an insecure network.
Great for state actors to inject malware into any site...
Couldn't you just run your recursive resolver as recursive resolver and let it ask respective authoritative servers directly, instead of forwarding to the middleman? You can run your own blocklists on your unbound/kresd/whatever.
Then DNS servers out on the Internet are queried by some random IP from a VPS/EC2/VM IP range, so they are about as wise as when queried by nextdns.io.
They are my favorite IaaS startup of the last 5-10 years - it is a genius idea and I wish I had thought of it.
Do you have a source for this?
But don't take my word for it:
https://ux.stackexchange.com/questions/31006/should-we-ask-f...
"While you're correct that Visa and MasterCard do not validate this information, that's not true of all credit card providers."
... actually, the entire stackex discussion at that link is fairly interesting ...
Forcing these probe requests onto Google's DNS would completely defy their purpose in the first place.
The problem with this is, of course, that a malicious resolver could detect this and NXDOMAIN those queries, while passing others through. I don't see what the incentive would be for ISPs to do that, but ISPs are weird.
I assume the reason for changing from a 10 char random string to a 7-14 char random string was exactly because some ISP's were detecting it...
https://chromium.googlesource.com/experimental/chromium/src/...
The real problem is not your ISP, but rather the fact that the most important sites on the Internet have rejected DNSSEC and aren't signed. DNSSEC can't do anything for you with hostnames in zones that haven't been signed by their operators, and, to a first approximation, every zone managed by a serious security team (with a tiny number of exceptions like Cloud Flare, who sells DNSSEC services) has declined to do so.
If you ssh to a server your OS will resolve the IP, but your SSH client will request and attempt to verify the server key. Same with browsers and HTTP.
HTTPS sure. SMTP when they start a TLS session sure, FTPs too, there's protections at a higher level to ensure MITM isn't working, and you could probably argue that's a reason that DNSSec isn't required at all - after all get the wrong IP and your secure application won't do anything past the initial handshake. That's still leaking information though.
DNSSec, if used, is something that should sit in my DNS resolver, which should be part of my OS, not in my browser or ssh client - after all I might not want to use DNS, I might want to use a different protocol for resolving address lookups.
While that might have been a better design, the reality is OS's only provide API's for unencrypted connections and each application builds their own encryption and authentication on top of that.
IBM's mainframe operating system z/OS (formerly known as MVS) has a feature called AT-TLS (Application Transparent TLS).
With AT-TLS, you can configure operating system policies to intercept TCP socket calls from an application, and automatically add TLS to the sockets. That way, some legacy app, which knows nothing about TLS, can have TLS support added to it, without any modifications required.
There is an IOCTL that can be called on the sockets, which can find out whether AT-TLS is enabled, what certificate is being used, etc. So applications can easily be enhanced to detect whether AT-TLS is enabled on a connection and respond differently.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/...
My OS resolves www.google.com to 123.45.67.8. It's the OS's responsibility to resolve the DNS, not the browser.