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

191–200 of 221 posts

Re: Chromium's Impact on Root DNS Traffic

#191

Post by aaronAgain »

kevincox wrote: post #187
majewsky wrote: post #141

Earlier quoted context omitted.

> It seems that these are random to avoid DNS servers hardcoding a response for them. However they could be pseudo random based on [the current date and browser release] That would still allow ISPs to compute the limited number of domains for which NXDOMAIN would need to be sent at any given point in time. (Whether they'd do it is another story. The random pattern currently used by Chrome looks like it may still be e…

As I said, if they make specific effort they will succeed. The current scheme can be broken by returning a number of different IPs instead of one or two. I think my proposal has a nice balance between making ISPs put in non-trivial effort and not putting a lot of load on the root servers.

This is a classic arms race. The hijackers back off for a while, but as is always the case in low-margin, low-regulation, low-consequence environments, bad actors will present a way to skim a tiny value out a massive amount of transactions. Give a percentage of that to the network operator, and take the rest home.

The network operators enable this behavior. It would be next to impossible for it to be useful (ROI wise) if they didn't intentionally support it with access to their networks. It doesn't need to be an arms race, but we refuse to regulate or punish anyone in this space. We waste massive amounts of resources detecting and counteracting the hijacking services. The human (developer) cost is where the big waste is here, not electricity.

and the fight goes on....

Re: Chromium's Impact on Root DNS Traffic

#192

Post by aaronAgain »

ananonymoususer wrote: post #115
zootboy wrote: post #24

Earlier quoted context omitted.

> THIS IS ALWAYS A BAD IDEA because once any account is compromised, ALL OTHER ACCOUNTS with locally stored keys ARE ALSO COMPROMISED. This is not universally true. If you generate separate private keys for each server-client pair, compromising one private key will limit the damage to just the one server.

That is just not true. It may be the case if the key itself is compromised, but consider that you may have many different accounts scattered on different servers. Once one of them is compromised, the attacker now has access to every other account because they are all chained together.

Yeah, the argument you are making about all keys being compromised doesn't make sense. You are leaving out a key assumption in your setup, and without it is not possible (for us) to accept the chained compromise you are describing.

Re: Chromium's Impact on Root DNS Traffic

#193

Post by aaronAgain »

tptacek wrote: post #185
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.

As I wrote above: DNSSEC can't do anything about unsigned zones, and the overwhelming majority of zones in both the North American Internet and in popular domain lists like the Moz 500 are unsigned, and will remain unsigned, despite almost a decade of pleading from DNSSEC advocates to recant. What's crazy about this is that there's a trivial solution to forged NXDOMAIN responses that people can adopt immediately: jus…

I've never looked at DOH as an attack on DNSSEC, though I suppose you could. I think the resistance is more about the big corporate and the Internet level DNS operators like Google's 8.8.8.8, they want to be able to manipulate DNS responses when necessary. I know, evil corporate IT Ops hijacking my HNN connection. No, not that.

Think about a coordinated effort by top tier DNS providers globally to stop a giant bot network by simultaneously 'hijacking' DNS responses for the command and control server host-names. In classic DNS this is easy, just intercept the requests at the LDNS provider and return a dummy server IP, all good.

That falls apart with DOH and DNSSEC. With DNSSEC you cannot forge a response to a client that strictly expects signed responses for a particular zone. And with DOH, the various corporate IT shops cannot inspect and 'hijack' the responses. Though, the DOH operator can still change the response. But that moves the capability outside of local corporate IT and into a multinational company that might not agree with your request to 'fix' a problem via assisted DNS hijacking.

So all of these new, safer DNS delivery methods do legitimately impact the ability of "good"* operators to protect the Internet. Is the trade off worth it to protect users DNS traffic versus being able to respond to threats? I think that protecting users daily traffic is net-net better as it is a steady state problem and state sponsored actors have the resources to subvert a population via DNS. But I also feel the loss of a tool to protect users at the same time. Things like this are never zero-sum.

Disclaimer: I work for Microsoft and although I don't operate DNS services as part of my job, I have spent a lot of time on this particular topic over the years. These are my opinions, not the companies. I welcome challenges to my opinions, that's how I learn.

*"good" is always a situational thing.

Re: Chromium's Impact on Root DNS Traffic

#194

Post by ikiris »

xg15 wrote: post #80

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…

This adds at least one full RTT, which chome is very much about minimizing them on user queries.

Re: Chromium's Impact on Root DNS Traffic

#195

Post by xg15 »

ikiris wrote: post #194
xg15 wrote: post #80

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…

This adds at least one full RTT, which chome is very much about minimizing them on user queries.

True, but I think it would be acceptable in this situation:

- the queries only affect the time after which the "local domain" hint appears. They don't influence the time until the main search results appear.

- if the result is cached, the additional roundtrip is only for the first hostname entered after a network change.

- the two "random hostname" probes can be executed in parallel, so it should not result in more than one additional roundtrip.

Re: Chromium's Impact on Root DNS Traffic

#196

Post by xg15 »

brown9-2 wrote: post #86
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

You can prefix your searches in the omnibox with “?” and they won’t be treated as possible short local network names

Also, if you prefix a hostname with "http://" or "https://", it won't be treated as a search.

Re: Chromium's Impact on Root DNS Traffic

#197

Post by Shared404 »

0xdeadb00f wrote: post #65
Shared404 wrote: post #48

Earlier quoted context omitted.

> Users, contrary to popular belief, are not stupid. "I don't care about learning, I just want it to work." "Why do I care again?" "Just make it do it right." "Can you come fix the CPU again?" (Speaking about PC, with the difference explained multiple times previously.) "Can you come fix the computer again?" (Same person speaking about monitor. Difference also explained previously.) These are all actual quotes from F…

Ignorance isn't stupidity. But it may be classified as stupid to purposefully remain ignorant so idk. But I do see your point.

> Ignorance isn't stupidity. But it may be classified as stupid to purposefully remain ignorant

Exactly what I was trying to say. I have no issues if someone is ignorant about something, and is actually trying to learn, even unsuccessfully.

But if someone won't even try, they get no pity from me.

Re: Chromium's Impact on Root DNS Traffic

#198

Post by rsync »

bacondude3 wrote: post #178
rsync wrote: post #174

Earlier quoted context omitted.

"That's another reason to use an internal DNS server which queries an upstream DOH server." Even better, spin up a little VM or VPS somewhere in the cloud, install 'unbound' as a recursive resolver and point it to your nextdns.io account/address. Let's unpack this ... backwards ... DNS servers out on the Internet are queried by nextdns, which presumably has no PII from you other than your CC number[1] and zip code. N…

> Remember, only AMEX verifies cardholder FIRST LAST. Use your VISA/MC. Do you have a source for this?

Anecdotally, I use three different Amazon accounts for both personal and business accounts and none of them have a real first/last name on them. In fact, I only use my actual first/last name with online payments when dealing with government agencies or regulated purchases.

But don't take my word for it:

https://ux.stackexchange.com/questions/31006/should-we-ask-f...

"While you're correct that Visa and MasterCard do not validate this information, that's not true of all credit card providers."

... actually, the entire stackex discussion at that link is fairly interesting ...

Re: Chromium's Impact on Root DNS Traffic

#199

Post by shock »

mzs wrote: post #168
AndyMcConachie wrote: post #102

Earlier quoted context omitted.

Not exactly. Chrome doesn't know if you're trying to enter a domain name, hence URL, or are trying to enter a search term. The Omnibar supports both. So Chrome tries to resolve the string you entered and if it gets back an NXDOMAIN it can assume that it's a search term. The problem is that some ISPs have configured their DNS resolvers to lie and not return NXDOMAIN. Instead redirecting you to some website for marketi…

That infuriates me. It totally can know. Did it start with http:// https:// ftp:// ...? I really dislike how browsers decided everything is a search.

> I really dislike how browsers decided everything is a search.

Not browsers, just chrome. The rest followed.

Re: Chromium's Impact on Root DNS Traffic

#200

Post by bacondude3 »

rsync wrote: post #198
bacondude3 wrote: post #178

Earlier quoted context omitted.

> Remember, only AMEX verifies cardholder FIRST LAST. Use your VISA/MC. Do you have a source for this?

Anecdotally, I use three different Amazon accounts for both personal and business accounts and none of them have a real first/last name on them. In fact, I only use my actual first/last name with online payments when dealing with government agencies or regulated purchases. But don't take my word for it: https://ux.stackexchange.com/questions/31006/should-we-ask-f... "While you're correct that Visa and MasterCard do n…

Thanks!
Post reply on HN