DNSSEC hätte diesen speziellen Fehler der Angreifer auffliegen lassen, aber wenn jemand die Domain unter Kontrolle hat, kann er DNSSEC einfach abschalten (wie auch hier gemacht von den Angreifern). DNSSEC per se hilft also nicht, aber es macht Manipulationen einfacher sichtbar WENN MAN MONITORED.
Was hilft:
- Monitoring. Wenn DNSSEC ausgeschaltet wird, obwohl man es selbst nicht war, ALARM.
- Monitoring: Wenn plötzlich fremde A-Records zurückgegeben werden, obwohl man sie selbst nicht geändert hat: ALARM
- Zwei-Faktor-Authentifizierung hätte geholfen gegen einfaches Abfischen der Passwörter für das EPP-Interface. Es hätte jedoch nicht geholfen beim Abfischen der IMAP/POP3-Passwörter/Token.
DNSSEC ist machbar heutzutage, Bind und Co können das vollautomatisch. Cloudflare zeigt, dass es auch jemand kann mit Millionen Zonen/Domains, es skaliert also (Google's Ausrede, dass es zu komplex sei, weil man zu viele Domains habe, gilt also nicht). Dank Cloudflare gibt es auch einen RFC 8078, der die vollautomatische Übergabe des DS-Keys an die Parent-Zone regelt. Leider können das aber erst wenige TLDs :-( Es ist also alle paar Jahre, wenn man den KSK-Key rotiert, etwas Handarbeit angesagt. Aber das ist wie gesagt lösbar durch RFC8078, man muss nur endlich mal in die Gänge kommen.
https://datatracker.ietf.org/doc/rfc8078/
Das Umbiegen von BGP-Routen wird hier nicht angesprochen, aber auch das ist machbar und wird gemacht. Man muss nicht unbedingt einen Domain-Registrar hacken, um eine Domain zu übernehmen und Traffic umzuleiten auf eigene, transparente Proxies.
Siehe zu dem Thema auch:
https://blog.cloudflare.com/monsters-in-the-middleboxes/
Bis zu 18% des HTTPS-Traffics wird intercepted. Auch da gibt es Mittel und Wege, das zu stoppen. Die großen Player sollten mal mit gutem Beispiel vorangehen, und DNSSEC, DANE, CAA etc. deployen. DNSSEC-Validierung in die Betriebssysteme einbauen usw.