Windows Server 2019を新規にドメイン コントローラーへ昇格した直後、ADSI EditやAD Explorerなどで「DNS settings」という見慣れない項目が見えて不安になることがあります。本記事では、その正体であるmsDNS-ServerSettingsの役割、削除してよいケースの有無、確認ポイントと安全な対処をまとめます。
結論：msDNS-ServerSettingsは仕様で、通常は削除しない
Windows Server 2019 をドメイン コントローラー（DC）へ昇格すると、DNS サーバーの役割も同時に導入・構成されることが多く、その過程で Active Directory（AD）上に DNS 関連の設定オブジェクトが作成されます。「DNS settings」かつ Type（クラス）が msDNS-ServerSettings の項目は、その代表例であり、基本的には “正常な状態の一部” です。
見慣れない名前のため「不要なファイルが増えた」「壊れているのでは」「削除してもいい？」と不安になりますが、Microsoft サポートからの明確な指示がある場合や、影響範囲を理解している場合を除き、削除・変更は避けるのが安全です。
| 観点 | 推奨 | 理由 |
|---|---|---|
| 新規にDC昇格した直後に見える | 無視して問題ない | AD統合DNSの管理情報として作成されるため |
| DNSSECを利用している／今後利用予定 | 削除しない | 鍵管理（Key Master）関連の参照点になり得るため |
| 過去に存在したDCを降格したのに残っている疑い | 状況確認のうえ慎重に | 残骸の可能性はあるが、誤削除の影響が大きい |
「DNS settings」が“ファイルのように見える”理由
この項目は、多くの場合ディスク上のファイルではありません。AD上に保存される DNS の設定オブジェクト（エントリ）を、ツールが一覧表示しているだけです。
ADSI Edit（adsiedit.msc）や Sysinternals の AD Explorer など、ディレクトリを「ツリー」「オブジェクト一覧」で表示するツールでは、オブジェクトがファイル/フォルダーのようなUIで見えるため、初見だと誤解しやすくなります。
msDNS-ServerSettingsとは何か
msDNS-ServerSettings は、AD統合DNS環境で DNS サービスの設定や、当該サーバーが関係するゾーン情報を保持するためのオブジェクトクラスです。特に Windows Server 2012 以降で強化された DNS 機能（DNSSEC など）と親和性が高く、“DNS サーバーのメタデータ置き場”として存在します。
ここがポイント：Key Master と msDNS-KeymasterZones
DNSSEC を有効化する環境では、ゾーン署名鍵の生成・ロールオーバーなど、鍵管理の責務を担うサーバー（Key Master）の概念が登場します。msDNS-ServerSettings は、その判断材料として使われる情報を保持します。
代表的な例として、msDNS-KeymasterZones という属性に AD統合DNSゾーンの一覧 が格納され、どのゾーンを誰が管理するか（または管理対象候補か）を追跡する用途で参照されます。DNSSEC を使っていない環境でも、将来の機能拡張や互換性のためにオブジェクトだけ先に作られているケースがあります。
どこに存在するのか
保存場所は環境や構成（アプリケーション パーティションの有無、レガシー互換など）で差が出ますが、「MicrosoftDNS」コンテナー配下にあることが多いです。たとえば以下のような場所で見つかります。
- ドメインDNS用のアプリケーション パーティション（DomainDnsZones）配下の
CN=MicrosoftDNS - フォレストDNS用のアプリケーション パーティション（ForestDnsZones）配下の
CN=MicrosoftDNS - 環境によっては
CN=MicrosoftDNS,CN=System配下（古い形式を引き継ぐ場合）
「ここに必ずある」と断言できないのは、DNS の統合先（どのパーティションにゾーンを格納しているか）や、昇格時の選択、過去の移行履歴で変わるためです。とはいえ、msDNS-ServerSettings 自体は “DNS をAD統合で運用しているなら存在して不思議ではないもの” と理解しておくと安心です。
削除してはいけない理由
msDNS-ServerSettings は “目に見える業務データ” ではなく、内部が参照する管理情報です。削除してしまうと、すぐに障害が顕在化しない場合もありますが、後から次のような形で影響が出る可能性があります。
- DNSSEC の鍵管理に関連する不整合（署名更新・ロールオーバーが進まない、役割判定ができない等）
- DNS サービスの設定解決に時間がかかる、イベントログに警告が出る
- 複数DNSサーバーがある環境で、ゾーン管理の整合性が崩れる
さらに厄介なのは、削除してもADの複製やキャッシュの影響で「しばらく動いているように見える」ことがある点です。問題が表面化した時点では原因が追いにくく、復旧コストが上がりがちです。
まずは健康診断：無害な“仕様”かどうかを確認するチェックリスト
新規に DC 昇格した直後に見えたなら、ほとんどのケースで仕様です。ただし、同じ名称でも「残骸」や「別の異常」と混ざって見えることはあるため、心配な場合は次の観点で確認すると判断がつきやすくなります。
| チェック項目 | 確認内容 | 問題がない目安 |
|---|---|---|
| 昇格時期 | DC昇格直後から見えているか | 昇格直後から存在するなら仕様であることが多い |
| DNSサービス | DNS Server サービスが稼働しているか | サービスが正常稼働し、名前解決も問題なし |
| ゾーンの状態 | AD統合ゾーンが表示され、更新が可能か | ゾーンが「読み取り専用」等になっていない |
| 複製 | AD複製エラーがないか | repadmin で重大エラーなし |
| イベントログ | DNS Server / Directory Service に警告がないか | 継続的なエラーが出ていない |
すぐ試せる代表コマンド
以下は「削除や変更をせずに」現状の健全性を確認するためのコマンド例です。実行は管理者権限の PowerShell / コマンドプロンプトを想定しています。
DNSの自己診断 dcdiag
dcdiag /test:dns /vDNS テストの結果にエラーがなければ、少なくとも DNS と AD の連携が大枠で破綻している可能性は下がります。
複製サマリ repadmin
repadmin /replsummary
repadmin /showreplDNS は AD と密接に結びつくため、複製エラーがあると DNS オブジェクトの見え方にも影響します。まずは複製を健全化するのが優先です。
msDNS-ServerSettings を読むだけで確認する PowerShell 例
Active Directory モジュールが利用できる環境では、msDNS-ServerSettings を検索して属性を確認できます（参照のみ）。
Get-ADObject -LDAPFilter "(objectClass=msDNS-ServerSettings)" -Properties whenCreated,whenChanged,msDNS-KeymasterZones |
Select-Object Name,DistinguishedName,whenCreated,whenChanged,msDNS-KeymasterZoneswhenCreated が DC 昇格のタイミングと近い、msDNS-KeymasterZones が空または想定どおり、といった状態なら「通常の管理オブジェクト」と判断しやすくなります。
DNSSEC を使っていないのに出るのはなぜ？
「DNSSEC を有効にしていないのに Key Master なんて関係ないのでは？」という疑問は自然です。ですが、実務では次のような理由で “関係なさそうな管理オブジェクトが先に作成される” ことがあります。
- 将来的な機能利用に備え、既定で関連スキーマ/オブジェクトを用意しておく設計
- 役割追加・DC昇格のウィザードが、条件分岐の簡略化のため一定のオブジェクトを作る
- 過去の環境からの移行やテンプレート構築で、DNS 機能が部分的に引き継がれている
つまり、“DNSSECを使っていない＝出てはいけない” ではありません。むしろ、何も問題が起きていないなら、見えたこと自体を異常とみなさないのが堅実です。
やってしまいがちなNG対応
不安になったときほど、次のような対応は避けてください。とくに「消して様子を見る」は、AD/DNS のような基盤機能では復旧難度が上がりがちです。
| やりがちな行動 | なぜ危険か | 代わりにやること |
|---|---|---|
| ADSI Edit で msDNS-ServerSettings を削除 | 内部参照の前提が崩れ、後から不整合が出る | まずはログと診断コマンドで健全性確認 |
| 属性を書き換える | Key Master/ゾーン情報の追跡が壊れる可能性 | 変更は Microsoft の手順・根拠がある場合のみ |
| 権限（ACL）を適当に変更 | DNS更新や複製に影響し、原因が追いにくい | 標準のアクセス権のまま運用する |
例外：DC降格後の“残骸”として残っている場合の考え方
スレッド等で論点になりやすいのが「すでに DC を降格（demote）したのに残っているように見える」ケースです。この場合は、たしかに “残骸” の可能性があります。ただし、残骸かどうかは見た目だけでは判断しにくく、誤って稼働中のサーバーに紐づくオブジェクトを消すと事故になります。
残骸を疑うサイン
- 対象サーバーはすでにドメインから削除済み（DC降格・コンピューターアカウント削除済み）
- DNS Server のイベントログで、存在しないサーバー名に関連する警告が繰り返し出る
- 複数DC環境で、特定のゾーンのDNSSEC関連操作だけが失敗する
安全に進めるための基本方針
残骸の整理が必要かもしれない場合は、次の順番で進めるのが現実的です（いきなりオブジェクト削除に行かない）。
- ADの基本クリーンアップを優先：降格済みDCのメタデータが残っているなら、まずは一般的なメタデータ クリーンアップ（
ntdsutil等）やサイト/サブネット/接続オブジェクトの整理を行う。 - DNSレコードの整理：降格済みサーバーに紐づく A/AAAA、SRV、NS などが残っていないかを確認し、不要なものを整理する（作業前に現状のエクスポートを取る）。
- 参照されていないことの確認：msDNS-ServerSettings が他オブジェクトから参照されていないか、関連属性（例：msDNS-KeymasterZones）に実体のないゾーンが残っていないかを調べる。
- 必要なら Microsoft の手順に沿って実施：DNSSEC を含む DNS の内部オブジェクト削除はリスクが高いため、根拠となる公式手順やサポートの案内に沿って実施する。
ポイントは、「降格済みであること」「参照されていないこと」「削除後に何が起きるか」を満たして初めて削除が選択肢に入る、ということです。
現場での実用アドバイス：不安を“確信”に変える見方
msDNS-ServerSettings のような内部オブジェクトは、知っているかどうかで不安が大きく変わります。最後に、運用者目線で「見るべきポイント」を整理します。
見るべきポイント
- 新規構築のDCなら、まずは放置でOK：その上で DNS / AD のテスト結果が正常なら、触る理由がありません。
- “見えること”より“症状があるか”を重視：名前解決が遅い、動的更新が失敗する、DNSSEC 署名が回らない、など具体的な症状があるときに初めて深掘りします。
- 変更前にバックアップ：どうしても手を入れる必要があるなら、少なくともシステム状態バックアップ等、復旧手段を確保してからにします。
判断に迷ったときの優先順位
AD/DNS は「動いているからOK」になりがちですが、基盤故障は後から効いてきます。迷ったら次の優先順位で対応すると、手戻りが減ります。
- 複製（replication）の健全化
- DNSの自己診断（dcdiag /test:dns）
- イベントログの継続監視（DNS Server / Directory Service）
- DNSSEC を使う予定があるなら、ゾーン署名や鍵管理の設計確認
- それでも解決しない場合に、内部オブジェクトの整理を検討
よくある質問
「DNS settings」はウイルスや不正ファイルの可能性がありますか？
表示されている Type（クラス）が msDNS-ServerSettings で、AD の DNS 関連コンテナー内に存在するなら、ほとんどのケースで不正ファイルではありません。ツールの見た目がファイル風でも、実体は AD のオブジェクトです。
削除してしまった場合、元に戻せますか？
AD オブジェクトの削除は、AD ごみ箱（AD Recycle Bin） を有効化しているかどうか、削除からの経過時間、複製状況などで復旧難度が変わります。復旧の成否が環境依存になりやすいため、最初から削除しないのが最善です。万一削除してしまい、DNS/DNSSEC で具体的な不具合が出た場合は、変更内容と時刻、ログ、複製状況を整理したうえで対応を進めてください。
「DNS settings」が複数見えます。正常ですか？
複数DC・複数DNSサーバーがある環境では、サーバーごとの設定オブジェクトが存在し得ます。また、ドメインDNS/フォレストDNSなどパーティションの違いで、似た情報が別の場所に見えることもあります。大切なのは “個数” ではなく、DNS と AD が健全に動作しているか、ログに異常が出ていないかです。
まとめ
Windows Server 2019 を DC へ昇格したあとに見える「DNS settings（msDNS-ServerSettings）」は、AD 統合 DNS の内部管理情報として作られることがある仕様（by design）です。特に DNSSEC の Key Master を含む将来的な運用・互換性を支える役割があり、通常は削除せず、そのまま運用して問題ありません。
もし不安が残る場合は、削除や変更を試す前に、dcdiag と repadmin、イベントログで “症状があるか” を確認してください。例外として DC 降格後の残骸が疑われるときだけ、Microsoft の案内に沿った安全なクリーンアップを検討するのが現実的です。
コメント