自宅環境のWindows Server 2022を使ったDNSフォワードの設定と名前解決検証

## はじめに
[前回の記事](https://qiita.com/free-honda/items/2fcdc8343aa878c17d9e)では、DNSサーバーの構築と基本的な名前解決の仕組み、検証を行いました。

今回は、自宅のDNSサーバーで名前解決できなかった場合に外部のDNSにフォワードされる設定と動作を確認していきます。

名前解決の検証用クライアント端末は気分を変えて、久しぶりにMacBookを使って検証します。

## 前提条件

:::note warn
**検証環境**
**サーバー環境:**
VirtualBox上で稼働しているWindows Server 2022を使用

**クライアント環境:**
プライベートPCとして使っているmacbook pro(M1)

**DNSサーバーの役割:**
AD統合DNSを使用し、内部ネットワークの名前解決を行う

**使用ミドルウェア:**
Windows ServerのDNS機能を採用

**ネットワーク:**
サーバーとクライアントが同一のローカルネットワーク内に接続されていること
:::

**自宅のVirtualBox環境**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/6548c2dd-7761-be07-4780-ad64a6543e04.png)

:::note info
※検証には「Windows Server 2022」と「プライベートのMacBook」を使用します。
:::

## 知識整理
DNSと名前解決については、前回の記事で詳しく解説していますので、こちらをご参照ください。

[Windows Server 2022で自宅ネットワークにADサーバーを構築し、Windows 10端末をドメインに参加させる方法](https://qiita.com/free-honda/items/2fcdc8343aa878c17d9e)

[自宅環境のWindows Server 2022を使ったDNS構築と名前解決検証](https://qiita.com/free-honda/items/807b36c839f49d7bdb47)

**DNSフォワーダについては、自分のDNSサーバーで解決できない場合、外部のDNSサーバーに問い合わせを行います。**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/182082eb-76ce-e41c-d7b6-648feb5a5d8b.png)
引用画像：https://atmarkit.itmedia.co.jp/ait/articles/1706/23/news042.html

:::note warn
他のサイトでも詳しく説明されていますので、知りたい方はこちらをご参照ください。
**参考サイト**：https://wa3.i-3-i.info/word12573.html
**参考サイト**：https://jprs.jp/glossary/index.php?ID=0198
:::

## 構築の流れ

フォワード設定を行うことで、内部のDNSサーバーが解決できないドメイン名を外部のDNSにフォワードし、広範な名前解決が可能になります。

:::note info
これを2つのステップに分けて解説します。
**ステップ1：内部DNSサーバのフォワード設定**
**ステップ2：フォワード設定の前後の検証**
:::

## ステップ1：内部DNSサーバのフォワード設定
このステップでは、DNSサーバーが解決できない外部ドメイン名に対して、外部DNSサーバーに問い合わせる設定を行います。

デフォルトではフォワード設定がされていますが、今回は検証のためにフォワード設定を外した状態からスタートします。

```
手順:

DNS管理ツールを開く
サーバーマネージャーからDNSツールを開きます。

DNSサーバーのプロパティを開く
DNS管理ツールでDNSサーバー名を右クリックし、プロパティを選択します。

フォワーダーの設定
プロパティ画面のフォワーダータブを開き、外部DNSサーバーのIPアドレスを入力します（例: 8.8.8.8 や 8.8.4.4などのGoogle Public DNS）。

設定の保存と確認
設定を保存し、フォワーダータブに入力したDNSサーバーが表示されていることを確認します。
```


**私の環境では、Googleの「8.8.8.8(優先)」「8.8.4.4(代替)」パブリックDNSをフォワーダー先に設定しています。**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/b9ad70d3-5449-1810-b761-f2d2345a1188.png)


## ステップ2：フォワード設定の前後の検証
まずは、Googleの「8.8.8.8（優先）」および「8.8.4.4（代替）」パブリックDNSのIPアドレスをフォワーダー先に設定する前の状態を確認します。

フォワード設定の前後でDNSサーバーが正しく動作しているかを確認するために、以下の手順を踏みます。

### 設定前の検証
**内部ドメインの名前解決の確認**
内部ドメイン（例: honda.co.jp）が正しく名前解決できているかを確認します。

プライベートのMacbookは、GoogleのパブリックDNSを設定しているので、**ここではnslookupコマンドを使い対話モードに入り確認していきます。**

```
➜  Desktop git:(honda-branch) ✗ nslookup
> server 192.168.1.7
Default server: 192.168.1.7
Address: 192.168.1.7#53
> 
> honda.co.jp
Server:		192.168.1.7
Address:	192.168.1.7#53

Name:	honda.co.jp
Address: 192.168.1.7
Name:	honda.co.jp
Address: 10.0.4.15
> 
```

内部ドメイン(honda.co.jp)が正常に解決できれば、DNSサーバーが自身のゾーン内の名前解決を行えていることが確認できます。

:::note info
DNSの名前解決を検証したいけど端末の設定は変更したくない場合や、GPOで制御されている場合などは、**このように既定のDNSを一時的に変更して名前解決を行うことをおすすめします。**
:::

**外部ドメインの名前解決の確認**

フォワーダー設定を行っていない場合、外部ドメイン（例: google.com）の名前解決に失敗します。

```
➜  Desktop git:(honda-branch) ✗ nslookup 
> server 192.168.1.7
Default server: 192.168.1.7
Address: 192.168.1.7#53
> 
> google.com
Server:		192.168.1.7
Address:	192.168.1.7#53

** server can't find google.com: SERVFAIL
> 
```

「**server can't find google.com: SERVFAIL**」と表示され、フォワーダー設定を行っていないため、外部ドメインの名前解決が失敗していることが確認できます。

### 設定後の検証
**外部ドメインの名前解決の確認**
フォワーダー設定後、外部ドメイン名（例: google.com）を再度確認します。

```
➜  Desktop git:(honda-branch) ✗ nslookup
> server 192.168.1.7
Default server: 192.168.1.7
Address: 192.168.1.7#53
> google.com
Server:		192.168.1.7
Address:	192.168.1.7#53

Non-authoritative answer:
Name:	google.com
Address: 142.250.206.238
```

名前解決が正常に行われ、外部DNSにフォワードされていることが確認できます。

:::note info
「**権限のない回答（Non-authoritative answer）**」として表示されるのは、内部DNSサーバーがgoogle.comのゾーン情報を持っていないため、外部のフォワード先DNSサーバーに問い合わせ、その結果を返している状態です。
:::

つまり、そのサーバー自身が持つDNSゾーンからの直接回答ではなく、他のサーバーから情報を得て返答しているということです。

## まとめ
フォワード設定を通じて、内部DNSサーバーで解決できない外部のドメイン名を外部DNSサーバーに委任することで、全体的な名前解決のカバー範囲を広げることができます。

この2つのステップを通じて、内部・外部の名前解決が正しく行われていることが確認できましたので、今回の構築は成功と言えます。

DNSのフォワード設定や動作確認もこれでばっちりですね！

## 実務でハマった箇所
私が何日も実務でハマった部分ですが、自分自身の内部DNS内に、例えば「google.com」のゾーンを保有していた場合、DNSのフォワード設定をしていてもフォワードされないことが分かりました。

これは、DNSサーバーが「権威的DNSサーバー」として動作するためであり、他のDNSサーバーにフォワーディングする必要がないと判断するため、内部で管理しているゾーンのクエリは自分で解決しようとするためです。

以下は、Googleの検索ページを名前解決しようとした結果、失敗した事象の再現です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/67d062d5-919d-966d-0ef2-d933af257d78.png)

:::note info
この部分につまづく方は少ないと思いますが、社内のゾーンを社外のDNSのゾーンに移行する際に、社外に移行したはずなのに名前解決に失敗したことから調査し、発見しました。
:::

対策としては、内部DNSの対象のゾーンごと削除することで、内部DNSは「このゾーン情報を持っていないので、誰か教えて！」と社外のDNSに問い合わせを行う動きになります。

## 参考記事
https://learn.microsoft.com/ja-jp/windows-server/networking/technologies/ipam/create-a-dns-zone

http://lan-pc.pc-beginner.net/net_cmd/nslookup.html

https://xtech.nikkei.com/it/atcl/column/15/042000103/080700081/