DNSサーバをインストールするには、YaSTを起動してから、ソフトウェア+ソフトウェア管理の順に選択します。表示+パターンの順に選択して、DHCPおよびDNSサーバを選択します。依存関係のあるパッケージのインストールを確認して、インストールプロセスを完了します。

YaSTモジュールを使用して、ローカルネットワーク用にDNSサーバを設定します。このモジュールを初めて起動すると、サーバ管理に関して2、3の決定を行うように要求されます。この初期セットアップを完了すると、基本的なサーバ設定が生成されます。エキスパートモードを使用すると、より詳細な設定タスク(ACLのセットアップ、ロギング、TSIGキーなどのオプション)を処理できます。

24.3.2. エキスパート設定¶

YaSTのモジュールを起動するとウィンドウが開き、複数の設定オプションが表示されます。設定を完了すると、基本的な機能が組み込まれたDNSサーバ設定が作成されます。

24.3.2.1. 起動¶

起動では、DNSサーバをシステムのブート中に起動するか、それとも手動で起動するか指定します。DNSサーバをすぐに起動するには、［ 今すぐDNSサーバを起動する を選択します。DNSサーバを停止するには、［ 今すぐDNSサーバを停止する を選択します。現在の設定を保存するには、設定を保存して、今すぐDNSサーバをリロードするを選択します。 ファイアウォールのDNSポートを開くにはファイアウォール内でポートを開くを、ファイアウォールの設定を変更するにはFirewall Detailsをクリックします。

LDAPサポートを有効にするを選択すると、ゾーンファイルがLDAPデータベースによって管理されるようになります。ゾーンデータを変更してそれがLDAPデータベースに書き込まれると、設定を再ロードするように要求されます。DNSサーバを再起動すると、変更がすぐに反映されます。

24.3.2.2. フォワーダ¶

ローカルDNSサーバは、要求に応答できない場合、要求をフォワーダに転送しようとします(そのように設定されている場合)。このフォワーダは、手動で、Forwarder Listに追加できます。フォワーダが、ダイアルアップ接続でのように静的でない場合は、netconfigが設定を処理します。netconfigの詳細については、man 8 netconfigを参照してください。

24.3.2.3. 基本的なオプション¶

このセクションでは、基本的なサーバオプションを設定します。オプションメニューから設定する項目を選択して、対応する入力フィールドに値を指定します。新しいエントリを追加するには、追加を選択してください。

24.3.2.4. ログ¶

DNSサーバがログに記録する内容とログの方法を設定するには、ログ記録を選択します。Log Typeに、DNSサーバがログデータを書き込む場所を指定します。システム全体のログファイル/var/log/messagesを使用する場合はシステムログを、別のファイルを指定する場合はファイルを選択します。別のファイルを指定する場合は、ファイル名、ログファイルの最大サイズ(メガバイト(MB))と保管するログファイル数(バージョン)も指定します。

追加ログには、さらに詳細なオプションが用意されています。すべてのDNSクエリをログに記録を有効にすると、すべてのクエリがログに記録されるため、ログファイルが非常に大きくなる可能性があります。ですから、このオプションを有効にするのはデバッグ時だけにすることをお勧めします。DHCPサーバとDNSサーバ間でのゾーン更新時のデータトラフィックをログに記録するには、ゾーン更新をログに記録を有効にします。マスタからスレーブへのゾーン転送時のデータトラフィックをログに記録するには、ゾーン転送をログに記録を有効にします。詳細については、図24.4「DNSサーバ:ログの記録」を参照してください。

図24.4 DNSサーバ:ログの記録¶

24.3.2.5. ACL¶

このダイアログでは、アクセス制限を強制するACL(アクセス制御リスト)を定義します。名前に個別名を入力したら、次の形式で、値にIPアドレス(ネットマスクは省略可)を指定します。

{ 192.168.1/24; }

設定ファイルの構文に従って、アドレスの末尾にはセミコロンを付け、中カッコで囲む必要があります。

24.3.2.6. TSIGキー¶

TSIG (トランザクションシグネチャー)の主な目的は、DHCPおよびDNSサーバ間で安全な通信を行うことです。24.8項 「安全なトランザクション」を参照してください。

TSIGキーを生成するには、キーIDフィールドに個別名を入力し、キーを格納するファイルをファイル名フィールドに入力します。生成をクリックすると、選択内容が確定されます。

作成済みのキーを使用するには、キーIDフィールドを空白のままにして、ファイル名で、そのキーが保存されているファイルを選択します。その後、追加をクリックすると、入力内容が確定されます。

24.3.2.7. DNSゾーン(スレーブゾーンの追加)¶

スレーブゾーンを追加するには、DNSゾーンを選択し、ゾーンタイプにスレーブを選択し、新規ゾーンの名前を書き込み、追加をクリックします。

マスタDNSサーバのIPの下のゾーンエディタサブダイアログで、スレーブがデータをプルするマスタを指定します。サーバへのアクセスを制限するために、リストから定義済みのACLを1つ選択します。

24.3.2.8. DNSゾーン(マスタゾーンの追加)¶

マスタゾーンを追加するには、DNSゾーンを選択し、ゾーンタイプにマスタを選択し、新規ゾーンの名前を書き込み、追加をクリックします。マスタゾーンの追加時には、逆引きゾーンも必要です。たとえば、ゾーンexample.com(サブネット192.168.1.0/24内のホストをポイントするゾーン)を追加する際には、カバーされるIPアドレス範囲の逆引きゾーンも追加する必要があります。定義上、このゾーンの名前は、1.168.192.in-addr.arpaとなります。

24.3.2.9. DNSゾーン(マスタゾーンの編集)¶

マスタゾーンを編集するには、DNSゾーンを選択し、テーブルからマスタゾーンを選択し、編集をクリックします。このダイアログには、基本(最初に表示される)、NSレコード、MXレコード、SOA、およびレコードのページがあります。

に示す基本ダイアログを使用すると、ダイナミックDNSの設定と、クライアントおよびスレーブネームサーバへのゾーン転送に関するアクセスオプションを定義できます。図24.5「DNSサーバ: ゾーンエディタ(基本)」ゾーンの動的更新を許可するには、動的アップデートの許可および対応するTSIGキーを選択します。このキーは、更新アクションの開始前に定義しておく必要があります。ゾーン転送を有効にするには、対応するACLを選択します。ACLは事前に定義しておく必要があります。

基本ダイアログで、ゾーン転送を有効にするかどうか選択します。リストされたACLを使用して、ゾーンをダウンロードできるユーザを定義します。

図24.5 DNSサーバ: ゾーンエディタ(基本)¶

ゾーンエディタ(NSレコード)

レコードダイアログでは、指定したゾーンの代替ネームサーバを定義できます。リストに自分が使用しているネームサーバが含まれていることを確認してください。レコードを追加するには、追加するネームサーバにレコード名を入力し、追加をクリックして確定します。詳細については、図24.6「DNSサーバ:ゾーンエディタ(NSレコード)」を参照してください。

図24.6 DNSサーバ:ゾーンエディタ(NSレコード)¶

ゾーンエディタ(MXレコード)

現行ゾーンのメールサーバを既存のリストに追加するには、対応するアドレスと優先順位の値を入力します。その後、追加を選択して確定します。詳細については、図24.7「DNSサーバ:ゾーンエディタ(MXレコード)」を参照してください。

図24.7 DNSサーバ:ゾーンエディタ(MXレコード)¶

ゾーンエディタ(SOA)

このページでは、SOA (start of authority)レコードを作成できます。個々のオプションについては、例24.6「The /var/lib/named/example.comゾーンファイル」を参照してください。LDAPを介して管理される動的ゾーンの場合、SOAレコードの変更がサポートされないので注意してください。

図24.8 DNSサーバ:ゾーンエディタ(SOA)¶

ゾーンエディタ(レコード)

このダイアログでは、名前解決を管理します。レコードキーでは、ホスト名を入力してレコードタイプを選択します。Aレコードはメインエントリを表します。この値はIPアドレスでなければなりません。CNAMEはエイリアスです。NSおよびMXの各タイプを指定すると、NSレコードおよびMXレコードの各タブで提供される情報に基づいて、詳細レコードまたは部分レコードが展開されます。この3つのタイプのは、既存のAレコードに解決されます。PTRは逆引きゾーン用レコードです。これは、次の例のように、Aレコードとは反対です。

hostname.example.com. IN A 192.168.0.1
1.0.168.192.in-addr.arpa IN PTR hostname.example.com.

	逆引きゾーンの編集
正引きゾーンの追加後、メインメニューに戻って、編集用の逆引きゾーンを選択します。次に、タブ基本で、チェックボックスAutomatically Generate Records Fromにチェック印を入れ、正引きゾーンを選択します。これにより、正引きゾーンでのすべての変更が、逆引きゾーンで自動的に更新されます。

SUSE® Linux Enterprise Serverシステムでは、ネームサーバBIND (Berkeley Internet name domain)は、事前設定されて提供されるので、インストールが正常に完了すればただちに起動できます。すでにインターネットに接続し、/etc/resolv.confのlocalhostにネームサーバアドレス127.0.0.1が入力されている場合、通常、プロバイダのDNSを知らなくても、すでに機能する名前解決メカニズムが存在します。この場合、BINDは、ルートネームサーバを介して名前の解決を行うため、処理が非常に遅くなります。通常、効率的で安全な名前解決を実現するには、forwardersの下の設定ファイル/etc/named.confにプロバイダのDNSとそのIPアドレスを入力する必要があります。いままでこれが機能している場合、ネームサーバは、純粋なキャッシュ専用ネームサーバとして動作しています。ネームサーバは、そのゾーンを設定してはじめて、正しいDNSにすることができます。簡単な例については、/usr/share/doc/packages/bind/configのドキュメントを参照してください。

	ネームサーバ情報の自動取得
インターネット接続やネットワーク接続のタイプによっては、ネームサーバ情報を自動的に現在の状態に適合させることができます。これを行うには、 /etc/sysconfig/network/configファイルのNETCONFIG_DNS_POLICY変数をautoに設定します。

ただし、公式のドメインは、その1つが責任のある機関によって割り当てられるまで、セットアップしないでください。独自のドメインを持っていて、プロバイダがそれを管理している場合でも、BINDはそのドメインに対する要求を転送しないので、そのドメインを使用しないほうが賢明です。たとえば、プロバイダのWebサーバは、このドメインからはアクセスできません。

ネームサーバを起動するには、rootユーザとして、コマンド「rcnamedstart」を入力します。右側に緑色で「done」と表示されたら、named(ネームサーバプロセス名)が正常に起動しています。サーバが正常に起動したらすぐに、hostまたはdigプログラムを用いてローカルシステム上でネームサーバをテストしてください。デフォルトサーバlocalhostとそのアドレス127.0.0.1が返されるはずです。これが返されない場合は、/etc/resolv.confに含まれているネームサーバエントリが誤っているか、同ファイルが存在しないかのいずれかです。最初のテストとして、「host127.0.0.1」を入力します。これは常に機能するはずです。エラーメッセージが表示された場合は、rcnamed statusを使用して、サーバが実際に起動されていることを確認します。ネームサーバが起動しない場合、または予想しない動作をしている場合、多くはログファイル/var/log/messagesでその原因が明らかになります。

プロバイダのネームサーバ(またはすでにネットワーク上で動作しているネームサーバ)をフォワーダとして使用する場合は、forwardersの下のoptionsセクションに、対応するIPアドレスまたはアドレスを入力します。に含まれているアドレスは、単なる例です。例24.1「named.confファイルの転送オプション」各自サイトの設定に合わせて変更してください。

options { 
        directory "/var/lib/named";
        forwarders { 10.11.12.13; 10.11.12.14; };
        listen-on { 127.0.0.1; 192.168.1.116; };
        allow-query { 127/8; 192.168/16 };
        notify no;
        };

optionsエントリの後には、ゾーン用のエントリ、localhostと0.0.127.in-addr.arpaが続きます。「.」の下のtype hint(タイプヒント)は必ず存在しなければなりません。対応するファイルは、変更する必要がなく、そのままで機能します。また、各エントリの末尾が「;」で閉じられ、中カッコが適切な位置にあることを確認してください。設定ファイル/etc/named.confまたはゾーンファイルを変更したら、rcnamedreloadを使用して、BINDにそれらを再読み込みさせます。または、rcnamedrestartを使用してネームサーバを停止、再起動しても同じ結果が得られます。サーバは「rcnamedstop」を入力していつでも停止することができます。

BINDネームサーバ自体のすべての設定は、/etc/named.confファイルに格納されます。ただし、処理するドメインのゾーンデータ(ホスト名、IPアドレスなどで構成されている)は、/var/lib/namedディレクトリ内の個別のファイルに格納されます。この詳細については、後述します。

/etc/named.confファイルは、大きく2つのエリアに分けられます。1つは一般的な設定用のoptionsセクション、もう1つは個々のドメインのzoneエントリで構成されるセクションです。ログセクションとacl (アクセス制御リスト)エントリは省略可能です。コメント行は、行頭に#記号または//を指定します。最も基本的な/etc/named.confファイルの例を、例24.2「基本的な/etc/named.confファイル」に示します。

options { 
        directory "/var/lib/named"; 
        forwarders { 10.0.0.1; };
        notify no;
};

zone "localhost" in {
       type master;
       file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" in {
        type master;
        file "127.0.0.zone";
};

zone "." in {
        type hint;
        file "root.hint";
};

logging {
        category default { null; };
};

zone "example.com" in {
      type master;
      file "example.com.zone";
      notify no;
};

zone "example.net" in {
      type slave;
      file "slave/example.net.zone";
      masters { 10.0.0.1; }; 
};

ゾーンファイルは2種類必要です。一方はIPアドレスをホスト名に割り当て、もう一方は逆にIPアドレスのホスト名を提供します。

	ゾーンファイルでのドット(ピリオド、フルストップ)の使用
フィルタフィールドの右側にある "."はゾーンファイル内で重要な意味を持ちます。末尾に.のホスト名を指定すると、ゾーンが追加されます。完全なホスト名を完全なドメイン名とともに指定する場合は、末尾に.を付けて、ドメインが追加されないようにします。ネームサーバ設定エラーの原因として最も頻繁に挙げられるのは、おそらくピリオド「.」の打ち忘れや位置の間違いです。

最初に、ドメインexample.comの責任を負うゾーンファイルexample.com.zoneについて検討します(例24.6「The /var/lib/named/example.comゾーンファイル」参照)。

1.  $TTL 2D 
2.  example.com. IN SOA      dns  root.example.com. ( 
3.               2003072441  ; serial
4.               1D          ; refresh
5.               2H          ; retry
6.               1W          ; expiry
7.               2D )        ; minimum
8.  
9.               IN NS       dns 
10.              IN MX       10 mail
11. 
12. gate         IN A        192.168.5.1 
13.              IN A        10.0.0.1 
14. dns          IN A        192.168.1.116 
15. mail         IN A        192.168.3.108 
16. jupiter      IN A        192.168.2.100
17. venus        IN A        192.168.2.101
18. saturn       IN A        192.168.2.102
19. mercury      IN A        192.168.2.103
20. ntp          IN CNAME    dns 
21. dns6         IN A6  0    2002:c0a8:174::

擬似ドメインin-addr.arpaは、IPアドレスからホスト名への逆引き参照に使用されます。このドメインの前に、IPアドレスのネットワーク部分が逆順に指定されます。たとえば、192.168は、168.192.in-addr.arpaに解決されます。参照先 例24.7「逆引き」。

1.  $TTL 2D
2.  168.192.in-addr.arpa.   IN SOA dns.example.com. root.example.com. (
3.                          2003072441      ; serial
4.                          1D              ; refresh
5.                          2H              ; retry
6.                          1W              ; expiry
7.                          2D )            ; minimum
8.
9.                          IN NS           dns.example.com.
10. 
11. 1.5                     IN PTR          gate.example.com. 
12. 100.3                   IN PTR          www.example.com. 
13. 253.2                   IN PTR          cups.example.com. 

通常、ゾーン転送は、異なるバージョンのBIND間でも問題なく行えるはずです。

動的アップデートという用語は、マスタサーバのゾーンファイル内のエントリが追加、変更、削除される操作を指します。この仕組みは、RFC 2136に記述されています。動的アップデートをゾーンごとに個別に構成するには、オプションのallow-updateルールまたはupdate-policyルールを追加します。動的に更新されるゾーンを手動で編集してはなりません。

サーバに更新エントリを転送するには、nsupdateコマンドを使用します。このコマンドの詳細な構文については、nsupdateのマニュアルページ(man8 nsupdate)を参照してください。セキュリティ上の理由から、こうした更新はTSIGキーを使用して実行するようにしてください(24.8項 「安全なトランザクション」参照)。

安全なトランザクションは、共有秘密キー(TSIGキーとも呼ばれる)に基づくトランザクション署名(TSIG)を使用して実現できます。ここでは、このキーの生成方法と使用方法について説明します。

安全なトランザクションは、異なるサーバ間の通信、およびゾーンデータの動的アップデートに必要です。アクセス制御をキーに依存する方が、単にIPアドレスに依存するよりもはるかに安全です。

TSIGキーの生成には、次のコマンドを使用します(詳細については、mandnssec-keygenを参照)。

dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2

これにより、次のような形式の名前を持つファイルが2つ作成されます。

Khost1-host2.+157+34265.private Khost1-host2.+157+34265.key

キー自体(ejIkuCyyGJwwuN3xAteKgg==のような文字列)は、両方のファイルにあります。キーをトランザクションで使用するには、2番目のファイル(Khost1-host2.+157+34265.key)を、できれば安全な方法で(たとえばscpを使用して)、リモートホストに転送する必要があります。host1とhost2の間で安全な通信ができるようにするには、リモートサーバでキーを/etc/named.confファイルに含める必要があります。

key host1-host2 {
 algorithm hmac-md5;
 secret "ejIkuCyyGJwwuN3xAteKgg==";
};

	/etc/named.confのファイルパーミッション
/etc/named.confのファイルパーミッションが適切に制限されていることを確認してください。このファイルのデフォルトのパーミッションは0640で、オーナーがroot、グループがnamedです。この代わりに、パーミッションが制限された別ファイルにキーを移動して、そのファイルを/etc/named.conf内にインクルードすることもできます。外部ファイルをインクルードするには、次のようにします。 include "filename" ここで、filenameには、キーを持つファイルへの絶対パスを指定します。

サーバhost1がhost2(この例では、アドレス10.1.2.3)のキーを使用できるようにするには、host1の/etc/named.confに次の規則が含まれている必要があります。

server 10.1.2.3 {
  keys { host1-host2. ;};
};

同様のエントリがhost2の設定ファイルにも含まれている必要があります。

IPアドレスとアドレス範囲に対して定義されているすべてのACL (アクセス制御リスト―ACLファイルシステムと混同しないこと)にTSIGキーを追加してトランザクションセキュリティを有効にします。対応するエントリは、次のようになります。

allow-update { key host1-host2. ;};

このトピックについての詳細は、update-policyの下の『BIND Administrator Reference Manual』を参照してください。

DNSSEC、すなわちDNSセキュリティは、RFC2535に記述されています。DNSSECに利用できるツールについては、BINDのマニュアルを参照してください。

ゾーンが安全だといえるためには、1つ以上のゾーンキーが関連付けられている必要があります。キーはホストキーと同様、dnssec-keygenによって生成されます。現在、これらのキーの生成には、DSA暗号化アルゴリズムが使用されています。生成されたパブリックキーは、$INCLUDEルールによって、対応するゾーンファイルにインクルードします。

dnssec-signzoneコマンドを使用すると、生成されたキーのセット(keyset-ファイル)を作成し、それらを安全な方法で親ゾーンに転送し、署名することができます。これによって、/etc/named.conf内のゾーンごとにインクルードするファイルが生成されます。

ここで扱ったトピックの詳細については、/usr/share/doc/packages/bind/ディレクトリにインストールされるbind-docパッケージ内の『BIND Administrator Reference Manual』を参照してください。BINDに付属のマニュアルやマニュアルページで紹介されているRFCも、必要に応じて参照してください。/usr/share/doc/packages/bind/README.SuSEには、SUSE Linux Enterprise ServerのBINDに関する最新情報が含まれています。