2台以上の内部DNSが冗長化されているか検証する二つの方法

内部DNSを2台以上用意しただけでは冗長化になりません。検証方法は二つです。第一に、`Resolve-DnsName -Server`または`nslookup 名前サーバーIP`で各DNSを明示して、内部A/AAAA、PTR、SRV、外部名、存在しない名前の応答を比較します。第二に、クライアントが通常設定のまま一台停止・通信遮断時に代替DNSへ切り替わり、サインインや業務が継続するかをテストします。設定一致とフェールオーバー実動作の両方が必要です。

「優先DNSへpingできる」「両方のIPがNICに入っている」だけでは、ゾーン複製、再帰、フォワーダー、クライアント切替を証明できません。

検証用の名前を決める

内部の代表ホスト、ドメインコントローラーのSRV、逆引き、条件付きフォワーダー先、インターネット名、存在しない名前を選びます。業務停止を避けるため、変更を伴わない問い合わせから始めます。内部名と外部名を同じ一件だけで評価しません。

期待値として、応答IP、TTL、Authoritative/Non-authoritative、RCODE、応答時間、CNAME連鎖を記録します。負荷分散で複数IPが返る名前は順序が違っても正常な場合があるため、集合とヘルスを比較します。DNSSECを使うゾーンは検証結果も確認します。

方法1：各DNSを直接問い合わせる

$servers = '10.0.0.10','10.0.0.11'
foreach($server in $servers){
  Resolve-DnsName -Name 'dc1.corp.example' -Type A -Server $server -DnsOnly
  Resolve-DnsName -Name '_ldap._tcp.dc._msdcs.corp.example' -Type SRV -Server $server -DnsOnly
}

`-Server`で問い合わせ先を固定し、Windows DNSクライアントの通常選択やキャッシュから切り離して比較します。テスト用ドメインには組織が管理する実在名を使い、記事中の`example`を本番へそのまま入力しません。結果と実行時刻をCSV等へ保管します。

nslookup dc1.corp.example 10.0.0.10
nslookup dc1.corp.example 10.0.0.11
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example 10.0.0.10

nslookupの非対話モードでは最初の引数が検索名、二番目が使用するDNSサーバーです。`Default Server: Unknown`は逆引き不足を示すことがありますが、対象の正引きが失敗した意味とは限りません。応答本文とタイムアウト、Server failed、Non-existent domainを区別します。

一致しない場合の切り分け

AD統合ゾーンなら、ゾーンの複製スコープ、各DNSが書き込み可能かRODCか、AD複製、SOAシリアル、動的更新、DNS Serverイベントを確認します。標準プライマリ/セカンダリなら、ゾーン転送、Notify、マスター、シリアルを確認します。レコードを手作業で両方へ重複登録して合わせません。

外部名だけ片方で失敗するなら、フォワーダー、条件付きフォワーダー、ルートヒント、ファイアウォール、DNSSEC検証、EDNS、TCP/53を比較します。UDPだけ通るが大きな応答のTCPが止まる場合もあります。

方法2：クライアント切替を試す

検証端末のNIC/DHCPで本番と同じDNS順序を確認し、パケットキャプチャまたはDNS Clientイベントを準備します。保守時間に一台のDNSへの通信だけを管理されたネットワーク制御で遮断し、もう一台は稼働させます。DNSサービスを本番サーバーで乱暴に停止するより、限定された検証セグメントで試します。

遮断前にクライアントのDNS設定、キャッシュ、利用中サーバーを記録します。
短TTLのテスト名、未キャッシュ名、SRV、外部名を順に問い合わせます。
最初のタイムアウト時間と代替DNSから成功するまでを測ります。
Kerberos認証、共有、Web、アプリ等の代表業務を実行します。
遮断を解除し、元DNSの利用復帰とイベントを確認します。

Windows DNSクライアントのサーバー選択は「問い合わせごとに完全なラウンドロビン」ではありません。キャッシュや到達履歴が影響します。`ipconfig /flushdns`を全社へ配布せず、検証端末だけで目的を理解して使います。既存TCPセッションが継続してもDNS冗長化の証明にはなりません。

DHCPと固定設定を確認する

DHCPスコープのOption 006、VPN、Wi-Fi、IPv6、仮想NIC、サーバー固定IPで異なるDNSが配られていないかを確認します。外部公開DNSや家庭用ルーターが混ざると、内部名漏えいと認証失敗につながります。AD参加端末は原則として組織内部DNSを使い、外部解決は内部DNSの転送設計で行います。

IPv4で二台設定していてもIPv6のDNSが別経路から優先される場合があります。`Get-DnsClientServerAddress`、`ipconfig /all`、MDM/GPO、VPN設定を照合します。DNSサフィックス検索リストの差で短い名前だけ失敗することもあります。

障害時に見るログ

クライアントのMicrosoft-Windows-DNS-Client/Operational
DNS Serverの管理・監査・必要時の分析ログ
AD DS・DFSR複製イベント
ファイアウォールとネットワーク機器のUDP/TCP 53ログ
DHCPリースとDNS動的更新結果
監視のQPS、応答時間、SERVFAIL、NXDOMAIN

タイムアウトが長く業務アプリが先に諦める場合、DNS自体が最終的に切り替わっても可用性要件を満たしません。アプリの名前解決回数、タイムアウト、接続プールを含めて測ります。監視は各DNSへの直接問い合わせとクライアント経路の合成テストを分けます。

テスト後の戻し

遮断ルール、テストレコード、短TTL、パケットキャプチャを元へ戻します。キャッシュ全消去やサービス再起動で見かけだけ直さず、権威データと複製、フォワーダーを恒久修正します。変更後に二つの検証方法を再実行し、結果を時刻付きで保存します。

合格基準

各DNSが内部A/AAAA・PTR・SRVへ同じ期待値を返す
外部名とNXDOMAINが設計どおりである
一台遮断時に許容時間内で代替へ切り替わる
認証・共有・業務アプリが継続する
DHCP/VPN/IPv6を含む端末設定が内部DNSだけを指す
復旧後に監視とログが正常化する

権威応答とキャッシュ応答を分ける

同じIPが返っても、一台は権威サーバー、もう一台は上流からキャッシュしただけなら冗長構成が誤っている可能性があります。SOA、NS、AAフラグ、ゾーン種別、複製スコープを確認し、内部ゾーンを両方が設計どおりに保持していることを確かめます。条件付きフォワーダーは格納先がADかローカルかも比較します。

TTLが極端に違う場合は単なるキャッシュ残時間か、レコード/ゾーン設定差かを判定します。SOAシリアルだけでAD統合ゾーンの全整合性を断定せず、対象レコード、AD複製、DNSイベントを組み合わせます。

定期的な自動試験

監視から各DNSへ同じ問い合わせを送り、期待値、RCODE、応答時間を記録します。監視元を一か所だけにせず、主要拠点やVPNからも試します。DNSサーバー自身のlocalhost問い合わせだけでは、クライアント経路のACL、ルート、MTU、ファイアウォール障害を検出できません。

公式情報・参考資料

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

2台以上の内部DNSが冗長化されているか検証する二つの方法

検証用の名前を決める