次世代のセキュリティ拡張DNSSECをBIND 9で実現：実用 BIND 9で作るDNSサーバ（13）（2/3 ページ）

[鶴長鎮一，＠IT]

BIND 9によるDNSSECの実現

　BIND 9.2.2以降で使用できるDNSSECはDS方式のみで、RFC 2535方式は使用できません。

　DS方式で鍵の作成とゾーンの署名を行ってみましょう。ただし、上位ドメインにDSレコードを登録する手順が現時点ではないため、ZSK鍵への署名とDSレコードの登録方法については言及しません。

BIND 9の再インストール

　BIND 9は、標準インストールではDNSSECに対応していないため、再インストールが必要です。RPMなどのパッケージも同様にDNSSEC対応版が必要ですが、ほとんどのディストリビューションでは用意されていないため、ソースからコンパイルする必要があります。

　configure実行時に--with-opensslでOpenSSL（http://www.openssl.org/）のインストール先を指定します。通常は/usrですが、OpenSSLをソースからインストールした場合は/usr/localになっている場合もあります。

# wget ftp://ftp.isc.org/isc/bind9/9.2.3/bind-9.2.3.tar.gz　←最新のBINDを入手 # tar xvfz bind-9.2.3.tar.gz # cd bind-9.2.3/ # ./configure --with-openssl=/usr

注：この場合、namedやdigなどのバイナリは/usr/localにインストールされます。--prefixで変更できますが、named.confの指定位置も変わります。

# make # make install

注：PGP Signatureによるソースファイルの検証などについては、第1回を参照。

　named.confやゾーンファイルは通常どおりに用意します（参考：第2回）。DNSSECのための作業はここでは特に必要ありません。

鍵ペアの作成と設定

　次に、ZSK鍵のペアを作成します。作業は/var/namedで行います。

# /usr/local/sbin/dnssec-keygen -a RSA -b 1024 -n ZONE example.jp Kexample.jp.+001+32394　←作成された鍵の名前の例

注：マシンパワーによっては数分かかります。コマンドパスおよびexample.jpは適宜書き換えてください。 　 dnssec-keygenのオプション 　 -a RSA、DSAなどの暗号アルゴリズムを指定 　 -b 鍵の長さを指定 　 -n ZONE、HOST、ENTITY、USERが指定可能。ここではHOSTを指定 　暗号アルゴリズム、鍵の長さは任意のもので構いませんが、KSK鍵を作成する際は更新頻度を考え、鍵の長さは十分大きな値に設定します。 　ここまでの作業で、鍵の名前.key、鍵の名前.privateファイルの対ができます。*.keyが公開鍵、*.privateが秘密鍵です。*.keyファイルは、ゾーン情報に登録できるようにフォーマットされています。 # ls K* Kexample.jp.+001+32394.key Kexample.jp.+001+32394.private # more Kexample.jp.+001+32394.key example.jp. IN KEY 256 3 1 AQPOnBAUz……（省略） 注：ファイルの名前は一例です。 　ZSK鍵の公開鍵をゾーンファイルに記述します。 # cat Kexample.jp.+001+32394.key >> /var/named/example.zone 注：ファイル名は各自の環境に合わせて適宜書き換えてください。 　準備ができたら、ゾーンファイルに署名します。すでに運用に入っているゾーンファイルの場合は、先にSOAレコード中のSerial値を上げておきます。 # dnssec-signzone -o example.jp /var/named/example.zone /var/named/example.zone.signed　←作成された署名済みゾーンファイル 　以上の作業により、以下のようなゾーンファイルが作成されます。 $TTL 86400 @            IN      SOA dns.example.jp. root.example.jp. (                      2004021401 ; serial                      3600       ; refresh 1hr                      900        ; retry 15min                      604800     ; expire 1w                      86400      ; min 24hr )              IN      NS     dns.example.jp. dns          IN      A      192.168.10.1 pc1          IN      A      192.168.10.11 pc2          IN      A      192.168.10.12 pc3          IN      A      192.168.10.13 pc4          IN      A      192.168.10.14 pc5          IN      A      192.168.10.15 署名前のゾーンファイル（第2回より） example.jp.        86400   IN SOA  dns.example.jp. root.example.jp. (                                    2004021401 ; serial                                    3600       ; refresh (1 hour)                                    900        ; retry (15 minutes)                                    604800     ; expire (1 week)                                    86400      ; minimum (1 day)                                    )                    86400   SIG     SOA 1 2 86400 20040315175332 (                                    20040214175332 5964 example.jp.                                    trmSnwDk75DSuqquFEbeEsEu5+sPr3ztL6Qj                                    （省略）                                    9gpklPm2fmISWCPtzQ== )                    86400   NS      dns.example.jp.                    86400   SIG     NS 1 2 86400 20040315175332 (……（省略）)                    86400   KEY     256 3 1 (                                    （省略）                                    ) ; key id = 32394                    86400   NXT     dns.example.jp. NS SOA SIG KEY NXT                    86400   SIG     NXT 1 2 86400 20040315175332 (                                    20040214175332 5964 example.jp.                                    （省略）                                    0E01fOlANPJOrMptoA== ) dns.example.jp.    86400   IN A    192.168.10.1                    86400   SIG     A 1 3 86400 20040315175332 (……（省略）)                    86400   NXT     pc1.example.jp. A SIG NXT                    86400   SIG     NXT 1 3 86400 20040315175332 (……（省略）) （以下略） 署名後のゾーンファイル 　作成した署名済みゾーンファイル（example.zone.signed）を現在のゾーンファイルに置き換え、 # rndc reload やnamedの再起動でゾーン情報を更新すれば作業終了です。 注：これだけでは、DNSSEC問い合わせに対応できません。ZSK鍵への署名とDSレコードの登録が必要です。 KEY／SIG／NXTレコード 　DNNSECは仕組みが多少複雑ですが、実際のゾーンファイルの作成は上記のようにdnssec-signzoneコマンドで、ほぼ自動で行えます。署名後のゾーンファイルを見ると、新しい資源レコードが追加されているのが分かります。 KEYレコード：公開鍵を指定 example.jp.   KEY     256 3 1 (公開鍵) ; key id = 32394 KEYレコードの例 256： ゾーン鍵の場合は256、それ以外は0 3： DNSSECのプロトコル番号「3」 1： 鍵を作成した暗号アルゴリズム。RSA/MD5は「1」。Diffie-Hellmanは「2」、DSA/SHA-1は「3」、RSA/SHA-1は「5」 (公開鍵)： Base64でエンコードされた公開鍵 32394： 鍵id。Kexample.jp.+001+32394のように、使用された鍵の名前の最終フィールドが鍵idになる SIGレコード：レコードに対する署名を指定 dns.example.jp.   SIG     A 1 3 86400 20040315175332 (署名) SIGレコードの例 A： 署名を行ったレコード。例ではdns.example.jp.のAレコードに対して署名が行われている 1： 使用した暗号アルゴリズム。KEYレコードと同様 3： dns、example、jpのように、オーナーが3ラベルで構成されていることを指定 86400： TTL 20040315175332： 署名の有効期限。YYYYMMDDHHMMSSフォーマットを使用 (署名)： Base64でエンコードされた署名 NXTレコード：次に来るレコードを指定 dns.example.jp.    NXT     pc1.example.jp. A SIG NXT NXTレコードの例 　上記の例では、dns.example.jpの次にpc1.example.jpのAレコードが来ることが分かります。こうすることで、（dns2やpc0などの）レコード名が存在しないことも保証できます。 　今回使用したゾーンファイルの例では、example.jp→dns.example.jp→pc1→pc2→pc3→pc4→pc5（注）の順で記述されています。 注：ホスト名の後ろのexample.jpを省略しています。 　署名されたゾーンファイルのNXTレコードを見ると、その連鎖順（注）も同じように作られ、最後はpc5→example.jpに戻っています。ドメイン名で連鎖を作り、さらに循環させることで、連鎖の間にはいかなるドメイン名も存在しないことを保証しています。例えば、dns.example.jpの次にpc1.example.jpのAレコードが来るため、dns0.example.jpやdns1.example.jpのようなドメイン名は存在が否定されます。 注：大文字・小文字を区別しないアルファベット順になります。 DNSSEC普及の課題 　BIND 9におけるDS方式への変更など、DNSSECにはまだ発展途上の感があり、普及には時間を要すると思われます。また、下位ゾーンから送られてくる公開鍵を上位ゾーンが確認する際に、いかに出元の保証を行うかなど、まだまだ検討の余地が残されています。何より、現在動いているシステムをどのように新しいものに置き換えるのか。IPv6と同様、大変重要な課題です。 SpecialPR 検索 スポンサーからのお知らせPR SpecialPR ＠IT eBook ユーザーの「無知」は罪なのか？――IT訴訟解説 ベンダーvs.ユーザー企業 死闘編 Pythonで日付を扱う際の「はて？」を解決する無料の電子書籍『解決！Python　日付データ編』 「このままゼロトラストへ進んでいいの？」と迷う企業やこれから入門する企業も必見、ゼロトラストの本質、始め方／進め方が分かる無料の電子書籍 超IT用語解説漫画「食べ超」を読んで、テクノロジーの進化に思いをはせよう » 一覧ページへ 注目のテーマ システム開発ノウハウ 【発注ナビ】PR 編集部からのお知らせ 12/4〜5【無料オンラインセミナー】クラウドネイティブイノベーターズ協会 代表理事 草間一人氏【基調講演　今こそ取り組むクラウドネイティブ - コンテナだけではない、企業のデジタル競争力を高める実践アプローチ】、多摩大学 ルール形成戦略研究所 客員教授 西尾素己氏【基調講演　究極のシフトレフト。最新のサイバー攻撃から開発環境を守れ。】もあります。「＠IT Cloud Native Week 2024秋〜理解が進んだ今こそ知りたい、クラウドネイティブで本当に価値を生み出すための前提条件〜」 あなたにおすすめの記事PR @ITについて お問い合わせ 広告について 採用広告について 利用規約 著作権・リンク・免責事項 サイトマップ RSSについて ＠ITのRSS一覧 アイティメディアIDについて アイティメディアIDとは メールマガジン登録 ＠ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。 申し込みページへ ITmediaはアイティメディア株式会社の登録商標です。 メディア一覧 | 公式SNS | 広告案内 | お問い合わせ | プライバシーポリシー | RSS | 運営会社 | 採用情報 | 推奨環境