dig
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に関する運用 に参加中!