Hacker News new | past | comments | ask | show | jobs | submit login

With DNSSEC, the public key is not hosted on the zone iself, where your zone delegation is hosted. It's the DS records : https://uk.godaddy.com/help/what-is-a-ds-record-6148



I don't see how this really solve this attack. Like, it solves the specific way they did it - standing up their own DNS server on the IPs they've started advertising - but really, all they have to do is announce the IP(s) that are in the DNSSEC signed records. Then you're still getting the traffic, and nothing has thrown any red flags on the DNSSEC side because nothing has changed as far as DNS goes.

The problem is that when you can hijack the routing for an IP there's nothing that can realistically be done with how the internet works today to protect again it. Basically every system of validation requires you have access to some outside authority that can verify authenticity, and if you can announce the route to those IPs to your own infrastructure, you can fool the validation.


If i'm not mistaken, in this scenario they only hijacked the dns traffic and were using it to resolve a domain to another IP, so they were changing the DNS zone. DNSSEC would have prevented this as the change they did in the zone needs to be signed, so it would require them to also get the private key used to sign the zone.

It fails to solve the issue if the dns resolver doesn't check DNSSEC signatures though.

If they managed to hijack the route to the server itself, there's no need to hijack DNS at all, so it's a different issue that can't be solved at DNS level itself as DNS is not involved in the attack


Well, that's specifically my point - fundamentally the two attacks are the same. The key part here is the BGP leak itself. This specific attack would potentially be solved by DNSSEC, but if you can poison the internet routing table, you can just advertise a route for the IP you want to steal traffic from just as easily.

The potential downside there is the specificity - last I checked, the internet routing table won't take anything more specific than a /24 - so if you can't provide a more specific route, as-path-length becomes the next determining factor, so you might be in a situation where you can announce the DNS cidr with more specificity and not whatever IP is in the A record... But that's pretty far outside of your control and could just as easily flip the other way.

All of this is to say: I think the important part of this whole thing was the BGP hijack, and not necessarily the lower level specifics, because the hijack isn't dependent on a lot of those specifics.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: