「その答え、本当に本物ですか？」
こんにちは！「リナックス先生」です。
BIND9講座、いよいよ大詰めとなる第10回です。
突然ですが、あなたは「DNSキャッシュポイズニング」という攻撃を知っていますか？
攻撃者がDNSサーバーを騙して、「google.com のIPはこれだよ」と偽のIPアドレス（偽サイト）を教え込ませる攻撃です。
もしこれを受けると、ユーザーが正しいURLを入力しても、見た目がそっくりな偽サイトに誘導され、IDやパスワードを盗まれてしまいます。
これを防ぐ唯一の技術が「DNSSEC（Domain Name System Security Extensions）」です。
DNSの応答に「電子署名（ハンコ）」を押すことで、「これは間違いなく本物のサーバーが回答した情報です」と証明する技術です。
昔はこのDNSSECの導入が非常に難しく、多くのエンジニアが挫折してきました。
しかし、時代は変わりました。BIND9の最新機能を使えば、面倒な作業はすべて自動化できます。
今回は、最新かつ最強の「自動署名」環境を構築しましょう！
先生、DNSSECって先輩が「絶対に手を出すな、運用で死ぬぞ」って言ってました…。
鍵を作ったり、有効期限が切れる前に更新したり、とにかく手順が複雑でミスるとドメインごと消えるって。
僕なんかがやって大丈夫なんですか？
先輩の言っていることは「昔の話」よ。
AlmaLinux 9 に入っている BIND 9.16 からは、「dnssec-policy」という魔法の機能が使えるの。
これを設定すれば、鍵の作成も、更新（ロールオーバー）も、署名も、全部BINDが勝手にやってくれるわ。
私たちは「DNSSECやるよ！」と宣言するだけ。簡単すぎて拍子抜けするわよ！
1. DNSSECの仕組み（ざっくり理解）
設定を自動化するとはいえ、何が起きているかを知らないとトラブルに対処できません。
最低限の仕組みをイメージで掴んでおきましょう。
1-1. 暗号化ではなく「署名」
SSL/TLS（HTTPS）と違い、DNSSECは通信の中身を暗号化するわけではありません。
誰でも読めるデータに対して、「改ざんされていないことを証明するハンコ（デジタル署名）」を付ける技術です。
1-2. 2つの鍵（KSKとZSK）
DNSSECでは、セキュリティ強度と処理速度のバランスを取るために、2種類の鍵を使います。
- ZSK (Zone Signing Key):
普段のレコード（Aレコードなど）に署名するための鍵。「認印」のようなもので、頻繁に交換（ロールオーバー）します。 - KSK (Key Signing Key):
ZSK自体に署名するための鍵。「実印」のようなもので、ZSKが偽物でないことを保証します。交換頻度は低めです。
昔は、この2つの鍵を手動コマンドで作って、カレンダーを見ながら「そろそろZSKの更新日だ…」と作業する必要がありました。
これが「運用で死ぬ」と言われた理由です。
1-3. 信頼の連鎖（Chain of Trust）
「自分の署名が正しいこと」を誰に証明してもらうか？
それは「上位のドメイン（親）」です。kou-house.lan なら .lan（実際にはルートなど）に、自分の鍵の指紋（DSレコード）を登録してもらうことで、信頼の連鎖が繋がります。
2. 導入前の準備（絶対に忘れてはいけないこと）
DNSSECを導入する前に、必ず確認すべき2つのポイントがあります。
ここを怠ると、導入した瞬間にDNSが止まります。
① 時刻同期（NTP）は完璧か？
電子署名には「有効期限」があります。
サーバーの時刻がズレていると、「この署名はまだ有効期間前だ」「もう期限切れだ」と判定され、すべての名前解決がエラーになります。chronyd が正常に動いているか、必ず確認してください。
chronyc sources
② パケットサイズ（EDNS0）とファイアウォール
DNSSECのパケットは、署名データが付くため非常に大きくなります（通常の512バイトを超える）。
Firewalldの設定は済んでいますが、もし経路上のルーターやファイアウォールで「大きなUDPパケット」や「IPフラグメント」を破棄する設定になっていると、通信できません。
3. 【実践】named.conf で自動署名を有効化する
それでは、いよいよ設定です。
今回は、最も運用が楽な「インライン署名（Inline Signing）」方式を採用します。
インライン署名とは？
人間が管理する「テキストのゾーンファイル（kou-house.lan.db）」はそのまま触らず、BINDがメモリ上で勝手に署名を付け足して配信してくれる機能です。
元のファイルが汚れないので、管理が非常に楽です。
3-1. dnssec-policy の定義
まず、/etc/named.conf を開き、どのようなポリシーで鍵を管理するかを定義します。options { ... }; のブロックの後ろあたりに追記してください。
sudo vi /etc/named.conf
BIND 9.16以降には、最初から default というポリシーが組み込まれていますが、学習のために明示的に書いてみます。
# DNSSECポリシーの定義
dnssec-policy "my-policy" {
keys {
# KSK (実印): ECDSAP256SHA256という軽いアルゴリズムを使用
ksk lifetime 365d algorithm ECDSAP256SHA256;
# ZSK (認印): 60日で交換
zsk lifetime 60d algorithm ECDSAP256SHA256;
};
};
3-2. ゾーン定義への適用
次に、署名したいゾーン（ここでは kou-house.lan）の設定ブロックに3行追加します。
※View機能を使っている場合は、view "internal" などの内部に記述してください。
zone "kou-house.lan" IN {
type master;
file "kou-house.lan.db";
# --- ここから追加 ---
# 1. 署名ポリシーを指定 (これで鍵作成から更新まで全自動！)
dnssec-policy "my-policy";
# 2. インライン署名を有効化 (元のファイルを汚さない)
inline-signing yes;
# --------------------
};
たったこれだけです。dnssec-enable yes; や dnssec-validation yes; は options にデフォルトで入っているはずですが、念のため確認しておいてください。
3-3. 権限設定（ハマりポイント）
BINDは鍵ファイル（.key や .private）を生成して保存する必要があります。
ゾーンファイルがあるディレクトリ（/var/named/）に、named ユーザーの書き込み権限が必要です。
# ディレクトリの権限を確認・変更 sudo chown named:named /var/named sudo chmod 770 /var/named
※セキュリティ上 /var/named 全体を書き込み可にするのを嫌う場合は、サブディレクトリ（例: /var/named/dynamic/）を作り、ゾーンファイルをそこに移動してパスを書き換えるのがプロの作法です。
4. 反映と鍵生成の確認
設定ミスのないようチェックしてから再起動します。
sudo named-checkconf sudo systemctl restart named
鍵が生成されたか見る
ディレクトリを見てみましょう。
ls -l /var/named/
成功していれば、以下のようなファイルが自動生成されているはずです。
Kkou-house.lan.+013+....key(公開鍵)Kkou-house.lan.+013+....private(秘密鍵)kou-house.lan.db.signed(署名済みゾーンデータ)kou-house.lan.db.jbk(ジャーナルファイル)
これらが勝手に出来ていれば、BINDが裏で一生懸命仕事をしてくれた証拠です。
5. 動作検証：署名はついているか？
dig コマンドを使って、本当にDNSSEC署名が付与されているか確認します。+dnssec オプションを付けます。
dig @127.0.0.1 ns1.kou-house.lan +dnssec
▼実行結果の注目ポイント
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; ANSWER SECTION: ns1.kou-house.lan. 86400 IN A 192.168.1.10 ns1.kou-house.lan. 86400 IN RRSIG A 13 3 86400 20260215... (署名データ)
ANSWERセクションに、Aレコードだけでなく RRSIG（Resource Record Signature） というレコードが増えていれば成功です！
これが「電子署名（ハンコ）」の実体です。
鍵情報の確認
DNSKEY（公開鍵）も見れるか確認しましょう。
dig @127.0.0.1 kou-house.lan DNSKEY +dnssec
長い文字列のレコードが返ってくれば、鍵も正常に公開されています。
6. 「信頼の連鎖」の課題（実務への橋渡し）
さて、これであなたのサーバーは「署名付き」で答えるようになりました。
しかし、これだけでは完全ではありません。
世界中のPC（リゾルバ）は、まだあなたの署名を「本物」だと信じてくれません。
なぜなら、上位のドメイン（今回なら .lan）に「この鍵を信じてやってくれ」という紹介状（DSレコード）を提出していないからです。
実務（.comなどを取得した場合）の手順
もしあなたが example.com をお名前.comなどで取得して運用する場合は、以下の手順が必要です。
- BINDが自動生成したDSレコードを確認する。
dig @127.0.0.1 kou-house.lan CDS +short - 表示されたDSレコードの値をコピーする。
- ドメイン登録業者（レジストラ）の管理画面にログインし、「DNSSEC設定」の項目にそのDSレコードを貼り付ける。
これで上位ドメイン（.com）と紐付き、世界中から「正当な署名」として検証されるようになります。
今回はローカルドメイン（.lan）なのでこの手順はできませんが、「親への登録が必要」ということだけ覚えておいてください。
7. 運用時の注意点：ゾーンファイルの修正方法
inline-signing yes; を設定した場合、ゾーンファイルの修正方法が少し変わります。
NGな方法：vi kou-house.lan.db で編集して、そのまま放置。
OKな方法：
1. vi kou-house.lan.db で編集する（シリアル番号を上げるのを忘れずに！）。
2. rndc reload を実行する。
BINDは、元のテキストファイルの更新日時をチェックし、変更があれば自動的に再読み込みして再署名を行ってくれます。
手動署名の時代のように dnssec-signzone コマンドを打つ必要はありません。
先生、本当に簡単でした…！dnssec-policy を書いただけで、ディレクトリに鍵ファイルが勝手に増えて、dig で見たらものすごい長い署名データが付いてて。
「裏で小人が必死にハンコを押してる」と思うと、BINDが可愛く見えてきました。
まとめ：DNSSECはもはや「標準装備」
第10回では、かつて最難関だったDNSSECを自動化ツールで攻略しました。
- DNSSECは「キャッシュポイズニング」を防ぐための電子署名技術。
- BIND 9.16以降の dnssec-policy を使えば、鍵管理は全自動になる。
- inline-signing を使うことで、元のゾーンファイルを汚さずに運用できる。
- 時刻ズレ（NTP）とパケットサイズ（Firewall）には要注意。
これでセキュリティ対策も含め、DNSサーバーとしての機能は完成しました。
次回（第11回）は、さらに一歩進んで、これからの時代に必須となる「IPv6」への完全対応と、大量のアクセスをさばくための「パフォーマンス・チューニング」について解説します。
「とりあえずIPv6は無効化」なんてもう言わせない！ プロフェッショナルな設定を目指しましょう。
▼DNSSEC運用を試せるVPS
DNSSECの鍵管理や、上位レジストラへのDSレコード登録をシミュレーションするには、自由に設定できるサーバーが必要です。学習用としておすすめのVPSはこちら。
コメント