【Windows Server上級 第3回】DNSの深淵。スプリットブレインDNS、ゾーン転送、DNSSECの構築

「named.conf」の波括弧を閉じる日々は、もう終わりです。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、DHCPフェイルオーバーとIPAMによるIPアドレス管理を学びました。
ネットワークの足回りが固まったところで、今回はその上で動く最重要サービス、「DNS」のお話です。

Linuxエンジニアの皆さん、BINDの設定ファイル（ゾーンファイル）の管理、辛くないですか？
「シリアル番号を上げ忘れて反映されない」「構文エラーでサービスが起動しない」「セカンダリサーバーへの転送設定が面倒」……。
Windows ServerのDNSを使えば、これらの苦労の9割は消滅します。

本記事では、AD統合ゾーンの仕組み、DNSポリシーによるスプリットブレインDNSの構築、BINDサーバーとの連携（ゾーン転送）、そしてDNSSECの導入手順までを徹底解説します。

---

第1章：Active Directory統合ゾーン。テキストファイルからの脱却

通常のDNSサーバー（BINDなど）は、ゾーン情報をテキストファイル（ゾーンファイル）で管理します。
プライマリサーバーでファイルを更新し、セカンダリサーバーへ「ゾーン転送（AXFR/IXFR）」を行って同期します。

AD統合ゾーンの仕組み

Windows DNSのデフォルトである「AD統合ゾーン」では、DNSレコードはActive Directoryデータベースのオブジェクトとして格納されます。

メリット：

1. マルチマスター複製： どのDNSサーバー（DC）でレコードを追加しても、ADの複製機能によって全サーバーに同期されます。「プライマリ/セカンダリ」という概念がなくなり、SPOF（単一障害点）が解消します。
2. セキュアな動的更新： 「ドメインに参加しているPCだけが、自分のAレコードを自動登録できる」という制限が可能です。勝手なPCがDNSを書き換えるのを防げます。
3. シリアル番号管理不要： ファイルではないため、SOAレコードのシリアル番号を手動でインクリメントする必要がありません。

---

第2章：PowerShellで実装する「スプリットブレインDNS」

「社内LANからのアクセスはローカルIP（192.168.x.x）を返し、社外からのアクセスはグローバルIP（203.0.113.x）を返す」。
これを実現するのがスプリットブレインDNSです。
BINDでは view 構文を使いますが、Windowsでは「DNSポリシー」を使います。

DNSポリシーの構成要素

GUIはありません。すべてPowerShellで設定します。

1. クライアントサブネット: アクセス元のIP範囲を定義。
2. ゾーンスコープ: ゾーンの「別バージョン（View）」。
3. DNSポリシー: 「誰が（サブネット）」「何をしたら（クエリ）」「どこを見る（スコープ）」というルール。

構築手順

例：www.example.com に対して、社内（192.168.1.0/24）からは 192.168.1.100、それ以外からは 203.0.113.100 を返す設定。

1. クライアントサブネットの定義

Add-DnsServerClientSubnet -Name "InternalSubnet" -IPv4Subnet "192.168.1.0/24"

2. ゾーンスコープの作成（社内用）

# "InternalScope" という名前のスコープを作成
Add-DnsServerZoneScope -ZoneName "example.com" -Name "InternalScope"

3. レコードの登録

# デフォルトスコープ（社外用）にグローバルIPを登録
Add-DnsServerResourceRecordA -ZoneName "example.com" -Name "www" -IPv4Address "203.0.113.100"

# 社内用スコープにローカルIPを登録
Add-DnsServerResourceRecordA -ZoneName "example.com" -Name "www" -IPv4Address "192.168.1.100" -ZoneScope "InternalScope"

4. ポリシーの適用

# "InternalSubnet" からのアクセスは "InternalScope" を参照せよ、というルール
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainPolicy" -ZoneName "example.com" `
    -ClientSubnet "EQ,InternalSubnet" -ZoneScope "InternalScope,1"

これで、アクセス元に応じて異なるIPが返るようになります。
Resolve-DnsName コマンドなどでテストしてみましょう。

---

第3章：異種混合環境。WindowsとBINDのゾーン転送

すべてのDNSサーバーをWindowsに置き換えられるとは限りません。
「既存のBINDサーバーをスレーブ（セカンダリ）として残したい」というケースは多々あります。

ゾーン転送の設定（Windows側）

AD統合ゾーンであっても、外部へのゾーン転送は可能です。

1. DNSマネージャーを開き、対象のゾーンを右クリック → 「プロパティ」。
2. 「ゾーン転送」タブを開く。
3. 「ゾーン転送を許可する」にチェックを入れ、「次のサーバーのみ」を選択。
4. BINDサーバーのIPアドレスを追加。

注意： セキュリティのため、「すべてのサーバー」への転送は絶対に許可しないでください。ゾーン情報が丸裸になります。

通知（Notify）の設定

レコードが更新された時に、即座にスレーブに「更新したよ！」と知らせる機能です。
「ゾーン転送」タブの「通知」ボタンをクリックし、BINDサーバーのIPを追加します。

BIND側の設定（named.conf）

Linux側では、通常のセカンダリ設定を行います。

zone "corp.example.com" {
    type slave;
    masters { 192.168.1.10; }; # Windows DNSのIP
    file "slaves/corp.example.com.db";
};

これで、Windowsでレコードを追加すると、即座にBIND側にも同期されるハイブリッド環境が完成します。

---

第4章：DNSSECの導入。改ざん検知の実装

DNSキャッシュポイズニング攻撃を防ぐための技術、DNSSEC。
BINDでの設定は非常に複雑（鍵生成、署名、ロールオーバー……）ですが、Windows Serverなら数クリック、または数行のコマンドで導入できます。

構築手順（GUI）

1. DNSマネージャーでゾーンを右クリック → 「DNSSEC」 → 「ゾーンの署名」。
2. ウィザードに従って進めます。「既定の設定を使用してゾーンに署名する」を選べば、推奨パラメータ（SHA-256など）で自動設定されます。
3. 完了すると、RRSIGやDNSKEYなどのレコードが自動生成されます。

トラストアンカーの配布

AD環境であれば、ドメイン参加している全PCに対して、トラストアンカー（署名鍵の信頼情報）を自動配布できます。
グループポリシーで「名前解決ポリシー テーブル (NRPT)」を設定し、「DNSSECを検証せよ」と指示するだけです。

---

第5章：実践！PowerShellでDNSレコード大量登録

移行プロジェクトなどで、Excelリストにある数百件のAレコードを登録したい場合、手入力はあり得ません。
PowerShellで一括登録しましょう。

CSVからのインポートスクリプト

records.csv (Hostname, IP) を用意します。

Hostname,IP
web01,192.168.1.101
web02,192.168.1.102
db01,192.168.1.201

登録スクリプト:

$ZoneName = "corp.example.com"
Import-Csv "C:\work\records.csv" | ForEach-Object {
    Add-DnsServerResourceRecordA -ZoneName $ZoneName `
        -Name $_.Hostname -IPv4Address $_.IP -CreatePtr
}

-CreatePtr オプションを付けるだけで、逆引きレコード（PTR）も同時に作成してくれます。
これもBINDにはない便利な機能です。

条件付きフォワーダーの設定

「特定のドメイン（例: partner.local）だけは、提携先のDNSサーバーに問い合わせたい」という場合の設定です。

Add-DnsServerConditionalForwarderZone -Name "partner.local" `
    -MasterServers "10.20.30.40" -ReplicationScope "Forest"

-ReplicationScope "Forest" を指定することで、フォレスト内の全DNSサーバーにこの設定が同期されます。

---

第6章：トラブルシューティングとキャッシュの罠

「DNS設定を変えたのに反映されない！」というトラブルは日常茶飯事です。
Windowsには「サーバー側のキャッシュ」と「クライアント側のキャッシュ」の2つがあることを意識してください。

1. サーバーキャッシュのクリア

DNSサーバー自体も、フォワーダーなどから得た結果をキャッシュしています。

Clear-DnsServerCache

または、DNSマネージャーでサーバー名を右クリック → 「キャッシュのクリア」。

2. クライアントキャッシュのクリア

PC側のリゾルバキャッシュです。

ipconfig /flushdns

3. nslookup と Resolve-DnsName の違い

Linuxエンジニアは dig を使いたいところですが、Windowsには標準では入っていません。
古き良き nslookup も使えますが、PowerShellの Resolve-DnsName の方が高機能で、DNSSECの検証なども可能です。

# DNSSECの署名検証を含めて問い合わせ
Resolve-DnsName -Name "www.example.com" -DnssecOk

---

まとめ：DNSを制する者はADを制す

お疲れ様でした！
上級編第3回は、Windows DNSの高度な機能について解説しました。

今回の重要ポイント：

• AD統合ゾーンを使えば、ゾーン転送設定なしで全拠点に同期される。
• DNSポリシーを使えば、GUIなしでスプリットブレインDNSが作れる。
• BINDへのゾーン転送も可能。ただしセキュリティ（許可リスト）に注意。
• DNSSECはWindowsなら「鍵の更新」まで完全自動化できる。

さて、インフラの基礎（クラスタ、ネットワーク）が整いました。
次は、セキュリティの中核となる「PKI（公開鍵基盤）」のお話です。
社内システムのHTTPS化、Wi-Fiの証明書認証、VPN接続……これらを支える「オレオレ認証局」ではない、本格的な認証局（CA）を構築します。

次回、第4回は「証明書基盤 (AD CS)。OpenSSL使いが知るべきエンタープライズPKI」です。
OpenSSLコマンドでチマチマCSRを作っていた日々とはおさらば。
ADと連携した証明書の自動配布（オートエンロールメント）の世界へご招待します。お楽しみに！