内容

DNSSECのレコード検証、公開鍵検証の仕組みとRoute53での運用方法について記載します。手順通りにやれば導入は簡単に出来るものの、導入時のDSレコードの登録、運用時のキーローテションなど仕組みを理解しないと何をやっているか分からない箇所もあると思うので図解化しました。

DNSSECの仕組み（レコード検証の仕組み）

上記図はPC（クライアント）からwww.example.comというレコードをキャッシュDNSサーバに問い合わせ。キャッシュDNSサーバから権威DNSサーバにレコードを問い合わせて得られたレコードをPC（クライアント）に返す流れの図です。

①レコードに電子署名

AレコードA=1.1.1.1に電子署名を追加して返すのがDNSSECです。下記を権威DNSサーバ側で実施します。まず、公開鍵DNSSECKEY、秘密鍵ZSKのキーペアを作成します。次にハッシュ関数を使用してAレコードA=1.1.1.1のハッシュ値123456を取得した後、秘密鍵ZSKで暗号化して電子署名PRSIG=XXXを作成します。クライアントからレコードの問い合わせがあった際は、A=1.1.1.1に電子署名PRSIG=XXX、公開鍵DNSSECKEYを付与してクライアントに応答として返します。

②レコードの電子署名の検証

クライアントは①のレコードを受け取り後、下記２つの値を取得して、値が一致していればレコードが改竄されておらず正しい相手から届いたデータであることを確認出来ます。

A=1.1.1.1に電子署名①と同様のハッシュ関数を使用してハッシュ値123456を取得をする
電子署名PRSIG=XXXを公開鍵DNSSECKEYで復号してハッシュ値123456を取得する

DNSSECの仕組み（公開鍵の検証）

DNSSECの仕組み（レコード検証の仕組み）の箇所で公開鍵が出てきましたが、この公開鍵の正当性を保証する必要があります。署名に使用する鍵は2階層になっていて、上記で出てきたZSKの他にZSKに署名するKSKという秘密鍵が出てきます。このKSKに対する公開鍵DNSSEK(KSK）の正当性が保証できればKSKに対する公開鍵DNSSEK(ZSK）の正当性も保証できるような流れになります。手順としてはまずハッシュ関数でDNSSEK(KSK）のハッシュ値を取得してDSレコードを作成します。このDSレコードを上位ドメイン側に登録してもらうことによって上位ドメインによって公開鍵の正当性が保証される仕組みになります。

Route53でのDNNSEC運用

DNSSECの導入

詳しい手順は割愛させて頂きますが、導入についてはKMSを使用してキーペアを作成、DNS署名の有効化、DSレコードの登録といった流れです。DSレコード登録についてはレジストラーによって対応状況や方法は異なります。

DNSSECの運用

定期的に鍵の更新をする場合、ZSK側のキーローテションはAWS側で実施してくれますが、KSK側のキーローテションについてはユーザ側で実施する必要があります。KSKのキーローテションの際はDSレコードの更新などあるため、普通にやると更新のタイムラグが発生して使用出来ない時間が発生してしまいます。double-signature法というタイムラグなしでキーローテションする方法があり、下記AWSブログでも紹介されています。