web-dev-qa-db-ja.com

古いレジストラはDNSSECを有効にしており、移行後、新しいレジストラはそれをサポートしません。これでサイトは読み込まれません

DNSSECをサポートしていないオペレーターに対して、DNSSECを有効にしてドメインを転送しました。最初のオペレーターにはDNSSECを無効にするオプションがなく、とにかく考えていませんでした。そして今、私には問題があります-転送は木曜日に行われ、今日までのドメインは世界中に表示されません（GoogleのDNSを含む）。これはDNSSECによるものでしょうか？この状況で伝播を完了する機会はありますか？

dnsdomain-registrardomain-transferdnssec
3
Insane

これはDNSSECによるものでしょうか？

はい。ただし、TLDでさえ、関係するドメイン名を指定しないため、確実ではありません（TLDに応じて転送およびDNSSECデータに関するルールが変更されます）。 DNSでDNSSEC関連の問題をデバッグすることは、壊れたドメインの名前を知っていればすでに複雑なタスクですが、それがなければ、これは不可能なタスクになります。

「ドメイン移管」でさえあまり明確ではないので、以下の答えはほとんどの通常のケースをカバーする一般的な説明にすぎません。

DNSSECには継続的なメンテナンスが必要です

ネームサーバーの処理に使用するDNSプロバイダーが何であれ、DNSSECを有効にする場合は、誰かが行う必要がある継続的なメンテナンスがあることを理解する必要があります。

  • ネームサーバーの内部でのみ、署名を再生成する必要があり、適切なセキュリティ慣行のために、通常ZSKの場合は数か月後にキーをローテーションする必要があります。

  • kSKも変更する場合（これも適切なセキュリティ慣行ですが、通常はZSKのように月ではなく年単位でカウントします）、親ゾーンでDSレコードを変更する必要があることを意味します。このDSを現在のレジストラに渡して、レジストリに転送してから公開します（その場合、レジストラを回避するために現在調理中の他のスキームがあります、.DKおよび.CH/.LIは、そのような機能を備えているか、まもなく備えます）

したがって、上記の意味は次のとおりです。DNSプロバイダーの変更は結果に影響する可能性があります。正しいペースで行われない場合、特に古いプロバイダーが協力しない場合、それは難しい問題です。それに関するガイダンスのためのRFCがあります。

DNSプロバイダーがレジストラであるかどうか

ドメイン名を購入すると、通常はレジストラに移動します。レジストラの仕事はドメイン名を登録することです。次に、解決する場合は、DNSサービスが必要です。レジストラは多くの場合DNSプロバイダー（場合によっては登録されていないドメイン名も含む）ですが、外部DNSプロバイダーも選択できます。

2番目のケースでは、DNSSECのメンテナンスはより複雑です。レジストラーがDNSプロバイダーでもあり、すべてのDNSSECレコードを自動的に維持している場合は、もちろん心配する必要はありませんが、すべてを同じバスケットに入れているので、理解するのは妥協です

レジストラ間のドメイン名の移管は、DNS解決に影響しません

ドメイン名が2つのレジストラ間で転送される場合、少なくともレジストリレベルで使用されるネームサーバーに変更はありません。

つまり、転送が終了するとすぐに、新しいレジストラにあるドメインは、転送前に使用していたのと同じネームサーバーを引き続き使用するため、DNSSECが以前に存在する場合、DNSSECはまったく同じ方法で動作し続ける必要があります。

警告付き：

  • dNSプロバイダーが、あなたが署名した契約に基づいて、移管したばかりの以前のレジストラであった場合、2番目のレジストラでドメインへのDNSサービスの提供を停止する場合としない場合があります。この場合でも、優れたレジストラは少なくとも数日間はサービスを提供し続けるので、適切に切り替える時間ができます。転送後にDNSサービスがすぐに切断される状況にある場合、すぐに苦痛の世界に陥ります。

  • 新しいレジストラに転送中にネームサーバーを変更するように依頼した場合、転送が終了した直後に操作を行う必要があります。ただし、新しいネームサーバーがDNSSECおよび特にDNSKEYレコードに関連するものを含めて、古いネームサーバーとまったく同じように設定されていない場合、ネームサーバーが変更されるとすぐに、ドメインは検証リゾルバーに対して壊れたように見えます（できます）親ゾーンにはNXDOMAINレコードが表示されますが、ネームサーバーにはDSレコードが表示されないため、ドメインのDNSKEYが生成されます

DNSSECを使用したドメイン名の移管

これは、TLDに大きく依存する場所です。

一部のレジストリでは、各レジストラの認証または少なくともDNSSECのチェックが必要であり、レジストリはDNSSEC対応レジストラから非DNSSEC対応レジストラへの転送を禁止します。

一部のレジストリでは、DNSSEC対応ドメインの転送が禁止されている場合があります（この場合、最初にDNSSECを削除して安全でないケースに戻り、次に転送してからDNSSECを戻す必要があります）。

一部のレジストリは、特に新しいレジストラがDNSSECに対応していない場合、またはDNSSECの保持を要求する特定のスイッチを使用していない場合、転送中にDNSSEC関連レコード（つまり（レジストリ）ゾーンのDSレコード）を削除する場合があります転送中の記録。

DNSSEC対応ドメインの転送を容易にする特定のEPP拡張があります。 Extensible Provisioning Protocolのキーリレーマッピング ただし：

  1. レジストリによって実装する必要があります。私の知る限り、これはSIDN、.NLレジストリの場合のみです
  2. 新しいレジストラはそれを使用する必要があります
  3. 古いレジストラは協力する必要があります

これは、あまり見られない多くの条件を作成します。

「伝播」に関する一言

誰もがDNSコンテキストでそれを使用していますが、間違っています。 DNSはトップダウンではありません。ゾーンで変更が発生しても、すべての再帰リゾルバーにプッシュダウンされるわけではありません（とにかく不可能なタスクです）。それどころか、再帰ネームサーバーは、キャッシュの内容とTTL（Time To Live）値の両方に応じて、一定の時間内に変更について学習し始めます。これが、テスト方法、以前にテストしたもの、どこからテストしたかに応じて、すぐに、または数時間または数日後に変更が表示される理由です。

Google DNSサーバーに言及していますが、これは何をすべきでないかを正確に示しています。DNSが変更された場合、最初に権限のあるネームサーバー（親ゾーンから開始）にクエリを実行して、期待される値があるかどうかを確認する必要があります。その後は、さまざまなパブリック再帰で突っ込み始めることができますが、Google以外の世界があることを忘れないでください。したがって、1.1.1.1（CloudFlare）、9.9.9.9（IBM + PCH）、80.80.80.80（Freenom）または64.6.64.6（VeriSign）、その他多数あり、データを送信するエンティティに応じて異なります。独自のボックス、LAN、またはISPネットワークのいずれかで、独自のローカル再帰ネームサーバーを使用して開始することもできます。

オンライントラブルシューティングツールもあります。

  • https://zonemaster.net/
  • https://dnsviz.net/ これは、DNSSECに特に適しています。ノードとリンクを含むイメージとして信頼と委任のチェーンを提示するため、テキスト出力よりも状況をはるかに簡単に理解できます（そして、実際にローカルにインストールすることもできます）

何が起こり得、何をすべきか？

  1. ネームサーバーは変更されている可能性があり、新しいサーバーのゾーンコンテンツは異なります。現在DNSKEYレコードがないため、これはすぐにDNSSECを破壊します。問題を解決するための最初のアクション：レジストラに移動し、DNSSECマテリアル（DSレコード）を削除して、ネームサーバーを正しくセットアップする時間を確保します
  2. レジストラが変更され、DSレコードがレジストリまたは新しいレジストラによって削除されました。ドメインは引き続き正しく解決されるはずですが、DNSSECによって保護されなくなりました。問題を解決するための最初のアクション：レジストラーがDNSSECを処理することを再確認し（つまり、DSレコードをレジストリに送信できることを意味します）、DNSプロバイダーにドメインでDNSSECを再度アクティブ化するように依頼します
  3. おそらく他にも多くのケースがありますが、それらはすべてあなたが提供しなかった詳細に依存しています
2
Patrick Mevzek