目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise Serverマニュアル / 管理ガイド / サービス / ドメインネームシステム
適用項目 SUSE Linux Enterprise Server 12 SP5

26 ドメインネームシステム

DNS (ドメインネームシステム)は、ドメイン名とホスト名をIPアドレスに解決するために必要です。これにより、たとえばIPアドレス192.168.2.100がホスト名jupiterに割り当てられます。独自のネームサーバをセットアップする前に、16.3項 「ネームレゾリューション」でDNSに関する一般的な説明を参照してください。次の設定例は、デフォルトのDNSサーバであるBINDについて示しています。

26.1 DNS用語

ゾーン

ドメインのネームスペースは、ゾーンと呼ばれる領域に分割されます。たとえば、example.comの場合は、comドメインのexampleセクション(つまりゾーン)を表します。

DNSサーバ

DNSサーバは、ドメインの名前とIP情報を管理するサーバです。マスタゾーン用にプライマリDNSサーバ、スレーブゾーン用にセカンダリサーバ、またはキャッシュ用にいずれのゾーンも持たないスレーブサーバを持つことできます。

マスタゾーンのDNSサーバ

マスタゾーンにはネットワークからのすべてのホストが含まれ、DNSサーバのマスタゾーンにはドメイン内のすべてのホストに関する最新のレコードが格納されます。

スレーブゾーンのDNSサーバ

スレーブゾーンはマスタゾーンのコピーです。スレーブゾーンのDNSサーバは、ゾーン転送操作によりマスタサーバからゾーンデータを取得します。スレーブゾーンのDNSサーバは、有効なゾーンデータである(期限切れでない)限り、ゾーンに適切に応答します。スレーブがゾーンデータの新規コピーを取得できない場合、ゾーンへの応答を停止します。

フォワーダ

フォワーダは、DNSサーバがクエリに回答できない場合に、そのクエリの転送先になるDNSサーバです。1つの環境設定内で複数の設定ソースを有効にするには、netconfigを使用します(man 8 netconfigも参照)。

レコード

レコードは、名前とIPアドレスに関する情報です。サポートされているレコードおよびその構文は、BINDのドキュメントで説明されています。次は、特別なレコードの一部です。

NSレコード

NSレコードは、指定のドメインゾーンの担当マシンをネームサーバに指定します。

MXレコード

MX(メール交換)レコードは、インターネット上でメールを転送する際に通知するマシンを説明します。

SOAレコード

SOA (Start of Authority)レコードは、ゾーンファイル内で最初のレコードです。SOAレコードは、DNSを使用して複数のコンピュータ間でデータを同期化する際に使用されます。

26.2 インストール

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

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

zypper in -t pattern dhcp_dns_server

26.3 YaSTでの設定

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

26.3.1 ウィザードによる設定

ウィザードは3つのステップ(ダイアログ)で構成されています。各ダイアログの適切な箇所でエキスパート環境設定モードに入ることができます。

  1. モジュールを初めて起動すると、図26.1「DNSサーバのインストール:フォワーダの設定」のようなフォワーダの設定ダイアログが表示されます。ローカルDNS解決ポリシーを使用して、次のオプションを設定できます。

    • フォワーダのマージは無効です

    • 自動マージ

    • フォワーダのマージは有効です

    • カスタム設定カスタム設定をオンにした場合は、カスタムポリシーを指定できます。デフォルトでは(自動マージが選択されている場合)、カスタムポリシーは[auto (自動)]に設定されますが、ここで、インタフェース名を設定したり、2つの特殊なポリシー名STATICおよびSTATIC_FALLBACKの一方を選択したりできます。

    ローカルDNS解決フォワーダで、使用するサービスとして、システムネームサーバを使用していますこのネームサーバ(バインド)、またはローカルdnsmasqサーバのいずれかを指定します。

    これらのすべての設定の詳細については、man 8 netconfigを参照してください。

    DNSサーバのインストール:フォワーダの設定
    図 26.1: DNSサーバのインストール:フォワーダの設定

    フォワーダは、ご使用のDNSサーバが回答できないクエリの送信先とするDNSサーバです。フォワーダのIPアドレスを入力して、追加をクリックします。

  2. DNSゾーンダイアログは、複数の部分で構成されており、26.6項 「ゾーンファイル」で説明するゾーンファイルの管理に関する項目を設定します。新しいゾーンの場合は、名前にゾーン名を入力します。逆引きゾーンを追加する場合は、.in-addr.arpaで終わる名前を入力しなければなりません。最後に、タイプ(マスタ、スレーブ、または転送)を選択します。図26.2「DNSサーバのインストール:DNSゾーン」を参照してください。既存のゾーンのその他の項目を設定するには、Editをクリックします。ゾーンを削除するには、Deleteをクリックします。

    DNSサーバのインストール:DNSゾーン
    図 26.2: DNSサーバのインストール:DNSゾーン
  3. 最後のダイアログでは、ファイアウォールで開いているポートをクリックして、ファイアウォールのDNSポートを開くことができます。次に、ブート時にDNSサーバ を起動するかどうか(オンか、オフか)を決定します。LDAPサポートを有効にすることもできます。詳細については、図26.3「DNSサーバのインストール:完了ウィザード」を参照してください。

    DNSサーバのインストール:完了ウィザード
    図 26.3: DNSサーバのインストール:完了ウィザード

26.3.2 エキスパート設定

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

26.3.2.1 起動

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

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

26.3.2.2 フォワーダ

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

26.3.2.3 基本的なオプション

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

26.3.2.4 ログ

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

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

DNSサーバ:ログの記録
図 26.4: DNSサーバ:ログの記録

26.3.2.5 ACL

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

{ 192.168.1/24; }

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

26.3.2.6 TSIGキー

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

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

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

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

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

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

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

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

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

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

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

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

DNSサーバ: ゾーンエディタ(基本)
図 26.5: DNSサーバ: ゾーンエディタ(基本)
ゾーンエディタ(NSレコード)

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

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

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

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

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

DNSサーバ:ゾーンエディタ(SOA)
図 26.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.
26.3.2.9.1 逆引きゾーンの追加

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

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

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

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

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

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

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

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

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

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

26.4 BINDネームサーバの起動

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

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

例 26.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エントリの後には、ゾーン用のエントリ、localhost0.0.127.in-addr.arpaが続きます。.の下のtype hint(タイプヒント)は必ず存在しなければなりません。対応するファイルは、変更する必要がなく、そのままで機能します。また、各エントリの末尾が;で閉じられ、中カッコが適切な位置にあることを確認してください。環境設定ファイル/etc/named.confまたはゾーンファイルを変更したら、systemctl reload namedを使用して、BINDにそれらを再ロードさせます。または、systemctl restart namedを使用してネームサーバを停止してから再起動しても同じ結果が得られます。サーバはsystemctl stop namedを入力していつでも停止することができます。

26.5 The /etc/named.conf環境設定ファイル

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

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

例 26.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";
};

26.5.1 重要な設定オプション

directory "FILENAME";

BINDが検索する、ゾーンファイルが格納されているディレクトリを指定します。通常は/var/lib/namedです。

forwarders { IP-ADDRESS; };

DNS要求が直接解決できない場合、それらが転送されるネームサーバ(ほとんどの場合、プロバイダのネームサーバ)を指定します。IP-ADDRESSには、IPアドレスを192.168.1.116のように指定します。

forward first;

ルートネームサーバでDNS要求の解決を試みる前に、それらを転送するようにします。forward firstの代わりにforward onlyを指定すると、要求が転送されたままになり、ルートネームサーバには送り返されません。このオプションは、ファイアウォール構成で使用します。

listen-on port 53 { 127.0.0.1; IP-ADDRESS; };

BINDがクライアントからのクエリを受け取るネットワークインタフェースとポートを指定します。port 53はデフォルトポートであるため、明示的に指定する必要はありません。ローカルホストからの要求を許可するには、127.0.0.1と記述します。このエントリ全体を省略した場合は、すべてのインタフェースがデフォルトで使用されます。

listen-on-v6 port 53 {any; };

BINDがIPv6クライアント要求をリッスンするポートを指定します。any以外で指定できるのはnoneだけです。IPv6に関して、サーバはワイルドカードアドレスのみ受け付けます。

query-source address * port 53;

ファイアウォールが発信DNS要求をブロックする場合、このエントリが必要です。BINDに対し、外部への要求をポート53から発信し、1024を超える上位ポートからは発信しないように指示します。

query-source address * port 53;

BINDがIPv6のクエリに使用するポートを指定します。

allow-query { 127.0.0.1; NET; };

クライアントがDNS要求を発信できるネットワークを定義します。NETには、アドレス情報を192.168.2.0/24のように指定します。末尾の/24は、ネットマスクの短縮表記で、この場合255.255.255.0を表します。

allow-transfer ! *;;

ゾーン転送を要求できるホストを制御します。この例では、!が使用されているので、ゾーン転送要求は完全に拒否されます。*. このエントリがなければ、ゾーン転送をどこからでも制約なしに要求できます。

statistics-interval 0;

このエントリがなければ、BINDは1時間ごとに数行の統計情報を生成してシステムのジャーナルに保存します。0を指定すると、統計情報をまったく生成しないか、時間間隔を分単位で指定します。

cleaning-interval 720;

このオプションは、BINDがキャッシュをクリアする時間間隔を定義します。キャッシュがクリアされるたびに、システムのジャーナルにエントリが追加されます。時間の指定は分単位です。デフォルトは60分です。

statistics-interval 0;

BINDは定期的にインタフェースを検索して、新しいインタフェースや存在しなくなったインタフェースがないか確認します。この値を0に設定すると、この検索が行われなくなり、BINDは起動時に検出されたインタフェースのみをリッスンします。0以外の値を指定する場合は分単位で指定します。デフォルトは60分です。

notify no;

noに設定すると、ゾーンデータを変更したとき、またはネームサーバが再起動されたときに、他のネームサーバに通知されなくなります。

すべての利用可能なオプションのリストについては、マニュアルページman 5 named.confを参照してください。

26.5.2 ロギング

BINDでは、何を、どのように、どこにログ出力するかを詳細に設定できます。通常は、デフォルト設定のままで十分です。例26.3「ログを無効にするエントリ」に、このエントリの最も簡単な形式、すなわちログをまったく出力しない例を示します。

例 26.3: ログを無効にするエントリ
logging {
        category default { null; };
};

26.5.3 ゾーンエントリ

例 26.4: example.comのゾーンエントリ
zone "example.com" in {
      type master;
      file "example.com.zone";
      notify no;
};

zoneの後、管理対象のドメイン名(example.com)を指定し、その後にinと関連のオプションを中カッコで囲んで指定します(例26.4「example.comのゾーンエントリ」参照)。スレーブゾーンを定義するには、typeslaveに変更し、このゾーンをmasterとして管理することをネームサーバに指定します(例26.5「example.netのゾーンエントリ」参照)。これが他のマスタのスレーブとなることもあります。

例 26.5: example.netのゾーンエントリ
zone "example.net" in {
      type slave;
      file "slave/example.net.zone";
      masters { 10.0.0.1; }; 
};

ゾーンオプション

type master;

masterを指定して、BINDに対し、ゾーンがローカルネームサーバによって処理されるように指示します。これは、ゾーンファイルが正しい形式で作成されていることが前提となります。

type slave;

このゾーンは別のネームサーバから転送されたものです。必ずmastersとともに使用します。

type hint;

ルートネームサーバの設定には、ゾーン.(hintタイプ)を使用します。このゾーン定義はそのまま使用できます。

example.com.zoneファイルまたはslave/example.net.zoneファイル

このエントリは、ドメインのゾーンデータが格納されているファイルを指定します。スレーブの場合は、このデータを他のネームサーバから取得するので、このファイルは不要です。マスタとスレーブのファイルを区別するには、スレーブファイルにディレクトリslaveを使用します。

masters { SERVER_IP_ADDRESS; };

このエントリは、スレーブゾーンにのみ必要です。ゾーンファイルの転送元となるネームサーバを指定します。

allow-update {! *; };

このオプションは、外部の書き込みアクセスを制御し、クライアントにDNSエントリへの書き込み権を付与することができます。ただし、これは通常、セキュリティ上の理由で好ましくありません。このエントリがなければ、ゾーンの更新は拒否されます。! *によってそのような操作が禁止されるため、前述のエントリは同じものをアーカイブします。

26.6 ゾーンファイル

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

ヒント
ヒント: ゾーンファイルでのドット(ピリオド、フルストップ)の使用

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

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

例 26.6: /var/lib/named/example.com.zoneファイル
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::
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行目:

シリアル番号は任意の番号で、このファイルを変更するたびに増加します。変更があった場合、セカンダリネームサーバ(スレーブサーバ)に通知する必要があります。これには、日付と実行番号をYYYYMMDDNNという形式で表記した10桁の数値が、慣習的に使用されています。

4行目:

リフレッシュレートは、セカンダリネームサーバがゾーンserial numberを確認する時間間隔を指定します。この例では1日です。

5行目:

再試行間隔は、エラーが生じた場合に、セカンダリネームサーバがプライマリサーバに再度通知を試みる時間間隔を指定します。この例では2時間です。

6行目:

有効期限は、セカンダリネームサーバがプライマリサーバに再通知できなかった場合に、キャッシュしたデータを廃棄するまでの時間枠を指定します。ここでは、1週間です。

7行目:

SOAレコードの最後のエントリは、ネガティブキャッシュTTLです。これは、DNSクエリが解決できないという他のサーバからの結果をキャッシュしておく時間です。

9行目:

IN NSでは、このドメインを担当するネームサーバを指定します。dnsは、dns.example.comに拡張されます。これは、末尾に「.」が付いていないためです。このように、プライマリネームサーバと各セカンダリネームサーバに1つずつ指定する行がいくつかあります。/etc/named.confnotifynoに設定しない限り、ゾーンデータが変更されると、ここにリストされているすべてのネームサーバにそれが通知されます。

10行目:

MXレコードは、ドメインexample.com宛ての電子メールを受領、処理、および転送するメールサーバを指定します。この例では、ホストmail.example.comが指定されています。ホスト名の前の数字は、初期設定値です。複数のMXエントリがある場合は、最小の値を持つメールサーバが最初に取得されます。このサーバへのメール配信に失敗すると、次に高い値を持つエントリが使用されます。

12~19行目:

これらは、ホスト名に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
20行目:

エイリアスntpdnsの別名として使用できます(CNAME一般名という意味)。

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

例 26.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.
1行目:

$TTLは、このファイルのすべてのエントリに適用される標準のTTLです。

2行目:

この設定ファイルは、ネットワーク192.168の逆引きを有効にします。ゾーン名は168.192.in-addr.arpaであり、これはホスト名に追加しません。したがって、すべてのホスト名は完全な形で、つまりドメインと末尾の"."が付いて指定されます。残りのエントリは、前出のexample.comの例の記述と同じです。

3~7行目:

前出の例のexample.comを参照してください。

9行目:

正引きの場合と同様、この行は、このゾーンを担当するネームサーバを指定します。ただし、ホスト名はドメインと末尾の"."(ピリオド)が付いた完全な形で指定されます。

11~13行目:

これらはそれぞれのホスト上でのIPアドレスを示すポインタレコードです。IPアドレスの最後の部分のみが、行の最初に入力され、末尾に"."(ピリオド)は付きません。ゾーンをこれに追加すると(.in-addr.arpaを付けずに)、完全なIPアドレスが逆順で生成されます。

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

26.7 ゾーンデータの動的アップデート

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

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

26.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を使用して)、リモートホストに転送する必要があります。host1host2の間で安全な通信ができるようにするには、リモートサーバでキーを/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には、キーを持つファイルへの絶対パスを指定します。

サーバhost1host2(この例では、アドレス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』を参照してください。

26.9 DNSセキュリティ

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

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

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

26.10 その他の情報

ここで扱ったトピックの詳細については、/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に関する最新情報が含まれています。