4 ms·

The best way to protect yourself against this kind of attack is DNSSEC. Plain and simple.

rocqua 9y ago
Only if your resolver fails closed. Otherwise, an attacker can just return non-signed responses. This is all client side, as a domain owner you simply need to trust your TLD. As long as most clients don't run tight DNSSEC, you're screwed if the TLD fucks up.
- AndyMcConachie 9y ago
  .io is signed and it has a DS record in the root zone. If you're using a DNSSEC validating recursive resolver(e.g., Google, Comcast) they should replace their cached NS records from auth resolvers that don't return signed respones, with cache entries that do return signed responses. If a stub tells a recursive resolver to return a DNSSEC signed response(by setting the DO bit to 1 in the query) that recursive should keep trying to find a signed response until it has exhausted all possible NS records in the parent zone. This assumes of course that the second-level zones are also signed. So it would only protect people going to example.io if example.io was signed. If you have a .io child zone then you should sign it.
tptacek 9y ago
I dispute this, even though this seems like the one case where we're talking about an attack that actually lines up with what DNSSEC actually does. The reason is, what we're talking about is a massive misconfiguration. It's not an elaborate technical spoofing attack that takes advantage of the weakness of the underlying DNS. The mistake the .IO team made is just as easy to make in DNSSEC as it is with vanilla DNS.
- AndyMcConachie 9y ago
  But if the attacker is unable to sign DNS responses, and you're validating those responses, then you're not going to have a bad time. I don't really understand your argument. I'm talking specifics and you seem to be talking about some hypothetical.
  - tptacek 9y ago
    The underlying "vulnerability" here is misconfiguration. DNSSEC doesn't defend against misconfiguration. That's the simple point I'm making.

Only if your resolver fails closed. Otherwise, an attacker can just return non-signed responses. This is all client side, as a domain owner you simply need to trust your TLD. As long as most clients don't run tight DNSSEC, you're screwed if the TLD fucks up.

AndyMcConachie 9y ago
.io is signed and it has a DS record in the root zone. If you're using a DNSSEC validating recursive resolver(e.g., Google, Comcast) they should replace their cached NS records from auth resolvers that don't return signed respones, with cache entries that do return signed responses. If a stub tells a recursive resolver to return a DNSSEC signed response(by setting the DO bit to 1 in the query) that recursive should keep trying to find a signed response until it has exhausted all possible NS records in the parent zone. This assumes of course that the second-level zones are also signed. So it would only protect people going to example.io if example.io was signed. If you have a .io child zone then you should sign it.

tptacek 9y ago

I dispute this, even though this seems like the one case where we're talking about an attack that actually lines up with what DNSSEC actually does. The reason is, what we're talking about is a massive misconfiguration. It's not an elaborate technical spoofing attack that takes advantage of the weakness of the underlying DNS. The mistake the .IO team made is just as easy to make in DNSSEC as it is with vanilla DNS.

AndyMcConachie 9y ago
But if the attacker is unable to sign DNS responses, and you're validating those responses, then you're not going to have a bad time. I don't really understand your argument. I'm talking specifics and you seem to be talking about some hypothetical.
- tptacek 9y ago
  The underlying "vulnerability" here is misconfiguration. DNSSEC doesn't defend against misconfiguration. That's the simple point I'm making.