DNS の清掃の問題のトラブルシューティング

2025-01-15

この記事では、ドメインネームシステム (DNS) の清掃に関連する問題のトラブルシューティング方法について詳しく説明します。

DNS の清掃に関する問題の基本的なチェック

DNS の清掃の問題につながる可能性があるさまざまなシナリオがあります。次の一般的なチェックを使用して、すべてのケースで清掃が正しく構成されていることを確認できます。

清掃を有効にするには、レコード、ゾーン、サーバーの 3 つのレベルで構成する必要があります。詳細については、 DNS の清掃のセットアップを参照してください。これらのレベルのいずれかが不足している場合、清掃は行われません。

清掃が発生しやすいレコードは、DNS のタイムスタンプに登録されているレコードです。これは、次のいずれかになります。
- 動的 DNS (DDNS) を使用して DNS に登録されている動的 IP アドレスで構成された Windows クライアント。
- 24 時間ごとに DNS に登録される静的 IP アドレスで構成された Windows ベースのマシン。
清掃では、タイムスタンプのない静的レコードとしてサーバーに手動で追加されたレコードは削除されません。

Note

DDNS を使用すると、そのレコードが動的レコードとして登録され、そのタイムスタンプを削除して静的レコードに変換された場合、静的レコードが DNS から削除される可能性があります。この場合は、レコードへの "削除" アクセス権を持つユーザーを確認する必要があります。
サーバー間の競合を回避するために、1 つの DNS サーバーのみが清掃が構成されていることを確認します。
ゾーンのエイジング設定を確認して、ゾーンレベルのエージングと競合するすべてのゾーンにグローバルエイジング設定があるかどうかを確認します。

Note

ゾーンレベルのエージングの方が優先順位が高くなります。

ゾーンレベル:

すべてのゾーンレベル:
Refresh、No-refresh、Scavenging サイクル時間を構成するときに使用する数値は、各組織の構成と設定によって異なるため、標準設定はありません。ただし、設定が次の式に従っていることを確認する必要があります。

Refresh + No-refresh >= 最大 DHCP リース数

Refreshと更新間隔の合計は、DHCP リース期間と清掃の間の重要な関係を強調し、動的ホスト構成プロトコル (DHCP) の最大リース以上である必要があります。この記事の「 Scenarios 」セクションでは、この式を検討する理由を示します。

トラブルシューティングの手順

ほとんどの問題は構成エラーによって引き起こされるため、トラブルシューティングには、清掃のための正しい構成を確保することが重要です。詳細については、「 DNS の清掃が正しく構成されていませんを参照してください。
シナリオに基づいて、イベント ID 2501 と 2502 のシグナル通知を確認して、清掃サイクルの最後の発生を追跡する必要がある場合があります
- イベント 2501 は、清掃サイクルが経過し、1 つ以上のレコードが削除されたことを意味します。
- イベント 2502 は、清掃サイクルが経過し、レコードが削除されていないことを意味します。
DNS サーバーで次の清掃サイクルがいつ発生するかを識別するには、最後の DNS 清掃サイクルの日付と時刻を取得し、清掃期間を追加する必要があります。詳細については、「 DNS サーバーで次の清掃サイクルがいつ発生するかを識別する方法を参照してください。
DNS サーバー監査ログを使用して、次の詳細を取得します。
- 清掃によって削除されるレコード: イベント ID 521。
- 清掃サイクルの開始: イベント ID 552。
- 清掃サイクルの終了: イベント ID 554。
- サーバーのスキャン: イベント ID 567。
その機能をテストするために、清掃を手動で開始することを検討してください。これにより、このサーバーで少なくとも 1 回は清掃が自動的に実行された場合にのみ、レコードが即座に削除されます。詳細については、「自動および手動で開始された清掃を参照してください。

シナリオ

このセクションでは、DNS の清掃で発生する可能性があるいくつかの一般的なシナリオを示します。

DNS に動的に登録されているサーバー上で静的に構成された IP では、レコードが削除される可能性があります

環境内に次の構成があるとします。

SRV1 IP = 2.2.2.2。タイムスタンプが 7/24/2024 午後 6:00 の DNS に登録されています。
Refresh interval は 2 時間に設定されます。
更新間隔 2 時間に設定。
清掃は 7 日に設定。
最後の清掃サイクルは、2024 年 7 月 17 日午後 11:00 に発生しました。

既定では、静的に構成された IP は 24 時間ごとに自身を登録します。上記の構成では、レコードは 2024 年 7 月 24 日午後 10:00 に古くなります。次の清掃サイクルが 2024 年 7 月 24 日午後 11:00 (2024 年 7 月 17 日および 7 日間) に発生すると、DNS サーバーはレコードが古くなっていることを検出して削除します。このシナリオでは、手動で登録するときに午後 11 時から翌日の稼働日まで、または前回の登録時刻から 24 時間後に再登録するときに、このサーバーで解決の問題が発生する可能性があります。

原因は、 Refresh + 更新間隔が 24 時間未満であることです。そのため、DNS レコードは失われます。

DNS レコードが予期せず削除される

完全なシナリオについては、「 DNS: Scavenging: DNSCMD で清掃が手動で無効になっている場合、レコードは削除されませんを参照してください。

DNSCMD で清掃が手動で無効になっている場合、DNS レコードは削除されません

完全なシナリオについては、「有効なフェーズ」を参照してください。

DNS の清掃は行われず、イベント 2501 と 2502 は生成されません

DNS サーバーは古いレコードを清掃できず、使用停止中のドメインコントローラー (DC) は、元の DC がレプリケートされていたサーバーです。

この問題をトラブルシューティングするには、システムの起動後にパーティション (ゾーンが格納されている場所) がレプリケートされていることを確認して、ゾーンが清掃に使用できるかどうかを確認します。

検証の理由は、長い間オフラインであった DC が、古く見えるが他の DC で更新されたデータを清掃しないようにするためです。

レプリケーションのチェック:

パーティションが最後のゾーン更新間隔で少なくとも 1 つのレプリケーションパートナーと完全に同期されていない場合は、ゾーンを清掃しないでください。
ディレクトリパーティションを調べて、DNS サービスが開始されてから、指定された期間内に少なくとも 1 つの他のパートナーとレプリケートされたかどうかを確認します。

使用停止の DC が不要になった場合は、DC を削除すると問題が解決します。特定のドメイン内のすべてのドメインコントローラーを一覧表示するには、次のコマンドを実行します。

nltest /dclist:<DomainName>

DNS 内の Azure マシンのレコードが削除され、解決の問題が発生する

Azure マシンのリース期間は 136 年です。したがって、どのような清掃設定が使用されても、50 年後のリース更新時間の 50% として、残りの Windows オンプレミスマシンと一致することはありません。そのため、マシンはタイムスタンプを更新せず、そのレコードは清掃によって削除されます。

解決策は、Refresh 間隔の間に、X 間隔ごとに Azure マシンが自身を登録し、そのタイムスタンプを DNS で更新するように強制することです。これを行うには、 RegistrationRefreshInterval ポリシーを適用します。

Computer Configuration\Administrative Templates\Network\DNS Client\Registration Refresh Interval

ポリシーはレジストリキーにマップされます。

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient

設定の既定値は 1800 秒 (30 分) です。

これは、DNS 更新登録間の時間間隔を指定します。この値を有効にするには、Windows を再起動する必要があります。

Note

Windows クライアントコンピューターでこのポリシーを適用する場合は、登録更新間隔を有効にするには、事前にComputer Configuration\Administrative Templates\Network\DNS Client\Dynamic Updateを有効にする必要があります。

DNS サーバーに重複レコードが存在する

完全なシナリオについては、「 DNS の清掃と DHCP リース期間の関係を参照してください。