Live data from Hacker News

DDoS Attack Against Dyn Managed DNS

dynstatus.com

471–480 of 721 posts

Re: DDoS Attack Against Dyn Managed DNS

#471
post #451

Earlier quoted context omitted.

Assume we serve the last known record after TTL. Here's the attack: - Compromise IP (maybe facebook.com) - DDoS nameservers - facebook removes IP from rotation - Users still connect to bad actor even though TTL expired "We have standards for a reason" is absolutely correct, and we can't start ignoring the standards because someone can't imagine why we need them _at this moment_

Yes, but there's one piece missing. > Here's the attack: > - Compromise IP (maybe facebook.com) - Attacker generates or acquires counterfeit facebook.com certificate. > - DDoS nameservers > - facebook removes IP from rotation > - Users still connect to bad actor even though TTL expired I understand what you are saying, but this attack scenario is extraordinarily difficult as a means to attack users who have opted to…

You're right! Completely, absolutely, 100% right. If this was a plausible attack vector, we could see it used now. And you know what? We do!

This is why some people are concerned about technical decisions that make this vector more dangerous. Systems that attack by, say, injecting DNS responses already exist and are deployed in real life. The NSA has one - Quantum. Why make the cache poisoning worse?

Re: DDoS Attack Against Dyn Managed DNS

#472
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…

It'd be nice to have a "backup TTL" included, to allow sites to specify whether and how long they wanted such caching behavior. Also, that cache would need to only kick in when the server was unreachable or produced SERVFAIL, not when it returned a negative result. Negative results returned by the authoritative server are correct, and should not result in the recursive resolver returning anything other than a negativ…

> Also, that cache would need to only kick in when the server was unreachable or produced SERVFAIL, not when it returned a negative result. Negative results returned by the authoritative server are correct, and should not result in the recursive resolver returning anything other than a negative result.

Precisely. I am not suggesting any change to how a caching resolver comprehends valid responses from the authoritative server for a domain. For example, if the authoritative server says, "No such domain," then the domain is understood to be gone. At that point, the domain being gone is in fact the last-known-good resolution.

Re: DDoS Attack Against Dyn Managed DNS

#474

I wanted to provide an update on the PagerDuty service. At this time we have been able to restore the service by migrating to our secondary DNS provider. If you are still experiencing issues reaching any pagerduty.com addresses, please flush your DNS cache. This should restore your access to the service. We are actively monitoring our service and are working to resolve any outstanding issues. We sincerely apologize f…

The outage started more than eight hours before you posted this message..

Re: DDoS Attack Against Dyn Managed DNS

#475

Earlier quoted context omitted.

Flush your DNS like the parent said.

Flushing DNS wont do shit

pagerduty.com moved to Route53, but the TTL on NS records can be very long. Flushing (restarting, ...) whatever can cache DNS records in your infra will help to quickly pick up the new nameservers.

Re: DDoS Attack Against Dyn Managed DNS

#476

I wanted to provide an update on the PagerDuty service. At this time we have been able to restore the service by migrating to our secondary DNS provider. If you are still experiencing issues reaching any pagerduty.com addresses, please flush your DNS cache. This should restore your access to the service. We are actively monitoring our service and are working to resolve any outstanding issues. We sincerely apologize f…

"Challenges" is exactly the sort of Dilbertesque euphemism that you should never say in a situation like this.

Calling it a "challenge" implies that there is some difficult, but possible, action that the customer could take to resolve the issue. Since that is not the case, this means either you don't understand what's going on, or you're subtly mocking your customers inadvertently.

Try less to make things sound nice and MBAish, and try more to just communicate honestly and directly using simple language.

Re: DDoS Attack Against Dyn Managed DNS

#477
post #431

Earlier quoted context omitted.

I appreciate the update, but your service has been unavailable for hours already. This is unacceptable for a service whose core value is to ensure that we know about any incidents.

Given that a large swath of SaaS services, infrastructure providers, and major sites across the internet are impacted, this seems harsh. Are you unhappy with PagerDuty's choice of DNS provider, or something else they have control over? I don't think anyone saw this particular problem coming.

A company that bills themselves as a reliable, highly available disaster handling tool ought to know better than to have a single point of failure anywhere in its infrastructure.

Specifically, they shouldn't have all of their DNS hosted with one company. That is a major design flaw for a disaster-handling tool.

Re: DDoS Attack Against Dyn Managed DNS

#479
post #468

Earlier quoted context omitted.

You apparently don't understand DNS. DynDNS is a very reputable DNS provider that twitter and many others use. For someone to take them down requires a massive amount of effort. Running a redundant DNS provider is expensive as all hell.

Really? Route53 on AWS is $0.50/zone and $0.40/million queries. API integration is also very easy. Using something like Route53 as a backup is significantly cheaper than suffering from the current Dyn outage.

That is not helpful if you want vanity name servers

Re: DDoS Attack Against Dyn Managed DNS

#480

Earlier quoted context omitted.

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

Assuming you're referring specifically to targeting media companies reporting on the results and not the electric grid like someone else mentioned, wouldn't they have to DDoS Google itself for that to work? I don't really see a DDoS of Google being effective.

.
Post reply on HN