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

71–80 of 221 posts

Re: Chromium's Impact on Root DNS Traffic

#71

Post by ogurechny »

elric wrote: post #46
g2347890 wrote: post #36

Earlier quoted context omitted.

all technically deprived people I have seen, use none of the above, the first thing they do is open google (most have it nowadays in defult tab page) and they type the URLs given to them there, no one knows about address/search bar, and if some know, they expect it to work like the google search box Update: I hide some site of mine from google, I do not care about SE traffic and block any crawler, and I have noticed…

Isn't that just a matter of educating users? Users, contrary to popular belief, are not stupid. Everyone starts off knowing nothing at all, but we can teach them what an address is and we can teach them how to search for things.

It most certainly is. Current “startup culture” (or should we say “swindle culture”?) values illiteracy of the masses because everyone's dream is, in simple terms, to screw millions (or billions) of fools over and make a lot of money from it. No wonder the path of adopting to ignorance, downgrading to lower level is chosen instead of the path of education and lifting people higher.

A user who doesn't know what address bar is and types all the things into search engine benefits Google. Therefore, you won't see any changes in Chrome.

Obviously, it's more general topic than bashing the usual IT evils. People take reading and writing for granted, just like they take having electricity and water supply for granted, but it doesn't just magically happen. There is an enormous continuing work. Remember the '80s talks about teaching kids using and programming computers because it was ESSENTIAL FOR THE FUTURE? What has happened? Computers haven't got simpler at all. You still need to teach how to use them, but today it's not a fashionable topic, and everyone pretends it's not their problem. The result of a disparate, self-maintained education is — who would've thought — uneducated people. In addition, the “educated” “specialists” treat users as if they are on a tropical plantation in a cork hat: “Those damn brutes can't learn to do anything properly! Can't argue with nature, stick to whips and simple tasks.”

It is important to remember that the radiance of modern IT sphere has little to do with Jobs' iphone presentation and whatnot. Without old simple-hearted initiatives, long forgotten BASIC listings in hobbyist journals, government programs on educational computers, and local electronics clubs a lot of people would not work there. Everyone was stupid once, there is no exception to that. The focus should be on the process of learning, not the state of being stupid.

Re: Chromium's Impact on Root DNS Traffic

#72

Post by ogurechny »

jve wrote: post #54
1vuio0pswjnm7 wrote: post #49

Why does Chrome (Google) need to know whether DNS is being intercepted? What actions does Google take based on the answer? Note that under this crude test of sending queries for unregistered domains, a user who administers their own DNS could be indistingushiable from "DNS interception" by an ISP or other third party. I administer my own DNS. I do not use third party DNS. These random queries would just hit my own DN…

From article: > Users on such networks might be shown the “did you mean” infobar on every single-term search. To work around this, Chromium needs to know if it can trust the network to provide non-intercepted DNS responses. Don't know if this is the sole reason.

No, the point is that in combined address and search bar you don't know whether something is a (local) domain or a search query. You can recognize known TLDs, but that's it.

Guess what Google' priorities were when they approached that problem.

Re: Chromium's Impact on Root DNS Traffic

#73

Post by Arnt »

ebg13 wrote: post #34
tasogare wrote: post #32

Earlier quoted context omitted.

> Screens are insanely wide these days This is not relevant for URL or search bars since they need to be displayed horizontally. Separate bars means less vertical screen space, which is still scarce.

> This is not relevant for URL or search bars since they need to be displayed horizontally Need? Has anyone tried?

I've seen it, back around 1999, possibly konqueror? Something that let you drag around toolbars and if you moved the address bar to the left/right side it would change the direction of writing.

Let's say that testing it briefly was enough. Editing tilted text works up to around 45 degrees, steeper than that is a strain.

Re: Chromium's Impact on Root DNS Traffic

#75

Post by londons_explore »

moonchild wrote: post #56
jiggawatts wrote: post #53

Earlier quoted context omitted.

So it looks like the root namespace providers output a totally reasonable amount of traffic. Divided between the hundreds of points of presence globally, this is tens of megabits per physical host. This FAQ is illuminating: https://www.verisign.com/en_US/domain-names/internet-resolut... The servers themselves are ordinary 1 RU physical rack mount servers with 1 Gbps or 10 Gbps Ethernet. Nothing special. I'm guessing…

Reasonable quantity of traffic, but they have to be very reliable.

No need for reliability when there is 26 way failover...

Re: Chromium's Impact on Root DNS Traffic

#76

Post by londons_explore »

amalcon wrote: post #69
thayne wrote: post #25

Earlier quoted context omitted.

Google could, you know, use their own DNS servers for this...

It wouldn't usually help to use 8.8.8.8, but they probably could use their own authoritative servers instead of the root servers. Look up .dnstest.google.com or .dev or something. The problem with this is, of course, that a malicious resolver could detect this and NXDOMAIN those queries, while passing others through. I don't see what the incentive would be for ISPs to do that, but ISPs are weird.

> that a malicious resolver could detect this

I assume the reason for changing from a 10 char random string to a 7-14 char random string was exactly because some ISP's were detecting it...

Re: Chromium's Impact on Root DNS Traffic

#77

Post by nickelpro »

stefan_ wrote: post #68
pilif wrote: post #64

Earlier quoted context omitted.

how would they maintain the root servers and correct issues without shell access or tcpdump? Make blind guesses and restart the server until the problem goes away (it won't)? No matter how high-profile the environment, eventually, the rubber will hit the road and some human will be in a privileged position to be able to fix a problem. That is true for every single service out there. Yes. Including Gmail. Including AW…

Why is a server with a problem still part of the root zone? And no, this is absolutely not the case for serious operators. Access to production systems is highly regulated.

Yes, highly regulated access with lots of hoop jumping, that's what they said. And there exists a person who has jumped through all the hoops and has that access. And that hoop jumping person ran tcpdump on the root server.

Re: Chromium's Impact on Root DNS Traffic

#78

Post by londons_explore »

encom wrote: post #67
mschuster91 wrote: post #13

The worst thing is, this will not even detect a well written NXDOMAIN interceptor that only hijacks requests to valid top level domains. It's about time for DNSSEC to be available on all TLDs and for browsers to nag if it is broken.

This comment, and another one mentioning DNSSEC has been downvoted. Please explain why you hate DNSSEC instead of downvoting things you disagree with.

Browser vendors seem to have shelved all work on DNSSEC for reasons they haven't publically stated. It had such promises to be able to reduce trust in CA's by pinning HTTPS certificates to DNS responses, so was exactly what browsers would have wanted, yet still all work stopped around 2015 or so.

To me, it's as if DNSSEC has some critical and unfixable security vulnerability, and people who make these decisions decided to stop all work on it, but not reveal the vulnerability because doing so would do too much damage.

This is probably the most comprehensive list of reasons not to use it: https://www.imperialviolet.org/2015/01/17/notdane.html

Re: Chromium's Impact on Root DNS Traffic

#79

Post by fanf2 »

jiggawatts wrote: post #53
steventhedev wrote: post #42

Earlier quoted context omitted.

Assuming the mean is close to the median, they are reporting ~10B requests daily with a median response size of around 1KB. 10TB daily is a little under 1Gpbs. Traffic is spiky, but this isn't particularly complex once you consider they have multiple data centers/servers. Of course, I may have misread something as daily that was hourly or something like that...

So it looks like the root namespace providers output a totally reasonable amount of traffic. Divided between the hundreds of points of presence globally, this is tens of megabits per physical host. This FAQ is illuminating: https://www.verisign.com/en_US/domain-names/internet-resolut... The servers themselves are ordinary 1 RU physical rack mount servers with 1 Gbps or 10 Gbps Ethernet. Nothing special. I'm guessing…

The root servers only serve the root, root-servers.net, and .arpa, and they are starting to move .arpa elsewhere - https://lists.dns-oarc.net/pipermail/dns-operations/2020-Aug...

Re: Chromium's Impact on Root DNS Traffic

#80

Post by xg15 »

Couldn't the traffic be somewhat reduced by changing the time and order of operations?

Currently, Chrome does the following:

(1) on each network change, send three DNS requests with random hostnames.

(1a) If at least two of the queries resolve to the same IP, store the IP as the "fake redirect address".

(2) on a user search, query the first search term as DNS.

(2a) If the query result is NXDOMAIN or matches the fake redirect address, do nothing. Otherwise, show the "local domain" hint.

Instead, it could do:

(1) on a user search, query the first search term as DNS.

(1a) if the query comes back with NXDOMAIN, don't show the hint and stop. We're done.

(2) otherwise, make two more DNS queries with random domain names to check for fake redirects.

(2a) if the two queries resolve to the same IP as the first one, we have a fake redirect. Don't do anything. Otherwise, show the "local domain" hint.

Results of step (2) could be cached until a network change.

This would only require 2 instead of 3 probe queries and only if the user actually searched for something and if the search term actually caused a DNS match (fake or genuine).

Post reply on HN