TLSが適切に構成されている場合、DNSSECは本当に役に立たないのですか？
私はこの記事を読んでいました http://sockpuppet.org/blog/2015/01/15/against-dnssec/ この行は、「TLSが適切に構成されていれば、DNSSECは何も追加しません」と私の目を引きました。私の腸の反応は同意しないことでしたが、それについて考えれば考えるほど、反例は考えられないことに気付きました。私がDNSSECを大まかに理解していることは確かですが、彼は正しいようです。何か不足していますか？
TL; TR：HTTPS（Web）などの一部のユースケースでは、DNSSecは実際には必要ありません。 SMTP（メール）のような他の使用例では、DNSスプーフィングはTLSによって認識されません。つまり、TLS自体が適切に使用されていてもDNSがスプーフィングされる可能性がある場合、中間者が可能です。
詳細：
HTTPS（ウェブ）および現在確立されているCAシステム内で使用する場合、ブラウザーはURLの名前を証明書の名前と照合し、ローカルに保存された（事前に信頼された）ルートを使用して信頼チェーンを検証するため、DNSSecは必要ありません。 -CA。ただし、証明書自体の適切な発行は、DNSスプーフィングの影響を受ける可能性があることに注意してください（以下を参照）。
SMTP（メール転送）では状況が異なります。メール配信内の次のホップを取得するには、メール転送エージェント（MTA）が、どのサーバーがどの受信者ドメインを担当しているかを知る必要があります。これは、DNSでMXレコードを検索することによって行われます。このレコードがスプーフィングされる可能性がある場合（DNSSecなしで実行可能）、MTAはメールを間違ったメールサーバーに配信します。 TLSを使用して配信が行われたとしても、MXが攻撃者サーバーをターゲットサーバーとして報告しても、攻撃者サーバーのホスト名と証明書内の名前が一致するため、送信MTAは通知しません。メールのMXと同様のメカニズムがSRVレコードの形式でSIP（VoIP）に存在するため、同じ問題があります。
それとは別に、安全なDNSに依存する他のプロトコルがあります。最も顕著なのは、現在使用されているが壊れているCAシステムを、期待される証明書がホスト名と同じ場所（DNS内）に格納されているシステムに置き換えようとするDANEです。 SSHホストキーを格納する方法と同じです。
また、パブリックの事前信頼されたCAを備えた現在のシステムでは、攻撃者が適切な場所でDNSスプーフィングを行うことができる場合、ドメイン検証済み証明書の発行時に行われるIDチェックのほとんどが偽造される可能性があります。これには、ドメインの検証がメールで行われる場合、または検証がHTTPのみでサイト上の特定のファイルにアクセスすることによって行われる場合が含まれます（サイトにはまだHTTPSがないため）。最初のケースではMXレコードを偽装する必要がありますが、2番目のケースではA/AAAAまたはCNAMEレコードを偽装する必要があります。また、攻撃者が問題のサイトの証明書を取得すると、そのサイトに対するMITM攻撃に気付かなくなります。