7 ms·

Can someone explain why this couldn't have been implemented purely client side and validating if what was entered was first even a valid hostname? Or were the D

Can someone explain why this couldn't have been implemented purely client side and validating if what was entered was first even a valid hostname? Or were the DNS queries only run after they passed an initial check? I think this is one of the key problems that emerged by merging the search functionality into the location bar. I still now always enable the separate search bar for Firefox and avoid running searches in the so-called Awesome bar. I still consider a search and host lookup very different operations in my mind.

dublinben 6y ago
Normal users don't enter hostnames directly any longer. Even for the most common sites like YouTube.com, Facebook.com and Amazon.com they will largely search the name and then click on the top search result. This behaviour actually suits Google well, because their incredibly lucrative "promoted results" are shown before the real destination site. You can't charge an advertising tax on users who browse directly to their destination.
- oconnor663 6y ago
  Normal users don't type "fa" in the browser bar and get autocompleted to "facebook.com"?
Deathmax 6y ago
I believe it was mainly to detect when a user is trying to navigate to an intranet site with a single-word name (for example http://fileserver http://fileserver). To do that, Chrome needs to make a DNS request for the word and check if it's valid. However, you can have misbehaving ISPs that replaces all NXDOMAIN responses with something (producing false positives for what constitutes "valid" hostnames), or a guest portal that is hijacking DNS responses, so Chrome will make requests for random DNS hostnames that are unlikely to exist to detect if DNS hijacking is occurring and disable the intranet detection if it is.
- lkbm 6y ago
  The APNIC post[0] backs this up, saying it's the "Intranet Redirect Detector". [1] has more details on how that system works (which is basically what you said, but slightly more in-depth). [0] https://blog.apnic.net/2021/02/04/how-chromium-reduces-root-dns-traffic/ https://blog.apnic.net/2021/02/04/how-chromium-reduces-root-... [1] https://www.archyde.com/chromium-function-against-dns-hijacking-puts-high-load-on-root-servers-computer-news/ https://www.archyde.com/chromium-function-against-dns-hijack...
- somehnguy 6y ago
  If that was the goal, it does a pretty poor job. The amount of times I've accidentally Googled things like 'internalserver', 'fileserver:80', or 'dockerhost:8000' over the years is way too high. And when you do eventually reach any of them via manually prepending 'http:// http://', they make the 'http:// http://' not visible in the bar. What confusing signaling! Hint for Chrome: if I'm appending a port and the DNS name exists I probably don't want to Google it.
  - NicoJuicy 6y ago
    Counterpoint, i do want to Google ml.net
    - Moru 6y ago
      Then you type !g ml.net
    - jbverschoor 6y ago
      or ?ml.net
      - JJMcJ 6y ago
        Or switch to Firefox, which haS an address bar and a separate search-only box.
        6y ago
shakna 6y ago
Worth noting that this doesn't actually affect the behaviour of a single user at this point in time. > Thanks, Matt, that's great to see. Note that that's the effect of the change in comment 37, which only affects Android. The desktop change is blocked on a planned experiment in M88. A wide rollout probably won't happen until late February or early March, at which point we expect an additional reduction in root traffic. [0] They were doing the DNS interception check on Android, but a different path of code was actually doing the checks (in a different way). Android was basically sending out useless requests. [0] https://bugs.chromium.org/p/chromium/issues/detail?id=1090985#c43 https://bugs.chromium.org/p/chromium/issues/detail?id=109098...
- treesknees 6y ago
  Which amazes me. Chrome does this check every time network settings change, including a new IP. So your Android phone connecting to various networks just spammed this stuff for no reason. The fact that this fixed dropped root server requests by nearly 50% is astounding.
rasengan 6y ago
Handshake [1] handles validation on the client side before making a query. [1] https://handshake.org https://handshake.org
- judge2020 6y ago
  Can you point to the specific piece of client side code that does this? It doesn’t sound like it inherently fixes the problem of either going to “myserver” (as in, http://myserver/ http://myserver/) and “myserver” (searching the web).
  - rasengan 6y ago
    Not all browsers are properly handling but placing a “.” after the name is a temporary fix.

dublinben 6y ago

Normal users don't enter hostnames directly any longer. Even for the most common sites like YouTube.com, Facebook.com and Amazon.com they will largely search the name and then click on the top search result. This behaviour actually suits Google well, because their incredibly lucrative "promoted results" are shown before the real destination site. You can't charge an advertising tax on users who browse directly to their destination.

oconnor663 6y ago
Normal users don't type "fa" in the browser bar and get autocompleted to "facebook.com"?

Deathmax 6y ago

I believe it was mainly to detect when a user is trying to navigate to an intranet site with a single-word name (for example http://fileserver http://fileserver). To do that, Chrome needs to make a DNS request for the word and check if it's valid. However, you can have misbehaving ISPs that replaces all NXDOMAIN responses with something (producing false positives for what constitutes "valid" hostnames), or a guest portal that is hijacking DNS responses, so Chrome will make requests for random DNS hostnames that are unlikely to exist to detect if DNS hijacking is occurring and disable the intranet detection if it is.

lkbm 6y ago
The APNIC post[0] backs this up, saying it's the "Intranet Redirect Detector". [1] has more details on how that system works (which is basically what you said, but slightly more in-depth). [0] https://blog.apnic.net/2021/02/04/how-chromium-reduces-root-dns-traffic/ https://blog.apnic.net/2021/02/04/how-chromium-reduces-root-... [1] https://www.archyde.com/chromium-function-against-dns-hijacking-puts-high-load-on-root-servers-computer-news/ https://www.archyde.com/chromium-function-against-dns-hijack...
somehnguy 6y ago
If that was the goal, it does a pretty poor job. The amount of times I've accidentally Googled things like 'internalserver', 'fileserver:80', or 'dockerhost:8000' over the years is way too high. And when you do eventually reach any of them via manually prepending 'http:// http://', they make the 'http:// http://' not visible in the bar. What confusing signaling! Hint for Chrome: if I'm appending a port and the DNS name exists I probably don't want to Google it.
- NicoJuicy 6y ago
  Counterpoint, i do want to Google ml.net
  - Moru 6y ago
    Then you type !g ml.net
  - jbverschoor 6y ago
    or ?ml.net
    - JJMcJ 6y ago
      Or switch to Firefox, which haS an address bar and a separate search-only box.
      - 6y ago

shakna 6y ago

Worth noting that this doesn't actually affect the behaviour of a single user at this point in time. > Thanks, Matt, that's great to see. Note that that's the effect of the change in comment 37, which only affects Android. The desktop change is blocked on a planned experiment in M88. A wide rollout probably won't happen until late February or early March, at which point we expect an additional reduction in root traffic. [0] They were doing the DNS interception check on Android, but a different path of code was actually doing the checks (in a different way). Android was basically sending out useless requests. [0] https://bugs.chromium.org/p/chromium/issues/detail?id=1090985#c43 https://bugs.chromium.org/p/chromium/issues/detail?id=109098...

treesknees 6y ago
Which amazes me. Chrome does this check every time network settings change, including a new IP. So your Android phone connecting to various networks just spammed this stuff for no reason. The fact that this fixed dropped root server requests by nearly 50% is astounding.

rasengan 6y ago

Handshake [1] handles validation on the client side before making a query. [1] https://handshake.org https://handshake.org

judge2020 6y ago
Can you point to the specific piece of client side code that does this? It doesn’t sound like it inherently fixes the problem of either going to “myserver” (as in, http://myserver/ http://myserver/) and “myserver” (searching the web).
- rasengan 6y ago
  Not all browsers are properly handling but placing a “.” after the name is a temporary fix.