Does it matter? If the attackers can redirect the domain names to their own IP addresses then they can obtain DV certificates for those domains. The security of TLS depends on secure domain name resolution.
1. Virtually nobody signs zones today, so this is a moot point.
2. Not all DV-issuing CAs reliably verify DNSSEC, so it's even mooter.
3. Even if everyone signed their zones today, the Five Eyes intelligence agencies (NSA, ASD, GCHQ, GCSB, and CSE) have de facto (and, in some cases, de jure) control over the most important TLD zones.
4. The Web PKI already has countermeasures in place to detect misissuances, and those countermeasures have already resulted in the deaths of several of the largest CAs; there is ample evidence that current Web PKI surveillance is up to the task.
5. Even with secure DNS resolution, DV cert verification processes don't have a secure channel, and remain vulnerable to traffic interception attacks; for instance, even with DNSSEC, BGP attacks can straightforwardly trick CAs.
6. There are countermeasures to DNS spoofing that are simpler to deploy than DNSSEC, especially in the limited settings needed for DV cert verification; for instance: multi-perspective DNS and DNS over HTTPS.
7. There is already work happening to link CAs directly to registrars using RDAP to bypass DNS entirely for domain validation. In addition to being more reliable than DNSSEC, RDAP is also drastically simpler to deploy, and doesn't require anyone to sign their zones.
DV certificate issuance and SMTP-TLS were the last two mainstream drivers for DNSSEC adoption. The Web PKI has worked around the problem, and, with SMTP-STS (a standard whose specific, stated rationale is to work around DNSSEC), so have the largest email providers.
In fact: nothing depends on secure domain resolution, all meaningful Internet protocol security work over the last two decades has been premised on DNS being insecure, and DNSSEC is done. Stick a fork in it.
> Even with secure DNS resolution, DV cert verification processes don't have a secure channel, and remain vulnerable to traffic interception attacks; for instance, even with DNSSEC, BGP attacks can straightforwardly trick CAs.
3.2.2.4.7 just does DNS, so DNSSEC can secure it regardless of "traffic interception" or other shenanigans.
Tightening up the Web PKI happens gradually. In 2017 we required the Ten Blessed Methods (3.2.2.4.x) to replace a previous free-for-all, and then we've whittled away those ten so that today there are only eight left, of which one is secured by DNSSEC and several are out-of-band, so shenanigans on the Internet won't help you there. I won't be surprised if it's six by late next year.
