Live data from Hacker News

DDoS Attack Against Dyn Managed DNS

dynstatus.com

671–680 of 721 posts

Re: DDoS Attack Against Dyn Managed DNS

#671

How can I, a proficient web developer but one with little experience working directly with its underlying infrastructure, help in whatever effort is being down to thwart this and related attacks? I feel a moral obligation to help as these attacks seem a grave threat to our economy and could cause unrest given the current political climate. Thanks.

Read all the analysis you can to form a better understanding of how this all works. Use that information to design and run more resilient services in the future. Teach what you have learned to others.

Re: DDoS Attack Against Dyn Managed DNS

#672
post #647
post #255

Earlier quoted context omitted.

OpenDNS does this: https://support.opendns.com/hc/en-us/articles/227987767-Dyna... It's called SmartCache.

I do this, too. It's called HOSTS and djb's cdb constant database. And one does not need to use a recursive cache to get the IP addresses. Fetching them non-recursively and dumping them to a HOSTS and a cdb file can sometimes be faster; I have a script that does that. Fetching them from scans.io can be even faster. cd||exit [ -c null ]||mknod null c 2 2 case $# in 0) { sed ' /#/d; /^[0-9]/!d; ' /etc/hosts \ |{ while…

What you are doing and claiming is ridiculous.

For one, how are you doing to deal with stale records?

Re: DDoS Attack Against Dyn Managed DNS

#673
post #672
post #647

Earlier quoted context omitted.

I do this, too. It's called HOSTS and djb's cdb constant database. And one does not need to use a recursive cache to get the IP addresses. Fetching them non-recursively and dumping them to a HOSTS and a cdb file can sometimes be faster; I have a script that does that. Fetching them from scans.io can be even faster. cd||exit [ -c null ]||mknod null c 2 2 case $# in 0) { sed ' /#/d; /^[0-9]/!d; ' /etc/hosts \ |{ while…

What you are doing and claiming is ridiculous. For one, how are you doing to deal with stale records?

[deleted]

Re: DDoS Attack Against Dyn Managed DNS

#674
post #393

Earlier quoted context omitted.

Well, the parts that relied out outside services hooked up via SSO were not demoed, but majority of it worked fine because demo server was misconfigured to not actually rely on the external services. It is pretty funny.

It's Friday. Story/short write up appreciated

I am a bit paranoid about disclosing details, but basically our SAML IDP was down, so the sales person couldn't log in at all. I was messing with the demo server to convince myself that it is 100% IDPs fault and we can't do anything about it, and discovered to my surprise that the form-based authentication was not disabled on it (normally our servers are in one mode or the other, but not both, even though this is an artificial separation). So I gave them the direct link to the form based entry point and most of the demo could be done.

Re: DDoS Attack Against Dyn Managed DNS

#675
post #274

Earlier quoted context omitted.

> 1) Memory and disk are cheap. My caching DNS resolver can handle some stale records. The problem is not that it would require storage but that stale records can be outright wrong. That timeout would require configuration and DNS does not provide that. So sure, a new timeout could be introduced but that currently does not exist in DNS.

If a server goes away for good, at some point NS records will stop pointing to it. We could serve stale records as long as all of the stale record's authority chain is either still there or unreachable.

I've had an IP address from a certain cloud provider for a month. Some abandoned domain still has its nameserver and glue records pointing to the IP, and i get DNS queries all the time.

The domain expires in January. I hope it's not set to auto-renew. :-)

Re: DDoS Attack Against Dyn Managed DNS

#676

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?

From what I know of the situation (don't trust me, I'm not going to offer citations or sources), this attack wasn't particularly large in terms of gigabits/second. It was, however, very large in terms of economic impact.

I would assume that when a large number of big enterprise-y things go down, HSI takes notice. When other providers get attacks that are 20x larger (gbit/sec), but have much less widespread impact and impact on less enterprise-y things, they don't care so much.

Re: DDoS Attack Against Dyn Managed DNS

#677
post #202

Earlier quoted context omitted.

> wouldn't hesitate to take down dns to the entire internet to avoid another similar data leak to the Snowden dump. I don't understand how this would change anything unless you're assuming they would take down the Internet permanently

It renders the server that's hosting a leak unable to broadcast the leak temporarily, while they arrange more conventional measures to seize it. It's a more rapid response than getting a warrant and a police team on location. The broad nature of the attack also avoids tipping off the server owners. I still give it less than a 5% probability, though.

> the server that's hosting a leak

Honestly, that's fairly thin. WL uses torrents and other means of disseminating data that don't rely on central control structures. Plus, presumably, WL has the ability to quickly shift data into secure hands who are willing to release it when things quiet down.

So, sure, the USA could go send someone to sieze the hard drives of someone who has confidential information. But, I have to imagine one of the first steps when getting that kind of information is to disseminate it to others (at least some of whom are unknown to the states). If they were hit, these people would very quickly take that as a signal to indiscriminately release all the information.

Re: DDoS Attack Against Dyn Managed DNS

#678

Earlier quoted context omitted.

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.

I'm not using the service, but I'm curious what an acceptable threshold for this company is. Like, if half the DNS servers are attacked? If hostile actors sever fiber optic lines in the Pacific? I ask because my secondary question, as a network noob, is was anybody prepared / preparing for a DDOS on a DNS like this? Were people talking about this before? I live in Mountain View so I've been thinking today about the s…

> is was anybody prepared / preparing for a DDOS on a DNS like this

Yes.

I have, personally, been under attack with as-large or larger than todays attacks at my DNS infrastructure and survived.

Re: DDoS Attack Against Dyn Managed DNS

#679

Earlier quoted context omitted.

Ah so make everything redundant. Double my costs in man hours and in monetary cost. Brilliant!

Your automation should be handling creating/modifying records in both providers. Also, if you're utilizing multiple providers you don't need to pay for 100% of your QPS (or whatever metric is used for billing) on every provider, only 50% for two or 33% for three. You can just pay for overages when you need to send a higher percentage of your traffic to a single provider.

A lot of providers do have 'fixed' portions of costs, so, it won't be quite 1/2 or 1/3rd.

It may, at scale, be like 100% (one provider), 55%+55% (two) and 40%+40%+40% (three). Still eminently affordable.

Re: DDoS Attack Against Dyn Managed DNS

#680

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…

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…

+1 for TinyDNS.

I just wish it scaled to multiple cores :(

Post reply on HN