Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Network IT Technology

A Chrome Feature is Creating Enormous Load on Global Root DNS Servers (arstechnica.com) 26

An anonymous reader shares a report: The Chromium browser -- open source, upstream parent to both Google Chrome and the new Microsoft Edge -- is getting some serious negative attention for a well-intentioned feature that checks to see if a user's ISP is "hijacking" non-existent domain results. The Intranet Redirect Detector, which makes spurious queries for random "domains" statistically unlikely to exist, is responsible for roughly half of the total traffic the world's root DNS servers receive. Verisign engineer Matt Thomas wrote a lengthy APNIC blog post outlining the problem and defining its scope. DNS, or the Domain Name System, is how computers translate relatively memorable domain names like arstechnica.com into far less memorable IP addresses, like 3.128.236.93.

Without DNS, the Internet couldn't exist in a human-usable form -- which means unnecessary load on its top-level infrastructure is a real problem. Loading a single modern webpage can require a dizzying number of DNS lookups. When we analyzed ESPN's front page, we counted 93 separate domain names -- from a.espncdn.com to z.motads.com -- which needed to be performed in order to fully load the page! In order to keep the load manageable for a lookup system that must service the entire world, DNS is designed as a many-stage hierarchy. At the top of this pyramid are the root servers -- each top-level domain, such as .com, has its own family of servers that are the ultimate authority for every domain beneath it. One step above those are the actual root servers, a.root-servers.net through m.root-servers.net.

This discussion has been archived. No new comments can be posted.

A Chrome Feature is Creating Enormous Load on Global Root DNS Servers

Comments Filter:
  • Dupe
  • So Chrome is melting Greenland?
  • More (Score:5, Insightful)

    by dohzer ( 867770 ) on Wednesday August 26, 2020 @07:32AM (#60442147)

    More information can be found here: https://tech.slashdot.org/stor... [slashdot.org]

  • Once again. (Score:5, Insightful)

    by msauve ( 701917 ) on Wednesday August 26, 2020 @07:35AM (#60442151)
    msmash proves /. "editors" don't read /.
    • I guess they liked the /. response so much the first time they just had to run it again.

      Apparently marking "Dupe" in the firehose does not help.

    • Yep. This time they dupe'd a story only one day old.

      This is my surprised face. See how surprised I am?

      Then they wonder why we complain.

      No, just kidding, they don't read the comments either

    • msmash proves /. "editors" don't read /.

      Cut him some slack. He's simply suffering from an enormous load.

    • "msmash proves /. "editors" don't read /."

      Nobody reads it anymore, it's just us bots left.

  • The real WTF here is that the resolvers which Chrome (for example) asks for the A record of "vjokephas" turn around and ask a root server for "vjokephas." (note the dot). This should never happen because TLDs shouldn't have A or AAAA records.
    • by mysidia ( 191772 )

      TLDs shouldn't have A or AAAA records.

      TLDs potentially will have those now with the introduction of the Vanity "Brand TLDs" [icannwiki.org], so they can make their website https:///example/ [example].

      • Oh well, then the root server operators need to shut up about the load and start making ICANN pay for it. Anyway, it's still stupid that these requests get to the root servers:
        1) Single-part domains ("name") should not be interpreted as "name." unless the application explicitly put that dot there. Anything else is an intrusion on the local namespace.
        2) Point 1 also means http://brandname/ goes to a host locally known by that name or none at all. Only http://brandname./ means a TLD.
        • by mysidia ( 191772 )

          then the root server operators need to shut up about the load and start making ICANN pay for it

          Its not ICANN's duty or ability to pay all the various TLD operators or Root operators' server costs. Those entities
          essentially have to fend for themselves, or in the case of commercial TLDs there is a Registry Fee people pay to register a domain in addition to the ICANN fee, and the per-TLD registry fee goes to the TLD operator.

          ICANN is a coordinating group / policy coalition; they have the tasks of mai

        • by mysidia ( 191772 )

          Point 1 also means http://brandname/ [brandname] goes to a host locally known by that name or none at all.

          I don't believe companies will agree with you. "." should be or will usually be a default search suffix, because of something you might have heard of called the DNS search order.
          Otherwise URLs such as https://google.com/ [google.com] would not work, since they need a DNS search against the "." suffix to figure out that a dot should be appended to it making the DNS lookup "https://google.com./".

          • Nobody who types a single-part domain name into anything means a host that is named by a TLD. A single-part name resolving as anything but a locally significant host name is unexpected behavior.
  • When consumers routers were using hardcoded NTP IPs and flooding the same servers every minutes. Now they started paying for servers but older routers are still active.
  • Seems we've got a new feature! Auto-dupe!

  • How is google making money off this.
    "spurious queries for random "domains" statistically unlikely to exist"

    Google does not do anything to just help. there has to be piles of cash for them somewhere.
    • by merky1 ( 83978 )

      It is under the guise of security... by bypassing your evil ISP dns, we have "stealthed" your browsing that we then record and track.

      SECURITY!!!!!!

      • It is under the guise of security... by bypassing your evil ISP dns, we have "stealthed" your browsing that we then record and track.

        SECURITY!!!!!!

        Except it doesn't bypass your ISP DNS. Chrome asks your configured DNS (your ISP DNS if you're using DHCP like most) two questions that statistically shouldn't return a IP number answer, if they do and it's the same answer then Chrome assumes that your configured DNS is giving you false information and warns you about it. The negative side effect of this is that when your configured DNS doesn't know the answer (the question is designed to be unknown) it goes up the chain to the root DNS causing unnecessary

  • It seems like basically a theft of service the maker of the browser is directly causing and therefore responsible for.

    The DNS root service is a non-profit enterprise and critical element of the internet. There is no ToS for the root dns service giving any applications or sites any permission to query them in a manner not given by the internet standards - the DNS names looked up ought to be either legitimate well-known hostnames, or a hostname supplied by an end user; certainly not frequent automated

"Virtual" means never knowing where your next byte is coming from.

Working...