2.3セキュアなDNSサーバーの実現

DNS はキャッシュ汚染や応答偽装など、古くから狙われてきたサービスです。プロセスの被害範囲を絞る基盤面の対策（chroot・forwarders 限定）と、応答の真正性を保証するプロトコル面の対策（DNSSEC・TSIG・DANE）の両輪で理解します。

2.3.1プロセスと転送先の制限

• chroot 環境＝named プロセスが見えるファイルシステムを限定したルート配下だけに制限する。侵害されても実際の /etc 等へ到達できず、被害範囲を局所化できる。
• forwarders＝再帰問い合わせを転送する先サーバーを named.conf の forwarders { } で明示的に限定する。無制限にどこへでも再帰させないことで、意図しない外部応答やキャッシュ汚染のリスクを抑える。

2.3.2DNSSECとTSIG・DANE

• DNSSEC＝ゾーンデータに電子署名を付け、応答が改ざんされていないことをリゾルバ側で検証できるようにする仕組み。鍵生成はdnssec-keygen、ゾーンへの署名はdnssec-signzoneで行う。
• TSIG（Transaction SIGnature）＝ゾーン転送や動的更新などサーバー間通信を共有鍵で認証・完全性保護する仕組み。DNSSEC がゾーンデータそのものの署名なのに対し、TSIG は通信メッセージ単位の保護。
• DANE（DNS-based Authentication of Named Entities）＝TLS証明書の情報を DNS（TLSA レコード）に載せ、DNSSEC で保護された経路を通じて証明書の正当性を補強する仕組み。

堅牢化は「壊れても被害を抑える層」と「そもそも偽物を見抜く層」を組み合わせて考えると整理できます。まず基盤面では、named をchroot配下（例 /var/named/chroot/）で稼働させることで、脆弱性が突かれても実ファイルシステムへの到達を防ぎます。あわせて named.conf の forwarders { 192.0.2.53; }; のようにforwardersを信頼できる社内・上流サーバーだけに絞り、任意の外部への再帰を許さない構成にします。次にプロトコル面では、ゾーンへの署名フローが定番です。dnssec-keygenでゾーン署名鍵（ZSK）と鍵署名鍵（KSK）を生成し、dnssec-signzoneでゾーンファイルに署名を付与すると、DNSKEY・RRSIG・NSEC 等のレコードが追加されたゾーンファイルが生成されます。これによりリゾルバは応答の署名を検証し、経路上の改ざん（キャッシュ汚染含む）を検出できます。プライマリ・セカンダリ間のゾーン転送や動的更新にはTSIGの共有鍵を設定し、正当なサーバーからの通信であることをメッセージ単位で確認します。さらに公開鍵基盤の証明書をDANE（TLSAレコード）でDNSに紐づけておけば、DNSSECで保護された経路を通じて証明書が正規の発行元のものであることを補強でき、認証局の信頼だけに依存しない多層防御になります。

2.3.3この節のまとめ

• 基盤対策＝chroot（到達範囲の局所化）／forwarders 限定（再帰転送先の制限）
• DNSSEC＝ゾーン署名検証（dnssec-keygen→dnssec-signzone）／TSIG＝サーバー間通信の鍵認証／DANE＝DNSSEC経由で証明書を補強