はじめに

今回は、ネットワークの道標であり、ADの心臓部でもある「DNSセキュリティ」を取り上げます。LinuxエンジニアにとってDNSといえば、BIND (named) や unbound が真っ先に浮かぶでしょう。ゾーンファイル（/var/named/ 配下のテキストファイル）を編集し、named.conf でACLをゴリゴリ書く世界です。

しかし、Windowsの「AD統合DNS」は、その内部構造も運用の思想も根底から異なります。この違いを理解しないまま運用することは、ディレクトリサービス全体の致命的な脆弱性に直結します。

対象環境

Windows Server 2016 / 2019 / 2022（Active Directoryドメインサービス構成済み）
各コマンドはドメインコントローラー上の管理者権限のPowerShellで実行してください。

1. BINDとは全く異なる「AD統合DNS」の内部構造

LinuxでBINDを運用する場合、ドメインのレコード情報はローカルディスクの「テキストファイル」として保存されます。セカンダリサーバーへの同期は、DNSプロトコルそのものを使った「ゾーン転送（AXFR/IXFR）」で行われます。

DNSレコードは「ADデータベース」の中にある

AD統合DNSでは、ゾーン情報をファイルとして持ちません。すべてのDNSレコードはActive Directoryのデータベースファイル（ntds.dit）の中に、ディレクトリオブジェクトとして直接格納されます。

ntds.dit はドメインコントローラー上の C:\Windows\NTDS\ に存在する、ADの心臓部とも言えるデータベースです。ユーザーアカウント、グループ、コンピューターアカウント、そしてDNSレコードまでもが、このファイルの中にオブジェクトとして共存しています。このファイルへのアクセスはOS・Kerberos認証・ACLによって多重に保護されており、単純なファイルコピーでは内容を解読できません。

同期方式の根本的な違い

2つのアーキテクチャの同期方式を対比すると、以下のようになります。

従来のDNS（BIND Primary / Secondary構成）

[Primary DNS]  ──(TCP 53: ゾーン転送 AXFR/IXFR)──>  [Secondary DNS]
   ゾーンファイル (.zone)                               ゾーンファイル (.zone)

AD統合DNS（マルチマスター構成）

[ドメインコントローラー A]  <──(RPC/Kerberos認証済みチャネル: ADレプリケーション)──>  [ドメインコントローラー B]
      ntds.dit (DNSレコード含む)                                                         ntds.dit (DNSレコード含む)

AD統合DNSは、ADのレプリケーション機構に「ただ乗り」してDNSレコードを同期します。

セキュリティ上の絶大なメリット：マルチマスター複製

この構造により、以下のメリットが生まれます。

デフォルトで暗号化・認証済み： レプリケーション通信はKerberos認証された安全なRPCチャネルで行われるため、通信経路でのスニッフィングや改ざんのリスクが極めて低くなります。BINDのゾーン転送のようにTSIGキーを手動で設定する必要がありません。
マルチマスター： すべてのDC（ドメインコントローラー）が読み書き可能となり、一部のDCがダウンしても名前解決とレコード更新が止まりません。BINDのPrimary/Secondary構成ではPrimaryの障害がサービス全体に影響します。

2. ネットワークを丸裸にする「ゾーン転送」の制限

AD統合DNSが安全なレプリケーションを行っているため、DC間での古い仕組みのゾーン転送（AXFR）は本来不要です。しかし、これがデフォルトで許可されていたり、移行時の古い設定が残っていたりすると、重大な情報漏洩リスクとなります。

ゾーン転送（AXFR）が開いているときのリスク

攻撃者が内部ネットワークに侵入した際に行うのが「偵察（Reconnaissance）」です。ゾーン転送が誰にでも許可されていると、攻撃者はLinux端末から以下のコマンド一発で、ネットワーク内の全サーバーのホスト名とIPアドレスのリストを引き抜けます。

# 攻撃者が実行する情報収集コマンド（一瞬で全貌がバレる）
dig @<DCのIPアドレス> yourdomain.local axfr

「ファイルサーバー（fs01）はここか」「管理サーバー（mgt-sv）はここだな」と、攻撃のロードマップを無料で渡しているようなものです。

`SecureSecondaries` の設定値を理解する

まず現在の設定状況を確認します。

# 現在のゾーン転送設定を確認
Get-DnsServerZone -Name "yourdomain.local" | `
  Select-Object ZoneName, SecureSecondaries, SecondaryServers

SecureSecondaries が取りうる値と意味は以下の通りです。

値	意味	推奨
`NoTransfer`	ゾーン転送を完全に禁止	✅ AD統合DNSではこれが基本
`TransferToZoneNameServer`	NSレコードで定義されたサーバーにのみ転送を許可	⚠ 必要な場合のみ
`TransferToSecureServers`	`-SecondaryServers` で明示指定したIPにのみ許可	⚠ 必要な場合のみ
`TransferAnyServer`	すべてのサーバーへ転送を許可	❌ 絶対に使用しない

TransferAnyServer や、SecondaryServersが設定されていない状態は即座に修正が必要です。

PowerShellでゾーン転送を制限する

AD統合DNS環境（外部セカンダリが不要な場合）：完全無効化

# ゾーン転送を完全に無効化（AD統合DNS環境での推奨設定）
Set-DnsServerZone -Name "yourdomain.local" -SecureSecondaries "NoTransfer"

# 設定確認
Get-DnsServerZone -Name "yourdomain.local" | Select-Object ZoneName, SecureSecondaries

ネットワーク機器やLinuxサーバーへのセカンダリ転送がどうしても必要な場合：転送先を明示指定

# 特定のセカンダリサーバーIPにのみゾーン転送を許可
Set-DnsServerZone -Name "yourdomain.local" `
  -SecureSecondaries "TransferToSecureServers" `
  -SecondaryServers @("192.168.10.20", "192.168.10.21")

# 設定確認
Get-DnsServerZone -Name "yourdomain.local" | `
  Select-Object ZoneName, SecureSecondaries, SecondaryServers

よくある誤り：TransferAnyServer + -SecondaryServers の組み合わせ
TransferAnyServer に設定した状態で -SecondaryServers に転送先IPを指定しても、ACLとして機能しません。TransferAnyServer は文字通り「全サーバーへの転送を許可」であり、転送先の制限には TransferToSecureServers を使う必要があります。

3. 「動的更新」の要塞化とスプーフィング対策

Linux環境でDHCP連携のDDNSを実現するには、nsupdate と TSIG キーを用いた複雑な設定が必要でした。WindowsのAD環境では、ドメイン参加済みのクライアントPCが自身のホスト名とIPをDNSサーバーに自動登録・更新します。これが「動的更新（Dynamic Update）」です。

非常に便利ですが、設定を間違えるとDNSスプーフィング（名前解決の乗っ取り）の温床になります。

動的更新の設定レベルを理解する

設定値	意味	推奨
`None`	動的更新を完全に禁止（手動のみ）	⚠ 小規模・静的環境向け
`NonsecureAndSecure`	ドメイン未参加のPCを含む誰でも登録・上書き可能	❌ 絶対に使用しない
`Secure`	ADで認証されたコンピューターアカウントのみ登録・更新可能	✅ 必須

NonsecureAndSecure が特に危険な理由は明確です。攻撃者が内部ネットワークに持ち込んだ野良PCから、fs01.yourdomain.local（ファイルサーバー）のAレコードを自分のIPに書き換えることが可能になります。認証情報を収集するフィッシングサーバーへの誘導が成立してしまいます。

PowerShellで動的更新の設定を確認・強制する

# 現在の動的更新設定を確認
Get-DnsServerZone -Name "yourdomain.local" | `
  Select-Object ZoneName, DynamicUpdate

# 「セキュアのみ」を強制する
Set-DnsServerZone -Name "yourdomain.local" -DynamicUpdate "Secure"

# 設定確認
Get-DnsServerZone -Name "yourdomain.local" | `
  Select-Object ZoneName, DynamicUpdate
# → Secure が返れば設定完了

4. DNSSECについて（補足）

DNSセキュリティを語る上で、DNSSEC（DNS Security Extensions） にも触れておく必要があります。DNSSECはDNSレスポンスにデジタル署名を付与することで、DNSキャッシュポイズニングやなりすましを防ぐ仕組みです。

Windows Server 2012以降、AD統合ゾーンでもDNSSECの署名は技術的に可能ですが、以下の点に注意が必要です。

AD統合ゾーンとDNSSECの制約： DNSSEC署名済みのゾーンをAD統合ゾーンとして運用する場合、署名の更新・ロールオーバーの管理が複雑になります。現時点では、外部向けゾーン（インターネット公開）での適用が主なユースケースです。
内部ADゾーンへの適用： 内部ゾーンでは、AD統合DNSのKerberos認証・暗号化レプリケーション・セキュア動的更新の組み合わせが実質的なセキュリティ層として機能しています。DNSSEC導入を検討する際は、運用負荷と得られるセキュリティメリットを慎重に評価してください。

まとめ：DNSとADは「一蓮托生」である

LinuxエンジニアがWindowsのDNSに向き合う際のポイントは以下の通りです。

DNSのゾーンデータは「ファイル」ではなく「ADそのもの（ntds.dit）」である。 BINDの常識を一度捨てること。
ゾーン転送（AXFR）は無効化（NoTransfer）が基本。 セカンダリが必要な場合でも TransferToSecureServers + 明示的なIP指定で最小化する。
動的更新は必ず「セキュア（Secure）」に。 NonsecureAndSecure はDNSスプーフィングの入り口になる。

今すぐ実行すべき確認コマンド

# ゾーンのセキュリティ設定を一括確認
Get-DnsServerZone | Where-Object {$_.IsAutoCreated -eq $false} | `
  Select-Object ZoneName, ZoneType, SecureSecondaries, DynamicUpdate, IsADIntegrated | `
  Format-Table -AutoSize

このコマンドで SecureSecondaries が TransferAnyServer、または DynamicUpdate が NonsecureAndSecure になっているゾーンがあれば、即座に修正が必要です。

Windows環境において、DNSの侵害は単なる名前解決の障害にとどまらず、Active Directory全体の崩壊を意味します。BINDの常識を一度捨て、ディレクトリサービスと一体化した防御レイヤーとしてDNSを要塞化しましょう。

参考