Dynamic DNSは、アップデーターがリモートクライアントが到達すべきインターフェースやインターネット出口と異なるものを検出した場合に、誤ったアドレスを更新します。
家庭内ネットワークでは、ルーターが別のゲートウェイの背後にあるプライベートWANアドレスを報告したり、サーバー側のアップデーターがVPNやプロキシの出口を認識したり、IPv6アップデーターがIPv4レコードを上書きしたり、異なる場所から同じホスト名を複数のクライアントが更新したりすることがあります。診断は、まず一つのパブリックアドレスの真実の情報源を選び、どのアップデーター、レコード、アドレスファミリー、検出方法が誤った値を生成したかを正確に特定することから始まります。
3つのアドレスを同時に比較する
DDNSレコード、ルーターのWANアドレス、外部のIPv4またはIPv6サービスが観測したパブリックアドレスを記録します。正当な最近の変更と誤った更新を混同しないようにタイムスタンプも追加してください。
TP-Linkのコミュニティ事例では、ルーターがプロバイダーのNATプールからのアドレスを報告している一方で、外部インターネットは異なるアドレスを認識し、DDNSホスト名が誤ったWAN側アドレスを指していることが示されました。
3つすべてが一致する場合、問題は更新値ではなくDNSキャッシュやリモート到達性の可能性が高いです。DDNSレコードがルーターと一致するが外部アドレスと一致しない場合は上流のNATを調査し、どちらとも一致しない場合はアップデーターの設定とログを確認してください。
アップデーターがアドレスを検出する方法を特定する
DDNSクライアントが名前付きインターフェースを読み取るのか、ルーターに問い合わせるのか、ローカルゲートウェイを解析するのか、更新要求の送信元アドレスを使うのか、外部の「自分のIPは何か」サービスに問い合わせるのかを判断します。
Zyxelのコミュニティディスカッションでは、別のNATルーターの背後にあるファイアウォールが、上流のプライベートWANアドレスしか知らない場合に、なぜ真のパブリックアドレスを自動更新できないのかが議論されています。
アップデーターがNATの背後にある場合はプロバイダーが対応していれば外部検出を選びます。インターフェース検出は、そのインターフェースが実際にパブリックアドレスを所有している場合にのみ選択してください。そうでなければ、正常に動作しているアップデーターでも設計上誤った値を公開することがあります。
ダブルNATとCGNATを確認する
ルーターのWANアドレスがプライベートまたは共有範囲内にあるか、別のモデムやISPゲートウェイが最初のNATを行っているかを調査します。Dynamic DNSはアドレスを公開できますが、制御していない上流ネットワークを通じたインバウンド転送を作成することはできません。
ドイツのSynologyサポートフォーラムの事例では、プロバイダーNATによりDDNSが実際のパブリックエンドポイントではないアドレスを検出したと報告されています。
上流ルーターを管理している場合は、下流ルーターをブリッジモードにするか、両方の層を通じて必要な経路を転送してください。ISPがCGNATを使用している場合は、パブリックアドレスの割り当てを依頼するか、DDNSクライアントを繰り返し変更する代わりにアウトバウンドトンネルやリレーを使用してください。
IPv4とIPv6の更新を分ける
AレコードとAAAAレコードを独立して調査し、それぞれ同じアドレスファミリーの外部テストと比較します。IPv6の更新が成功したからといってIPv4レコードが正しいとは限りません。
1つのインターフェースを監視するよう設定されたクライアントは、一時的なIPv6アドレス、後に変わる委任プレフィックスアドレス、またはVPN出口のIPv4アドレスを公開することがあります。アドレスファミリーごとに異なるライフサイクルがある場合は、更新ジョブとプロバイダーのレコードを分けて管理してください。
疑わしいアドレスファミリーの更新のみを無効にしてテストを繰り返します。誤ったAAAAまたはAレコードを削除してリモートアクセスが回復した場合は、デュアルスタックDNSを復元する前にその経路を修正してください。
重複クライアントと誤ったレコードターゲットを見つける
ホスト名を更新する資格情報を持つすべてのルーター、NAS、コンテナ、スクリプト、クラウドホスト、モバイルデバイスをリストアップします。異なる場所にある2つの有効なクライアントが互いに上書きし合うことがあります。
Dynuユーザーは、1つの更新クライアントが複数のレコードを1つのIPに上書きした事例を記録しており、アカウントやクライアント設定が意図以上のレコードを対象にしていたことが原因でした。
各場所とアドレスファミリーに固有のホスト名、トークン、更新ジョブを割り当て、未使用の資格情報は取り消してください。成功メッセージを信用する前に、ログが正確に変更されているレコード名を示していることを確認してください。
実際のアドレス変更でレコードを検証する
検出方法とアップデーターの所有権を修正した後、安全なWAN再接続を強制するか、次の正当なアドレス変更を待ちます。新しい外部アドレス、更新ログ、権威DNS応答、再帰的リゾルバー応答、リモート接続結果を記録してください。
ZimaSpaceのリモートアクセスが古いIP状態を追い続ける理由のガイドは、DDNS値自体が正しくなった後の次の段階を示しています。
問題は、1つの承認されたアップデーターが正しいIPv4またはIPv6アドレスを公開し、2番目のクライアントが上書きせず、権威応答が期待される間隔内に変わり、外部クライアントが意図したホームサービスに到達できたときにのみ解決されます。
サポートとヒント
もっと読む

How to Reduce Plex Database Contention on a Busy Docker Host
A Plex configuration guide for busy hosts that treats the database as local application state and reduces I/O contention without inventing a shared DB...

How to Prevent Duplicate Plex Scans and Imports
A prevention guide for duplicate Plex scans and imports that removes overlapping triggers instead of disabling library updates entirely.

How to Recover Plex After Its App-Data Volume Fills Up
A recovery ladder for full Plex app-data volumes that protects the database first and avoids deleting unknown files just to make the service start.

