Unbound をインストールする手順｜パッケージ導入から最小設定・DNSSEC 検証・動作確認まで

Unbound は、OS の標準パッケージで入れ、待ち受けアドレスと問い合わせを許可する範囲だけを書いた小さな設定から始めるのが手堅い進め方です。DNSSEC の検証は初期状態で働くようになっていることが多いため、余計な設定を足すより「何が既定で有効か」を確かめることのほうが大切です。この記事では、Debian・Ubuntu 系と RHEL 系での導入、最小構成の unbound.conf、起動前の検査、DNSSEC を含む動作確認、つまずきやすい点を順に説明します。

インストールの前に決めておくこと

作業の前に、次の3点を決めておくと設定で迷いません。

• 用途：Unbound はキャッシュ（再帰）DNS サーバーです。自分のドメインを外部に公開する権威 DNS としては、NSD や Knot DNS などと組み合わせるのが一般的です。社内や自宅の端末が使う名前解決サーバーとして入れる前提で進めます。
• 待ち受けるアドレス：サーバー自身だけが使うなら 127.0.0.1、社内の端末にも使わせるなら社内側のインターフェースのアドレスです。インターネット側のアドレスで待ち受ける必要は通常ありません。
• 問い合わせを許可する範囲：社内ネットワークの CIDR です。ここを広く取りすぎると、誰でも使える再帰サーバー（オープンリゾルバー）になり、攻撃の踏み台にされるおそれがあります。

本番のサーバーにいきなり入れるのではなく、検証用の仮想マシンで一度手順を通しておくと、OS ごとの差を事前に把握できます。

パッケージでインストールする

多くの環境では、ソースからビルドするより OS のパッケージを使うほうが、セキュリティ更新を apt や dnf の通常の更新で受け取れるため管理が楽です。

# Debian・Ubuntu 系
sudo apt update
sudo apt install unbound

# RHEL・AlmaLinux・Rocky Linux 系
sudo dnf install unbound

# 入ったバージョンと、組み込まれた機能を確認する
unbound -V

unbound -V では、バージョンのほか、DNSSEC の検証に使う暗号ライブラリや、DNS over TLS などの対応状況が表示されます。ディストリビューションによって収録されているバージョンは異なり、新しい機能の一部は古いパッケージでは使えません（2026年10月現在）。ネット上の設定例を使う前に、自分のバージョンで使える項目かどうかを公式ドキュメントの unbound.conf の説明で確かめてください。

Debian・Ubuntu 系では、インストール直後にサービスが起動しようとします。後述する 53番ポートの競合で起動に失敗していても、インストール自体は完了しているので、設定を整えてから起動し直せば問題ありません。

最小構成の設定を書く

設定ファイルは /etc/unbound/unbound.conf です。Debian・Ubuntu 系では、この中で /etc/unbound/unbound.conf.d/ 以下の .conf を読み込む形になっているため、自分の設定は別ファイルにまとめると、パッケージ更新時の差分が見やすくなります。RHEL 系では unbound.conf 自体に多くの設定が書かれているので、既存の記述を確認してから追記します。

# /etc/unbound/unbound.conf.d/local.conf（Debian・Ubuntu 系の例）
server:
    # 待ち受けるアドレス（サーバー自身と社内側のアドレス）
    interface: 127.0.0.1
    interface: 192.168.10.53

    # 問い合わせを許可する範囲。書いていない送信元は拒否される
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.10.0/24 allow

    # バージョンやホスト名を問い合わせで答えない
    hide-identity: yes
    hide-version: yes

    # ログの詳しさ（1 が通常運用の目安）
    verbosity: 1

access-control を書かなかった場合、Unbound はローカルホスト以外からの問い合わせを拒否します。社内の端末に使わせるには、許可する範囲を明示する必要があります。IPv6 でも待ち受ける場合は、IPv6 のアドレスと許可範囲も忘れずに書き足してください。

ルートサーバーの一覧は Unbound に組み込まれているため、最初のうちは root-hints を指定しなくても動きます。上流の DNS サーバーに転送したい場合は forward-zone を追加しますが、まずは転送なしで、Unbound 自身がルートから順にたどる構成で動作を確認すると、問題の切り分けがしやすくなります。

DNSSEC の検証が有効かを確かめる

DNSSEC の検証には、ルートゾーンの信頼の起点（トラストアンカー）が必要です。Unbound は auto-trust-anchor-file に指定したファイルでこれを保持し、鍵の更新に自動で追従します。

Debian・Ubuntu 系のパッケージでは、この設定が /etc/unbound/unbound.conf.d/ 内の別ファイルにあらかじめ用意されていることが多く、RHEL 系でも既定の unbound.conf に書かれていることがあります。すでに設定されているのに自分の設定ファイルにも同じ行を足すと、二重の指定になって混乱のもとになります。追記する前に、次のように既存の指定を探してください。

sudo grep -rn "trust-anchor" /etc/unbound/

指定が見つからない場合は、unbound-anchor コマンドでトラストアンカーのファイルを作成し、そのパスを auto-trust-anchor-file に書きます。ファイルは Unbound の実行ユーザーが書き込める場所に置く必要があります。

起動前に検査して起動する

設定を書いたら、起動する前に unbound-checkconf で文法を検査します。誤りがあると、行番号付きでエラーが表示されます。

sudo unbound-checkconf
# 問題がなければ「no errors in /etc/unbound/unbound.conf」と表示される

sudo systemctl enable --now unbound
sudo systemctl status unbound

起動に失敗したときは、journalctl -u unbound -n 50 で直近のログを確認します。エラーの文言から原因を絞り込むのが近道です。

動作を確認する

サーバー自身から、次の順に確認します。

# 1. 名前解決ができるか（status: NOERROR と答えが返る）
dig @127.0.0.1 www.example.com

# 2. DNSSEC の検証が働いているか（flags に ad が付く）
dig @127.0.0.1 example.com +dnssec

# 3. 署名が壊れたドメインを拒否するか（status: SERVFAIL になれば検証が働いている）
dig @127.0.0.1 dnssec-failed.org

3つ目は、検証の失敗を確かめるために意図的に署名を壊して公開されているドメインです（こうした確認用ドメインは公開をやめることもあるため、結果がおかしいときは別の確認用ドメインでも試してください）。ここで答えが返ってくる場合は、検証が無効になっているか、トラストアンカーが読み込まれていません。

続けて、許可した範囲の端末から dig @192.168.10.53 www.example.com で答えが返ること、許可していない端末からは status: REFUSED になることを確かめます。端末側の DNS サーバー設定を Unbound に向けるのは、ここまで確認できてからにします。

つまずきやすい点と確認方法

53番ポートがほかのプロセスに使われている

Ubuntu などでは、systemd-resolved が 127.0.0.53 の 53番ポートで待ち受けています。Unbound を 0.0.0.0 で待ち受けさせようとすると、ポートの競合で起動できないことがあります。sudo ss -lunpt | grep ':53 ' で、53番ポートを使っているプロセスを確認してください。

対処は、Unbound の interface を具体的なアドレスに限定するか、systemd-resolved の設定（/etc/systemd/resolved.conf の DNSStubListener）でスタブの待ち受けを止めるかのどちらかです。後者を選ぶとサーバー自身の名前解決の経路も変わるため、/etc/resolv.conf の向き先もあわせて見直します。

待ち受けアドレスがまだ存在しない

起動時にネットワークの準備が終わっていないと、interface に書いたアドレスで待ち受けられずに失敗することがあります。手動で起動し直すと動く場合はこれが原因です。systemd のユニットでネットワークの準備完了を待つ設定にするか、ip-freebind: yes で、まだ存在しないアドレスでも待ち受けを始められるようにします。

ファイアウォールで止まっている

ローカルでは答えるのに社内の端末から届かない場合は、ファイアウォールを確認します。DNS は UDP だけでなく TCP の 53番も使うため、両方を許可します。許可する送信元は、access-control と同じ社内の範囲に絞ってください。

運用を始める前にしておくこと

• 設定ファイルを変更する前に、元のファイルをコピーしておきます。
• 設定の変更後は毎回 unbound-checkconf を実行してから反映します。
• unbound-control を使えるようにしておくと、キャッシュの確認や統計の取得ができます。パッケージによっては鍵の作成が自動で行われ、そうでない場合は unbound-control-setup で作成します。
• セキュリティ更新が出たら速やかに適用できるよう、OS の自動更新や通知の仕組みに Unbound も含めておきます。

まとめ

• Unbound は OS のパッケージで入れ、unbound -V でバージョンと機能を確認します。
• 最初は interface と access-control だけの小さな設定で始め、許可範囲を広げすぎないようにします。
• DNSSEC のトラストアンカーはパッケージで設定済みのことが多いため、追記する前に既存の指定を探します。
• 起動前に unbound-checkconf、起動後に dig で名前解決・ad フラグ・SERVFAIL の3点を確認します。
• 起動できないときは、53番ポートの競合、アドレスの準備、ファイアウォールの順に確認します。

• Unbound の再起動方法
• Unbound のACL設定方法