Live data from Hacker News

DDoS Attack Against Dyn Managed DNS

dynstatus.com

241–250 of 721 posts

Re: DDoS Attack Against Dyn Managed DNS

#241
post #214

Out of curiosity, why do caching DNS resolvers, such as the DNS resolver I run on my home network, not provide an option to retain last-known-good resolutions beyond the authority-provided time to live? In such a configuration, after the TTL expiration, the resolver would attempt to refresh from the authority/upstream provider, but if that attempt fails, the response would be a more graceful failure of returning a la…

i seem to remember that dns has generally been reliable (until recently, i guess), probably nobody has ever thought that to be necessary. you could write a cron script that generates a date-stamped hosts file based on a list of your top-used domain names, and simply use that on your machine(s) if your dns ever goes down. that's basically a very simple local dns cache. if you feel like living dangerously, have it upda…

> i seem to remember that dns has generally been reliable (until recently, i guess)

Probably because people used to use long TTLs (1 hour, 4 hours, whatever) and now the default behavior in services like Amazon Route 53 is to use 5 minutes.

Re: DDoS Attack Against Dyn Managed DNS

#242

Relevant (or at least a-propos) post by Bruce Schneier, from a month ago: "Someone Is Learning How to Take Down the Internet" https://www.schneier.com/blog/archives/2016/09/someone_is_le... Edit: And to be clear: I don't mean to imply there's any connection :)

Prediction: A massive, sustained attack will occur on key US Internet infra on election night in an attempt to debase the US election results.

That was exactly my thought. This may be unrelated, or it may be a test run. But a large scale attack on Election Day that crippled communications would stir up unrest for a variety of reasons. Although I think that's highly unlikely to change the outcome, unrest after such a contentious election is not good.

Re: DDoS Attack Against Dyn Managed DNS

#243
post #214

Out of curiosity, why do caching DNS resolvers, such as the DNS resolver I run on my home network, not provide an option to retain last-known-good resolutions beyond the authority-provided time to live? In such a configuration, after the TTL expiration, the resolver would attempt to refresh from the authority/upstream provider, but if that attempt fails, the response would be a more graceful failure of returning a la…

All will break the moment that one of the websites that you access makes a server-side request to another website ( think about logging-services, server-clusters, database servers, etc - they all either have IPs or most-likely some domains. )

I'm not sure I understand what you're saying.

The scenario is that my local network's caching DNS resolver retains resolutions beyond the authority-provided TTL in the event that a TTL-specified refresh at expiration fails. Therefore, my web browser may—in the very rare situation where this arises—make an HTTP request to an IP address of a server that has been intentionally moved by a service provider (let's assume they did so expecting their authoritative TTL to have expired). Since this scenario only arises because my caching resolver wasn't able to reach the authority, I'm not seeing a downside.

But if I understand your reply correctly, you are saying that the web server I've contacted may, in turn, be using a DNS resolver that is similarly configured to provide last-known-good resolution when its upstream provider/authority cannot provide resolution. This would potentially result in that web server making an HTTPS API request to a wrong IP, again only in the rare case where we have defaulted to a last-known-good resolution. I'm not really seeing the problem here except that the HTTPS request might fail (if the expected service was moved and no longer exists at the last-known-good IP), but how is that worse than the DNS resolution having failed? In both cases, the back-end service request fails.

Re: DDoS Attack Against Dyn Managed DNS

#245
post #230
post #205

Earlier quoted context omitted.

I'm in New-York too and can't resolve Paypal, Etsy, Soundcloud, Github, Netflix, Heroku or Twitter

I'm in NYC too. Github.com is resolving/working fine. Netflix.com is resolved but all assets (probably) weren't loading. Additionally Zendesk is also affected.

NYC, fios: github, twitter, soundcloud, heroku back up for me. Tunneling through an ec2 instance on us-east-1d gives the same results - can't find anything that is unreachable now.

Re: DDoS Attack Against Dyn Managed DNS

#246
post #214

Out of curiosity, why do caching DNS resolvers, such as the DNS resolver I run on my home network, not provide an option to retain last-known-good resolutions beyond the authority-provided time to live? In such a configuration, after the TTL expiration, the resolver would attempt to refresh from the authority/upstream provider, but if that attempt fails, the response would be a more graceful failure of returning a la…

i seem to remember that dns has generally been reliable (until recently, i guess), probably nobody has ever thought that to be necessary. you could write a cron script that generates a date-stamped hosts file based on a list of your top-used domain names, and simply use that on your machine(s) if your dns ever goes down. that's basically a very simple local dns cache. if you feel like living dangerously, have it upda…

This company, for example, has a 99.999% uptime SLA. Thats roughly 5 minutes per year.

Re: DDoS Attack Against Dyn Managed DNS

#247
post #214

Out of curiosity, why do caching DNS resolvers, such as the DNS resolver I run on my home network, not provide an option to retain last-known-good resolutions beyond the authority-provided time to live? In such a configuration, after the TTL expiration, the resolver would attempt to refresh from the authority/upstream provider, but if that attempt fails, the response would be a more graceful failure of returning a la…

> Is there a spectacular downside to doing so? Since the last-known-good resolution would only be used if a TTL-specified refresh failed, I don't see much downside.

Because you would keep old DNS records around forever if a server goes away for good. So you need to have a timeout for that anyways.

Re: DDoS Attack Against Dyn Managed DNS

#249
post #214

Out of curiosity, why do caching DNS resolvers, such as the DNS resolver I run on my home network, not provide an option to retain last-known-good resolutions beyond the authority-provided time to live? In such a configuration, after the TTL expiration, the resolver would attempt to refresh from the authority/upstream provider, but if that attempt fails, the response would be a more graceful failure of returning a la…

Historically, doing this has been a source of a truly awe-inspiring amount of pain.

Re: DDoS Attack Against Dyn Managed DNS

#250

Relevant (or at least a-propos) post by Bruce Schneier, from a month ago: "Someone Is Learning How to Take Down the Internet" https://www.schneier.com/blog/archives/2016/09/someone_is_le... Edit: And to be clear: I don't mean to imply there's any connection :)

> The Department of Homeland Security told CNBC that it is "looking into all potential causes" of the attack.

http://www.cnbc.com/2016/10/21/major-websites-across-east-co...

Is this par for course for all large DDOS attacks or did something tip them off?

Post reply on HN