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

211–220 of 221 posts

Re: Chromium's Impact on Root DNS Traffic

#211

Post by nnt38 »

jakub_g wrote: post #167
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.

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)

Re: Chromium's Impact on Root DNS Traffic

#212

Post by skissane »

xg15 wrote: post #209
skissane wrote: post #207

Earlier quoted context omitted.

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

> I disagree. In this case, it would be Google who is changing the status quo.

This code has been in Chrome since 2010. When you've been doing something for the last ten years, you aren't changing the status quo, now you are part of 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.

So, there are two ways of "not implementing HEAD": (1) ways that don't harm the availability of the service or other connections to it (return a HTTP error, abruptly close the connection, etc) (2) ways which do (e.g. crash the whole service upon HTTP HEAD on a single connection)

If a service isn't implementing HTTP HEAD in way (1), then Chrome isn't going to hurt it. If a service isn't implementing HTTP HEAD in way (2), then it is buggy, poorly written, and also insecure (HTTP HEAD becomes a denial of service attack), and that's not Google's problem, that's the problem of whoever maintains that service

In practice, few services which don't implement HEAD in way (2) are even going to exist, because browsers (both Chrome and others) regularly send HTTP HEAD in other circumstances as well (e.g. CORS checks). If HTTP HEAD makes your service crash, your service is going to be crashing a lot even if Google had never implemented this particular feature

Re: Chromium's Impact on Root DNS Traffic

#213

Post by elric »

ubercow13 wrote: post #59
elric wrote: post #26

I don't get this feature. And I really hate that it's present in pretty much every browser these days. If I want to type an URL, I'll use the address bar. If I want to search, I'll use the search bar. Different bars with different keyboard shortcuts and different purposes. Why do so many browsers merge these two? Screens are insanely wide these days, so screen real estate can't be the reason. Are we trying to trick u…

Firefox's omnibox is probably my favourite feature, it's so much better than separate bars. The reason is that it also searches within your bookmarks and history for items matching the terms you enter. At least half the time when I use the location bar, I am looking for a site I have been to before or bookmarked, and it will pop up as the first result in the suggestions. If nothing is found, it makes sense to fall ba…

I agree that that's the least painful implementation. But last time I tried FF mobile, the behaviour had changed and it was giving me search suggestions (as in actively contacting a search engine as I was typing), with no way to turn it off. That's a deal breaker for me.

If I want to search in just my history, I can simply press CTRL-H and type to search in history.

Re: Chromium's Impact on Root DNS Traffic

#214

Post by Lammy »

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.

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

Re: Chromium's Impact on Root DNS Traffic

#215

Post by onionisafruit »

mehrdadn wrote: post #121
onionisafruit wrote: post #118

Earlier quoted context omitted.

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.

Re: Chromium's Impact on Root DNS Traffic

#217

Post by [deleted] »

ubercow13 wrote: post #59
elric wrote: post #26

I don't get this feature. And I really hate that it's present in pretty much every browser these days. If I want to type an URL, I'll use the address bar. If I want to search, I'll use the search bar. Different bars with different keyboard shortcuts and different purposes. Why do so many browsers merge these two? Screens are insanely wide these days, so screen real estate can't be the reason. Are we trying to trick u…

Firefox's omnibox is probably my favourite feature, it's so much better than separate bars. The reason is that it also searches within your bookmarks and history for items matching the terms you enter. At least half the time when I use the location bar, I am looking for a site I have been to before or bookmarked, and it will pop up as the first result in the suggestions. If nothing is found, it makes sense to fall ba…

[deleted]

Re: Chromium's Impact on Root DNS Traffic

#218

Post by JdeBP »

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.

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

Re: Chromium's Impact on Root DNS Traffic

#219

Post by JdeBP »

majewsky wrote: post #145
Slartie wrote: post #29

Earlier quoted context omitted.

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.

... only when the delegation for google. is cached.

Re: Chromium's Impact on Root DNS Traffic

#220

Post by boring_twenties »

JdeBP wrote: post #218
boring_twenties wrote: post #92

Earlier quoted context omitted.

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

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.
Post reply on HN