【エンジニア0年生】DNSサーバーの設定

こんにちは。インフラエンジニア歴マイナス1カ月のdessinです。
ネットワークスペシャリストに向けた勉強としてDNSの本を読んだので、実際にサーバーの設定をしてみました。
ドメインに関する理解はまだまだですが、DNSの仕組みについては理解が深まったと思います。

環境

• Azure 仮想マシン（Windows Server 2019)にDNSサーバーを設定する。
• ローカルマシンはWindows 11を使用する。

作業

Azure仮想マシン作成とリモートデスクトップ接続

前回の記事と同様に作成します。ただし仮想マシン名は「DNSserver」としました。
仮想ネットワークやサブネットも前回と同じものを流用しています。作成できたら、リモートデスクトップ接続します。「Windowsキー＋R」を押してから「mstsc」です。

DNSサーバーのソフトウェアをインストール

公式DOCを参考にしてDNSサーバーとしての機能を設定します。このURLのja-jp部分をenに変えると、英語版になるので、仮想マシン内での表記とDOCの表記が違ってやりづらい場合はどうぞお試しください。
まずここからスタートします。

公式DOC通りのインストールを行いました。
DNSサーバーを選択するときに画面が出てきますがAdd Featuresします。
もう一つ出てきましたがContinueしました。
インストールが完了したらCloseします。

DNS概要

ここから設定に入っていくので、DNSについて少し私なりの解釈をば。

• DNSは、ドメイン名をIPアドレスに変換（名前解決）する仕組みの名前である。
• ドメイン名の個数は一個のサーバーで管理するには多すぎるので、「IPアドレスとドメイン名の対応の情報」を複数のサーバーに分散して持たせている。
• 「IPアドレスとドメイン名の対応の情報」を抜け漏れなく、かつ探しやすいように、それらのサーバーは階層的に設定されている。
• 例えば、全世界からある住所に住む人の名前を知りたいときに、国＞県＞市＞町村と階層を下っていくのと同じように、広い範囲から狭い範囲に向けて、情報の管理を下位のサーバーに委任している。
• したがって名前解決には、「IPアドレスとドメイン名の対応の情報」のほかに「その対応を知っているサーバーの位置情報」が重要になる。
• なお「IPアドレスとドメイン名の対応の情報」のほかに「その対応を知っているサーバーの位置情報」を管理するサーバーを「権威サーバー」、権威サーバーに実際に聞きに行くサーバーを「フルリゾルバー」または「キャッシュDNSサーバー」と呼ぶ。
  図はここを参照してください。

DNSサーバーの構成

ここからまた公式DOCに戻って設定をします。

インターフェイスの構成

DNSサーバーはデフォルトのままでは、どこからの要求でも応答します。これでは、悪意のある人から大量に嫌がらせの要求が来てもこのDNSサーバーは健気に応答を返しパンクしてしまいます。検証用でも、外部からの要求はシャットアウトしてしまいましょう。
まずここからスタート
DNSマネジャー画面を開いて、プロパティからIPアドレスを制限します。

補足１

DNSマネジャーには、スタートメニューからでなくとも行けます。私は性格上、説明書通りの手順でやらないといけないのかと思ってしまうんですが、まったくそんなことはありません。サーバーマネジャーから、DNSサーバーを選んで右クリック、プロパティで同じ画面が開けます。

補足２

先ほどのインストール作業をすべてGUIでやれば問題はありませんでしたが、インストールのみpowershellでやった場合、公式DOCのコマンドでは管理ツールがインストールされないようです。するとDNSサーバーの構成を、公式DOCの手順通りにはできなくなります。Install0WindowsFeature DNS -IncludeManagementToolsとする必要があります。この記事が参考になりました。

ルートヒントの構成

公式DOCで書いているのは、「このDNSサーバーが、自分の持っているIPアドレスードメイン名の対応情報（ホストゾーン）と、最近名前解決したことがあって記憶した対応情報（キャッシュ）の両方を探しても名前解決ができないとき、ほかのサーバーに聞きに行く必要があるがそのサーバーをルートヒントサーバーといいます」ということだと思います。ルートヒントは設定された状態でインストールされるようですが、もし自分で指定したいときは設定できるということですね。今回は触りません。

フォワーダーの構成

フォワーダーはフルリゾルバー（実際にIPアドレスを探しに行くサーバー）に「名前解決をお願いします」と頼みに行く役割を持ちます。DNSの利用者からみるとフォワーダーが名前解決しているように見えます。

上の画像の赤枠で囲んだ部分が、ルートヒントの説明と全く同じやないかと感じますが、「ルートヒントサーバー行く前にフォワーダーもいるで～」って感じなんでしょうか。
とりあえずgoogleの8.8.8.8を登録しておきます。

とりあえずここまでで公式DOCに書かれた設定は終了です。続いては「IPアドレスとドメイン名の対応の情報」を登録する作業です。

ゾーン情報の設定

ゾーン情報とは「IPアドレスとドメイン名の対応の情報」その他、権威サーバーが持つ情報の全体です。
DNSマネジャーのActionタブからNewZoneで追加です。

ウィザードが開きますが、ほとんどデフォルトのままでNextです。
ここで適当なドメイン名を付けて登録します。「test.com」です。

終了すると、DNSマネジャーのForward Lookup Zonesに新しいファイルができました。ここから設定できます。

WEBサーバーの名前解決をしたいので、その情報を書きます。ドメイン名はなんでもいいんですが、DNSの本質としては宛先を覚えやすいということなのでわかりやすいものにします。そして、WEBサーバーのプライベートIPアドレスを登録します。

以上で最小限の構成が終了しました。

実際に名前解決してみる

設定をした仮想マシンローカル（要するにDNSServerと名前を付けたマシン）で名前解決をしてみます。パワーシェルを起動します（Windowsキー＋Rを押してから「powershell」と入力しエンター）。

プライベートネットワークの名前解決

自分の仮想ネットワーク内での名前解決を行います。nslookup webserver.test.com localhostで名前解決させるサーバー指定のコマンドと、nslookup wevserver.test.comと指定なしで比べます。localhostでは、先ほど設定したDNSサーバーが利用されるはずです。
結果は↓

前者のコマンドでは時間がかかったものの、先ほど登録したアドレスが返りました。
後者のコマンドでは、168.63.129.16というサーバーが利用されたようです。その結果、webserver.test.comというドメイン名は本当に適当に作りましたが、インターネット上ではすでに正式に登録されており、69.167.164.199というIPアドレスを持っていることがわかりました。当然ですが、自前のDNSサーバーはこのアドレスのことを知らないので、登録された10.0.0.4を返したことになります。完全にプライベートな名前解決です。
ちなみに168.63.129.16というサーバーはAzureから名前解決すると利用されるサーバーであり、Azureはこういうものなのでしょう。深入りしません。

インターネットの名前解決

それでは、google.comの名前要求をさせてみましょう。先ほどと同様に、localhost指定と非指定で使い分けます。localhost（自分で作ったDNSサーバー）はgoogle.comを知りませんがどうなるでしょうか。

非指定ではAzure独自のサーバーが利用され、142.251.42.174と名前解決されました。ところがlocalhost指定では解決に失敗しました。個人的にはforwarderに設定した8.8.8.8を利用してもらいたかったのですが、、、。
8.8.8.8とのやり取りができない理由を考えるとネットワークセキュリティグループの受信規則でDNSが許可されていませんでした。それで結果が返ってこなかったのでしょう。
設定しなおす（ポート53、UDPの受信を許可）と、名前解決できました。でも１回目でIPv6だけが返っているのはどうしてだろう・・・ここは今回深入りしません。
google.comはいくつものIPアドレスに紐づいていることも今回でわかりました。サーバーは何台あるんでしょうね。
なお、セキュリティグループの設定ですが、許可するソースIPアドレスを8.8.8.8に設定すると名前解決できませんでしたが、8.8.0.0/16とすると成功しました。
今回は長くなりましたがこれで終了です。お疲れさまでした。