Hacker News Reader

Comment by tptacek | Hacker News Reader

In almost any other scenario, this traffic would be indistinguishable from a distributed denial of service (DDoS) attack.

Yes, but see, it's not a distributed denial of service attack. It's a productive use of a capability the DNS roots were designed to serve. It's a huge amount of traffic because Chrome is one of the 3 most important and popular applications on the Internet, and the most popular of those, at that. The cart doesn't drag the horse.

View on HN

And the author's incorrect claim that "interception is the exception rather than the norm" doesn't help. The author tries to compare with Firefox, but Firefox captive portal test uses an existing known URL [1] which has a very different goal from Chromium's NXDOMAIN interception test. In fact I think Firefox would have to implement a similar approach if it were popular enough.

[1] http://detectportal.firefox.com/success.txt etc.

I believe the point they were making is that they could use their own domain and infrastructure for the same kind of testing. Something like "<random-chars>.nxdetect.firefox.com" would keep the responsibility for the feature on Firefox's name servers. The same could be done for Chromium rather than contributing to a tragedy of the commons situation.

There is an obvious flaw which is that this behavior is detectable and avoidable by ISPs that become aware of what that domain is being used for... But that argument applies to the current detection method as well (as this post demonstrates).

> But that argument applies to the current detection method as well (as this post demonstrates).

No, because the post is a post-mortem analysis. If ISPs are going to block this they will have to do so in live, and as presented I don't think they can do that without a disruption.

Sorry, I realized its not directly covered by the post and I read between the lines a little bit. What I read (between the lines) is that there are only a handful of truly valid roots which are all well known. None of the randomly generated Chrome domains will ever resolve to a real address because the random characters are not valid top level domains. A malicious filtering actor could fairly easily change their redirect behavior to only apply to NXDOMAINs issued to valid TLDs and bypass this check.

The original point stands in that this feature abuses a common good at the expense of an operator (requiring 2x the capacity without it by the metrics given in this post) for a niche feature that they could run with equal effectiveness against a domain they control instead.

It's not abusing anything. All it's doing is creating a prominent feature on a graph. The roots are designed to handle this kind of traffic, required to do so, and more than capable of doing so. Application developers are not required to use the DNS parsimoniously, and never have been.

The roots are a "common good" and yes they're designed to handle this level of traffic because they have to. I also agree application developers don't have to be generally restrained in their use of DNS when using the protocol for its intended purposes.

Attempting to look up domains with the intention that they don't exist and are expecting the general case to be a failed query is not using the DNS system as intended. As I mentioned this could be solved by the application including a domain they control so they are not excessively consuming a public good at the expense of others (someone does have to pay for these servers).

The roots should not be expected to double their capacity because one application implements a feature in bad faith.

The roots aren't "doubling their capacity". They're not doing anything resembling doubling their capacity. The only thing that "doubled" is a line on a graph. If your conception of the root servers is that they're generally redlining and we're just scraping by with the capacity we need for current load: no. If we don't have a shared understanding of the facts here, we can't have a productive discussion about this topic.

I think "productive" depends on who's paying the bill and whether the uses of it were how the system was actually designed. I don't think that the roots ever had the idea of serving random requests billions of times because that's the entire point of having the downstream servers and DNS caching. I remember a time when directly pinging the root servers was considered very bad practice because you should always be using the downstream... Google's method essentially makes those downstream servers useless.

All of these norms about DNS queries are deployed situationally. Namedroppers types angry about excess root queries today will defend the notion of end-user operating systems querying the roots directly to facilitate DNSSEC (which without direct recursive lookups from end-systems condenses down to a single "yes I did DNSSEC" bit set by your local DNS server).

Everybody can look at this DNS probe code and kibitz about whether it could have been done more efficiently or whether it should be done at all, but this is a straightforward use of the DNS to do something important for end-users (detect whether their ISP's nameserver is lying to them about NXDOMAIN). Whatever else it is, it isn't a DDOS attack, and whatever else these servers are, they're not quiet out-of-the-way private systems; they're core Internet infrastructure.

People seem to think DNS root queries are answered by monks or something. There are ~1000 anycast sites serving the 13 roots and their load is close enough to zero to be ignored. Even if Chrome causes half of the traffic, who cares?

Your house must look like a hoarder house, then. I mean, there was all that space in there, and space is meant for filling, so why not fill it up? /s

Like any computer system, Root DNS was designed around expectations of typical utilization and expected response time, with margins for burst traffic. Capacity was left unused for a reason.

Google's action here is an example of cost shifting. It doesn't cost Google or the individual user anything to test for a hijacked DNS resolver, because the costs are shifted to the Root DNS. As the article puts it, this cost shifting is indistinguishable from a DDoS because it consumes network capacity and CPU resources and electrical power in an unplanned fashion.

Root DNS was designed around resolving names, not testing for hijacked DNS. And just because you can use DNS to test for hijacked DNS doesn't mean you should.

Root DNS was designed around resolving names, not testing for hijacked DNS.

Says who? You? Have you double checked that belief with the RFCs? Last I looked, there's a lot more than just name->IP in the DNS. "Testing for hijacked DNS" is a DNS function. The root servers are there to make applications work, not the other way around. They're fine, and people watching them don't dictate terms to the browsers.

Well, I just searched RFCs 1034, 1035, 1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065, 2136, 2181, 2137, 2308, 2535, 2673, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 4592, 5936, 5966, 6604, 7766, 8020, 8482, 8490, and 8767 for the word "hijack", and the only reference I can find is rfc2845 §4.4, and that's referencing using TSIG to prevent man-in-the-middle TCP connection-hijacking of a DNS-over-TCP request.

Nothing that I can find there about checking for hijacked DNS. Did you have a specific RFC/section in mind that you were thinking of?

(Damn, there are a lot of RFCs devoted to DNS!)

What else could DNSSEC possibly be for, if not for testing whether DNS has been hijacked?

Reply on news.ycombinator.com