Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DDoS Attack Against Dyn Managed DNS

dynstatus.com

Post reply on HN
Print view View original

311–320 of 721 posts

Re: DDoS Attack Against Dyn Managed DNS

#311

Post by Shank »

rybosome wrote: post #299
Shank wrote: post #267

Earlier quoted context omitted.

If this is a test run, this is an amazing early warning for Twitter and the like to immediately start working on contingency plans for election day.

What can they do? It's not Twitter themselves being DDOS'd, it's a DNS provider. This propagates up the chain to impact both a Tier 1 network and cloud providers, which hits tons of stuff on top of that.

Have a failover DNS provider. Amazon uses Dyn, but also has UltraDNS as a backup, and it's obviously still up. Twitter vs Amazon:

host -t ns twitter.com: ns3.p34.dynect.net, ns4.p34.dynect.net, ns1.p34.dynect.net, ns2.p34.dynect.net.

host -t ns amazon.com: ns3.p31.dynect.net, ns4.p31.dynect.net, ns2.p31.dynect.net, pdns6.ultradns.co.uk, pdns1.ultradns.net, ns1.p31.dynect.net.

Re: DDoS Attack Against Dyn Managed DNS

#312

Post by bhauer »

Kalium wrote: post #292
gmaslov wrote: post #273

Earlier quoted context omitted.

Aw, don't leave us hanging like that. What problems did it cause?

Imagine migrating your website to a new host. A month later, you learn that a major ISP has decided that its customers don't need to know about the move, because they hold on to last-known-good records as they like. So half your traffic and business is gone. Or maybe you can't use anything run on Heroku, because the dynamicism there doesn't play nice with your resolver's policies. That's the kind of world we used to…

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 expires.

Re: DDoS Attack Against Dyn Managed DNS

#313

Post by jrochkind1 »

Is it time for everyone to actually start using secondary name servers/DNS resolvers too from a different provider from primary? DNS _is_ built for this, for the very purpose of handling failure of the primary resolver, isn't it? Just most people don't seem to do it -- including major players?

Or would that not actually solve this particular scenario?

Re: DDoS Attack Against Dyn Managed DNS

#317

Post by Kalium »

bhauer wrote: post #312
Kalium wrote: post #292

Earlier quoted context omitted.

Imagine migrating your website to a new host. A month later, you learn that a major ISP has decided that its customers don't need to know about the move, because they hold on to last-known-good records as they like. So half your traffic and business is gone. Or maybe you can't use anything run on Heroku, because the dynamicism there doesn't play nice with your resolver's policies. That's the kind of world we used to…

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…

The rogue ISPs thought they were helping people by serving stale data. After all, better something past its use-by date than failing, right? A low tolerance for DNS response times, and suddenly large chunks of the internet are failing a lot...

Among other problems, this enables attacks. Leak a route, DDoS a DNS provider, and watch as traffic everywhere goes to an attack server because servers everywhere "protect" people by serving known-stale data rather than failing safe.

Be very, very careful when trying to be "safer". It can unintentionally lead somewhere very different.

Re: DDoS Attack Against Dyn Managed DNS

#318

Post by cloudjacker »

crftr wrote: post #293
nodesocket wrote: post #287

I've been singing the praise of AWS Route53 for a long time, they up and running. I can't believe major multi-million dollar companies (Twitter, GitHub, Soundcloud, Pagerduty) would not run a mix of multiple DNS providers. Also what is happening is a cascade effect, where a 3rd party being down effects others.

> I've been singing the praise of AWS Route53 for a long time, they up and running. I'm a fan of Route53, too. But can we say that it weathered the attack? Or was it just lucky that its systems weren't targeted?

> Or was it just lucky that its systems weren't targeted?

I was wondering that too

Re: DDoS Attack Against Dyn Managed DNS

#319

Post by bhauer »

drinchev wrote: post #303
bhauer wrote: post #243

Earlier quoted context omitted.

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 t…

I think you understood me. Maybe I can explain more. If you have a service `log.io` with it's own DNS servers ( running named or djbdns ). And one day you decide to shut them down and rename the service to `loggy.io`. What will happen is that any DNS trying to query the `log.io` DNS will reach unreachable server, which will lead to serving the last-known IP from the proposed DNS Cache on your machine. If you don't us…

Thanks for the reply.

> If you have a service `log.io` with it's own DNS servers ( running named or djbdns ). And one day you decide to shut them down and rename the service to `loggy.io`. > What will happen is that any DNS trying to query the `log.io` DNS will reach unreachable server, which will lead to serving the last-known IP from the proposed DNS Cache on your machine.

To reiterate the scenario you've put forth as I understand it: I'm a service operator and I've just renamed my company and procured a new domain. I've retired the old domain and expect to fulfill no more traffic sent to that domain. When a customer of my service attempts to resolve my old domain, their caching DNS resolver may return an IP address even though I have since shut down the authoritative DNS servers for the retired domain. They will make an HTTPS request to my servers (or potentially someone else's, if I also gave up my IP addresses), and fail the request because the certificate will be a mismatch.

The customer's application will see a failed request either by (a) DNS failing to resolve or (b) HTTPS failing to negotiate. Either way, my customer needs to fix their integration to point to my new domain.

To be clear, it is up to my customer to decide whether they want their caching DNS resolver to provide a last-known-good resolution in the event that authoritative servers are unreachable. If they prefer failure type (a) over (b), they would configure their DNS resolver to not provide last-known-good resolutions.

Re: DDoS Attack Against Dyn Managed DNS

#320

Post by cloudjacker »

ChadMoran wrote: post #192
kiostech wrote: post #114

Earlier quoted context omitted.

Maybe run in localhost bro

Or bra

Exhibit A of MEN having zero consequences for their sexual assault on the English language! Especially in the tech industry, where English sexual assault is unlike other industries!
Post reply on HN