How come you can access these sites from some countries? I imagine there are lots of name servers and that the attackers are specifically targeting servers for US?
DDoS Attack Against Dyn Managed DNS
491–500 of 721 posts
Re: DDoS Attack Against Dyn Managed DNS
#492[deleted]
Re: DDoS Attack Against Dyn Managed DNS
#493Earlier quoted context omitted.
I'm curious why you don't host your status page on a different domain/provider? When checking this AM why GitHub was down, I also couldn't reach the status page.
+1 The only way that I could check to see if Github knew they were having problems was by searching Google for "github status", and then seeing from the embedded Twitter section in the results page that there was a tweet about having problems. Twitter also being down for me didn't help the situation either.
The attack is on the DNS servers, which take names like www.github.com and resolve them to ip addresses (i.e. 192.30.253.112 for me). Their status page is status.github.com - it is on the same domain name (github.com) as the rest of the site. Normally this isn't a problem because availability is usually something going on with a server, not DNS.
In this case, the servers (DNS server under attack at Dyn) that knows how to turn both www.github.com and status.github.com into an IP address were under attack and couldn't respond to a query. The only way to mitigate this would be to have a completely different domain (i.e. githubstatus.com) and host the DNS with a different company (i.e. not Dyn).
Re: DDoS Attack Against Dyn Managed DNS
#494Earlier 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…
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?
Re: DDoS Attack Against Dyn Managed DNS
#495Earlier quoted context omitted.
How am i meant to see twitter status updates when twitter is down?
Please check our status page as an alternative method for updates. Unfortunately, it's also been encountering the same issue so we're sending out an email with the latest updates.
I didnae get an email
Re: DDoS Attack Against Dyn Managed DNS
#496Earlier quoted context omitted.
Running a redundant DNS provider is expensive as all hell. While 'expensive' is a relative term, I disagree that it's cost-prohibitive for most firms, as I looked into this specifically (ironically considered using Dyn as our secondary). The challenge isn't coming up with the funds, it's if you happen to use 'intelligent DNS' features; these are proprietary (by nature) and thus they don't translate 1:1 between provid…
Ah so make everything redundant. Double my costs in man hours and in monetary cost. Brilliant!
When your service literally says it exists to help provide uptime, redundancy makes sense.
Re: DDoS Attack Against Dyn Managed DNS
#497Earlier 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 does sound dickish.
Thanks, account created 9 minutes ago.
Re: DDoS Attack Against Dyn Managed DNS
#498Quick 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 is the first time in 5+ years that I ever got spam texts or calls to my number. Do you think Dynu was also hacked?! Or maybe Dynu sells client numbers (which is how the guy in India claimed to get my number) and it was just by random chance that this happened at the same time as the Dyn hack.
Re: DDoS Attack Against Dyn Managed DNS
#499So who was prepared for this? Pornhub: pornhub.com: Name Server: ns1.p44.dynect.net Name Server: ns2.p44.dynect.net Name Server: ns3.p44.dynect.net Name Server: ns4.p44.dynect.net Name Server: sdns3.ultradns.biz Name Server: sdns3.ultradns.com Name Server: sdns3.ultradns.net Name Server: sdns3.ultradns.org ultradns.biz: Name Server: PDNS196.ULTRADNS.ORG Name Server: ARI.ALPHA.ARIDNS.NET.AU Name Server: ARI.BETA.ARIDN…
Looks like Pagerduty just dumped Dyn:
pagerduty.com:
Name Server: NS-219.AWSDNS-27.COM
Name Server: NS-1198.AWSDNS-21.ORG
Name Server: NS-1569.AWSDNS-04.CO.UK
Name Server: NS-739.AWSDNS-28.NET
Re: DDoS Attack Against Dyn Managed DNS
#500Earlier quoted context omitted.
Running a redundant DNS provider is expensive as all hell. While 'expensive' is a relative term, I disagree that it's cost-prohibitive for most firms, as I looked into this specifically (ironically considered using Dyn as our secondary). The challenge isn't coming up with the funds, it's if you happen to use 'intelligent DNS' features; these are proprietary (by nature) and thus they don't translate 1:1 between provid…
Ah so make everything redundant. Double my costs in man hours and in monetary cost. Brilliant!
Ah so make everything redundant. Double my costs in man hours and in monetary cost. Brilliant!
The sarcasm is curious. It's a business decision. Either your revenue is high enough that the monetary loss from a several-hour intra-day outage is potentially worse than the cost of said redundancy, or you don't care enough to invest in that direction (it's expensive).
Making things redundant is exactly a core piece of what infrastructure engineering is. I guess with the world of VPSes and cloud services, that aspect is being forgotten? And yes, redundancy / uptime costs money!