Chromium's Impact on Root DNS Traffic • Hacker News Board

Re: Chromium's Impact on Root DNS Traffic

#201

Post by AndyMcConachie » Fri, Aug 21, 2020, 11:06 PM UTC

tptacek wrote: post #183

AndyMcConachie wrote: post #102

Earlier quoted context omitted.

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 marketi…

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…

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

Re: Chromium's Impact on Root DNS Traffic

#202

Post by vetinari » Fri, Aug 21, 2020, 11:14 PM UTC

rsync wrote: post #174

merlinscholz wrote: post #85

Earlier quoted context omitted.

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

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.

Re: Chromium's Impact on Root DNS Traffic

#203

Post by rsync » Fri, Aug 21, 2020, 11:37 PM UTC

vetinari wrote: post #202

rsync wrote: post #174

Earlier quoted context omitted.

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

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 whe…

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.

Re: Chromium's Impact on Root DNS Traffic

#204

Post by danudey » Sat, Aug 22, 2020, 2:05 AM UTC

pmontra wrote: post #169

gregmac wrote: post #155

Earlier quoted context omitted.

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…

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.

Re: Chromium's Impact on Root DNS Traffic

#205

Post by danudey » Sat, Aug 22, 2020, 2:07 AM UTC

awj wrote: post #161

Spivak wrote: post #148

Earlier quoted context omitted.

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 wa…

> 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 "t…

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.

Re: Chromium's Impact on Root DNS Traffic

#206

Post by pvg » Sat, Aug 22, 2020, 2:15 AM UTC

aaronAgain wrote: post #193

tptacek wrote: post #185

Earlier quoted context omitted.

As I wrote above: DNSSEC can't do anything about unsigned zones, and the overwhelming majority of zones in both the North American Internet and in popular domain lists like the Moz 500 are unsigned, and will remain unsigned, despite almost a decade of pleading from DNSSEC advocates to recant. What's crazy about this is that there's a trivial solution to forged NXDOMAIN responses that people can adopt immediately: jus…

I've never looked at DOH as an attack on DNSSEC, though I suppose you could. I think the resistance is more about the big corporate and the Internet level DNS operators like Google's 8.8.8.8, they want to be able to manipulate DNS responses when necessary. I know, evil corporate IT Ops hijacking my HNN connection. No, not that. Think about a coordinated effort by top tier DNS providers globally to stop a giant bot ne…

Losing the ability to do this very specific mitigation seems a tiny price to pay for not having everybody's DNS requests have zilch for transit privacy and integrity all the time.

Re: Chromium's Impact on Root DNS Traffic

#207

Post by skissane » Sat, Aug 22, 2020, 2:56 AM UTC

xg15 wrote: post #182

skissane wrote: post #160

Earlier quoted context omitted.

> (1a) If at least two of the queries resolve to the same IP, store the IP as the "fake redirect address". 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…

> 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, fol…

> 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

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

Re: Chromium's Impact on Root DNS Traffic

#208

Post by tptacek » Sat, Aug 22, 2020, 5:01 AM UTC

AndyMcConachie wrote: post #201

tptacek wrote: post #183

Earlier quoted context omitted.

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…

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.

Re: Chromium's Impact on Root DNS Traffic

#209

Post by xg15 » Sat, Aug 22, 2020, 10:24 AM UTC

skissane wrote: post #207

xg15 wrote: post #182

Earlier quoted context omitted.

> 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, fol…

> 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 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 th…

I disagree. In this case, it would be Google who is changing 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.

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.

Re: Chromium's Impact on Root DNS Traffic

#210

Post by nikeee » Sat, Aug 22, 2020, 11:23 AM UTC

merlinscholz wrote: post #89

russellbeattie wrote: post #10

I'm sure anyone here who has set up a PiHole ad-blocking DNS server at home has run into these random domain requests and wondered what was going on. At first I thought one of my devices had a virus on it or something until I did a few searches and discovered it was Chrome being ludicrous. (Next topic: Getting Chrome to actually use the DNS provider that you specify and nothing else...)

I recently just blocked port 53 in my firewall completely, for that exact reason. I use an internal DNS server the forwards to an DOH upstream server. No more rogue devices trying to use their own dns, at least until they all switch to DOH too

I also blocked port 53 in my firewall (except for the Pihole; no DoH there). After that, I noticed that some applications have some DNS servers hard-coded. 8.8.8.8 being pretty prominent.

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.