"That's another reason to use an internal DNS server which queries an upstream DOH server."
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 ...
I still don't understand what's nextdns.io doing in the stack.
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.
Anecdotally, I use three different Amazon accounts for both personal and business accounts and none of them have a real first/last name on them. In fact, I only use my actual first/last name with online payments when dealing with government agencies or regulated purchases.
Last I checked, I think “DNS Security” (DoH) was shipped in Chrome, you can pick an alternative in Settings, I think. Such as, in this case, Google. Not sure if that changes the way this nxdomain check behaves, presumably Chrome trusts TLS but not the ISP’s DoH?
For DoH Chrome does not do that check. Instead one of the requirements to be one their allowed DoH providers is that they don't do the evil redirect NX Domain responses.
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.
To me, the single bar functions kind of like a CLI for the browser. I regularly use it to:
* 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.)
There is no extra thinking, at least for me: search on the right, URLs and history on the left. I mean: it's automatic, my fingers know what to do. I guess search engine keywords would go to the right too but I don't use that feature.
Firefox's UI is kind of all over the place, but I love that I can paste or type a search term, and then arrow-key my way down to a set of search options at the bottom.
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.
I mean after a certain point you just have to accept the kinds of things that your users will type in whatever text boxes you show them and make it work. If you know what the user is trying to do then it's not good UX to throw an error or tell them "I know you're trying to search, but I won't until you retype it into this other box".
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.
> 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.
That was my first thought as well. This is going to lead to people typo'ing, opening a blank file, being confused that their credentials are gone, and then adding in the updated credentials in the wrong place.
Yes, you need keyword.enabled set to false otherwise Firefox will still search even though you have a different search box :(.
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.
In the good old times, ctrl-l went to the location bar and ctrl-k went to the search bar. After they merged, ctrl-k just prepends the question mark. But... as an old shortcut, pretty much everything supports it.
I'm referring not to a recursive nameserver, but to a caching one that simply forwards queries to an upstream resolver. Like the one in every consumer router. Usually that's dnsmasq, with this option:
-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.
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.
Not exactly. Chrome doesn't know if you're trying to enter a domain name, hence URL, or are trying to enter a search term. The Omnibar supports both. So Chrome tries to resolve the string you entered and if it gets back an NXDOMAIN it can assume that it's a search term.
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).
I think this only happens after you press enter, not as part of the omnibox real time results. After all the infobar mentioned in the article definitely only appears after you commit the search query.
So because Google thinks I am too stupid to handle a separate URL box and search box, and they are so much smarter than me that they can write a simple if-else to discern what I want with a few bullshit DNS queries, I’m stuck with a browser that leaks information and fails to do what I want several times a day until I learn to work around this behavior. And the proposed solution is for me, dumb dumb user that I am, to run my own resolver with DNSSEC validation and NSEC caching?
I am getting close to moving to a hut in the woods and forgetting all about the internet.
DNSSEC can only distinguish valid from invalid NXDOMAINs on signed zones. A tiny, tiny minority of zones in .COM, .NET, .ORG, and .IO are signed. Installing your own local DNSSEC resolver to "fix" the Chrome URL bar would be a tremendous misallocation of effort.
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.
My proposed mitigation is being deployed in every modern browser, and completely eliminates the ISP-spoofed NXDOMAIN problem. Yours asks users to install their own DNS server, and still doesn't eliminate the problem. I'm comfortable saying that my advice is correct, and the advice to use DNSSEC to solve this problem is malpractice.
