Hacker News Reader

Comment by Animats | Hacker News Reader

"“One of our cloud services associated with maintaining router operations was negatively impacted by a change made in our data center that caused a false denial of service."

Well, that's a non-explanation explanation. What "cloud services associated with maintaining router operations" are being performed? "Lawful interception", perhaps? Somebody needs to record the traffic between the router and Belkin HQ.

View on HN

While the conspiracy theories are fun, what actually was happening was that the router pinged a heartbeat server they had to detect whether it was connected to the internet, and when it wasn't, it would shut off the dns resolver so browsers would get the "internet is not connected" error messages, rather than some other random one.

That's what Reddit says. (http://www.reddit.com/r/technology/comments/2ik43h/belkin_fi...) Belkin, though, didn't say that. Some people thought that Belkin did a remote firmware update on the device. Belkin's own site indicates that firmware updates must be performed through the device's web interface, which, hopefully, can't be reached from the outside network.

Belkin routers apparently talk to "heartbeat.belkin.com", which is really an Amazon AWS instance.

Apparently they moved it to AWS in the past day, perhaps to recover from the outage.

During the outage heartbeat.belkin.com resolved to 67.20.176.130 which is held by Sungard.

We (and several other ISPs) got our customers back online by putting 67.20.176.130/32 on a loopback interface on one of our routers so it would always respond to pings. Other ISPs put overrides in their caching DNS servers so heartbeat.belkin.com always resolves to 127.0.0.1 (belkin.com doesn't roll DNSSEC).

this seems like fairly poor design. A router can't ping some heartbeat IP, therefore it shuts itself down?

It's not the heartbeat I take issue with - it's the dependency on the heartbeat for operation that doesn't seem to make sense.

Reply on news.ycombinator.com