There are several things which went wrong here and MyEtherWallet could have done things to reduce the risk. The issue was that the traffic to the DNS server was hijacked and thus queries for specific domains resulted in a spoofed response, thus directing the browser to the attackers IP address with a server impersonating the original site. There the user was presented was a fake site which looked like the original one.
DNSSec is designed to prevent exactly this kind of spoofing, i.e. detect that a response is fake. But, DNSSec requires support from the domain owner (must sign records), the DNS server (must return the signed records) and from the client (must require signed records). While MyEtherWallet could have configured there system to offer DNSSec for the domain it has no control over the client part: the attacker could have just returned an unsigned response since only some clients will request DNSSec in the first place and even fewer will insist on getting only a signed response.
Easier would have been to set HSTS for the domains of MyEtherWallet. If this HTTP header is set modern browsers will remember that the domain always needs to be accessed by HTTPS and that no exceptions in case of SSL problems are allowed. To bypass this simple to setup protection the attacker would also need to get a valid certificate for the attacked domain. It is often possible to get such a certificate if the attacker temporarily controls the domain (as seen in this report from an attack against Fox-IT) but by using a CA issuer with additional controls and by restricting the issuer CA using DNS CAA records it could have been made impossible or at least very hard for the attacker to get a certificate for this domain from a public CA.
In summary: MyEtherWallet could have done several things to make it harder for the attacker. Some of these would be easy to implement but still very effective (HSTS). Others (like DNSSec) require adequate support on the client side which is not reality today.
