Live data from Hacker News

DDoS Attack Against Dyn Managed DNS

dynstatus.com

711–720 of 721 posts

Re: DDoS Attack Against Dyn Managed DNS

#711
post #609
post #608

Earlier quoted context omitted.

Well, it obviously happens when the resolver is down, but that's the situation that this logic is being proposed to smooth over. The normal day-to-day does not see a high percentage of resolvers failing to respond, or else people would be getting NX DOMAIN for high profile domains much more often.

I'm just trying to make sure we don't wind up making DNS poisoning nastier in an effort to be more user-friendly.

All the attacks mentioned here seem to be of the following shape:

1. Let's somehow get a record that points at a host controlled by us into many resolvers (by compromising a host or by actually inserting a record).

2. Let's prolong the time this record is visible to many people by denying access to authoritative name servers of a domain.

(1) is unrelated to caching-past-end-of-ttl, so you need to be able to do (1) already. (2) just prolongs the time (1) is effective and required you to be able to deny access to the correct DNS server. Is it really that much easier to deny access to a DNS server than it is to redirect traffic to that DNS server and supply bogus reponses?

Re: DDoS Attack Against Dyn Managed DNS

#712

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

Fwiw, this isn't a hack, this is a DDoS (denial of service). It seems almost certain that your information was either given out by dynu, or your WHOIS record isn't protected. Check your domains out with your favorite WHOIS tool first. Otherwise... time for an awkward conversation with dynu.

Right, hack wasn't the right word. Anyway, thanks for the info.

Re: DDoS Attack Against Dyn Managed DNS

#713
post #711
post #609

Earlier quoted context omitted.

I'm just trying to make sure we don't wind up making DNS poisoning nastier in an effort to be more user-friendly.

All the attacks mentioned here seem to be of the following shape: 1. Let's somehow get a record that points at a host controlled by us into many resolvers (by compromising a host or by actually inserting a record). 2. Let's prolong the time this record is visible to many people by denying access to authoritative name servers of a domain. (1) is unrelated to caching-past-end-of-ttl, so you need to be able to do (1) al…

DNS cache poisoning is currently a very common sort of attack. The UDP-y nature of DNS makes it very easy. There are typically some severe limitations placed on the effectiveness of this attack by low TTLs. It does not require you to deny access to the authoritative server. This attack is also known as DNS spoofing: https://en.wikipedia.org/wiki/DNS_spoofing

Ignoring TTLs in favor of your own policy means poisoned DNS caches can persist much longer and be much more dangerous.

Re: DDoS Attack Against Dyn Managed DNS

#714
post #713
post #711

Earlier quoted context omitted.

All the attacks mentioned here seem to be of the following shape: 1. Let's somehow get a record that points at a host controlled by us into many resolvers (by compromising a host or by actually inserting a record). 2. Let's prolong the time this record is visible to many people by denying access to authoritative name servers of a domain. (1) is unrelated to caching-past-end-of-ttl, so you need to be able to do (1) al…

DNS cache poisoning is currently a very common sort of attack. The UDP-y nature of DNS makes it very easy. There are typically some severe limitations placed on the effectiveness of this attack by low TTLs. It does not require you to deny access to the authoritative server. This attack is also known as DNS spoofing: https://en.wikipedia.org/wiki/DNS_spoofing Ignoring TTLs in favor of your own policy means poisoned DN…

Right now, to keep a poisoned entry one must keep poisoning the cache.

In that world, one can still do that. One can also poison the entry once and then deny access to the real server. You seem to be arguing that this is easier than continuous poisoning. Do I understand you correctly?

Re: DDoS Attack Against Dyn Managed DNS

#715
post #714
post #713

Earlier quoted context omitted.

DNS cache poisoning is currently a very common sort of attack. The UDP-y nature of DNS makes it very easy. There are typically some severe limitations placed on the effectiveness of this attack by low TTLs. It does not require you to deny access to the authoritative server. This attack is also known as DNS spoofing: https://en.wikipedia.org/wiki/DNS_spoofing Ignoring TTLs in favor of your own policy means poisoned DN…

Right now, to keep a poisoned entry one must keep poisoning the cache. In that world, one can still do that. One can also poison the entry once and then deny access to the real server . You seem to be arguing that this is easier than continuous poisoning. Do I understand you correctly?

You are correct in your assessment of the current dangers of DNS poisoning.

I am in no way arguing about ease of any given attack over any other. I am arguing that a proposed change results in an increased level of danger from known attacks.

I'm arguing that the proposed change at hand, keeping DNS records past their TTLs, makes DNS poisoning attacks more dangerous because access to origin servers can be denied. Right now TTLs are a real defense against DNS cache poisoning, and the idea at hand removes that in the name of user-friendliness.

Re: DDoS Attack Against Dyn Managed DNS

#716
post #715
post #714

Earlier quoted context omitted.

Right now, to keep a poisoned entry one must keep poisoning the cache. In that world, one can still do that. One can also poison the entry once and then deny access to the real server . You seem to be arguing that this is easier than continuous poisoning. Do I understand you correctly?

You are correct in your assessment of the current dangers of DNS poisoning. I am in no way arguing about ease of any given attack over any other. I am arguing that a proposed change results in an increased level of danger from known attacks. I'm arguing that the proposed change at hand, keeping DNS records past their TTLs, makes DNS poisoning attacks more dangerous because access to origin servers can be denied. Righ…

The way I read your argument, it relies on denying access to be cheaper or simpler than spoofing (X == spoofing, Y == denying access to authoritative NS):

You are arguing that a kind of attacks is made more dangerous, because in the world with that change an attacker can not only (a) keep performing attack X, but can also (b) perform attack X and then keep performing Y. If Y is in no way simpler for the attacker why would an attacker choose (b)? S/he can get the same result using (a) in that world or in our world.

Am I misreading you or missing some other important property of these two attack variants?

Re: DDoS Attack Against Dyn Managed DNS

#717
post #716
post #715

Earlier quoted context omitted.

You are correct in your assessment of the current dangers of DNS poisoning. I am in no way arguing about ease of any given attack over any other. I am arguing that a proposed change results in an increased level of danger from known attacks. I'm arguing that the proposed change at hand, keeping DNS records past their TTLs, makes DNS poisoning attacks more dangerous because access to origin servers can be denied. Righ…

The way I read your argument, it relies on denying access to be cheaper or simpler than spoofing (X == spoofing, Y == denying access to authoritative NS): You are arguing that a kind of attacks is made more dangerous, because in the world with that change an attacker can not only (a) keep performing attack X, but can also (b) perform attack X and then keep performing Y. If Y is in no way simpler for the attacker why…

I believe you may have failed to consider the important role played by reliability.

X cannot always be done reliably - it usually relies on timing. Y, as we've seen, can be done with some degree of reliability. Combining them, in the wished-for world, creates a more reliable exploit environment because the spoofed records will not expire. The result is more attacks that persist longer and are more likely to reach their targets.

Such a world is certain to not be better than this one and likely to be worse.

Re: DDoS Attack Against Dyn Managed DNS

#718
post #717
post #716

Earlier quoted context omitted.

The way I read your argument, it relies on denying access to be cheaper or simpler than spoofing (X == spoofing, Y == denying access to authoritative NS): You are arguing that a kind of attacks is made more dangerous, because in the world with that change an attacker can not only (a) keep performing attack X, but can also (b) perform attack X and then keep performing Y. If Y is in no way simpler for the attacker why…

I believe you may have failed to consider the important role played by reliability. X cannot always be done reliably - it usually relies on timing. Y, as we've seen, can be done with some degree of reliability. Combining them, in the wished-for world, creates a more reliable exploit environment because the spoofed records will not expire. The result is more attacks that persist longer and are more likely to reach the…

Indeed I didn't consider that. Thanks a lot for being patient and enlightening.

Re: DDoS Attack Against Dyn Managed DNS

#719
post #708

Earlier quoted context omitted.

The part where you repeated Verisign's mistake in breaking a fundamental protocol. NXDOMAIN. Kind of a thing, and important to protocols other than HTTP.

The point is that the company did just fine even having made a mistake. Ignoring that is just being difficult.

No, the point that a company doing just fine is somehow an excuse for its actions is just the reason why we can't have nice things.

Re: DDoS Attack Against Dyn Managed DNS

#720
post #696
post #651

Earlier quoted context omitted.

Well, the fact that people still remember goes to show what a truly terrible idea it really was and that it probably did permanent damage to your brand.

I'm not sure what metric you use to judge it as terrible. I thought it was great. 10,000 companies pay for my service today. 65 million people use my infrastructure today. Cisco bought the company for more than $650m. It continues to innovate on the decades old DNS in secure and useful ways. So let me know what part is terrible.

"I got mine."
Post reply on HN