現場の課題：/etc/hosts運用の限界
ホームラボや社内ネットワークで仮想マシン、コンテナ、スイッチなどが20〜30台規模になると、192.168.1.45のような静的IPアドレスを都度手入力するのは非常に手間がかかります。手っ取り早い回避策として、各端末の/etc/hostsファイルに直接記述して済ませるケースも多いでしょう。しかし、この方法はデバイスが5台未満の場合にしか通用しません。それを超えると、K8sノードやGitLabサーバーのIPアドレスが変わるたびに、何十台もの端末のhostsファイルを手作業で同期する不毛な作業に追われることになります。
この問題を根本から解決する最もクリーンなアプローチは、専用のローカルDNSサーバーを構築することです。Fedora Serverは最新のカーネルと迅速なパッケージアップデートを備えており、検証・ラボインフラとして非常に適した選択肢です。そしてFedoraと組み合わせるDNSサーバーといえば、デファクトスタンダードであるBIND9（namedデーモン）が依然として最適です。軽量かつ堅牢で、ドキュメントも豊富に揃っています。
最大の関門となるのは、Enforcing（強制）モードで稼働するSELinuxです。コンテキストのラベル付けを誤ったり、グループ権限を間違えたりすると、BINDは明確なエラーログを出力せずにゾーンファイルの読み込みを拒否してしまいます。本ガイドでは、SELinuxを無効化することなく、セキュリティ標準に則った堅牢なDNS環境を構築する手順を解説します。
ローカルDNSを構成する3つの基本要素
設定ファイルを記述する前に、まず以下の3つの概念を整理しておきましょう。
- 正引きゾーン（Forward Lookup Zone）：ホスト名（FQDN）からIPアドレスを解決します。例：
gitlab.lab.localへの問い合わせに対して192.168.1.50を返します。 - 逆引きゾーン（Reverse Lookup Zone）：
PTRレコードを使用して、IPアドレスからホスト名を逆引きします。集中ログのデバッグやSSH接続元の確認、ネットワーク監視ツールによる誤検知の防止において極めて重要です。 - フォワーダー（Forwarders）：
github.comなどインターネット上のドメインに対して、内部DNSサーバーはルートサーバーへ直接問い合わせを行いません。Cloudflare（1.1.1.1）やGoogle（8.8.8.8）といった上位のDNSサーバーへクエリを転送します。解決結果はキャッシュされるため、2回目以降の問い合わせではレイテンシが35msから2ms未満へと劇的に短縮されます。
Fedora ServerでのBIND設定手順
本記事では、以下のラボ環境のパラメータを前提として進めます。
- Fedora DNSサーバーのIP：
192.168.1.10 - 内部ドメイン：
lab.local - サブネット：
192.168.1.0/24
ステップ1：BINDとbind-utilsのインストール
BIND本体と、名前解決の検証ツール（dig、nslookup、named-checkconfなど）を含むユーティリティパッケージをインストールします。
sudo dnf install -y bind bind-utils
ステップ2：メイン設定ファイル /etc/named.conf の編集
設定を変更する前に、必ず元のファイルのバックアップを取得してください。
sudo cp /etc/named.conf /etc/named.conf.orig
sudo nano /etc/named.conf
optionsブロックを探し、リッスン対象のIPアドレスとクエリ許可範囲を更新します。その後、ファイルの末尾に2つの新規ゾーン宣言を追加します。
options {
# localhostとサーバーの静的IPでポート53をリッスン
listen-on port 53 { 127.0.0.1; 192.168.1.10; };
listen-on-v6 port 53 { ::1; };
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";
secroots-file "/var/named/data/named.secroots";
recursing-file "/var/named/data/named.recursing";
# 192.168.1.0/24のクライアントからのDNSクエリを許可
allow-query { localhost; 192.168.1.0/24; };
# 外部インターネットへの名前解決のため再帰問い合わせを有効化
recursion yes;
# 外部クエリをCloudflareとGoogleへ転送
forwarders {
1.1.1.1;
8.8.8.8;
};
dnssec-validation yes;
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
# lab.local の正引きゾーン
zone "lab.local" IN {
type primary;
file "lab.local.zone";
allow-update { none; };
};
# 192.168.1.0/24 サブネットの逆引きゾーン
zone "1.168.192.in-addr.arpa" IN {
type primary;
file "192.168.1.rev";
allow-update { none; };
};
ステップ3：正引きおよび逆引きゾーンファイルの作成
/var/named/lab.local.zoneに正引きゾーンファイルを作成します。
sudo nano /var/named/lab.local.zone
SOA、NSレコード、および具体的なAレコードを定義します。
$TTL 86400
@ IN SOA ns1.lab.local. admin.lab.local. (
2026110601 ; シリアル番号: YYYYMMDDNN (ファイル編集ごとに増分)
3600 ; リフレッシュ (1時間)
1800 ; リトライ (30分)
604800 ; 有効期限 (1週間)
86400 ) ; 最小TTL (1日)
; 権威DNSサーバー
@ IN NS ns1.lab.local.
; ホスト識別レコード
ns1 IN A 192.168.1.10
router IN A 192.168.1.1
gitlab IN A 192.168.1.50
k8s IN A 192.168.1.60
続いて、/var/named/192.168.1.revに逆引きゾーンファイルを作成します。
sudo nano /var/named/192.168.1.rev
対応するPTRレコードを記述します。FQDNの末尾には必ずドット（.）を付与してください。ドットを省略すると、BINDによってベースドメインが自動的に付加されてしまいます。
$TTL 86400
@ IN SOA ns1.lab.local. admin.lab.local. (
2026110601 ; シリアル番号
3600
1800
604800
86400 )
@ IN NS ns1.lab.local.
; IPアドレスの最終オクテット (ホスト部)
10 IN PTR ns1.lab.local.
1 IN PTR router.lab.local.
50 IN PTR gitlab.lab.local.
60 IN PTR k8s.lab.local.
ステップ4：ファイル所有権とSELinuxコンテキストの設定
これはRHEL/Fedora系OSにおいて最も重要なステップです。namedデーモンは非特権サービスアカウントで実行されます。ゾーンファイルのセキュリティラベルが正しくない場合、SELinuxによってファイルの読み取りアクセスが即座にブロックされます。
# ファイルの所有グループをnamedに変更し、パーミッションを640に設定
sudo chown root:named /var/named/lab.local.zone /var/named/192.168.1.rev
sudo chmod 640 /var/named/lab.local.zone /var/named/192.168.1.rev
# システムポリシーに基づいてデフォルトのセキュリティラベルを復元
sudo restorecon -v /var/named/lab.local.zone
sudo restorecon -v /var/named/192.168.1.rev
ls -Z /var/named/コマンドでセキュリティコンテキストを確認します。有効なコンテキストとして、正しいタイプであるnamed_zone_tが表示されている必要があります。
ls -Z /var/named/lab.local.zone
# 期待される出力: system_u:object_r:named_zone_t:s0 /var/named/lab.local.zone
ステップ5：構文チェックとファイアウォールの設定
いきなりサービスを起動せず、構文チェックツールを実行してタイポや記述ミスを事前に検出します。
# 全体設定ファイルの検証 (何も出力されなければ正常)
sudo named-checkconf
# 各ゾーンファイルの構文チェック
sudo named-checkzone lab.local /var/named/lab.local.zone
sudo named-checkzone 1.168.192.in-addr.arpa /var/named/192.168.1.rev
両方のcheckzoneコマンドでステータスOKとシリアル番号が返ってきたら、サービスを有効化し、firewalldでポート53（UDPおよびTCP）を開放します。
# BINDサービスの起動および自動起動の有効化
sudo systemctl enable --now named
# ファイアウォールでDNSサービスを恒久的に開放
sudo firewall-cmd --add-service=dns --permanent
sudo firewall-cmd --reload
ステップ6：digコマンドによる名前解決の動作検証
LAN内の任意の端末またはサーバー自身から、digコマンドで192.168.1.10へ直接問い合わせて動作確認を行います。
# 1. 正引きの検証
dig @192.168.1.10 gitlab.lab.local +short
# 出力結果: 192.168.1.50
# 2. 逆引きの検証
dig @192.168.1.10 -x 192.168.1.50 +short
# 出力結果: gitlab.lab.local.
# 3. 外部インターネットの名前解決の検証
dig @192.168.1.10 fedoraproject.org +short
各コマンドで意図したIPアドレスが返り、ステータスフラグがNOERRORであれば、DNSサーバーは正常に稼働しています。
まとめ
Fedora Server上でのBIND構築では、適切なファイルパーミッションとSELinuxコンテキストの管理が不可欠です。しかし、一度正しく設定してしまえば、Enterprise Linux準拠の極めて堅牢で安定した基盤を手に入れることができます。自前のDNSサーバーが完成したら、ルーターのDHCP設定でプライマリDNSに192.168.1.10を指定するだけで完了です。以降、LANに参加するすべてのデバイスは、二度とhostsファイルを書き換えることなく、ドメイン名で内部サーバーへアクセスできるようになります。
