31 ドメインネームシステム #

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

または、コマンドラインで次のコマンドを使用します。

tux > sudo zypper in -t pattern dhcp_dns_server

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

31.3.2 エキスパート設定 #

 

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

31.3.2.1 起動 #

 

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

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

31.3.2.2 フォワーダ #

 

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

31.3.2.3 基本的なオプション #

 

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

31.3.2.4 ログ記録 #

 

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

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

図 31.4: DNSサーバ: ログの記録 #

 

31.3.2.5 ACL #

 

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

{ 192.168.1/24; }

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

31.3.2.6 TSIGキー #

 

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

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

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

31.3.2.7 DNSゾーン(スレーブゾーンの追加) #

 

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

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

31.3.2.8 DNSゾーン(マスタゾーンの追加) #

 

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

31.3.2.9 DNSゾーン(マスタゾーンの編集) #

 

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

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

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

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

 

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

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

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

 

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

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

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

 

ゾーンエディタ(SOA)

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

図 31.8: DNSサーバ: ゾーンエディタ(SOA) #

 

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

このダイアログでは、名前解決を管理します。レコードキーでは、ホスト名を入力してレコードタイプを選択します。Aタイプは、メインエントリを表します。この値はIPアドレス(IPv4)でなければなりません。IPv6アドレスの場合は、AAAAを使用します。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.

31.3.2.9.1 逆引きゾーンの追加 #

 

逆引きゾーンを追加するには、以下の手順を実行します。

1. YaST › DNSサーバ › DNSゾーンを開始します。

2. マスタ転送ゾーンを追加していない場合は、追加して、編集します。

3. レコードタブで、対応するレコードキー)と値を入力し、追加でレコードを追加してから、OKで確認します。YaSTからネームサーバで存在しないレコードがある旨通知された場合、NS Records(NSレコード)タブで追加します。

   

   図 31.9: マスタゾーンのレコードを追加 #

    

4. DNSゾーンウィンドウに戻り、逆引きマスタゾーンを追加します。

   

   図 31.10: 逆引きゾーンの追加 #

    

5. 逆引きゾーンを編集すると、レコードタブに、PTR: Reverse translation（PTR逆変換)レコードタイプが表示されます。対応するレコードキーと値を追加してから、追加でレコードを追加し、OKで確認します。

   

   図 31.11: 逆引きレコードの追加 #

    

   必要に応じて、ネームサーバレコードを追加します。

ヒント: 逆引きゾーンの編集

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

SUSE® Linux Enterprise Serverシステムでは、ネームサーバBIND (Berkeley Internet Name Domain)は、事前設定されて提供されるので、インストールが正常に完了すればただちに起動できます。通常、すでにインターネットに接続し、/var/run/netconfig/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ユーザとして、systemctl start namedコマンドを入力します。systemctl status namedを使用して、ネームサーバ(呼びだされたネームサーバプロセス)が正常に起動したかどうかを確認します。サーバが正常に起動したらすぐに、hostまたはdigプログラムを用いてローカルシステム上でネームサーバをテストしてください。デフォルトサーバlocalhostとそのアドレス127.0.0.1が返されるはずです。これが返されない場合は、/var/run/netconfig/resolv.confに含まれているネームサーバエントリが誤っているか、同ファイルが存在しないかのいずれかです。最初のテストとして、「host127.0.0.1」を入力します。これは常に機能するはずです。エラーメッセージが表示された場合は、systemctl status namedコマンドを使用して、サーバが実際に起動されていることを確認します。ネームサーバが起動しないか、予期しない動作をする場合は、journalctl -eの出力を確認します。

プロバイダのネームサーバ(またはすでにネットワーク上で動作しているネームサーバ)をフォワーダとして使用する場合は、forwardersの下のoptionsセクションに、対応するIPアドレスまたはアドレスを入力します。例31.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またはゾーンファイルを変更したら、systemctl reload namedを使用して、BINDにそれらを再ロードさせます。または、systemctl restart namedを使用してネームサーバを停止してから再起動しても同じ結果が得られます。サーバはsystemctl stop namedを入力していつでも停止することができます。

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

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

$TTL 2D 1
example.com. IN SOA      dns  root.example.com. ( 2
             2003072441  ; serial 3
             1D          ; refresh 4
             2H          ; retry 5
             1W          ; expiry 6
             2D )        ; minimum 7

             IN NS       dns 8
             IN MX       10 mail dns 9
gate         IN A        192.168.5.1 10
             IN A        10.0.0.1
dns          IN A        192.168.1.116
mail         IN A        192.168.3.108
jupiter      IN A        192.168.2.100
venus        IN A        192.168.2.101
saturn       IN A        192.168.2.102
mercury      IN A        192.168.2.103
ntp          IN CNAME    dns 11
dns6         IN A6  0    2002:c0a8:174::

1	$TTLは、このファイルのすべてのエントリに適用されるデフォルトの寿命(time to live)です。この例では、エントリは2日間(2 D)有効です。
2	ここから、SOA (start of authority)制御レコードが始まります。 管理対象のドメイン名は、先頭のexample.comです。この末尾には、"."(ピリオド)が付いています。ピリオドを付けないと、ゾーンが再度、末尾に追加されてしまいます。あるいはピリオドを@で置き換えることもできます。その場合は、ゾーンが/etc/named.confの対応するエントリから抽出されます。 IN SOAの後には、このゾーンのマスタであるネームサーバの名前を指定します。この名前は、末尾に"."が付いていないので、dnsからdns.example.comに拡張されます。 この後には、このネームサーバの責任者の電子メールアドレスが続きます。@記号はすでに特別な意味を持つので、ここでは代わりに"."を使用します。root@example.comの場合、エントリはroot.example.comをクリックします。ここでもゾーンが追加されないよう、"."を末尾につける必要があります。 (は、)までの行をすべてSOAレコードに含める場合に使用します。
3	シリアル番号は10桁の数字です。このファイルが変更されるたびに変更される必要があります。変更があった場合、セカンダリネームサーバ(スレーブサーバ)に通知する必要があります。この場合、日付と実行数からなる10桁の数字は慣例的形式(YYYY = 年、MM = 月、DD = 日)のYYYYMMDDNNで記載されます。NNは指定された日に複数回アップデートする場合のシーケンス番号です。
4	リフレッシュレートは、セカンダリネームサーバがゾーンserial numberを確認する時間間隔を指定します。この例では1日です。
5	再試行間隔は、エラーが生じた場合に、セカンダリネームサーバがプライマリサーバに再度通知を試みる時間間隔を指定します。この例では2時間です。
6	有効期限は、セカンダリネームサーバがプライマリサーバに再通知できなかった場合に、キャッシュしたデータを廃棄するまでの時間枠を指定します。ここでは、1週間です。
7	SOAレコードの最後のエントリは、ネガティブキャッシュTTLです。これは、DNSクエリが解決できないという他のサーバからの結果をキャッシュしておく時間です。
8	IN NSでは、このドメインを担当するネームサーバを指定します。末尾に"."が付いていないので、dnsは、dns.example.comに拡張されます。このように、プライマリネームサーバと各セカンダリネームサーバに1つずつ指定する行がいくつかあります。/etc/named.confでnotifyをnoに設定しない限り、ゾーンデータが変更されると、ここにリストされているすべてのネームサーバにそれが通知されます。
9	MXレコードは、ドメインexample.com宛ての電子メールを受領、処理、および転送するメールサーバを指定します。この例では、ホストmail.example.comが指定されています。ホスト名の前の数字は、初期設定値です。複数のMXエントリがある場合は、最小の値を持つメールサーバが最初に取得されます。このサーバへのメール配信に失敗すると、次に低い値を持つエントリが使用されます。
10	この行と次の行は、ホスト名に1つ以上のIPアドレスが割り当てられている実際のアドレスレコードです。ここでは、名前が"."なしで一覧にされています。これは、これらの名前にはドメインが含まれていないためです。したがって、これらの名前にはすべて、example.comが追加されます。ホストgateには、ネットワークカードが2枚搭載されているので、2つのIPアドレスが割り当てられます。ホストアドレスが従来型のアドレス(IPv4)の場合、レコードにAが付きます。アドレスがIPv6アドレスの場合、エントリにAAAA が付きます。 注記: IPv6の構文 IPv6レコードの構文は、IPv4と少し異なっています。断片化の可能性があるため、アドレスの前に消失したビットに関する情報を入力する必要があります。IPv6アドレスを必要な数の「0」で埋めるには、アドレス内の正しい位置に2つコロンを追加します。 pluto AAAA 2345:00C1:CA11::1234:5678:9ABC:DEF0 pluto AAAA 2345:00D2:DA11::1234:5678:9ABC:DEF0
11	エイリアスntpをdnsの別名として使用できます(CNAMEは一般名という意味)。

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

$TTL 2D 1
168.192.in-addr.arpa.   IN SOA dns.example.com. root.example.com. ( 2
                        2003072441      ; serial
                        1D              ; refresh
                        2H              ; retry
                        1W              ; expiry
                        2D )            ; minimum

                        IN NS           dns.example.com. 3

1.5                     IN PTR          gate.example.com. 4
100.3                   IN PTR          www.example.com.
253.2                   IN PTR          cups.example.com.

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

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

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

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

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

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

tux > sudo tsig-keygen -a hmac-md5 host1-host2 > host1-host2.key

これにより、次のようなコンテンツを持つhost1-host2.keyという名前のファイルが作成されます。

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

ファイルは、できれば安全な方法で(たとえば、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セキュリティは、RFC 2535で規定されています。DNSSECで使用可能なツールは、BINDマニュアルで説明されています。

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

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

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