検索
連載

スレーブ・サーバのゾーン転送とセキュリティ：実用 BIND 9で作るDNSサーバ（5）（3/3 ページ）

DNSサーバを運営する場合は、スレーブ・サーバ（セカンダリ・サーバ）で冗長化する必要がある。その際に検討すべきはマスター−スレーブ間のゾーン転送とそのセキュリティである。（編集局）

Share
Tweet
LINE
Hatena
前のページへ | 　　　　　　

ゾーン転送のセキュリティ対策

　本連載では別に回を設けてBIND 9のセキュリティについて説明する予定ですが、ゾーン転送に関しては極めて危険度が高いため、この点についてはここで紹介しておきます。

使わせないのが基本

　ゾーン転送に関するセキュリティ対策は、何よりもマスター・サーバ側で、あらかじめ指定されたスレーブ・サーバ以外からはゾーン転送を受け付けないようにするのが第一です。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

（1）追加したい分だけ「;」で区切って追加する
（2）ゾーンセンテンスでも記入可能
（3）無指定
（4）optionsステートメントで指定されたものより、ゾーンセンテンスで指定されたものの方が優先されるため、この場合example.jpに対してはどこからもゾーン転送が行えない

　設定したらnamedを再起動し、digコマンドで許可が与えられているサーバとそうでないサーバで期待したレスポンスが返ってくるかどうかを確認します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

TSIGの利用

　マスター・サーバのアクセス制限は上記の要領で完了しますが、スレーブ・サーバはIPアドレスでのみマスターを識別しているため、マスター・サーバのIPを偽装した「なりすましサーバ」が出現した場合はまったくの無防備になります。

　そこで、TSIG（Transaction Signature）を用います。TSIGはサーバとクライアントで共通の秘密鍵を保有し、DNSメッセージ全体に署名を行うことでメッセージの完全性の保証やリクエスト認証を可能にします（注）。

図4　TSIGの仕組み
図4　TSIGの仕組み
注：暗号には認証と秘匿2つの機能があり、ここでは認証の機能のみが提供されます。そのため、マスターとスレーブで交換されるメッセージは平文のままです。


　では、TSIGを実装します。まず、dnssec-keygenコマンドを使用して共有鍵を作成します。作業はマスター、スレーブどちらでも構いません。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

-a RSA、DSAなどの暗号化アルゴリズムを指定できるが、TSIGではHMAC-MD5（鍵付きハッシュ関数）を指定
-b 鍵の長さを指定。十分な長さが必要だが、HMAC-MD5アルゴリズムでは512bits（注）が最大になる
-n ZONE、HOST、ENTITY、USERが指定できるが、ここではHOSTを指定
example.jp 鍵の名前。鍵の名前にはゾーン転送の対象になるドメイン名を指定


　以上の操作で次の2つのファイルが作成されます。

  • Kexample.jp.+157+01798.key
  • Kexample.jp.+157+01798.private

　「157」はHMAC-MD5で生成されたことを示し、「01798」はハッシュ値であるため環境によって変わります。

　ファイルの中身は次のようになっています。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　次に、生成されたファイルから共有鍵（上の赤字の個所）を抜き出し、named.confに埋め込みます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

（1）dnssec-keygenを実行した際に指定した「鍵の名前」を指定
（2）暗号化アルゴリズムを指定
（3）該当ドメインのゾーンセンテンス
（4）ここでIPを指定した場合は、そのサーバのみゾーン転送時にTSIGは要求されない

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

（1）次のセンテンスを追加
（2）複数形のkeysになっていることに注意
（3）該当ドメインのゾーンセンテンスは修正の必要ない

　重要な共有鍵が記入されているため、named.confのパーミッションに注意しましょう。特定のユーザー（たいてはroot）のみがアクセス権を持つように、

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

としておきます。

　実施に当たっては、rsyncと同様に2台のサーバの内蔵時計が同期していることが重要になるため、前述のntpdateなどで時刻の修正を行ってからnamedデーモンを再起動します。再起動したら、バックアップファイルのタイムスタンプやログファイルを参照し、スレーブ側でゾーン転送が行われていることを確認します。この時点で、先ほど紹介したdigコマンドによるAXFRの確認はできなくなっています。これは正常な動作で、TSIGを使用しなければゾーン転送は実施されません。

　以上でTSIGの実装は完了ですが、共有鍵を定期的に変更することを考えると、多少の手間を感じます。そのため、BIND 9では共通鍵交換を支援するTKEYが用意されました。今後のバージョンアップが期待されます。

　今回はスレーブ・サーバの運用についてお話ししました。サーバ1台当たりの処理能力が上がっても、依然としてDNSの分散配置の重要性は増すばかりです。「データの一貫性を保証する分散システム」の代名詞ともてはやされるDNSですが、そこで利用されているゾーン転送の仕組みをご理解いただけたと思います。

「次回」へ


「実用 BIND 9で作るDNSサーバ」バックナンバー
前のページへ | 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る