第8回 DHCPとDynamic DNSの連携システム
鶴長 鎮一
2003/8/5
nsupdate同様、ソースIPアドレスによる制限だけでは心もとないため、TSIG認証（注）を導入します。手順は第7回同様に行い、DHCP側での鍵の指定はdhcpd.conf中で行います。
| 注：dnssec-keygenやTSIGについては、第5回も参照。 |
■マスター・ゾーンサーバ側の設定
まず、マスター・ゾーンサーバで共有鍵の生成を行います。
# /usr/sbin/dnssec-keygen -a HMAC-MD5 -b 512 -n HOST example.jp |
生成されたファイルから共有鍵を抜き出し、named.confに埋め込みます。
key "example.jp" { |
| /etc/named.conf |
■DHCPサーバ側の設定
key "example.jp" { |
| /etc/dhcpd.conf追加分 |
以上で設定は終了です。named、dhcpdともに再起動し、動作を確認しましょう。
DNSに登録されるホスト名は、クライアントから渡されるものを使用すると前述しました。それでは、同じホスト名が設定されたクライアントが複数 存在する場合はどうなるでしょう。または、1台のマスター・ゾーンサーバに対して複数のDHCPサーバからupdate要求が行われるとどうなるでしょ う。
これらの場合、クライアントAのためのゾーン情報が、クライアントBによって上書きされたり削除されることが懸念されます。そこで、DHCPサー バはクライアントの情報を基にHASH値を生成し、TXTレコードとして埋め込みます。以降の更新にはこのHASH値の確認が必要になり、その過程は /var/log/messagesでうかがうことができます。また、サーバ側でホスト名を指定することもできます。
host bbb { hardware ethernet XX:XX:XX:XX:XX:XX; ddns-hostname "クライアントのホスト名"; } |
| /etc/dhcpd.conf追加分 |
クライアントから、ホスト名でなくFQDNが渡される場合もあります。FQDNにDHCPサーバが想定していないドメインが付随していることも考えられます。DHCPサーバ側では、以下の2つのモードでFQDNを処理可能です。
ignore client-updates; |
| /etc/dhcpd.conf追加分 注：この設定を有効にした場合、クライアントがホスト名しか送ってこない場合は正引きのAレコードは登録されず、逆引きのPTRだけ登録されます。 |
DHCPサーバが自由にできる環境であればこれまでに紹介した方法が利用できますが、多くの場合DHCPサーバはプロバイダのものであったり、そもそもDHCPではなくPPPoEやPPPを利用しているケースもあることでしょう。
こうした環境にDynamic DNSが付加できれば、動的に与えられたIPアドレスをいちいち直打ちする必要はなくなります。その手順を自動化できれば、不意なプロバイダとの切断で新 しいアドレスが割り当てられた場合に、即座にDNS Updateを実施できます。以下では、簡単なPerlスクリプトを使った自動化の手順を紹介します。
 |
| 図3 ホームサーバをゾーン情報に登録 |
■クライアント／サーバプログラムの作成
| サーバ側 | ||
| server.pl（漢字コードEUC） | ||
| hosts.key | ||
| クライアント側 | ||
| client.pl（漢字コードEUC） | ||
ここでは図4のようなネットワークを想定しています。プロバイダから付与されたただ1つのIPアドレスを静的IPマスカレード（注）を用いて、特定のポートに来たIPパケットを指定されたプライベートネットワーク内のサーバに転送しています。
| 注：多くのブロードバンドルータでは「仮想サーバ」の名称で呼ばれています。Apacheなどで利用されるバーチャルドメインサーバとは本質的に異なるものです。 |
このサーバに、外部からhome.example.jpで接続できるようにDynamic DNSを利用します。しかし、ローカルサーバにグローバルアドレスが直接振られる場合は割り当てられたグローバルアドレスを簡単に取得できますが、静的 IPマスカレードを使用している状況では、ルータに振られたグローバルアドレスを何らかの手段で知る必要があります。そこで次のような仕組みを考えます。
 |
| 図4 クライアント／サーバプログラムの導入 |
この例では、クライアント／サーバ方式を採用しています。nsupdateはnamedが起動しているサーバ内で実行させることにし、そのための要求待ち受けプログラムと、外部からnsupdateを実行させるクライアントスクリプトの2つを用意します。
クライアント／サーバ方式を使用することで、クライアントのソースIP、それもルータに付与されたIPアドレスをサーバ側で検出できます。NAT 内から送信されたIPパケットは、ルータ内でソースアドレスをグローバルIPに書き換えるため、サーバ側は容易に必要なIPアドレスを知ることができま す。
■クライアント／サーバプログラムの内容
クライアント側はわざわざスクリプトを作成するまでもなく、telnetコマンドで直接サーバと対話することも可能ですが、crontabなどで定期的に実行させることも考えてスクリプト化しました。
| |||||||||||
| 図5 クライアント／サーバプログラムの内容 |
クライアント側に用意するファイルはclient.plのみです。必要な情報はプログラムへの引数で指定します。サーバ側にはserver.plとhost.keyファイルを用意します。
host.keyファイルには、あらかじめ登録が予想されるホスト名と一意なキーを空白文字で区切って記述します。ここで指定したキーは、クライ アントとサーバ間での認証に使用されます。認証にはCRYPT暗号を利用し、平文キーを垂れ流さないようにささやかな配慮を実施しています。
サーバは要求が正当なものであることを確認した後、同じゾーン情報を複数回登録しないように、update前に同じレコードが登録されていないか 否かを確認します。登録されていなければnsupdateを実行します。この際に、同じレコードがなくても、古い情報（以前に割り当てられていたIP）で 登録されていることを考慮し、事前にレコードの削除を行います。ホスト名に対しては、Aレコードを1つに限定しています。
プログラムの詳細については、ファイル中のコメント行を参照してください。
■クライアント／サーバプログラムの実行例
サーバスクリプトは、マスター・ゾーンサーバに置きます。DNSサーバにとってはlocalhostからnsupdateが実行されることになるため、named.confの指定は次のようになります。
zone "example.jp" { |
| named.conf追加分 |
named.confの設定を有効にした後、server.plとhost.keyを任意のディレクトリに展開します。2つのファイルは同じディ レクトリに置きますが、何らかの理由でhost.keyファイルを移動せざるを得ない場合は、server.plの10行目にある$key_fileを修 正します。次に、host.keyファイルにDNSへの登録が予想されるホスト名のFQDNと、それに対するキーを記述します。
FQDNホスト名 認証キー |
| host.keyファイル。FQDNホスト名と認証キーの間は空白文字で区切る |
では、サーバ側スクリプトを実行します。server.plに適切な実行権を設定するか、次のように実行します。
$ perl ./server.pl |
次にクライアント側でスクリプトを実行します。特に準備は必要ありません。先ほどサーバ側で設定したホスト名とキーを使用し、client.plを次のように実行します。
$ perl ./client.pl ホスト名 キー サーバ (port) |
登録がうまくいっているかどうか、digやhostコマンドで確認しましょう。
実際に使用する場合は、BIND側のupdate-policyを厳しくしたりPREREQ指定を行ってDNS Updateの手続きを複雑にするなど、安全性を考慮した修正を適宜加えてください。
■フリーのDynamic DNSサービス
独自ドメインを所有し、DNSサーバを運用されている方も多いと思いますが、中にはDynamic DNSをキーワードにして検索し、このページを見つけた方もいるでしょう。
Dynamic DNSの利用にDHCPサーバは必須ではありませんが、DNS Updateに対応したDNSサーバが必要になります。ホームサーバを利用するために、わざわざドメインを取ってDNSサーバを立ち上げるのも面倒です。 そこで、有料／無料で提供されているDynamic DNSサイトを利用します。サイトによっては、持ち込んだドメインでサービスを利用したり、メールサーバはサイトのものが利用できるなどの特典がありま す。
こうしたサービスではnsupdateなど標準のBINDツールではなく、独自のクライアントソフトやWebインターフェイスが提供されており、登録するレコードのTTL設定値や個数に制限があるため、サービス選択の際は十分に吟味しましょう。
◆
以上、2回にわたりDynamic DNSについて紹介しました。
IPアドレスの割り当てがDHCPなど動的な方法が主流になるにつれ、Dynamic DNSの用途は今後も増していくことが予想されます。BINDでは比較的簡単な作業でDynamic DNSが利用できることがお分かりいただけたと思います。
とはいえ、いきなり運用環境に実装するのではなく、テスト環境を用意して各クライアントやサーバの挙動を確認することをお勧めします。数台のPCで箱庭環境を作ってしまえば、Dynamic DNSのテストに限らず、さまざまな利用方法があるはずです。
 | 2/2 | |
No comments:
Post a Comment