Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chromium's Impact on Root DNS Traffic

blog.apnic.net

Post reply on HN
Print view View original

141–150 of 221 posts

Re: Chromium's Impact on Root DNS Traffic

#141

Post by majewsky »

kevincox wrote: post #138

It seems like they could rotate these much less frequently to let caches work. It seems that these are random to avoid DNS servers hardcoding a response for them. However they could be pseudo random based on the current day, month or release so that it would be hard enough to intercept them (unless the DNS server was really committed to doing this, but there are other ways to achieve this) while still allowing a lot…

> It seems that these are random to avoid DNS servers hardcoding a response for them. However they could be pseudo random based on [the current date and browser release]

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

Re: Chromium's Impact on Root DNS Traffic

#142

Post by majewsky »

gruez wrote: post #129
peteretep wrote: post #58

Wait, so Chrome leaks the first word of my searches to my ISP? That doesn’t sound like something I want to happen

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

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.

Re: Chromium's Impact on Root DNS Traffic

#143

Post by gnu8 »

AndyMcConachie wrote: post #102
peteretep wrote: post #58

Wait, so Chrome leaks the first word of my searches to my ISP? That doesn’t sound like something I want to happen

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…

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.

Re: Chromium's Impact on Root DNS Traffic

#144

Post by a1369209993 »

josteink wrote: post #100
peteretep wrote: post #58

Wait, so Chrome leaks the first word of my searches to my ISP? That doesn’t sound like something I want to happen

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

Re: Chromium's Impact on Root DNS Traffic

#145

Post by majewsky »

Slartie wrote: post #29
thayne wrote: post #25

Earlier quoted context omitted.

Google could, you know, use their own DNS servers for this...

No, they couldn't. The whole purpose of these probe requests is to assess whether the DNS server used by a particular client is acting normally (responding with NXDOMAIN if a domain does not exist), so these must bde sent to the DNS server of the client, which effectively means that unless this DNS server performs the hijacking that is to be detected, they will inevitably end up on a root DNS server, because no serve…

Instead of http://asdoguhwrouyh, they could probe something like http://asdoguhwrouyh.google or anything else in a zone owned by them, so the uncachable traffic would hit only their authoritative name servers and not the root servers.

Re: Chromium's Impact on Root DNS Traffic

#147

Post by iso1631 »

londons_explore wrote: post #136
ViViDboarder wrote: post #132

Earlier quoted context omitted.

That’s not how SSH or HTTP work. 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.

In an alternate universe, an application would call connect('google.com', secure=true), and the OS would make an encrypted connection and verify that the person on the other end of the connection really was google.com using dnssec published keys. 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 authentic…

In reality my browser says "connect to www.google.com on port 80", the the library eventually calling like getaddrinfo to translate the domain name to an IP address.

My OS resolves www.google.com to 123.45.67.8. It's the OS's responsibility to resolve the DNS, not the browser.

Re: Chromium's Impact on Root DNS Traffic

#148

Post by Spivak »

majewsky wrote: post #142
gruez wrote: post #129

Earlier quoted context omitted.

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

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.

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.

Re: Chromium's Impact on Root DNS Traffic

#149

Post by iso1631 »

ViViDboarder wrote: post #132
iso1631 wrote: post #113

Earlier quoted context omitted.

Shouldn't it be up to my OS to do that validation though, not the browser? After all when I ssh to my.server.com I want the same guarentee as when I https to it.

That’s not how SSH or HTTP work. 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.

No, browsers won't do anything of the sort with HTTP. Or ftp. Or SMTP.

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.

Re: Chromium's Impact on Root DNS Traffic

#150

Post by IX-103 »

lstamour wrote: post #130
merlinscholz wrote: post #85

Earlier quoted context omitted.

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

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.

Post reply on HN