「とりあえず動く」ではなく「理解して動かす」
こんにちは！「リナックス先生」です。
BIND9講座、第2回へようこそ。
前回はDNSの壮大な仕組みについてお話ししましたが、今回からはいよいよ実践編です。
黒い画面（ターミナル）を開いて、実際にBIND9をインストールし、DNSサーバーとして命を吹き込みます。
ネット上には「この設定をコピペすれば動くよ」という記事がたくさんあります。
しかし、プロのエンジニアとして言わせていただくと、DNS設定のコピペは自殺行為です。
一行の意味を知らずに設定すると、気づかないうちに世界中に迷惑をかける「踏み台サーバー（オープンリゾルバ）」を作り出してしまう危険性があるからです。
今回は、あえてデフォルトの設定ファイルを一度空にして、「自分たちが理解できる行だけを書く」というアプローチで構築します。
遠回りに見えるかもしれませんが、これが最短で最強のサーバーを作る近道ですよ！
先生、ドキドキしてきました。
DNSの設定ファイルって、カッコ { } とかセミコロン ; がいっぱいで、一つでも間違えると動かないって聞きました。
僕、タイピングミスには自信があるんですけど…（汗）
ふふ、だからこそ「最小限」から始めるのよ。
最初から100行もある設定ファイルを見るから嫌になるの。
たった10行程度なら、ミスしてもすぐ気づけるでしょ？
プロが使う「構文チェックコマンド」も教えるから安心してついてらっしゃい！
1. BIND9のインストール
まずはソフトウェアを入れなければ始まりません。
AlmaLinux 9 では、非常に簡単に最新の安定版を入手できます。
1-1. パッケージのインストール
以下のコマンドを実行します。bind が本体、bind-utils はテストに使う便利な道具箱（digコマンドなど）です。
sudo dnf install bind bind-utils -y
【プロの補足：bind-chrootは入れるべき？】
古い解説記事を見ると bind-chroot というパッケージを入れていることがよくあります。
これは、BINDが乗っ取られた時に被害を最小限にするため、専用の監獄（chroot環境）に閉じ込めて動かすためのものです。
しかし、AlmaLinux 9（RHEL 9）では、OS標準のセキュリティ機能であるSELinuxが強力にBINDを守ってくれるため、設定が複雑になるchrootは必須ではなくなりました。
本講座では、ディレクトリ構成をシンプルに保ち、ミスを防ぐためにchrootは使いません。
1-2. インストール確認
無事にインストールされたか、バージョンを確認してみましょう。
named -v
▼実行結果例
BIND 9.16.23-RH (Extended Support Version)
このようにバージョンが表示されればOKです。
2. 設定ファイルの「断捨離」
インストール直後の設定ファイルを確認してみましょう。
場所は /etc/named.conf です。
sudo cat /etc/named.conf
見ると分かりますが、英語のコメントや複雑な設定がびっしりと書かれています。
これを初心者が編集して「どこを間違えたか分からない」となるのが典型的な失敗パターンです。
2-1. バックアップを取る
まずは、オリジナルのファイルを別名で保存しておきます。
これはサーバーエンジニアの基本動作です。
sudo cp /etc/named.conf /etc/named.conf.org
2-2. ファイルを空にする
思い切って、設定の中身を空っぽにします。
自分の手で、意味の分かる行だけを積み上げていくためです。
sudo truncate -s 0 /etc/named.conf
これで、真っ白なキャンバスが用意できました。
3. 【実践】named.conf の作成（キャッシュサーバー編）
ここからが本番です。
まずは、社内や自宅内のPCからの問い合わせに答える「キャッシュサーバー」としての設定を書きます。
お好みのエディタ（vi, nanoなど）で /etc/named.conf を開き、以下の内容を記述してください。
※IPアドレス部分は、あなたの環境に合わせて書き換えてください。
sudo vi /etc/named.conf
▼記述する内容（完全版）
# ACL定義: 「身内」の範囲を定義します
acl internal-network {
127.0.0.1;
192.168.1.0/24; # あなたのLANのネットワークアドレスに合わせて変更！
};
options {
# 待ち受け設定
listen-on port 53 { 127.0.0.1; 192.168.1.10; }; # サーバー自身のIP
listen-on-v6 { none; }; # 今回はIPv6は無効化
# データの保存場所
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
# 【重要】アクセス制御
allow-query { internal-network; }; # 身内からのみ質問を受け付ける
recursion yes; # 再帰問い合わせ（代わりに調べる機能）を許可
# パフォーマンスとセキュリティ設定
dnssec-validation yes; # DNSSEC（改ざん検知）を有効化
empty-zones-enable yes; # 空のゾーンを自動生成してノイズを減らす
};
# ログ設定（今回はデフォルトに近い設定）
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
# ルートヒント（インターネットの根っこの情報）を読み込む
zone "." IN {
type hint;
file "named.ca";
};
これだけで動きます。
それぞれの行が何をしているのか、プロの視点で深掘り解説しましょう。
解説①：ACL（アクセスコントロールリスト）
acl internal-network { ... };
ここで「誰を信頼するか」というグループを作っています。
IPアドレスを直接あちこちに書くよりも、こうしてグループ名を付けて管理する方が、後でネットワーク構成が変わった時に楽ができます。192.168.1.0/24 の部分は、ご自身の環境（VPSならVPN経由のIPなど、自宅ならルーターのセグメント）に合わせてください。
解説②：listen-on（誰の声を聞くか）
listen-on port 53 { 127.0.0.1; 192.168.1.10; };
BINDが耳を傾けるIPアドレス（自分自身のアドレス）です。
デフォルトでは 127.0.0.1 だけになっていることが多く、外部から繋がらない原因になります。
サーバー自身のLAN側IPアドレス（例：192.168.1.10）を追記するのを忘れないでください。
解説③：【最重要】allow-query と recursion
ここがセキュリティの要です。
- allow-query: 「誰からの質問に答えるか」です。先ほど作った
internal-network（身内）だけを指定します。ここをany（誰でも）にしてしまうと、世界中から攻撃の踏み台にされます。 - recursion yes: 「再帰問い合わせ（＝知らないことを代わりに調べてあげる機能）」をONにします。キャッシュサーバーには必須の設定です。
＜オープンリゾルバの恐怖＞
もし allow-query { any; }; かつ recursion yes; に設定してインターネットに公開すると、あなたのサーバーは悪意ある攻撃者に利用され、他人のサーバーを攻撃する「DDoS攻撃の加害者」になってしまいます。
これをオープンリゾルバと呼びます。絶対に避けてください。
4. 構文チェックとFirewalld設定
設定ファイルを書いたら、起動する前に必ず「テスト」を行います。
いきなり再起動してエラーで落ちるのはカッコ悪いですからね。
4-1. named-checkconf コマンド
BINDには、設定ファイルのミスをチェックしてくれる専用コマンドがあります。
sudo named-checkconf
実行結果：
何も表示されなければ合格です！
もしミスがあれば、/etc/named.conf:10: missing semicolon（10行目にセミコロンがないよ）のように教えてくれます。
4-2. FirewalldでDNSの穴を開ける
Firewalld講座のおさらいです。
DNSは UDPの53番（通常通信）と TCPの53番（大きなデータ転送用）の両方を使います。
# 現在のゾーンを確認（基本はpublic） sudo firewall-cmd --add-service=dns --permanent sudo firewall-cmd --reload
※VPSなどでグローバルに公開されている場合、public ゾーンでDNSを開放すると外部からアクセスできてしまいます。
厳密に運用するなら、Firewalldの「リッチルール」を使って、接続元のIPアドレスを制限する（自分の自宅や会社のIPからだけ許可する）のがベストプラクティスです。
5. サービスの起動と動作確認
準備は整いました。BINDを起動しましょう。
5-1. 起動と自動起動設定
sudo systemctl enable --now named
状態を確認します。
systemctl status named
緑色の文字で Active: active (running) と表示されれば成功です！
もし赤文字で failed と出たら、journalctl -xe コマンドでログの最後を見て、エラー原因（スペルミスなど）を探ります。
5-2. digコマンドで問い合わせテスト
最後に、ちゃんと「DNSサーバーとして仕事をしているか」を確認します。bind-utils に入っている dig コマンドを使います。
自分自身（127.0.0.1）に対して、google.com のIPアドレスを聞いてみましょう。
dig @127.0.0.1 google.com
▼実行結果の読み方（重要な部分だけ抜粋）
; <<>> DiG 9.16.23-RH <<>> @127.0.0.1 google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; ANSWER SECTION: google.com. 300 IN A 142.250.196.14 ;; Query time: 45 msec ;; SERVER: 127.0.0.1#53(127.0.0.1)
- status: NOERROR → 成功！もし
SERVFAILなら失敗、NXDOMAINならドメインが存在しません。 - flags: ... ra →
ra(Recursion Available) があれば、再帰問い合わせ（代わりに調べてくる機能）が有効になっています。 - ANSWER SECTION →
142.250.196.14という答えが返ってきています。 - SERVER: 127.0.0.1 → ちゃんと自分のサーバーが答えてくれました。
おめでとうございます！
これであなたのサーバーは、インターネット上のドメインを解決できる「フルサービス・リゾルバ（キャッシュサーバー）」になりました。
6. プロのテクニック：フォワーダーの活用
最後に一つ、実務でよく使うテクニックを紹介します。
現在の設定だと、あなたのサーバーは毎回インターネットのルートサーバーまで問い合わせに行きます。
これは真面目ですが、少し時間がかかります。
そこで、「自分では調べず、プロバイダのDNSやGoogleのDNS(8.8.8.8)に丸投げして、答えだけもらう」という設定（フォワーダー）を使うと、高速化できる場合があります。
▼named.conf の options 内に追記
forwarders {
8.8.8.8;
8.8.4.4;
};
forward only; # 自分では調べに行かない
社内LAN用のDNSサーバーなどでは、この設定を入れておくことで、インターネット回線の負荷を減らしつつ高速なレスポンスを実現できます。
おおー！ dig コマンドで答えが返ってきたとき、ちょっと感動しました！
自分で作ったサーバーが Google の住所を教えてくれるなんて。
設定ファイルも、自分で書いたから何をしてるか分かります！
まとめ：まずは「調べる機能」が完成
第2回では、BIND9のインストールから、キャッシュサーバーとしての基本動作までを構築しました。
- 設定ファイルはコピペせず、最小限から書くのがトラブル回避のコツ。
allow-queryとrecursionの設定ミスはセキュリティ事故の元。- 必ず
named-checkconfで構文チェックをする癖をつける。 digコマンドはDNSエンジニアの聴診器。結果を読めるようにしておく。
今はまだ「他人のドメイン（Googleなど）」を調べているだけですが、次回（第3回）は、いよいよ「自分だけのドメイン」をこのサーバーに登録し、LAN内の機器を名前で呼べるようにする「内部向け権威サーバー」へと進化させます。
「IPアドレスを覚えなくていい生活」まであと一歩です。お楽しみに！
▼今回の構築環境におすすめのVPS
BIND9の設定を安全に試すには、自由に再インストールができ、固定IPが使えるVPSが最適です。学習用としてコストパフォーマンス抜群のAlmaLinux 9対応VPSはこちら。
コメント