Windows Server 2019 の新しいドメイン コントローラー（DC）を追加した直後、「名前解決はできているのに dcdiag /test:dns の出力だけが Root Hints（ルート ヒント）絡みで大量に失敗して不安になる」ケースがあります。本記事では、実害の有無を切り分けつつ、ログのノイズを減らして DNS を健全化するための現実的な手順をまとめます。
起きている現象を整理：合格するのに Root Hints 関連の失敗が大量に出る
今回の相談で多いのは、次のような流れです。
- 旧ドメイン コントローラー（例：Windows Server 2008 R2）が正しい降格（demote）なしに故障・消失
- 残った DC 側で AD/DNS のメタデータ クリーンアップを実施
- 新しく Windows Server 2019 を追加 DC として昇格
- クライアントの名前解決はできている／業務影響は見えない
- しかし、新しい DC の dcdiag /test:dns だけ、h.root-servers.net などルート サーバー宛のテストや、1.0.0.127.in-addr.arpa（127.0.0.1 の逆引き）や …ip6.arpa の PTR クエリ失敗が大量に出る
- 最終行では “passed test DNS” になっているが、途中の失敗ログが気になる
まず押さえたいのは、「passed ＝ 出力内に失敗が1行もない」ではないという点です。dcdiag は複数のサブテストを走らせ、最終的にテスト全体としては合格扱いになる一方で、途中で「到達不能」「タイムアウト」「委任の指摘」などを大量に吐くことがあります。特に Root Hints（ルート ヒント）や IPv6 が絡むと、環境差・設定差がそのままノイズとして出やすいです。
| よく見るメッセージ例 | 意味（ざっくり） | まず疑うべきポイント | 緊急度 |
|---|---|---|---|
| h.root-servers.net などへのテストが失敗 | 外部（ルート）へ再帰問い合わせできるかの確認で躓いている | Root Hints の重複／到達不能、FWで外向きDNS遮断、IPv6経路なし | 中（外部解決が要件なら高） |
| PTR record query for 1.0.0.127.in-addr.arpa failed | Root Hints 動作確認として 127.0.0.1 の逆引きを投げている | Root Hints サーバー側がその逆引きゾーンを持たない／再帰しない | 低〜中（他に症状がなければノイズになりやすい） |
| …ip6.arpa の PTR 失敗が大量 | IPv6 側の Root Hints で同様の逆引き確認が失敗 | IPv6 を無効化/経路なし、IPv6 Root Hints への到達不可 | 低〜中（IPv6運用方針次第） |
| 最終行は passed test DNS | DNSテスト全体としては合格扱い | ただしノイズに重要な指摘が混ざることがある | 状況次第 |
最優先の基本：DC の DNS クライアント設定は「自分自身を最優先」にする
ここが崩れていると、dcdiag の DNS テストに限らず、SRV レコード登録やDC ロケーター、レプリケーション、ログオンなどで遠回りなトラブルが連鎖しがちです。さらに今回のように「旧DCが突然死→新DC追加」というフェーズでは、DNS の参照順が少し違うだけで“新DCだけ結果が騒がしい”状態が発生します。
推奨はシンプルで、DC の NIC（ネットワークアダプター）の DNS サーバー設定を次の順番に揃えます。
| 構成 | 優先 DNS | 代替 DNS | 補足 |
|---|---|---|---|
| DC が 2 台（新旧 DC） | 自分自身（できれば自分の固定 IP） | もう一台の DC の IP | 「自分→相手」の順に統一。ループバック（127.0.0.1）運用もあるが、切り分けのしやすさなら固定IP推奨。 |
| DC が 1 台（単独） | 自分自身（固定 IP） | 空欄（または将来の追加 DC） | 外部 DNS（8.8.8.8 等）を NIC に入れない。外部解決はフォワーダーで行う。 |
| 追加 DC を昇格させる直前〜直後 | （昇格直前）既存 DC の DNS | （昇格直後）レプリケーション確認後に自分優先へ変更 | 昇格中は既存 DNS に依存するが、昇格が完了し AD/DNS が同期したら「自分→相手」に揃える。 |
やってはいけない代表例も押さえておくと、後工程が楽になります。
| 設定例 | 何が起きやすいか | 推奨の置き換え |
|---|---|---|
| DC の NIC に ISP/パブリックDNS（8.8.8.8 など）を入れる | Netlogon の登録先が分散し、AD 関連レコードが正しく揃わない／切り分け困難 | 外部解決は DNS サーバー側のフォワーダーへ |
| DC1 の優先 DNS が DC2、DC2 の優先 DNS が DC1（相互参照のみで自分が後ろ） | 起動順や一時停止で「DNS が見えない」時間が生まれ、登録やテストが不安定になりやすい | 両方とも自分→相手の順に統一 |
| 旧DCのIPが DNS サーバー欄に残っている | タイムアウト待ちが積み上がり、dcdiag が騒がしい／遅い | 旧DCのIPを除去し、現役DCだけにする |
変更後は、最低限次を実施して「登録・キャッシュ」のズレを減らします。
ipconfig /flushdns
ipconfig /registerdns
net stop netlogon
net start netlogon（再登録が必要な状況では、これだけで dcdiag のノイズが大きく減ることもあります。）
今回の本命：Root Hints に「重複＋到達不能」の古い IP が混ざっている
dcdiag の出力末尾付近に、次のような示唆が出ている場合はほぼ当たりです。
- Root Hints の一覧に同じルート サーバー名が複数あり、片方が Invalid (unreachable) などで失敗扱い
- 新しい DC のほうだけ Root Hints が古い／重複している
相談例では、Root Hints に次の「無効（到達不能扱い）の重複エントリ」が混在していました。同じ名前に有効な別 IP が既にあるので、「置き換え」ではなく無効な重複分だけ削除するのがポイントです。
| 対象（Root Hints） | 削除候補（無効・重複） | なぜ削除して良いか | 注意点 |
|---|---|---|---|
| b.root-servers.net | 128.9.0.107 | 同名の有効 IP が別に存在し、無効側がテスト失敗の原因になっている | 有効側まで消さない（同名で複数 IP があるのは正常） |
| d.root-servers.net | 128.8.10.90 | 同上 | 削除は「無効な重複のみ」 |
| h.root-servers.net | 128.63.2.53 | 同上 | IPv6/IPv4 の両方がある場合は運用方針に合わせる |
| l.root-servers.net | 198.32.64.12 | 同上 | 同名で別 IP が残っていることを確認してから |
このタイプの重複は、「昔の root hints 情報が残っていた」「手作業で root hints を足した」「旧DC由来のファイルや設定を参照した」などで起きやすく、名前解決自体はできてしまう一方で、dcdiag が律儀に到達試験をすることで大量の失敗ログとして可視化されます。
どこを見ればいい？Root Hints の確認場所と “重複が見える” 典型パターン
Root Hints は GUI から確認でき、内部的には Cache.dns にも反映されます（Windows の DNS サービス起動時に参照されるため、ファイル側で重複が見えることもあります）。
| 確認場所 | 見るべきポイント | 注意点 |
|---|---|---|
| DNS マネージャー（dnsmgmt.msc）→ サーバーのプロパティ → Root Hints | 同じルート サーバー名が複数あり、片方が到達不能／古いIPになっていないか | ここでの変更が運用上もっとも安全 |
| %SystemRoot%\System32\DNS\Cache.dns | Root Hints の記載が重複していないか、極端に古い/おかしいIPがないか | ファイル直接編集は推奨しない。まずは GUI で整理する |
| dcdiag /test:dns /v の出力 | 「どの root server のどの IP に対して失敗したか」がそのまま出る | “どれを消すべきか” のヒントが最短で揃う |
対処手順：DNS マネージャーで Root Hints の「無効な重複」を削除する
最短で安全にノイズを減らすなら GUI での整理が確実です。
- DNS マネージャー（dnsmgmt.msc）を開く
- 左ペインで対象の DNS サーバー（新しい DC）を右クリック → プロパティ
- Root Hints タブを開く
- 一覧から、同名で複数 IP がぶら下がっているものを展開し、unreachable（到達不能）扱いの古い IP だけを削除する
- 適用後、必要に応じて DNS サーバーのキャッシュをクリアする
dnscmd /clearcacheこの時点で dcdiag の Root Hints 関連の失敗ログが目に見えて減ることが多いです。特に「重複＋到達不能」が原因の場合は、削除後に即効果が出ます。
Root Hints を “更新” したい場合：コピー機能で健全な一覧に揃える
重複削除で改善しない／Root Hints が全体的におかしい場合は、「一部を直す」よりも「正しい一覧をコピー」した方が早いケースがあります。
- DNS マネージャー → サーバーのプロパティ → Root Hints タブ
- Copy from Server（サーバーからコピー） を使い、信頼できる DNS サーバーから Root Hints を取得
ただし、ここで指定する “コピー元” は運用設計に合わせましょう。
| コピー元の例 | 向いている環境 | 注意点 |
|---|---|---|
| 組織内の上位 DNS（社内リゾルバー） | 閉域網／インターネット直通を禁止している | 社内設計に合う。外部直通しない前提なら最適 |
| インターネット到達可能な DNS サーバー | DC が外部解決も担う一般的な環境 | FW/プロキシ条件により到達できない場合がある |
補足：なぜ 127.0.0.1（1.0.0.127.in-addr.arpa）や ip6.arpa の PTR 失敗が出るのか
Root Hints 周りのエラーで特に不安になりやすいのが、次の2つです。
- 1.0.0.127.in-addr.arpa（127.0.0.1 の逆引き）
- （長い）…ip6.arpa（IPv6 側の同様の逆引き）
ここは仕様・設計の影響が出やすい部分です。dcdiag は Root Hints の動作確認として、逆引き PTR の問い合わせを使って “外部へ再帰が回るか” を見にいきます。しかし多くの外部 DNS（ルート サーバーを含む）は、次の理由でこのテストにきれいに答えないことがあります。
- 外部側がその逆引きゾーン（127.0.0.1 相当や IPv6 の特殊逆引き）を持っていない
- 権威サーバーとして振る舞い、再帰問い合わせ（recursive lookup）をしない
- ネットワークやファイアウォールの都合で、特定の宛先（UDP/TCP 53）だけ落ちる
つまり、これらの PTR 失敗が出ても、即「社内 DNS が壊れている」には直結しません。ただし、次に該当する場合は “ノイズ扱い” にしない方が安全です。
| 状況 | 判断 | 優先して見るべきこと |
|---|---|---|
| クライアントが DC を DNS として使い、外部名解決が必須（M365、外部SaaS等） | Root Hints / フォワーダーの外向き経路を健全化すべき | フォワーダー設定、FW（UDP/TCP 53）、Root Hints の到達性 |
| 閉域網で外部解決をそもそも許可していない | Root Hints テスト失敗は出やすい（設計上の結果） | 社内の上位DNSへ転送（フォワーダー）する設計に寄せる |
| “新しい DC だけ” 失敗が多い | 設定差が原因の可能性が高い | NIC の DNS 設定順、Root Hints の重複、IPv6 条件 |
Root Hints とフォワーダー：設計を決めるとトラブルが減る
Root Hints のノイズに悩まされる環境では、そもそも DNS の外部解決を「Root Hints に任せるか／フォワーダーに寄せるか」を決めると、運用が安定します。
| 方式 | 概要 | メリット | 注意点 |
|---|---|---|---|
| Root Hints を使用（フォワーダーなし） | DNS サーバーがルートから辿って再帰解決 | 上流DNSに依存しない | 外向きDNS（UDP/TCP 53）を広く許可する必要があり、FW設計が難しい |
| フォワーダーを使用（推奨されやすい） | 社内上位DNSや指定DNSへ転送して解決 | 許可先が絞れてセキュア、統制しやすい | フォワーダー障害時の挙動（Root Hints へフォールバックするか）を決める |
| 閉域網（外部解決は上位システムのみ） | DC は外部を直接引かない | 設計が明快 | dcdiag の Root Hints 系テストは失敗しやすい。評価基準を社内で決める |
フォワーダー運用の場合は、DNS サーバーのプロパティ（Forwarders タブ）に上位 DNS を設定し、必要に応じて 「Use root hints if no forwarders are available」（フォワーダーが使えない場合に Root Hints を使用）をどうするかを検討します。ここが曖昧だと、障害時に Root Hints へ流れてタイムアウトが増え、dcdiag も“騒がしい”ままになりがちです。
コマンドでの確認：dcdiag の見方と、Root Hints の棚卸し
状況把握のために、まずは “どのテストが” “どの宛先で” 失敗しているかを可視化します。
dcdiag /test:dns /v /s:（対象DC名）外部解決が本当にできているかを確かめたい場合は、DNS 関連のテスト種別も使い分けます。
| コマンド例 | 見たいこと | ポイント |
|---|---|---|
dcdiag /test:dns /DnsBasic /v | 基本の DNS クライアント設定やゾーン存在 | まずここが通っているか |
dcdiag /test:dns /DnsForwarders /v | フォワーダー周りのチェック | フォワーダー運用なら特に重要 |
dcdiag /test:dns /DnsResolveExtName /DnsInternetName:www.microsoft.com /v | 外部名解決の実力テスト | “Root Hints が騒がしいだけ” か “実害がある” か切り分けしやすい |
Root Hints のキャッシュ要素も含めて “一度きれいにして再評価” したい場合は、DNS サーバー側のキャッシュクリアも有効です。
dnscmd /clearcachePowerShell が使える環境なら、DNS サーバー キャッシュのクリアは次でも可能です。
Clear-DnsServerCache -ForcePowerShell で Root Hints の重複を削除する（GUI が使えない場合）
GUI で直すのが最も安全ですが、リモート作業や自動化で PowerShell を使う場合は、Root Hints の削除コマンドも選択肢になります。削除対象はあくまで “無効な重複” のみです。
# 例：無効な重複エントリだけを削除（対象サーバーはローカル想定）
Remove-DnsServerRootHint -NameServer "b.root-servers.net." -IPAddress "128.9.0.107" -Force
Remove-DnsServerRootHint -NameServer "d.root-servers.net." -IPAddress "128.8.10.90" -Force
Remove-DnsServerRootHint -NameServer "h.root-servers.net." -IPAddress "128.63.2.53" -Force
Remove-DnsServerRootHint -NameServer "l.root-servers.net." -IPAddress "198.32.64.12" -Force削除後は Root Hints の一覧を再確認し、同名の有効 IP が残っていることを確認してください。操作に不安がある場合は、先に DNS マネージャーで Root Hints をスクリーンショット保存しておくと安心です。
最後の仕上げ：dcdiag の“ノイズ”を実害にしないためのチェックリスト
Root Hints の重複を整理しても、環境によっては “PTR 失敗が少し残る” ことがあります。そこで、運用上の健全性を担保する観点で、次のチェックリストで総点検しておくと安心です。
| チェック項目 | 確認方法 | OKの目安 | NGなら |
|---|---|---|---|
| 新DCの NIC DNS が「自分→相手」になっている | ipconfig /all | 優先DNSが自分（固定IP）、代替が相手 | 順番を入れ替え、外部DNSはNICから外す |
| 旧DCのIPが参照先に残っていない | NIC設定、フォワーダー、名前解決の設定 | 現役DC/上位DNSのみ | 残骸を削除 |
| Root Hints に unreachable な重複がない | DNSマネージャー → Root Hints | 同名の無効IPが消えている | 無効な重複だけ削除／コピーで更新 |
| 外部解決が必要な環境で、外部名が解決できる | dcdiag /test:dns /DnsResolveExtName /DnsInternetName:www.microsoft.com /v | 外部名が解決できる | フォワーダー／FW（UDP/TCP53）／IPv6方針を再確認 |
| SRV など DC のDNSレコードが登録されている | DNSマネージャー（_msdcs, _tcp 等） | 新DCのSRV/Aが存在 | netlogon再起動、registerdns、ゾーン設定（動的更新）確認 |
今回のように「dcdiag は合格するが、Root Hints 絡みの失敗ログが大量」というケースは、実際にはDNS クライアントの参照順とRoot Hints の“無効な重複”という、比較的シンプルな設定差で起きていることが少なくありません。新DCを追加した直後は特に差が出やすいので、まずは「自分→相手」の DNS 設定に揃え、Root Hints を整理してから dcdiag を再実行する、という順番が最短で安全です。
コメント