[deleted]
DDoS Attack Against Dyn Managed DNS
261–270 of 721 posts
Re: DDoS Attack Against Dyn Managed DNS
#262Relevant (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 :)
Maybe they are also using deep learning.
Re: DDoS Attack Against Dyn Managed DNS
#263Interesting. Lots of sites have been down for me, here in Mexico City. Twitter. Github. Loads of other random sites. When I turned on my US based VPN. It all started working again.
Re: DDoS Attack Against Dyn Managed DNS
#264Earlier quoted context omitted.
Yes, but: 1) Memory and disk are cheap. My caching DNS resolver can handle some stale records. 2) I suggested above that this behavior would continue until an administrator-specified and potentially quite generous maximum TTL expires. That is, I could configure my caching DNS resolver to fully purge expired records after, for example, 2 weeks.
> 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.
> The problem is not that it would require storage but that stale records can be outright wrong.
Again, the scenario is that the authoritative/upstream resolver cannot be reached in order to refresh after the authority-provided TTL expires. Are you saying that in the case of a service having been intentionally removed from the Internet (the domain is deactivated; the service is simply no more), my caching resolver will continue to resolve the domain for a time? Yes, it would. What's the downside though?
> That timeout would require configuration and DNS does not provide that.
Yes. This would be a configurable option in my caching DNS resolver, in the same vein as specifying the forwarders, roots, and so on. But to be clear, this would not be a change to the DNS protocol, merely a configuration change to control the cache expiration behavior of my resolver. I'm not wanting to sound flippant, I'm not sure I understand the point you're trying to make here.
Re: DDoS Attack Against Dyn Managed DNS
#265Earlier quoted context omitted.
Yes, but: 1) Memory and disk are cheap. My caching DNS resolver can handle some stale records. 2) I suggested above that this behavior would continue until an administrator-specified and potentially quite generous maximum TTL expires. That is, I could configure my caching DNS resolver to fully purge expired records after, for example, 2 weeks.
> 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.
>The problem is not that it would require storage but that stale records can be outright wrong.
But the tradeoff here is a wrong record vs a complete failure to lookup the record. I would rather have the wrong one.
Re: DDoS Attack Against Dyn Managed DNS
#266Earlier quoted context omitted.
yup, that's what I meant. they can use different DNS providers, e.g. route53 AND dyn
Route53 doesn't allow using it as slave DNS. https://forums.aws.amazon.com/thread.jspa?threadID=56011
Maybe not, but you can store your records in a local place and push to both.
That's one of the reasons I setup a git -> Route53 setup at https://dns-api.com/
Re: DDoS Attack Against Dyn Managed DNS
#267Earlier 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.
That was exactly my thought. This may be unrelated, or it may be a test run. But a large scale attack on Election Day that crippled communications would stir up unrest for a variety of reasons. Although I think that's highly unlikely to change the outcome, unrest after such a contentious election is not good.
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.
Re: DDoS Attack Against Dyn Managed DNS
#268Any quick script to see if a given domain ultimately resolves to them? My SaaS company has a lot of custom domains from whatever DNS servers pointed at us and I'd like to be able to tell people whether it's our fault or not.
`whois $domain`.
But it should be "obvious" if your users report "Server not found" vs. "Cannot connect" or "Page not found" style errors.
Re: DDoS Attack Against Dyn Managed DNS
#269Earlier quoted context omitted.
You don't need to target voting infrastructure. You target media infrastructure (DNS, streaming, web media) in order to either reduce or shift voter turnout. A candidate ahead in a battleground state? You stomp on media reporting to ensure their opponent's voters aren't dissuaded from heading to the polls. Control the message, and through that the actual votes cast.
Given various fuckups over the years, media won't call a state until the polls are completely closed. Silencing them doesn't change this strategy.
This is not congruent with their behavior during the primaries.
Re: DDoS Attack Against Dyn Managed DNS
#270Earlier quoted context omitted.
Yes, but: 1) Memory and disk are cheap. My caching DNS resolver can handle some stale records. 2) I suggested above that this behavior would continue until an administrator-specified and potentially quite generous maximum TTL expires. That is, I could configure my caching DNS resolver to fully purge expired records after, for example, 2 weeks.
> 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.
I think what the poster above you is saying is a feature on some software that isn't in an RFC somewhere.