2.1BINDの設定と管理

名前解決はほぼすべてのネットワークサービスの前提です。BIND（Berkeley Internet Name Domain・実行プロセス名 named）は最も普及した DNS サーバー実装で、L2 では構成ファイルの構造と問い合わせ・運用コマンドを正確に扱えるかが問われます。

2.1.1named.confの構造

• named.conf＝BIND の中核設定。options { } で全体の既定動作（リッスンアドレス・再帰許可・転送先など）を定義し、zone "example.com" { type master; file "..."; }; のようにゾーンごとのステートメントを並べる。
• ゾーンの type には主に master（正・自ゾーンの原本を保持）・slave（副・master からゾーン転送で複製）・forward（自身では答えず指定サーバーへ転送のみ）がある。
• 文法・記述ミスの検査はnamed-checkconfで行う（起動前に確認する習慣が事故を防ぐ）。反映は設定変更後に rndc reload 等で行う。

2.1.2問い合わせと運用コマンド

• dig＝最も詳細な問い合わせツール。dig @ns1.example.com www.example.com A のように問い合わせ先サーバー・名前・レコード種別を明示でき、ANSWER SECTION・AUTHORITY SECTION まで表示するためトラブルシュートの主力。
• host＝簡易な名前解決確認（host www.example.com）。nslookup＝対話/非対話の両対応の伝統的ツール。いずれも dig より出力は簡素。
• rndc＝稼働中の named をリモート制御（rndc reload＝設定再読込・rndc reload zone＝特定ゾーンのみ・rndc flush＝キャッシュ破棄・rndc status）。named を止めずに反映できるのが利点。

実運用のシナリオで整理すると理解が定着します。社内向けにゾーン example.com を新設master サーバーとして立てる場合、named.conf に zone "example.com" { type master; file "/var/named/example.com.zone"; }; を追記し、まずnamed-checkconfで構文エラーが無いことを確認、その後 rndc reload で稼働中の named に反映します。副サーバー（slave）側は同じゾーン名で type slave; masters { 192.0.2.1; }; のようにmaster のIPアドレスを指定し、初回起動時にゾーン転送でデータを取得します。問い合わせが返ってこないトラブルでは、digでどのサーバーに聞いているか（@ オプション）を切り替えながら、権威サーバーが正しいレコードを返すか・再帰的にキャッシュサーバー経由で解決できているかを順に切り分けます。小規模・組み込み用途ではdnsmasq（軽量DNS＋DHCP）、キャッシュ専用の再帰リゾルバとしてUnbound、権威サーバーの高速・シンプル実装としてNSD、DBバックエンド運用に強いPowerDNSというように、要件に応じてBIND以外の実装が選ばれる場面もあります。

2.1.3この節のまとめ

• named.conf の zone type＝master（正）／slave（副・ゾーン転送で複製）／forward（転送のみ）
• named-checkconf＝構文検査／rndc＝無停止の運用制御／dig＝詳細な問い合わせ。軽量代替＝dnsmasq・Unbound・NSD・PowerDNS