Live data from Hacker News

DDoS Attack Against Dyn Managed DNS

dynstatus.com

551–560 of 721 posts

Re: DDoS Attack Against Dyn Managed DNS

#551

Earlier quoted context omitted.

> Worst case, they know and set up a phishing site. They'd need to specifically gain access to the last known good IP address, which might be different depending on which DNS resolver you talk to (geodistribution, when the record was last updated, etc). I wouldn't really consider that a realistic attack vector.

Withing a small hosting provider this might be pretty simple. Attacker might lease a bunch of new servers and get the IP that was recently released. Then they could launch a DDoS to force address resolution in their favor. It's a bit far-fetched, but a lot of very successful attacks seem that way until someone figures out a way to pull them off.

Sure, within a small host or ISP, that may be doable; even then, I'd consider it a stretch. But if we were to limit it to those constraints, when will this ever be exploited except as a PoC? No entity large enough to actually want to run this exploit on has an architecture where this would be feasible (due to things like geodistribution and load balancing), nor would be hosted on a provider so small that their IP pool can be exploited in the manner described. If I were an attacker, I'd focus on something with much bigger RoI.

Re: DDoS Attack Against Dyn Managed DNS

#552
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.

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.

I believe you don't understand DNS. It's probably the most resilient service (granted it's used correctly). There's nothing inherent in the protocol that would prevent them to use multiple DNS providers.

> Running a redundant DNS provider is expensive as all hell.

What makes you think that?

Re: DDoS Attack Against Dyn Managed DNS

#553
post #490

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.

Latest github NS moved to awsdns $ dig -tNS github.com @8.8.8.8 ; > DiG 9.8.3-P1 > -tNS github.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER But my local copy is still on dynect $ dig -tNS twitter.com ; > DiG 9.8.3-P1 > -tNS twitter.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER ;; WHEN: Fri Oct 21 13:02:14 2016 ;; MSG SIZE rcvd: 179

Your local copy is also twitter, instead of github :)

Re: DDoS Attack Against Dyn Managed DNS

#554
In (well, after) attacks like this, and really any other massive DDOS, shouldn't it be possible to identify potential botnets and try to take them out (notify their owners that they're being used, notify their hosting providers, etc) so that they can't be used again in the future?

Re: DDoS Attack Against Dyn Managed DNS

#555

Earlier quoted context omitted.

Sorry if this sounds dickish, but renting 3 servers @ $75 apiece from 3 different dedicated server companies in the USA, putting TinyDNS on them, and using them as backup servers, would have solved your problems hours ago. Even a single quad-core server with 4GB RAM running TinyDNS could serve 10K queries per second, based on extrapolation and assumed improvements since this 2001 test, which showed nearly 4K/second p…

That's not how that sound be done. Just use a mix of two providers. Using your own servers and TinyDNS is silly for million/billion dollar companies. See MaxCDN for example who uses a mix of dns providers (AWS Route53 and NS1): ns-5.awsdns-00.com. ['205.251.192.5'] [TTL=172800] ns-926.awsdns-51.net. ['205.251.195.158'] [TTL=172800] ns-1762.awsdns-28.co.uk. ['205.251.198.226'] (NO GLUE) [TTL=172800] ns-1295.awsdns-33.…

Not neccesarily. Granted this is how I would configure a system (two providers), but it is just as sensical to use one major provider which falls back to company servers in the event of an attack like this. It is all in sysadmin preference, while it is smart to relegate low-level tasks to managed providers it is also smart to have a backup solution that is under full control just in case that control needs to be taken at some point in time.

Re: DDoS Attack Against Dyn Managed DNS

#556
post #494
post #312

Earlier quoted context omitted.

The scenario I was describing was one where a last-known-good resolution would be used if and only if a refresh attempt fails after the authority-provided TTL expires. I believe the scenario you are describing is a rogue ISP ignoring that authoritative TTL wholesale, caching resolutions according to its own preferences regardless of whether the authority is able to provide a response after the authoritative TTL expir…

So if our resolver was on our resolver was on our laptop and had a nice UI that would work great. Now the question is : why is the resolver not in my laptop?

It can be if you want it to be, but it's probably much less interesting than you think.

You likely underestimate the sheer number of DNS records you look up just by surfing the web, and how useful that information would be to 99.99% of users.

Basically the tools exist for you to do this yourself if you are so inclined, but they may not be that user friendly since they aren't generally useful to most.

Re: DDoS Attack Against Dyn Managed DNS

#557

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…

PagerDuty outage is the real low point of this whole situation. Email alerts from PagerDuty that should have alerted of the outage in the first place, only got delivered hours later after the whole mess cleared out.

Re: DDoS Attack Against Dyn Managed DNS

#558

Earlier quoted context omitted.

Sorry if this sounds dickish, but renting 3 servers @ $75 apiece from 3 different dedicated server companies in the USA, putting TinyDNS on them, and using them as backup servers, would have solved your problems hours ago. Even a single quad-core server with 4GB RAM running TinyDNS could serve 10K queries per second, based on extrapolation and assumed improvements since this 2001 test, which showed nearly 4K/second p…

That's not how that sound be done. Just use a mix of two providers. Using your own servers and TinyDNS is silly for million/billion dollar companies. See MaxCDN for example who uses a mix of dns providers (AWS Route53 and NS1): ns-5.awsdns-00.com. ['205.251.192.5'] [TTL=172800] ns-926.awsdns-51.net. ['205.251.195.158'] [TTL=172800] ns-1762.awsdns-28.co.uk. ['205.251.198.226'] (NO GLUE) [TTL=172800] ns-1295.awsdns-33.…

That would be a quick fix similar to adding another NS provider. Of course if dyn is out completely they might not have their master zone anywhere else. Then it's similar to any service rebuilding without a backup.

Re: DDoS Attack Against Dyn Managed DNS

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

> - Attacker generates or acquires counterfeit facebook.com certificate.

So you enabled an attack vector that has to be nullified by a deeper layer of defense? And in some cases possibly impacted by a user having to do the right then when presented with a security warning.

Why would you willingly do that?

Also I do find your assumption of ubiquitous TLS rather alarming - facebook is a poor example here, there are far softer and more valuable targets for such an attack vector to succeed.

Edit: Also to keep my replies down...

> I would personally like to configure my local caching resolver to hold onto last-known-good resolutions for a while.

You can! All these tools are open source, and there are a number of simple stub resolvers that run on linux (I'd imagine OSX as well) which you can configure to ignore TTL. They may not be as configurable as you like, but again they are open source and I'm sure would welcome a pull request :)

Re: DDoS Attack Against Dyn Managed DNS

#560

Quick question for you all. Just two days ago I registered two domain names at dynu (not dyn). Early this morning I a cold call from a company in India who knew the domain names and my phone number and was calling to ask if I wanted them to help me manage my website cheaply. Also, this morning I got a spam text from someone who claimed to by godaddy offering the same thing. Now I protect my number really well so this…

Fwiw, this isn't a hack, this is a DDoS (denial of service). It seems almost certain that your information was either given out by dynu, or your WHOIS record isn't protected. Check your domains out with your favorite WHOIS tool first. Otherwise... time for an awkward conversation with dynu.
Post reply on HN