IPv6環境でActive Directory（AD）のローカルDNSを自動配布したいのに、Router Advertisement（RA）を有効にするとISP側DNSが優先され、無効にするとデフォルトゲートウェイが消えて通信できない――。DHCPv6とRAの役割分担を整理し、Windows Server 2016で確実に解決する手順をまとめます。
起きている現象を「競合」として言語化する
まず大前提として、IPv6の自動設定はRA（ルーター広告）とDHCPv6の両方が関わります。ここを曖昧にしたまま設定を触ると、今回のように「どちらかを止めると別の要素が壊れる」状態になりがちです。
質問の状況を、クライアント目線で整理すると次の通りです。
| 状態 | クライアントに起きること | 結果 |
|---|---|---|
| RAを無効 | DHCPv6でアドレス等は取れても、デフォルトルート（ゲートウェイ）が入らない／他情報も不完全になりやすい | 外へ出られず、名前解決も不安定 |
| RAを有効 | デフォルトルートは入るが、ルーター側が配る外部DNSが混ざる／優先される | ローカルドメイン名がIPv6で解決できない |
つまり本質は「RAとDHCPv6が同じ領域（DNSなど）に手を出して、クライアント側のDNS設定が意図しない順番になる」ことです。ここを解けば、RAは止めずに、ローカルDNSを確実に優先させられます。
結論：RAとDHCPv6は役割分担が前提
結論から言うと、実運用で一番トラブルが少ないのは次の分担です。
- RA：デフォルトルート（ゲートウェイ）とプレフィックス（SLAACの材料）
- DHCPv6：DNS（Option 23）など追加情報
今回の「RAを止めるとゲートウェイが消える」は、まさにこの設計思想ど真ん中の挙動です。DHCPv6は万能ではなく、IPv6はまずRAありきでネットワークが成立するように作られています。
| 配布したい情報 | 得意な仕組み | 備考 |
|---|---|---|
| デフォルトゲートウェイ（デフォルトルート） | RA | IPv6ではこれが基本。RA停止は基本的に非推奨 |
| アドレス（SLAAC） | RA | 端末が自分でアドレス生成。RAのプレフィックス情報が必要 |
| アドレス（DHCPv6） | DHCPv6 | Stateful DHCPv6。運用ポリシー次第 |
| DNSサーバー | DHCPv6（Option 23）またはRA（RDNSS） | 競合しやすい。どちらで配るかを決めて一本化が安全 |
| ドメイン検索サフィックス | DHCPv6（Option 24）またはRA（DNSSL） | 短いホスト名解決を安定させたいなら重要 |
「Windows Server 2016のDHCPv6はDNS/ゲートウェイを配れないの？」への答え
まず誤解が起きやすいポイントを分けます。
- DNSは配れます。Windows Server 2016のDHCPv6でも、Option 00023（DNS Recursive Name Server）で配布できます。
- デフォルトゲートウェイは基本的にDHCPv6で配りません。仕様というより、IPv6の設計として「デフォルトルートはRAで広告する」のが基本です。
そのため「RAを止めたらゲートウェイが入らない」は自然で、DHCPv6側の欠陥ではありません。逆に言うと、RAを生かしたままDHCPv6でDNSだけ配る構成に寄せるのが最短ルートです。
最初にやるべき前提確認：ローカルDNS（AD DC）がIPv6で“本当に”使えるか
外部DNSが優先される問題を直しても、ローカルDNS（ADドメインコントローラー）がIPv6で正常応答していなければ同じように詰みます。設定に入る前に、次を押さえてください。
DC/DNSサーバー側のチェック
- DNSサーバー自身に安定したIPv6アドレスがあるか
可能なら固定（静的）にします。少なくともサーバー再起動や回線再接続で変わらない設計にします。 - DNSサービスがIPv6で待ち受けできているか
WindowsのDNSは通常IPv6でも待ち受けますが、セキュリティ製品やFWでIPv6の53番が落ちているケースがあります。 - 内部向けDNSとして「外部も引ける」状態にしておく
クライアントから見たDNSは原則DCだけにします。外部名解決はDC側のフォワーダーでISPやパブリックDNSへ転送します。
疎通と名前解決の簡易テスト
DC上、または同一セグメントの端末上で、以下のような確認をします（例）。
ipconfig /all
nslookup yourdc.example.local
nslookup -type=AAAA yourdc.example.local
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.local
AD環境ではSRVレコードが引けることが重要です。IPv6で運用する以上、クライアントがAAAA（IPv6）を選びやすくなるため、IPv6でDNSが不安定＝AD全体が不安定になりがちです。
解決策の中核：Windows Server 2016 DHCPv6でローカルDNSを配布する
ここが今回の一番のポイントです。DHCPv6のGUIはIPv4より馴染みが薄く、設定箇所を見落としやすいため、手順を具体的に書きます。
前提：DHCPサーバーが正しく稼働しているか
- DHCPサーバー役割がインストールされている
- Active Directory環境では、DHCPサーバーが承認（Authorize）されている
- DHCPv6のスコープが作成・有効化されている（Stateless運用でも、オプション配布の単位としてスコープを使うことが多い）
「DHCPv6は動いている（アドレスは取れている）のにDNSだけ入らない」という場合、ほとんどがOption 23未設定です。
設定するのはOption 00023（DNS Recursive Name Server）
DHCPv6でDNSサーバーを配る標準のオプションがOption 00023です。ここにローカルDNS（DC）のIPv6アドレスを入れます。
DHCP管理コンソールでの設定手順
- DHCP管理コンソールを開く
- IPv6を展開し、対象サーバー配下のServer Optionsを開く
- Configure Optionsを開く
- Option 00023（DNS Recursive Name Server）にチェックを入れる
- 下の一覧にローカルDNS（DC）のIPv6アドレスを追加する
サーバー全体に効かせたくない場合は、サーバーオプションではなくスコープ（IPv6 Scope）のScope Optionsに同じOption 23を入れる運用もできます。拠点ごとにDNSを出し分けたい場合はこちらが便利です。
| 項目 | 推奨 | 理由 |
|---|---|---|
| Option 00023（DNS Recursive Name Server） | ローカルDNS（DC）のIPv6を指定 | クライアントがADドメインを確実に解決できる |
| Option 00024（Domain Search List） | 必要に応じてADドメインを指定 | 短い名前（host名だけ）での解決を安定させる |
よくある落とし穴：DHCPv6を配っているのが“別の機器”になっている
RAを有効にした途端に外部DNSが入る場合、クライアントが受け取っているDNS情報は次のどれかです。
- ルーターがRAでDNS（RDNSS）を広告している
- ルーターがDHCPv6サーバーとして動いており、そこで外部DNSを配っている
- ルーター自体をDNSとして配り、ルーターが外部DNSへフォワードしている
この状態でWindows ServerのDHCPv6を設定しても、そもそもクライアントがWindows Server側のDHCPv6を使っていなければ効果が出ません。次章の「RA側の調整」は、まさにこの競合を潰す作業です。
RA側の調整：デフォルトルートは維持しつつ、DNS広告の競合を止める
今回の症状は「RAを有効にすると外部DNSが優先される」なので、RA側でDNSを広告しない／ローカルDNSを広告するのが王道です。
まず理解しておきたい：RAは“ゲートウェイだけ”を配るとは限らない
RAはデフォルトルートやプレフィックスを配りますが、実装によってはDNSサーバー（RDNSS）やドメイン検索サフィックス（DNSSL）も配れます。つまり、ルーター設定のどこかに「IPv6 DNS配布」や「RDNSS」相当の項目があるなら、それが競合の原因になり得ます。
ルーターで見るべき設定項目（一般形）
| 設定項目（名称は機種で異なる） | 推奨設定 | 狙い |
|---|---|---|
| RAのDNS広告（RDNSS / IPv6 DNS Advertisement） | 無効またはローカルDNS（DC）を指定 | 外部DNSが混ざるのを根本から止める |
| RAのフラグ（Managed / Other） | DNSをDHCPv6で配るならOther（O）を有効 | 「追加情報はDHCPv6で取ってね」を端末に示す |
| DHCPv6サーバー機能（ルーター側） | Windows Serverで配るなら無効 | DHCPv6が二重になって情報がブレるのを防ぐ |
「HE（Hurricane Electric）のDNSが優先される」という状況は、ルーターが外部DNSを配っている可能性が高いです。ルーターがトンネルブローカーの設定テンプレートに従って外部DNSを設定している場合、内部DNS（AD DNS）に置き換えるだけで状況が一気に改善します。
RAとDHCPv6の併用パターン（おすすめの選び方）
ネットワーク内の端末種類で、最適解が変わります。Windows中心の社内LANだけならDHCPv6寄りが扱いやすいですが、スマホやIoTが混ざるとRA DNS（RDNSS）が必要な場面もあります。
| パターン | アドレス配布 | DNS配布 | 向いている環境 |
|---|---|---|---|
| SLAACのみ | RA | 手動 or RA（RDNSS） | 小規模、固定DNSで良い、ADなし |
| SLAAC + Stateless DHCPv6 | RA | DHCPv6（Option 23） | 今回の解決に最も近い。RAでゲートウェイ維持、DNSはDHCPv6で統一 |
| Stateful DHCPv6 | DHCPv6 | DHCPv6（Option 23） | アドレス管理を厳密にしたい。端末がDHCPv6対応であることが前提 |
今回の要件「ADのローカルDNSを自動配布して、ローカルドメイン名をIPv6で解決したい」に最短で効くのは、SLAAC + Stateless DHCPv6（RAで経路、DHCPv6でDNS）です。
パケットで“どこからDNSが来ているか”を一発で確認する
GUIだけ見ていると迷子になりやすいので、可能ならWiresharkで確認するのが最短です。見るべきパケットは2種類だけです。
- RA（Router Advertisement）：ICMPv6 Type 134
- DHCPv6：UDP 546/547（Solicit/Advertise/Reply、またはInformation-request/Reply）
フィルタ例を置いておきます。
icmpv6.type == 134
dhcpv6
RAの中にRDNSS（DNSサーバー情報）が入っているなら、そこが外部DNS混入の入口です。逆にRAにDNSが無く、DHCPv6 ReplyにOption 23が入っているなら、DHCPv6側でDNSを配れている証拠になります。
ルーター側が調整できないときの現実的な回避策
家庭用ルーターやISP貸与機器だと、RAのDNS広告を細かく制御できない場合があります。その場合でも、AD環境を守るための逃げ道があります。
- 内側に自前ルーター（pfSense/OPNsense/MikroTik等）を置き、そちらでRAとDHCPv6を制御する
上流は単にIPv6疎通させるだけにして、LAN側の配布情報は自前機器で統一します。 - スイッチでRA Guardを有効化し、意図しないRAを遮断する
「勝手にRAを出す機器」がいると、デフォルトルートやDNSがぐちゃぐちゃになります。企業LANなら特に有効です。 - どうしても最後の手段：GPOやスクリプトでDNSを強制する
DHCP/RA設計を直すのが本筋ですが、短期的な暫定回避としては有効です。
特に複数ルーター環境（仮想基盤、テザリング、ICSなどが混在）では、意図しないRAが混入しやすいので「RAを誰が出しているか」を最優先で疑うと解決が早いです。
参考：radvdを使う場合の設定例
自前ルーター（Linuxなど）でRAを制御できる場合は、次の考え方が分かりやすいです。環境に合わせてプレフィックスやDNSは読み替えてください。
interface eth0 {
AdvSendAdvert on;
# Stateless DHCPv6を使う想定：アドレスはSLAAC、追加情報はDHCPv6
AdvManagedFlag off;
AdvOtherConfigFlag on;
prefix 2001:db8:1234:5678::/64 {
AdvOnLink on;
AdvAutonomous on;
};
# もしRAでDNSを配るなら、外部DNSではなくローカルDNSを指定する
# RDNSS 2001:db8:1234:5678::53 { };
# DNSSL example.local { };
}; クライアント（Windows）での確認ポイント
設定を入れたら、必ずクライアント側で「何が配られているか」を確認します。DHCP側が正しくても、RA側が外部DNSを出し続けていれば再発します。
確認コマンド
ipconfig /all
route print -6
netsh interface ipv6 show dnsservers
powershell -Command "Get-DnsClientServerAddress -AddressFamily IPv6"
powershell -Command "Get-NetIPConfiguration"
期待する状態
- IPv6のデフォルトルート（::/0）が存在し、次ホップがルーターになっている（RAで入る）
- DNSサーバー一覧にローカルDNS（DC）のIPv6が入っている
- 外部DNSが混ざっていない、または混ざっていてもローカルDNSが先頭
- ローカルドメイン名（例：
host.example.local）がAAAAで解決できる
名前解決の実地テスト
nslookup host.example.local
nslookup host.example.local <DCのIPv6アドレス>
ping -6 host.example.local
2行目のように、DNSサーバーを明示したnslookupで成功するのに、明示しないと失敗する場合は、DNSサーバーの優先順位・混在が原因です。RA/DHCPv6のどちらがDNSを出しているかに戻って確認します。
それでも直らないときの原因切り分け
IPv6は「ICMPv6を止めると壊れる」世界です。特にRA関連のICMPv6がフィルタされていると、DHCPv6だけ頑張っても不安定になります。トラブルシュートは、症状から逆引きするのが早いです。
| 症状 | ありがちな原因 | 対処 |
|---|---|---|
| RAを有効にすると外部DNSが入る | ルーターがRA（RDNSS）またはDHCPv6で外部DNSを配布 | ルーターのDNS広告を無効化／ローカルDNSに変更。DHCPv6二重起動を解消 |
| RAを止めるとデフォルトルートが消える | 想定通り（IPv6の基本設計） | RAは止めない。必要ならM/OフラグやDNS広告だけ調整する |
| DHCPv6 Option 23を設定したのに端末が受け取らない | 端末がそのDHCPv6サーバーを見ていない／Oフラグが無い／FWでUDP 546/547が遮断 | DHCPv6の到達性を確認。RAのOフラグ設定。FWでDHCPv6を許可 |
| 端末はDNSを受け取っているのにローカル名だけ引けない | 端末が外部DNSへ問い合わせている／検索サフィックスが不足／DC側DNSがそのゾーンを持っていない | DNS一覧を内部に統一。Option 24またはGPOでサフィックスを整備。ゾーン/委任を確認 |
| ローカルDNSを使っているのにAD関連が不安定 | DCのDNSが外部へフォワードできない／DNSゾーンが不整合／IPv6の53番が遮断 | DNSフォワーダー、ゾーン、FWを点検。IPv6での問い合わせログも確認 |
| 端末によって挙動が違う | OSがDHCPv6非対応（または限定的）／Wi-Fiと有線で別経路／複数RA混在 | 端末混在を前提に「RA DNSを使う」設計へ寄せるか、RAの出どころを一本化する |
AD環境での実践的ベストプラクティス
最後に、単に「繋がる」だけでなく、運用を楽にしてトラブルを減らすためのポイントをまとめます。
クライアントDNSは内部（DC）に一本化する
ADのクライアントが外部DNSを引くと、次の問題が起きます。
- 内部ドメイン名が解決できず、サインインやGPO、ファイル共有が不安定になる
- SRVレコード探索が失敗し、「ドメコンが見つからない」系の障害に繋がる
- 内部名前（ホスト名）が外部へ漏れる（情報漏えい・監査面で嫌われる）
そのため、クライアントへ配布するDNSは原則DCのみ。DC側で外部向けのフォワーダー（ISPやパブリックDNS）を設定して、外部名前解決はサーバー側で制御します。
DNSの“優先順位が勝手に入れ替わる”を防ぐ
端末に複数のDNSサーバーが入っていると、応答が速い側に寄ったり、障害時にフェイルオーバーしたりします。一見便利ですが、AD環境では外部DNSに寄った瞬間に内部名が引けなくなるのが致命傷です。
- 配布経路を一本化し、端末に外部DNSを入れない（RA/DHCPv6の競合を潰す）
- 外部DNSはDCのフォワーダーとしてのみ使う
- 再発防止として、FWでクライアントの外向きDNS（53/853等）を制御するのも有効
IPv6アドレス設計を「変わらない」方向へ寄せる
トンネルブローカーやISPのプレフィックスは、運用によって変わることがあります。内部サービス（DC、ファイルサーバー、認証基盤）のアドレスが変わるとDNS・証明書・固定設定が連鎖的に壊れます。
- 可能ならDCは静的なIPv6を持たせる（プレフィックスが変わる環境なら、内部用にULAも検討）
- DNSは「クライアントから見た入口」を固定する（例：DNSは常にDC）
- ルーターやFWのポリシーに「外部DNSへ直接出ない」制御も入れると再発防止になる
“RAを止める”より、“RAの中身を整える”が近道
IPv6でRAを止めるのは、IPv4でDHCPを止めて「各端末に静的ルート入れて頑張る」に近い無理筋です。RAは活かしつつ、次の2点を整えるのが現実的です。
- RAはデフォルトルートとプレフィックスだけ（または内部DNSを広告）
- DHCPv6はDNS（Option 23）を確実に配る（必要ならOption 24も）
まとめ
- DNSはWindows Server 2016のDHCPv6で配布可能。Option 00023にローカルDNS（DC）のIPv6を設定する
- デフォルトゲートウェイはDHCPv6ではなくRAで配るのが基本。RAを止めるとゲートウェイが消えるのは自然
- RA有効時に外部DNSが優先されるなら、ルーター側のDNS広告（RDNSS）やDHCPv6二重配布が原因になりやすい
- 最終的には「RA＝経路」「DHCPv6＝DNS」で一本化し、クライアントDNSは内部（DC）に統一するとADが安定する
コメント