# DNSSEC Intro

## DNSSEC 概要

公開鍵暗号方式と電子署名を利用して、ゾーンデータや権限委譲の妥当性を向上させるためのもの。

## 動作

### 鍵について

各サーバでは **ZSK** と **KSK** の 2 つの鍵を利用する。

1. ZSK (Zone Signing Key) ゾーン署名鍵 ZSK は、各ゾーン(もといレコード)に署名する際に用いられる\
   ZSK に対応する公開鍵が DNSKEY レコードとして公開されるので、交換が必要となる\
   ZSK の更新を比較的頻繁に行うことにより、鍵を解析される危険を減らすことができる
2. KSK (Key Signing Key) 鍵署名鍵 KSK は、ゾーン署名鍵 ZSK を署名するもの

それぞれの鍵は DNSKEY レコードにて公開される。

#### ZSK 詳細

Private ZSK を利用して、それぞれの RRSet を署名する。\
署名されたものは RRSIG レコードとして公開される。\
そして、もし名前解決要求があった場合は、権威サーバはそのタイプの RRSIG を添えて返す。\
RRSIG は、「これらのレコードは僕のもので、僕のサーバから公開されてますよ」という感じに保証するためのもの。\
公開鍵 (DNSKEY レコード) を参照して、完全性を確認する。

つまり、 RRset と RRSIG と DNSKEY から、正しいレコードを検証できる。

<figure><img src="https://424990375-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdLe1PxI1aH2CKpQEpGDv%2Fuploads%2FyC90oIL7Dwt8I80lzaNk%2Fzsk2.jpg?alt=media&#x26;token=0766092b-1cd7-4a7b-bbd8-14f8361176a4" alt=""><figcaption></figcaption></figure>

Q. そもそも DNSKEY を信用できるの？どうすれば安全にできる？\
A. KSK をつかう。

#### KSK 詳細

ZSK を検証するために、 KSK で鍵を署名する。\
Public KSK も、 ZSK 同様 DNSKEY レコードとして公開される。\
Private KSK は、 Public ZSK と Public KSK 両方を含む DNSKEY レコードに署名する。

<figure><img src="https://424990375-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdLe1PxI1aH2CKpQEpGDv%2Fuploads%2FVEgOiaG5EPgfxoJJhm2u%2Fksk.jpg?alt=media&#x26;token=b34b74f2-a315-45f5-9d8a-15cf0477eb16" alt=""><figcaption></figcaption></figure>

#### 鍵の使い方

1. リゾルバが名前解決を要求
2. RRset と共にそのタイプに対する RRSIG が返される
3. リゾルバは RRSIG を検証するために DNSKEY (ZSK and KSK) を要求する
4. DNSKEY を返す際も、 DNSKEY に対する RRSIG が返される
5. Public ZSK を使って、 RRset に対する RRSIG を検証する
6. Public KSK を使って、 DNSKEY に対する RRSIG を検証する (つまり ZSK を検証する)

### 信頼の連鎖

ゾーンの情報が正しいとしても、 Delegation が正しいかがわからない。\
NS は署名されてても、それを正しいと言っているのはそのゾーンであり、上位ゾーンからの委任については確認できない。\
そこで、 DS レコードにより信頼の連鎖を行う。

#### DS レコード

下位ゾーンの DNSKEY (KSK;flag257) レコードのハッシュ値を、上位ゾーンに置かせてもらう。

<https://tools.ietf.org/html/rfc4035#section-2.4>

Q. なぜハッシュ値を使うの？\
A. KSK は鍵が大きいのでコスト削減のため

Q. これにより信頼の連鎖を構築できるの？\
A. DS 自体は公開された情報のみで生成できるが、上位ゾーンがその DS に対して署名して RRSIG を公開することで上位ゾーンが信頼性を担保する\
委任されている下位ゾーンの検証ができてから、上位ゾーンの DS に登録するという流れがあるみたい\
よく考えてみれば、下位ゾーンから上位ゾーンへの情報の受け渡しの信頼性がなければ、 NS の信頼性もなくなるし、レジストリの信頼性も無くなってしまうので、そこまでは考慮しなくても良いという感じだろうか

### 鍵交換

ゾーンの更新があるたびに親ゾーンに DS を再登録するとなると、更新の負荷が高まるが、このように鍵を二つに分ける運用をすることで、 KSK の更新があったときにのみ、親ゾーンに DS を再登録すればよくなる。\
KSK の更新は、長くとも 1～2 年程度の間隔で行うことが推奨されている(らしい)。

## 参考情報

* <https://www.nic.ad.jp/ja/newsletter/No43/0800.html>
* <https://www.cloudflare.com/dns/dnssec/how-dnssec-works/>
* <https://www.nic.ad.jp/ja/materials/iw/2010/proceedings/s10/iw2010-s10-01.pdf>
* <https://www.cloudflare.com/dns/dnssec/how-dnssec-works/>
