Hacker News Reader

Comment by merlinscholz | Hacker News Reader

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

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

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.

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.

Reply on news.ycombinator.com