That's another reason to use an internal DNS server which queries an upstream DOH server.

"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.

Yes, of course nextdns is not required - I simply added it because that is my own setup and it adds the pihole-like ad-blocking to the workflow.

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.

> Remember, only AMEX verifies cardholder FIRST LAST. Use your VISA/MC.

Do you have a source for this?

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.

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 ...

Thanks!

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.

I'm always baffled why chrome can't have a separate search/address bar, which avoids this issue entirely.

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.

They design for an audience that, on average, cannot distinguish betweeen the address bar of the browser and the search bar on the Google homepage.

This isn't always a good thing.

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.

Computers are bad and we should feel bad.

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.

FYI:

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)

FYI

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)

Because it's designed to make as many Google queries as possible instead of being geared for URL entry.

You can prefix your searches in the omnibox with “?” and they won’t be treated as possible short local network names

Also, if you prefix a hostname with "http://" or "https://", it won't be treated as a search.

Ctrl+K for Windows users looking for a shortcut key.

It also works on Firefox (and on Linux); if you use split address/search bar it focuses to the search bar instead as it used to be.

Indeed, I normally turn off "keyword.enabled" and "browser.urlbar.oneOffSearches" in about:config.

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.

That works on multiple platforms! I'm able to do that on Arch.

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.

Isn’t “?” and ctrl-k the same number of keystrokes?

Only if you don't count your mouse clicking the omnibar as a keystroke.

That’s a good point. I didn’t consider that, and now I’ll use this shortcut. If I had been at my computer I would have realized that immediately.

Chrome leaks 1 word searches in the address bar, yes.

Your local nameserver should be configured to not forward unqualified names upstream.

Any time you say something 'should' be something, it's an indication that sometimes it's not.

There is no such thing as unqualified names at this level. All domain names are fully qualified, and comprise one or more labels.

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.

That is not an unqualified domain name, and notice that it does not say that it is.

* 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.

See https://news.ycombinator.com/item?id=15232208 .

How many people know how to configure their local name server outside of the HN crowd?

This is the default configuration in all consumer routers I've seen. Granted, that's not very many.

So how does it resolve com then? Or the (small number) of sites that are on the TLD.

It doesn't. It's not a recursive resolver. It forwards qualified names (those including a dot) to the upstream nameserver (the ISP's).

My local nameserver is run by comcast!

Really? Your router does not have a caching nameserver built in?

Both may be true. https://www.logicum.co/wp-content/uploads/2016/08/Comcast-Ro...

How do you mean? So if I type ihavecancer, it tries to resolve to ihavecancer.com or something?

It tries to resolve `ihavecancer` as a TLD, because it may be a local TLD on your intranet.

WAIT

> Wait, so Chrome leaks

That’s obviously so, because that’s it’s entire raison d’entre.

Its raison d'entre is to leak stuff to Google. While that's a problem, and probably a worse one, it's not the same problem as leaking stuff to a ISP.

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).

This post contains a bunch of information about the question, but it doesn't seem to actually address the question.

The question is: does Chromium send the first word I type to my ISP?

The answer appears to be: yes.

I justed tested this myself via logging the DNS queries, and yes, this is true.

> the first word

No.

The answer appears to be yes if you said "the only word", though.

...which the first word would be, as you typed it?

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.

depends how fast you type - there's a delay on the query so it's not re-querying for every keystroke. but probably yes.

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.

I moved to the desert in a developing country. But fibre optics to the house took 4 days and is $55/month. There is no escape.

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.

Do whatever you want as your proposed mitigation, but we are talking about the root zone here, which is signed.

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.

That infuriates me. It totally can know. Did it start with http:// https:// ftp:// ...? I really dislike how browsers decided everything is a search.

> I really dislike how browsers decided everything is a search.

Not browsers, just chrome. The rest followed.