unboundをキャッシュリゾルバに本番導入しDNSSEC検証とフォワード設定を有効化する

なぜ今unbound か――キャッシュリゾルバ選定の現場判断

DNSキャッシュリゾルバの選択肢として、多くの運用者は dnsmasq や systemd-resolved を使い続けています。しかし、DNSSEC検証をフルスタックで処理しつつ、アップストリームへのフォワードと再帰解決を柔軟に切り替えたい場合、unboundは依然として最も成熟した選択肢です。

unboundはNLnet Labsが開発するOSSのキャッシュ/再帰リゾルバで、RFC準拠のDNSSEC検証を自前で完結させられます。systemd-resolvedはスタブリゾルバに留まり、DNSSEC検証はアップストリームへの委譲が前提です。dnsmasqはLAN向けの軽量設計でDNSSECの実装が限定的です。小規模なオフィスLANから数百台規模のサーバ環境まで、「信頼できる検証をローカルで完結させたい」要件ではunboundの採用事例が増えています。

本記事では、Debian/Ubuntu系・RHEL/Rocky系を対象に、unboundを本番環境へ導入し、DNSSEC検証とフォワード設定を有効化するまでの一連の手順を、切り戻し手順や2026年時点の注意点も含めて解説します。

インストールとサービス起動――systemd連携の基本

パッケージインストールはディストリビューションのリポジトリから行います。2026年時点では、Debian 12（Bookworm）で 1.19系、Ubuntu 24.04 LTSで 1.19〜1.20系、Rocky Linux 9 で 1.16系がそれぞれ提供されています。DNSSEC検証に使うトラストアンカーの自動更新機能（unbound-anchor）は1.6以降に含まれているため、いずれのバージョンでも動作します。

Debian/Ubuntu系では apt install unbound、RHEL/Rocky系では dnf install unbound でインストールします。インストール直後にsystemdユニット unbound.service が登録されますが、まだ起動せずに設定を先に整えるのが安全です。

設定ファイルは /etc/unbound/unbound.conf が主エントリポイントで、多くのディストリビューションでは /etc/unbound/unbound.conf.d/ 配下に分割ファイルを置く慣習になっています。本番では機能単位に分割することで、後からのレビューや差分管理が容易になります。

DNSSEC検証の有効化――トラストアンカーと検証ポリシー

DNSSECはDNS応答の改ざんを検出するための署名検証の仕組みです。unboundはルートゾーンのトラストアンカー（KSK: Key Signing Key）を保持し、応答を検証します。このアンカーファイルはRFC 5011に基づき自動的にロールオーバーを追跡します。

設定ファイルに以下のブロックを追加します。ファイル名は /etc/unbound/unbound.conf.d/dnssec.conf として分離するのが管理上おすすめです。

server:
    # トラストアンカーファイル（unbound-anchorで自動生成・更新）
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

    # DNSSEC検証失敗時にSERVFAILを返す（デフォルト有効だが明示推奨）
    val-permissive-mode: no

    # 鍵ロールオーバーの猶予期間（秒）。デフォルト172800（2日）
    val-sig-skew-max: 86400
    val-sig-skew-min: -3600

トラストアンカーファイルの初期生成は unbound-anchor -a /var/lib/unbound/root.key コマンドで行います。このコマンドはIANAのサーバへアクセスしてルートKSKを取得するため、初回実行時はインターネット接続が必要です。エアギャップ環境や閉域網では、あらかじめ取得済みのアンカーファイルを配布する運用設計が必要です。

Debian/Ubuntu系では unbound-anchor がインストール時にdpkg管理の仕組みで自動実行されます。RHEL/Rocky系では手動実行か、unbound-anchor.service（ディストリビューションによっては別パッケージ）を有効化して対応します。

検証モードは本番では val-permissive-mode: no（デフォルト）を維持してください。permissiveモードはDNSSEC検証の失敗を無視してそのまま応答を返すため、セキュリティ上の意味が失われます。段階的に展開する際のステージング期間だけ一時的に使う目的に限定すべきです。

DNSSEC検証の例外設定――ネガティブキャッシュとinsecureドメイン

社内ドメインや一部レガシードメインでDNSSEC署名が設定されていない場合、domain-insecure ディレクティブで検証対象から除外できます。社内向けゾーンを例外扱いにすることは、本番導入フェーズではよくある現実解です。ただし除外範囲は最小限にとどめ、理由とともにコメントに残しておくことが後から見た際の混乱を防ぎます。

server:
    # 社内ゾーンはDNSSEC非署名のため検証対象外
    domain-insecure: "internal.example.local"

フォワード設定――アップストリームリゾルバへの委譲とDNS over TLS

フォワードモードを設定すると、unboundは再帰解決を自身で行わず、指定したアップストリームリゾルバへクエリを転送します。閉域網や企業プロキシ環境では再帰解決が許可されていないケースが多く、フォワード設定が事実上の必須要件になります。

2026年時点では、パブリックリゾルバへの転送にDNS over TLS（DoT）を使うことが標準的になっています。unbound 1.7以降でDoTフォワードがサポートされており、現行のどのディストリビューションパッケージでも利用できます。

forward-zone:
    name: "."
    # DoTを使用してアップストリームへ転送（例: Cloudflare 1.1.1.1）
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com

    # DNSSEC検証を維持しつつフォワード（重要）
    forward-first: no

ここで注意が必要なのは forward-first の扱いです。yes にするとフォワード失敗時に再帰解決にフォールバックしますが、DoTが使えないネットワーク環境でポート853が遮断されていた場合に平文UDP/TCPにフォールバックするリスクがあります。セキュリティポリシーを優先するなら no のままにして、フォワード失敗はSERVFAILとして扱うべきです。

フォワードとDNSSEC検証を組み合わせる場合、アップストリームがDNSSEC対応していることが前提になります。アップストリームがDNSSEC非対応の場合は、unboundが検証に必要なRRSIGやDSレコードを受け取れず、正当なドメインでもSERVFAILが多発します。Cloudflare（1.1.1.1）、Google（8.8.8.8）、Quad9（9.9.9.9）はいずれもDNSSEC対応済みです。

ローカルゾーンとフォワードの優先順位

社内ゾーンだけを内部DNSサーバへ転送し、それ以外はパブリックリゾルバへ向ける構成も、forward-zone を複数定義することで実現できます。ゾーン名の長いものが優先されるため、社内ドメインを先に定義し、ワイルドカードにあたる "." を最後に置きます。

forward-zone:
    name: "internal.example.local"
    forward-addr: 192.168.1.53

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com

起動・検証フロー――設定確認からDNSSECテストまで

設定ファイルを書いたら、起動前に構文チェックを行います。unbound-checkconf /etc/unbound/unbound.conf はエラーがあれば行番号付きでレポートします。CIパイプラインやAnsibleのpre-taskに組み込むことで、設定ミスによるサービス断を防げます。

サービス起動は systemctl enable --now unbound で行います。起動後すぐに systemctl status unbound でActiveステータスと起動ログを確認してください。active (running) にならない場合は journalctl -u unbound --no-pager -n 50 でエラーを拾います。よくあるエラーはポート53の競合（systemd-resolved がスタブで53を使用中）とパーミッション不足です。

DNSSEC検証の動作確認には dig コマンドが便利です。以下の点を確認します。

• dig @127.0.0.1 dnssec-failed.org: DNSSEC署名が意図的に壊れたテストドメイン。SERVFAILが返れば検証が機能しています。
• dig @127.0.0.1 iana.org +dnssec: 正常署名済みドメイン。応答のフラグに ad（Authenticated Data）が立っていれば検証成功です。
• dig @127.0.0.1 . NS +dnssec: ルートゾーンのNSレコード。adフラグとRRSIGの有無を確認します。

フォワード設定の確認は unbound-control lookup example.com コマンドで転送先の情報を表示できます。unbound-control stats_noreset でキャッシュヒット率や検証カウンタも確認でき、本番監視のベースラインに活用できます。

切り戻し計画と運用上の注意点――2026年環境での差分も含めて

本番導入時に備えておきたい切り戻し手順は次のとおりです。

• クライアントのDNS設定（resolv.conf やsystemd-resolvedのDNS=）は段階的に切り替え、一部ホストでのみunboundを向けた状態でテスト期間を設けます。
• 切り戻しは systemctl stop unbound ののち、クライアントのresolv.confを元の設定に戻すか、systemd-resolvedを再有効化します。
• 設定ファイルはgitで管理し、変更前のタグを付けておくことで即時ロールバックが可能です。

systemd-resolved との共存は現在も多くの環境で課題になっています。Ubuntu 22.04以降やDebian 12では、systemd-resolved がデフォルトで127.0.0.53:53をリッスンしており、unboundとポートが競合します。対応策として、systemd-resolved をスタブモードのみに制限（/etc/systemd/resolved.conf の DNSStubListener=no）してからunboundを起動する方法が標準的です。resolv.confは /etc/resolv.conf を nameserver 127.0.0.1 を指すファイルに置き換えます。

Rocky Linux 9 / AlmaLinux 9 環境では、firewalldがデフォルトで有効なため、ローカルネットワークからのポート53アクセスを許可するルールを追加する必要があります。firewall-cmd --add-service=dns --permanent && firewall-cmd --reload が必要になるケースが多いです。

2026年時点でのもう一つの差分はルートKSKのロールオーバー追跡です。2018年のKSKロールオーバー以降、次のロールオーバー計画についてIANAから継続的に情報が発信されています。auto-trust-anchor-file を使い、unboundのバージョンを最新に維持することがロールオーバーへの最良の備えです。長期間アップデートを怠った環境では、古いKSKを信頼している可能性があり、ロールオーバー後に全ドメインがSERVFAILになるリスクがあります。定期的な unbound-anchor -v による検証と、バージョン管理の自動化が運用上の必須事項です。

DNS over HTTPSをフォワード先に使いたいケースでは、unbound単体ではDoHクライアント機能を持たないため、dnscrypt-proxy や cloudflared との組み合わせが現実解です。unboundはDoTフォワードまでをカバーし、DoHが必要な閉域網では中間プロキシと連携する設計が増えています。

unboundをキャッシュリゾルバとして正しく設定することで、DNSの信頼性とセキュリティを組織のインフラレイヤーで自律的に確保できます。DNSSEC検証の有効化はセットアップ時の追加コストは小さく、改ざん検出の恩恵は大きいため、新規導入のタイミングで合わせて有効化することが現在のベストプラクティスとなっています。