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

161–170 of 221 posts

Re: Chromium's Impact on Root DNS Traffic

#161

Post by awj »

Spivak wrote: post #148
majewsky wrote: post #142

Earlier quoted context omitted.

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

Re: Chromium's Impact on Root DNS Traffic

#162

Post by [deleted] »

jiggawatts wrote: post #9
gbil wrote: post #6

Earlier quoted context omitted.

We got hit by this issue in March when our remotr users increased 5+ times and the DNS traffic going through our VPNs was causing a headache to our DNS servers. We pinpointed this to tis Chrome functionality, which includes also other chromium based browers like new Edge, and we had to deploy a relevant GPO to disable this functionality. Some background, I'm talking about ~200+k remote users. Also while in the office…

The last time I saw DNS throughput or performance issues was around 2003 on a network with 200K desktops and servers. That was 17 years ago, and they don't have a problem any more, despite growing in footprint to nearly half a million client machines. I struggle to understand how DNS can possibly be a performance issue in 2020. In most corporate environments, the "working set" of a typical DNS servers will fit in the…

[deleted]

Re: Chromium's Impact on Root DNS Traffic

#163

Post by stjohnswarts »

boring_twenties wrote: post #92
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

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

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

Re: Chromium's Impact on Root DNS Traffic

#164

Post by skissane »

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 an alternate universe, an application would call connect('google.com', secure=true), and the OS would make an encrypted connection

IBM's mainframe operating system z/OS (formerly known as MVS) has a feature called AT-TLS (Application Transparent TLS).

With AT-TLS, you can configure operating system policies to intercept TCP socket calls from an application, and automatically add TLS to the sockets. That way, some legacy app, which knows nothing about TLS, can have TLS support added to it, without any modifications required.

There is an IOCTL that can be called on the sockets, which can find out whether AT-TLS is enabled, what certificate is being used, etc. So applications can easily be enhanced to detect whether AT-TLS is enabled on a connection and respond differently.

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/...

Re: Chromium's Impact on Root DNS Traffic

#165

Post by triangleman »

cbsks wrote: post #158
majewsky wrote: post #142

Earlier quoted context omitted.

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…

Computers are bad and we should feel bad.

Re: Chromium's Impact on Root DNS Traffic

#166

Post by joveian »

tankenmate wrote: post #140
forgotpwd16 wrote: post #126

Earlier quoted context omitted.

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.

Re: Chromium's Impact on Root DNS Traffic

#167

Post by jakub_g »

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.

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)

Re: Chromium's Impact on Root DNS Traffic

#168

Post by mzs »

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…

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

Re: Chromium's Impact on Root DNS Traffic

#169

Post by pmontra »

gregmac wrote: post #155
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.

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.

Re: Chromium's Impact on Root DNS Traffic

#170

Post by xnyanta »

warp wrote: post #154
majewsky wrote: post #145

Earlier quoted context omitted.

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.

But then a lying DNS server could easily identify those, and NOT lie about http://*.google -- the reason these requests are entirely random domain names is so they're not easily recognized as probes.

Except that the queries are already totally identifiable as probes in their current form, which is demonstrated in the article.
Post reply on HN