2つのドメイン名のシナリオ
example.com
DNSSECで保護example.org
DNSSECで保護されていないsmtp.example.org
で実行されているメールサービス:
TLSA/DANEを使用してメールサービスを保護したい。これはどういうわけか可能ですか?ほとんどのDANE対応ソフトウェアで機能することを期待できますか?
このアイデアは、TLSAレコード_25._tcp.smtp.example.com
と、smtp.example.com
を指すCNAMEレコードsmtp.example.org
を公開することです。 org
ゾーンからの応答はDNSSECセキュアではないため信頼できませんが、com
からのTLSAレコードは信頼できます。これは、DNSSECがまだ準備されていないゾーンにDANEを登録するための合理的な方法ですか?
更新: rfc7671 のセクション7でこれを見つけました:
セクション6で説明されているように、DANE TLSAレコードがサービスプロバイダーのドメインで検出されると、キー管理の調整の複雑さが大幅に解消されます。最終的なターゲットホストにホップします(CNAMEがDNSSEC検証されているかどうかにかかわらず、各ステップで注意します)。 CNAME拡張の各段階でDNSSEC検証ステータスが「安全」である場合、最終的なターゲット名はTLSAルックアップの優先ベースドメインである必要があります(SHOULD)。
したがって、私の場合、検証ステータスは「安全」ではなく、rfcは続行します。
CNAME展開の最終ターゲットのベース名を使用してTLSAレコードを見つけることができない実装は、元の宛先名を使用してTLSAクエリを発行する必要があります(SHOULD)。つまり、優先TLSA基本ドメインは完全に拡張された名前から派生する必要があり(SHOULD)、失敗した場合は初期ドメイン名である必要があります(SHOULD)。
クライアントは最終的に初期ドメイン名を「解決する必要があります」が、実際にほとんどの場合それが発生するかどうかはわかりません。
構成:
example.com. IN MX 0 smtp.example.com. ; AD=1
smtp.example.com. IN CNAME smtp.example.org. ; AD=1
smtp.example.org. IN A 192.0.2.1 ; AD=0
_25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0...b855 ; AD=1
DANEで保護されたTLSを生成し、少なくともいくつかのDANE実装を使用します。 Postfix。ただし、次の2つの理由により、これがすべての場合に機能するとは限りません。
安全でないAレコードを指すCNAME RRが安全であるかどうかを判断するには、同じ名前の別のCNAMEクエリが必要です。これにより、リゾルバーでの再帰が抑制され、CNAME自体のセキュリティステータスが返されます。 Exim、そしておそらく他のいくつかのMTAはそうしないかもしれません。 RFC7672はそうすべきであると述べていますが、それはかなり微妙なロジックであり、実装ではスキップされる可能性があります。
結論として、本当にDANEを機能させたい場合は、CNAMEが安全でないドメインに入るのを避け、必要に応じて、基になるホストのA/AAAAレコードを複製する安全なドメインにA/AAAAレコードを公開します。
example.com. IN MX 0 smtp.example.com. ; AD=1
; smtp.example.com. IN CNAME smtp.example.org. ; AD=0
smtp.example.com. IN A 192.0.2.1 ; AD=1 (cloned from smtp.example.org)
_25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0...b855 ; AD=1
- この場合、 http://imrryr.org/~viktor/ICANN61-viktor.pdf#page=2 で提案しているように、DANE/TLSAの二重レコードも公開することは理にかなっていますか?
堅牢なキー管理に使用するTLSレコードタイプの選択は、ほとんど別の問題です。したがって、はい。もちろん、少なくとも「2 1 1」(現在+次)または「3 1 1」+「2 1 1」(サーバー+発行者)の2つのレコードが少なくとも2つあるはずです。
しかしながら:
- さらに、使用された証明書はおそらくsmtp.example.comと一致しません。送信メールサーバーは通常、サーバー名と証明書を照合しないため、これは重要ではないと思います。正しい?
証明書は、問題のサーバーにメールを転送するために任意のドメインで使用されるすべてのMXホスト名と一致する必要があります。これが、証明書のsubjectAlternativeNameの目的です。 TLSAレコードと証明書の使用法とのSMTPマッチングでは、DANE-EE(3)は証明書のDNS名を明示的に無視し、DNSのTLSAレコードから名前バインディングを取得しますが、証明書の使用法DANE-TA(2)には同じことが当てはまりません。したがって、証明書に必要な名前をすべてリストしてください。