Update Regarding DDoS Event Against Dyn Managed DNS on Oct 21

> Etsy and eBay will survive. Ford survived the Exploding Pinto. Firestone survived its tire debacle. And we are all the safer for it.

Ford and Firestone aren't retailers, they're manufacturers, and they were held responsible for their own mistakes, not the mistakes of third parties.

There is no reasonable way for online retailers to evaluate product safety of millions of small batch third party products. Either they sell them without evaluating them or they don't sell them. Imposing liability on them is exactly how you get them to not sell them, but then we can't have Etsy or eBay.

> This is not the first time in history that a plague of imported items causes a problem.

It seems like the first time the problem has happened in this particular way. Historically importing was a large-scale operation done in bulk with homogeneous products, so the importer knew what they were doing and had deep pockets. Today you can cost-effectively get a 99 cent piece of electronics shipped directly from a one-person shop in China. Either you shut down the entire idea of that, and then things are going to cost a lot more than they do now, or we need a different approach.

The lawsuit will never happen, because the consumer isn't the one feeling the harm in this case.

The party feeling the harm doesn't know what the device was, where it was, whether it is still on any network, whether it is behind NAT, who owns the device, who bought the device, who distributed the device, who the retailer was, or what the attributes of the device are. So they will have a hell of a time filing a lawsuit, or, even if they try, getting standing to sue anybody.

DNS seems ripe for revolution!

Yesterday it felt obvious that we are treating DNS data as too ephemeral. I am not intimately familiar with the implementations in BIND and others, but it seems like when we hit the TTL we just throw away the data. Usually, that works fine. But, in the case of the origin servers not responding, yesterday I was wishing that it would just give me back the stale data rather than giving me nothing.

I'll admit the impact on me was somewhat limited. Around 10am Mountain I was trying to install some Atom.io modules and couldn't reach that site or a github download URL. I had some success with using 4.2.2.2 (8.8.8.8 was not answering the names).

Using a stale cached result probably wouldn't have helped for atom.io though, I hadn't been there in a while and this was querying my own local name servers. Do I want my name servers keeping weeks old stale data around? Probably not in RAM, but saving old names to disk sounds like it would require a lot of IOPS for a big provider. But I do know I'd visited the sites I was trying to hit within the last few weeks, since I couldn't reach the authoritative servers it'd be nice to have tried the last IP I had for them.

Of course, I ran into this about an hour after I rebooted my entire dev/staging infrastructure to fix the Linux kernel privilege escalation issue, so my caches were cold.

Sure would be nice if my server could "ask around" if it can't talk to an authoritative server. "Hey Google, hey Comcast, hey Level-3, do you know this name?" That's effectively what I did by changing my resolv.conf. But if you start asking around too widely, you ideally probably want to have some signature to verify the data you are getting.

Seems like the new norm might be listing authoritative DNS servers from multiple big providers (Dyn and Route53) and having to keep them in sync? Then you lose some of the advance features...

Funny aside: One of the sites I run uses Distil in front of it to protect against content scrapers. Months ago I was working with their support about getting a health checker set up in Route53 to test the full paper path through distil and fail over to our backup site if anything on the primary paper path didn't work. Distil assured me that their services were so resilient that we shouldn't worry about them being down. Guess what the only part of our infrastructure was that was impacted by this? :-)

> If it is foreseeable that your defective product would be used to harm another person, you can be held liable. Yes, the intervening actor is behaving illegally. That doesn't matter. You still bear your fair share of responsibility.

That's the point. The unlawful intervening actor has 99% of the responsibility. The security vulnerability doesn't even give them anything inherently malicious or dangerous -- anyone can buy bandwidth and IP addresses on the open market. All the vulnerability does is give them the opportunity to take them without paying.

The traditional rationale for imposing liability on the "wrong person" like that is when the actually responsible party can't be found and someone who could easily do something to prevent it can be found. But the manufacturers of these things can't be found either, and the retailers can't easily do anything about it.

And whose judgements are enforced by the government monopoly on violence!

Libertarians have this curious tendency to define institutions as "government" or "not-government" however it suits them best...