dnssec
2010年04月06日
前回は、DNSSECそのものの設定でした。今回は、それにDynamic Update(動的更新)の機能を組み込む。
DNSのDynamic Updateは、ホストが自分のホスト名とIPアドレスをDNSのゾーンに自動で登録することのできる機能である。
DHCPでIPアドレスを動的に割り当てられたホストのIPアドレスを、第三者が知ることは難しい。
当該ホストが起動時にIPアドレスを割り当てられた後、自分のホスト名とIPアドレスをDNSに申告し登録してもらえば、第三者はそのホスト名を頼りにIPアドレスを知ることが出来る。
ここでは、DNSSECで保護されているゾーンファイルにDynamic Updateを適用する方法をまとめる。
といっても、特別なことはなく、ゾーンレコードのupdateが起きるとDNSは自動でゾーンの再署名をやってくれる。
1.Dynamic update用の鍵の作成
dnssec-keygenコマンドで鍵ペアを作る。DNS Updateは、updateを申告する側とDNS側で同じ鍵を持つ事前共有鍵方式である。ここで作った鍵ペアの秘密鍵(.private)を使う。
|
Kdynamic1.+157+55555
と表示され、*.keyと*.privateの鍵ペアができる。
|
|
2.プライベート鍵の読み込み
named.confに*.privateファイルを登録する。
ここではdynamic1.privateというファイルを用意し、それをinclude文でnamed.confに読み込ませる。
|
|
3.named.confのゾーン定義ブロックに、updateを許可する行を追加する
|
4.namedの設定再読み込み
|
5.ファイルパーミッション
ゾーンファイルのパーミッションが、namedプロセスの実行IDで書き込み権があることを確認する。
また、公開鍵秘密鍵共に読込み権があるかも確認する。
6.テスト更新
テストスクリプトの用意
|
↑最後には必ず空の改行(行頭に改行)をいれておく。それがないとupdate queryが飛ばない。
updateの実施
(1)パターン1
|
(2)パターン2
|
パターン1と2では、与えている鍵は同じだが、記述形式が異なる。
パターン1の場合、Kddns.+157+55555.keyも存在しないといけない。
updateをするときTSIGは共有鍵方式の認証なので、公開鍵は使っていない(と思う)。 *.keyがなぜ必要かは、いまいち理解できていない。
自動的にSIG(0)を使っている?
7.更新の確認
更新がsuccessしたら、登録したホストがひけるか確認。
|
エラーなく、無事にAレコードがひけたら成功。
- ブログネタ:
- Linuxに関する運用 に参加中!
2010年04月01日
前回は、理論編でした。
今回は、実際の設定をみていく。
4.DNSSECの導入手順
(1)BINDの入手
BINDは、9.3系列でDNSECのDS方式をサポートしている。 最新版は、ISCからbind9.7をダウンロードする。
http://www.isc.org/software/bind/970-p1/download/bind-970-p1targz |
(2)インストール
DNSECを使うには、OpenSSLのライブラリを使用しているので、以下のパッケージを導入しておく。
- openSSL
- libssl-dev
(3)コンパイル
以下のように、上記のソースを展開しコンパイルする。
なおdigが +sigchase オプションを使えるように、シェルの環境変数に以下を設定しておく。
|
これで/usr/local/にバイナリがインストールされる。
5.DNSSECの設定手順
(1)設定環境
通常のDNSでは、ホストwww.beta.alphaのIPアドレスを検索するのに、以下の手順をとる。
- リゾルバはルートDNS にalphaのネームサーバ(NSレコード)を聞く。
- リゾルバは、alphaのネームサーバにbetaのネームサーバ(NS)を聞く
- リゾルバは、betaのネームサーバにwwwのホスト(A)を聞く
以下での設定例での登場人物は、以下。
- TLD相当のalphaゾーン権威サーバ
- その配下のbeta権威サーバ
- DNSSECを検証するキャッシュサーバ
今回ルートサーバは省略し、alphaとbetaとキャッシュサーバを作る。
alphaがbetaに権利委任する。 betaのゾーンに、wwwのAレコードがある。
また、キャッシュサーバはalphaのKSKを信頼し、事前に登録しておく。
この状況で、キャッシュサーバがwww.beta.alpha.を名前解決できれば成功である。
既に通常のDNS設定は終わっているとし、そこから変更点のみを以下に記述していく。
(2)alphaドメインのDNS
A)ZSK鍵ペアを作る
$ dnssec-keygen -r /dev/urandom -a NSEC3RSASHA1 -b 1024 -e -n zone alpha. |
- -rで疑似乱数を使っている。本番では/dev/randomを使うこと。その場合、作成時間が数十分かかる。
- -aでの暗号アルゴリズム指定は、NSEC3を使わなければRSASHA1でもよい。
B)KSK鍵ペアを作る
$ dnssec-keygen -r /dev/urandom -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE alpha. |
- -fオプションでKSKであるフラグをたてている。257となる。ちなみにZSKは256。
- -bで鍵のビット長を指定する。KSKはZSKに比べて更新手順が複雑であり、そのため長期間使用する。なので、ビット長は長めにとっておく。
C)鍵の確認
Kalpha.+007+11111.keyというファイルとKalpha.+007+22222.privateというファイルがそれぞれできる。+007は-aで指定したアルゴリズム番号。+11111は、鍵ID。
.keyファイルの中をみると、以下のような形式に成っている。
これが、そのままゾーンファイル内に記述するDNSKEYレコードである。 DNSKEYの次の数値が257ならKSK、256ならZSKと見分けられる。
alpha. IN DNSKEY 257 3 7 AwEAA..(omitted).....BgM= |
D)ゾーンファイルへの追記
KSKとZSKの*.keyファイルを、ゾーンファイルに追記する。
$INCLUDE Kalpha.+007+11111.key ;KSK |
E)ゾーンファイルのシリアル番号を上げる
この後の手順で、ゾーンファイルにZSKで電子署名をするが、その際、SOAレコードも対象となるため、シリアル番号を署名前に変更しておかなければならない。
署名後にシリアルを変えてしまうと、SOAが改竄されたと見なされてしまう。
F)ゾーンファイルのZSKでの署名
dnssec-signzone -a -H 10 -3 abcd -k Kalpha.+007+11111.key -o alpha. alpha.zone Kalpha.+007+22222.key |
- -3のあとの数値は、乱数発生のシードなのでなんでもいい。
これで、alpha.zoneファイルから、alpha.zone.signedファイルが出来上がる。
G)named.confの変更
named.confに、DNSSECの有効化オプションと、新しいsignedされたゾーンファイルを読み込ませる。
|
H)namedの設定再読み込み
# rndc reload |
syslogにエラーが出ないかを確認する。
(3)betaドメインのDNS
A)ZSK鍵ペアを作る
$ dnssec-keygen -r /dev/urandom -a NSEC3RSASHA1 -b 1024 -e -n zone beta.alpha. |
B)KSK鍵ペアを作る
$ dnssec-keygen -r /dev/urandom -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE beta.alpha. |
C)ゾーンファイルへの追記
KSKとZSKの*.keyファイルを、ゾーンファイルに追記する。
$INCLUDE Kbeta.alpha.+007+33333.key ;KSK |
E)ゾーンファイルのシリアル番号を上げる
F)ゾーンファイルのZSKでの署名
dnssec-signzone -a -H 10 -3 abcd -k Kbeta.alpha.+007+33333.key -o beta.alpha. beta.alpha.zone Kbeta.alpha.+007+44444.key |
これで、beta.alpha.zoneファイルから、beta.alpha.zone.signedファイルが出来上がる。
G)named.confの変更
named.confに、DNSSECの有効化オプションと、新しいsignedされたゾーンファイルを読み込ませる。
|
H)namedの設定再読み込み
# rndc reload |
syslogにエラーが出ないかを確認する。
(4)DSレコードの追加
上位のalpha DNSがbeta.alphaのKSK公開鍵を認証するために、betaはDSレコードを作成し、alphaに登録依頼をする。
A) betaでのDSレコード作成
$ dnssec-dsfromkey Kbeta.alpha.+007+33333.key |
すると、以下のように表示される。
beta.alpha. IN DS 35163 7 1 D545D...(omitted)...ACC20 |
B)DSレコードの登録
alphaのゾーンファイル内に、上記2行を追記し、シリアル番号をあげて、ゾーンを再署名し、読み込ませる。
(5)キャッシュサーバ
A)DNSSECの有効化
named.confのoptionsにDNSSECの有効化と、検証をする、の以下2行を追記する。
|
B)信頼できる鍵の登録
trusted-keysというブロックを作り、信頼するDNSのKSKを追記する。本来、ルートDNSの証明書を記述するが、この実験ではalpha DNSのKSKを登録する。
trusted-keys { "alpha." 257 3 7 "AwEXmL5...(omitted)...IjcBgM="; }; |
C)namedの設定再読み込み
# rndc reload |
6.動作テスト
1)正常系
キャッシュサーバ上で、digに+dnssecオプションを付けて検索する。
dig +dnssec @localhost www.beta.alpha a |
+sigchaseオプションを付けて検索する。
dig +dnssec +sigchase +trusted-key=trusted-key.key www.beta.alpha a |
このとき、./trusted-key.keyファイルは、上位のDNSの公開鍵を指定する。具体的には、Kalpha.+007+xxxxx.keyの内容から、コメントを除いたDNSKEYレコードを記述する。
2)異常系
alphaのDSレコードの数値を一文字変更して、再起動し、同じ検索をする。
すると、Aレコードが表示されない。
また、キャッシュサーバのsyslogに以下のようなエラーが出力される。
|
次回は、DNSSECで保護されたゾーンファイルに、Dynamic Update(動的更新)をする設定を行う。
- ブログネタ:
- Linuxに関する運用 に参加中!
1.DNSSECとは
DNSにおける問い合わせと回答が、本当に正しいDNSからの回答であこと、また回答が改竄されていないことを公開鍵暗号方式の技術を使い保証するDNSの拡張機能である。
DNS Security Extension。
このDNSのセキュリティ拡張によって、権威サーバからの回答を、キャッシュサーバもしくはリゾルバは、完全性と正当性を検証することが可能となる。
2.DNSSEC 関連のRFCと参考リンク
[RFC4033]は DNSSECの概要と用語
[RFC4034]はリソースレコードの定義
[RFC4035] はDNSSECプロトコル処理
その他のリンクは、こちらにまとめてある。
3.DNSSECの用語
(1)公開鍵暗号方式
DNSSECでは、公開鍵暗号方式を使ってドメインあたり2種類の鍵ペアを使い分けて、電子署名を行う。
鍵ペアは、秘密鍵と公開鍵で一対をなし、いずれかの片方の鍵で暗号化した情報は、もう一方の鍵で容易に復号化できる。
他者への盗聴を防ぐためには、情報の発信者は、受信者の公開鍵を使って情報を暗号化する。受信者は、自分しか知らない秘密鍵で容易に暗号を復号できる。
秘密鍵を持っていない人は、非常に長い計算を行わないと復号化できない仕組みになっている。
こうして情報の秘匿性を確保する。
(2)電子署名
電子署名とは、情報の発信者が正しい人であることを受信者に証明する鍵ペアの使い方である。
情報の発信者は、送信情報を自分の秘密鍵を使って暗号化する。情報の受け取り手は、送り手の公開鍵を使って復号化する。正常に復号化できれば、受け取り手は、情報の送り手しか持っていない秘密鍵で暗号化したことがわかるため、情報の送り手は正しい人であり、偽者が送ってきた情報でないことがわかる。誰でも暗号を復号できるので、情報の秘匿性は確保できない。
(3)DNSSECにおける鍵の種類
DNSSECにおいてゾーン管理者は、以下の2種類の鍵ペアを使用する。
A) ZSK (Zone Signing Key)
自ドメインのゾーンファイルを署名するための鍵ペア。
B) KSK (Key Signing Key)
ZSKを署名するための鍵ペア。
(4)DNSSECにおけるレコード(RR)の種類
通常のDNSのRRは、Aレコード、NSレコード、SOAレコード、PTRレコード、MXレコードなどが主に使用される。
DNSSECでは、これらに以下の4種類が追加される。
A) DNSKEY(DNS Public Key)
自分のZSKやKSKの公開鍵を記載するレコード。 DNSキャッシュサーバはここに記述されている公開鍵を使用して、署名を検証する。
B)RRSIG(Resource Record Signature)
RRSIGは、ゾーンファイル内の各レコードに電子署名したレコード。 SOAレコードを含む全てのレコード毎に作られる。 DNSキャッシュサーバはこのRRSIGに記述されている署名を使用し、問い合わせた結果が正当であるかを検証する。
C)DS(Delegation Signer)
下位のDNSが持っているKSK公開鍵のハッシュ値。このレコードで、上位と下位のDNS間で鍵の信頼がつながる。
D)NSEC(Next Secure)
問い合わせレコードが存在しなかった場合、不存在の回答に署名するためのレコード。アルファベット順にソートしたレコードから問い合わせレコードを探し、見つからなかった場合、その前後にあったレコードを提示して不在証明とする。 問い合わせに関係のないレコードを提示していしまうために、機械的にNSECレコードを取得することで、ゾーン内の全レコードを習得できてしまうという、zoneenumeration問題があるため、使用は推奨されない。
D')NSEC3
NSECに代わる不在証明のレコード。提示するレコード情報をハッシュ化し、zoneenumeration問題を回避している。
(5)DS方式による信頼の連鎖(chain of trust)
下図の通り。
ポイントは、キャッシュサーバ(やリゾルバ)が信頼している鍵を所持しておき、取得した情報の署名と公開鍵を連鎖的にたどっていき、信頼する鍵にたどりつくことで、その経路全てを信頼するという考え方である。
続きは、実践編。実際の設定を行っていく。
- ブログネタ:
- Linuxに関する運用 に参加中!