I'm updating a list of confirmed outages as I see them here https://news.ycombinator.com/item?id=12759520 So far twitter, etsy, soundcloud, spotify, github, pagerduty...crazy that this can even happen
All of these work for me from Germany, and querying their authorative nameservers works just fine (so definitely no caching effect). Anycast for the win!
DDoS Attack Against Dyn Managed DNS
331–340 of 721 posts
Re: DDoS Attack Against Dyn Managed DNS
#332Twitter and Github are still down here in LA (and confirmed on isup.me)
Re: DDoS Attack Against Dyn Managed DNS
#333Re: DDoS Attack Against Dyn Managed DNS
#334Relevant (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.
Maybe some Deep Learning experiment actually created Skynet and it is probing us.
Re: DDoS Attack Against Dyn Managed DNS
#335I was not aware of the attacks going on until this happened: 1. Tried to download "Unknown Horizons" (game featured recently on Hacker News) binary, github-link doesn't work. 2. Think "Ok, might be an old link", google their github-repository, github appears down. 3. Try accessing github status website, is down. 4. Interested, try to visit github status twitter account, twitter is down. Really weird experience, norma…
Had a similar experience. When I went to confirm on twitter, that was down too. I was able to acces Twitter from my phone though, where I found a ton of tweets saying "Twitter down!". Strange.
Re: DDoS Attack Against Dyn Managed DNS
#336Re: DDoS Attack Against Dyn Managed DNS
#337Earlier 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…
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" peo…
You seem to be continuing to warn against a proposal that isn't the one that was made. What specifically is dangerous about using cached records only in the case of the upstream servers failing to reply?
Re: DDoS Attack Against Dyn Managed DNS
#338Earlier quoted context omitted.
Why? The OP is only proposing using a cached result when there's no updated record available.
Serving wrong records is usually worse than serving no records. EDIT: It would be fine as long as your site only served HTTPS content and HSTS was enabled for your domain, preventing any sort of MITM attack.
If your DNS server is offline, is the last record it returned when it was online really the "wrong" one? There'd be no right one in that case.
Re: DDoS Attack Against Dyn Managed DNS
#339Currently I am able to get into every site on the web, including GitHub, by using a VPN service based in Hong Kong.
Re: DDoS Attack Against Dyn Managed DNS
#340Earlier 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…
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" peo…
> A low tolerance for DNS response times, and suddenly large chunks of the internet are failing a lot...
Hang on a second. I feel that you're piling on other resolver changes in order to make a point. I'm not suggesting that the tolerance for DNS response times be reduced. Nor am I suggesting a scenario where the authority gets one shot after their TTL, after which they're considered dead forever. I would expect my caching DNS resolver to periodically re-attempt to resolve with the authority once we've entered the period after the authority's TTL.
> 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.
I think you're suggesting that someone could commandeer an IP and then prevent the rightful owner to correct their DNS to point to a temporary new IP.
Isn't the real problem in this scenario the ability to commandeer an IP? The malicious actor would also need to be able to provide a valid certificate at the commandeered IP. And at that point, I feel we've got a problem way beyond DNS resolution caching. Besides, if what you have proposed is possible, isn't it also possible against any current domain for the duration of their authoritative TTL? That is, a domain that specifies an 8-hour TTL is vulnerable to exactly this kind of scenario for up to an 8-hour window. Has this IP commandeering and certificate counterfeiting happened before?