はじめに
「Linuxサーバー構築標準教科書 (Ver.4.0.1)」に基づく構築シリーズの第3回です。
今回はネットワークの土台となる「DNS（Domain Name System）」をBINDを用いて構築し、名前解決ができる環境を整えます。
1. 構築図
VirtualBox の Host-Only Network（192.168.56.0/24）上に
3台の BIND（named）サーバを配置した DNS 検証環境を示しています。
各サーバは enp0s8（Host-Only）で相互通信を行い、
DNS（UDP/TCP 53）および ICMP（ping）による疎通確認を実施しています。
外部通信は enp0s3（NAT）を利用し、DNS サービスは firewalld により許可しています。
jp ゾーンを管理する上位の権威 DNS（host0.jp）から、
example1.jp および example2.jp の各ゾーンを
それぞれの権威 DNS（host1.example1.jp / host2.example2.jp）へ
委任（NS レコードによるゾーン委任）している構成です。
ドメイン単位で DNS 管理を分離しています。
2. 構築環境と使用ソフトウェア
- 仮想マシン構成: VirtualBox 上に 3 台の仮想マシンを構築
- OS: AlmaLinux 9.7 (x86_64)
- DNSソフトウェア: BIND 9.16 (named)
- セキュリティ構成: bind-chroot を導入
- ネットワーク: NAT（外部通信用）＋ ホストオンリーアダプタ（内部通信用）の複数 NIC 構成
3. DNSサーバ構築のポイント
① セキュリティのためのchroot化
LinuCレベル2の範囲でもあるchroot機能を利用しました。これはBINDプロセスがアクセスできるディレクトリを /var/named/chroot 以下に制限する仕組みです。万が一、BINDの脆弱性を突かれた際も、システム全体への被害を最小限に抑えることができます。
要するに侵入を防ぐ仕組みではなく、侵入された後の被害を限定するための設計 です。
② 設定ファイルの構成
/etc/named.conf を編集し、以下の設定を行いました。
- listen-on: 自身のIP（192.168.56.101等）で問い合わせを待ち受け。
-
allow-query: 学習環境のため
any（すべて許可）に設定。 -
recursion: コンテンツサーバとしての動作を優先するため
noに設定（上位サーバのみyes）。
③ ゾーンファイルの作成
example1.jp.zone ファイルを作成し、SOAレコード、NSレコード、およびWeb/メールサーバ用のAレコードを定義しました。
ゾーンファイルは、権威DNSサーバが名前解決の根拠として参照する設定ファイルです。後述する dig コマンドによる名前解決結果の根拠となる情報を定義しています。
4. 名前解決の確認
構築後、dig コマンドを用いて名前解決が正しく行えるかを確認しました。
ホストの名前解決（Aレコード）の確認
$ dig host1.example1.jp
# 192.168.56.101が表示されれば成功
# host1.example1.jp が 192.168.56.101 に解決されることを確認
ネームサーバの情報（NSレコード）の確認
$ dig example1.jp ns
# host1.example1.jp が表示されれば成功
# example1.jp の管理を行う権威 DNS が host1.example1.jp であることを確認
メールサーバの情報（MXレコード）の確認
$ dig example1.jp mx
# mail.example1.jp が表示されれば成功
# example1.jp のMX が mail.example1.jp であることを確認
mail.example1.jpに対してdigコマンドを使用
$ dig mail.example1.jp
# mail.example1.jp が 192.168.56.101 に解決されることを確認
これらの確認を各サーバ（host0,host2）でも行います。
5. pingによる疎通確認
DNS サーバを構築しているため、疎通確認は IP アドレスではなく
ホスト名を指定して ping を実行し、名前解決を含めた確認を行いました。
※ 各サーバの /etc/resolv.conf には、上位DNSまたは自身を設定しています。
host1 → host0.jp
$ ping -c 3 host0.jp
host1 → host2.example2.jp
$ ping -c 3 host2.example2.jp
これらの確認を各サーバ（host0,host2）でも行います。
6. トラブル：片方向のみpingが成功する
構築中、サーバ間の疎通確認（ping）において、一方向の疎通は成功するが、逆方向が失敗するという事象に遭遇しました。
【事象】
- host1 → host2：ping 成功
- host2 → host1：ping 失敗（Destination Host Unreachable）
【原因：インターフェースへのIP付与ミス】
調査の結果、一方のサーバでホストオンリーアダプタ（内部通信用NIC）ではなく、NAT（外部通信用NIC）に対して内部用IPを割り当ててしまっていたことが判明しました。
複数NIC構成の場合、OS上では enp0s3 や enp0s8 といった複数のインターフェース名が表示されますが、これを見誤ったまま設定したのが原因です。
【解決策】
-
ip aコマンドで各NICのMACアドレスとVirtualBoxの設定画面を照らし合わせ、正しいインターフェースを特定。 - 設定画面にて、適切なインターフェースに固定IPを再設定。
- サーバ間での双方向疎通を確認。
7. まとめと学び
- NICの識別: 複数のネットワークアダプタを使用する場合、
ip aによる物理（仮想）構成の確認を怠ると、通信ができないこと - chrootの重要性: 重要なインフラサービスを構築する際、機能の実現だけでなく、セキュリティ（ディレクトリの隔離）をセットで考える実務の視点を得られました。
DNSが完成したことで、サーバ同士が名前で呼び合えるようになりました。
次回は、このDNS環境を前提とした「Postfixによる複数ドメイン間メール配送」の検証を行います。
参考文献