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.
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.
Dupe (Score:1)
Re: (Score:1)
As Neo said: Whoa deja vu
Trying again (Score:2)
More (Score:5, Insightful)
More information can be found here: https://tech.slashdot.org/stor... [slashdot.org]
Once again. (Score:5, Insightful)
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
msmash proves /. "editors" don't read /.
Cut him some slack. He's simply suffering from an enormous load.
Re: (Score:2)
"msmash proves /. "editors" don't read /."
Nobody reads it anymore, it's just us bots left.
Why do resolvers ask A records from root servers? (Score:2)
Re: (Score:2)
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].
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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./".
Re: (Score:2)
Public NTP servers have the same issue. (Score:2)
A /. Feature is Creating Enormous Loads of Dupes (Score:1)
Seems we've got a new feature! Auto-dupe!
The question I have is (Score:2)
"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.
Re: (Score:2)
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!!!!!!
Re: (Score:3)
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
Re: (Score:2)
While everyone's familiar with Issue 1090985: Disable Intranet Redirect Detector by default [chromium.org] mentioned in ArsTechnica's article there also another issue on the feature that was opened in February, Issue 935772: Chrome FR: Disable Intranet Redirect detector for proxies [chromium.org]. I haven't tried it myself, but the latter ticket mentions this command line switch for macOS/Windows machines:
--disable-background-networking
Send Google a bill? (Score:2)
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