web-dev-qa-db-ja.com

DNSSEC以外のCNAMEを使用するサービスのTLSAレコードを公開しても問題ありませんか？

2つのドメイン名のシナリオ

  • example.com DNSSECで保護
  • example.orgDNSSECで保護されていない

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）。

クライアントは最終的に初期ドメイン名を「解決する必要があります」が、実際にほとんどの場合それが発生するかどうかはわかりません。

dnssecdane
3
Dons

構成：

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つの理由により、これがすべての場合に機能するとは限りません。

  1. CNAMEは、MXレコードのexchangeフィールドがCNAMEではなく、既に正規であるというRFC要件に違反しています（ https：// tools。 ietf.org/html/rfc5321#section-5.1 ）したがって、ここではCNAMEを許可しないMTAについては知りませんが、標準に準拠している場合は準拠しています。ただし、（今日）MXレコードを持つ4,244,642 DNSSEC署名ドメインの私の調査では、21,262がCNAME（34,886ドメインにサービスを提供）であり、明らかに問題がない1,432,478の異なるMXホストを見つけました。そのため、実際にはMXレコードのCNAMEが機能しているように見えます。
  2. さらに重要なことに、 https://tools.ietf.org/html/rfc7672#section-2.2.2 は、MXホスト名が署名されていないゾーンにある場合、TLSAルックアップをスキップする必要があることを説明しています。 A/AAAAレコードのセキュリティステータス。 CNAMEが含まれていない場合、これは単純であり、実装はこのケースを誤って処理することはほとんどありません。 MXホスト名が安全でないゾーンへのCNAMEである場合、一部の実装（Eximなど）は初期CNAMEのセキュリティステータスを決定しないため、（Postfixとは異なり）その場合はTLSAルックアップを試みません。

安全でない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
5
Viktor Dukhovni
  1. この場合、 http://imrryr.org/~viktor/ICANN61-viktor.pdf#page=2 で提案しているように、DANE/TLSAの二重レコードも公開することは理にかなっていますか？

堅牢なキー管理に使用するTLSレコードタイプの選択は、ほとんど別の問題です。したがって、はい。もちろん、少なくとも「2 1 1」（現在+次）または「3 1 1」+「2 1 1」（サーバー+発行者）の2つのレコードが少なくとも2つあるはずです。

しかしながら：

  1. さらに、使用された証明書はおそらくsmtp.example.comと一致しません。送信メールサーバーは通常、サーバー名と証明書を照合しないため、これは重要ではないと思います。正しい？

証明書は、問題のサーバーにメールを転送するために任意のドメインで使用されるすべてのMXホスト名と一致する必要があります。これが、証明書のsubjectAlternativeNameの目的です。 TLSAレコードと証明書の使用法とのSMTPマッチングでは、DANE-EE（3）は証明書のDNS名を明示的に無視し、DNSのTLSAレコードから名前バインディングを取得しますが、証明書の使用法DANE-TA（2）には同じことが当てはまりません。したがって、証明書に必要な名前をすべてリストしてください。

0
Viktor Dukhovni