TL;TR：在某些用例中，例如 HTTPS (web) DNSSec 并不是真正需要的。在其他用例中，例如 SMTP（邮件）DNS 欺骗不会被 TLS 注意到，即使正确使用 TLS 本身，如果 DNS 可以被欺骗，那么中间人是可能的。

细节：

当在 HTTPS (web) 和当前建立的 CA 系统中使用时，您不需要 DNSSec，因为浏览器会根据证书中的名称检查 URL 中的名称，并使用本地存储的（预信任的）根来验证信任链-CA。但请注意，证书本身的正确颁发可能会受到 DNS 欺骗的影响（见下文）。

使用 SMTP（邮件传输）情况就不同了。为了在邮件传递中获得下一跳，邮件传输代理 (MTA) 必须知道哪个服务器负责哪个收件人域。这是通过在 DNS 中查找 MX 记录来完成的。如果此记录可以被欺骗（可以在没有 DNSSec 的情况下完成），则 MTA 会将邮件传递到错误的邮件服务器。即使使用 TLS 完成交付，发送 MTA 也不会注意到 MX 是否将攻击者服务器报告为目标服务器，因为攻击者服务器的主机名和证书中的名称仍然匹配。SIP (VoIP) 以 SRV 记录的形式存在类似于邮件 MX 的机制，因此存在相同的问题。

除此之外，还有其他依赖安全 DNS 的协议。最突出的可能是 DANE，它试图用一个系统替换当前使用但损坏的 CA 系统，其中预期的证书存储在与主机名相同的位置，即 DNS 内部。同样的方式你也可以存储 SSH 主机密钥。

此外，在当前具有公共预信任 CA 的系统中，如果攻击者能够在正确的位置进行 DNS 欺骗，则在颁发域验证证书时所做的大多数身份检查都可以被伪造。这包括使用邮件完成域验证或通过仅使用 HTTP 访问站点上的特定文件来完成验证的情况（因为该站点还没有 HTTPS）。虽然在第一种情况下需要欺骗 MX 记录，但在第二种情况下需要欺骗 A/AAAA 或 CNAME 记录。一旦攻击者获得了相关站点的证书，针对该站点的 MITM 攻击将不再被注意到。