とことこロゴス
DNSSEC
DNSのデータにデジタル署名を付け、検証によってデータの出自と完全性を確かめるためのDNSの拡張仕様。
イマシルちゃんの解説
Webサイトを開くときは、ドメイン名からIPアドレスを調べるDNSが使われるよ。
この情報を偽られると、別のサイトへ誘導されるおそれがあるんだ。
DNSSECは、DNSのデータの出所と改ざんの有無を確かめられるようにする拡張仕様だよ。
ドメインを管理する側が、データに管理者だけが持つ秘密鍵で作ったデジタル署名を付けるんだ。
検証するDNSサーバは、信頼できる公開鍵という検証用の鍵で署名を確かめるよ。
署名が正しく検証できれば、その管理者のデータが途中で書き換えられずに届いたと確認できるんだ。
この解説はわかりやすかったですか？
より深い解説
定義
DNSSEC（DNS Security Extensions）は、RFC 4033〜4035などで定められた、DNSの拡張である。権威DNSサーバが自分のゾーンのリソースレコードにデジタル署名を付け、フルサービスリゾルバがそれを公開鍵で検証する。これにより、次の2つを確かめられる。
| 確かめられること | 意味 |
|---|---|
| 送信者の正当性（出自の認証） | 応答が、そのゾーンの正しい管理者のデータであること |
| データの完全性 | 応答の内容が途中で改ざんされていないこと |
DNSSECは、問合せや応答の内容を暗号化するものではない。通信の盗聴を防ぎたいときは、DNS over TLSやDNS over HTTPSを使う。
追加されるリソースレコード
| レコード | 内容 |
|---|---|
| RRSIG | リソースレコードの集まりに付けたデジタル署名 |
| DNSKEY | 署名の検証に使う公開鍵 |
| DS | 子のゾーンの鍵のハッシュ値。親のゾーンに登録する |
| NSEC / NSEC3 | 「その名前は存在しない」ことを、署名付きで証明する |
信頼の連鎖
子のゾーンの公開鍵（DNSKEY）が正しいことは、親のゾーンに登録された、署名付きのDSレコードで確かめる。親の公開鍵はさらにその親で確かめる、とたどり、最後はルートゾーンの公開鍵にたどり着く。検証するフルサービスリゾルバは、ルートゾーンの公開鍵を信頼の起点（トラストアンカー）としてあらかじめ持っている。
鍵には、ゾーンのデータに署名する鍵（ZSK）と、その鍵に署名する鍵（KSK）の2種類を使い分けることが多い。
防げる攻撃
フルサービスリゾルバに偽の応答を覚えさせるキャッシュポイズニングを防げる。偽の応答には正しい署名を付けられないため、検証で見破られる。
DNSに関係するほかの仕組みとの違い
| 仕組み | 目的 |
|---|---|
| DNSSEC | 応答の正当性と完全性の検証（デジタル署名） |
| TSIG | 共通鍵とハッシュ関数で、ゾーン転送や動的更新の要求の送り手を認証する |
| セカンダリDNSサーバ | 権威DNSサーバを冗長化して、名前解決の可用性を高める |
| 再帰的問合せの範囲の制限 | オープンリゾルバにしないための設定 |
取引単位の認証との使い分け
TSIGは、事前に共有した秘密を使い、個々のDNSメッセージの送り手と内容を確かめる仕組みである。RFC 8945で定義され、HMACなどによるメッセージ認証符号を用いる。ゾーン転送や動的更新など、相手を限定したやり取りに適している。
| 観点 | DNSSEC | TSIG |
|---|---|---|
| 主に保護する対象 | DNSのレコード集合の出自と完全性 | 通信当事者間のDNSメッセージ |
| 鍵の使い方 | 秘密鍵で署名し、公開鍵で検証する | 当事者が共有する秘密を使う |
| 利用例 | キャッシュを介して受け取った応答の検証 | 動的更新要求やゾーン転送の認証 |
どちらも、それだけでDNSの内容を暗号化するわけではない。また、TSIGによる認証が成功しても、どのゾーンのどの更新を許可するかは別途設定する。認証と権限の制御を区別する必要がある。