39 ドメインネームシステム #
DNS (ドメインネームシステム)は、ドメイン名とホスト名をIPアドレスに解決するために必要です。これにより、たとえばIPアドレス192.168.2.100がホスト名jupiter
に割り当てられます。独自のネームサーバをセットアップする前に、23.3項 「ネームレゾリューション」でDNSに関する一般的な説明を参照してください。次の設定例は、デフォルトのDNSサーバであるBINDについて示しています。
39.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を使用して複数のコンピュータ間でデータを同期化する際に使用されます。
39.2 インストール #
DNSサーバをインストールするには、YaSTを起動してから、
› の順に選択します。 › の順に選択して、 を選択します。依存関係のあるパッケージのインストールを確認して、インストールプロセスを完了します。または、コマンドラインで次のコマンドを使用します。
>
sudo
zypper in -t pattern dhcp_dns_server
39.3 YaSTでの設定 #
YaST DNSモジュールを使用して、ローカルネットワーク用にDNSサーバを設定します。このモジュールを初めて起動すると、サーバ管理に関して2、3の決定を行うように要求されます。この初期セットアップを完了すると、基本的なサーバ設定が生成されます。エキスパートモードを使用すると、より詳細な設定タスク(ACLのセットアップ、ロギング、TSIGキーなどのオプション)を処理できます。
39.3.1 ウィザードによる設定 #
ウィザードは3つのステップ(ダイアログ)で構成されています。各ダイアログの適切な箇所でエキスパート環境設定モードに入ることができます。
モジュールを初めて起動すると、図39.1「DNSサーバのインストール: フォワーダの設定」のような ダイアログが表示されます。 を使用して、次のオプションを設定できます。
auto
]に設定されますが、ここで、インタフェース名を設定したり、2つの特殊なポリシー名STATIC
およびSTATIC_FALLBACK
の一方を選択したりできます。
これらのすべての設定の詳細については、
man 8 netconfig
を参照してください。図 39.1: DNSサーバのインストール: フォワーダの設定 #フォワーダは、ご使用のDNSサーバが回答できないクエリの送信先とするDNSサーバです。フォワーダのIPアドレスを入力して、
をクリックします。39.6項 「ゾーンファイル」で説明するゾーンファイルの管理に関する項目を設定します。新しいゾーンの場合は、 にゾーン名を入力します。逆引きゾーンを追加する場合は、
ダイアログは、複数の部分で構成されており、.in-addr.arpa
で終わる名前を入力しなければなりません。最後に、 (プライマリ、セカンダリ、または転送)を選択します。図39.2「DNSサーバのインストール: DNSゾーン」を参照してください。既存のゾーンのその他の項目を設定するには、 をクリックします。ゾーンを削除するには、 をクリックします。図 39.2: DNSサーバのインストール: DNSゾーン #最後のダイアログでは、図39.3「DNSサーバのインストール: 完了ウィザード」を参照してください。
をクリックして、ファイアウォールのDNSポートを開くことができます。次に、ブート時にDNSサーバ を起動するかどうか( か、 か)を決定します。LDAPサポートを有効にすることもできます。図 39.3: DNSサーバのインストール: 完了ウィザード #
39.3.2 エキスパート設定 #
YaSTのモジュールを起動するとウィンドウが開き、複数の設定オプションが表示されます。設定を完了すると、基本的な機能が組み込まれたDNSサーバ設定が作成されます。
39.3.2.1 起動 #
では、DNSサーバをシステムのブート中に起動するか、それとも手動で起動するか指定します。DNSサーバをすぐに起動するには、 を選択します。DNSサーバを停止するには、 を選択します。現在の設定を保存するには、 を選択します。ファイアウォールのDNSポートを開くには を、ファイアウォールの設定を変更するには をクリックします。
を選択すると、ゾーンファイルがLDAPデータベースによって管理されるようになります。ゾーンデータを変更してそれがLDAPデータベースに書き込まれると、設定を再ロードするように要求されます。DNSサーバを再起動すると、変更が反映されます。
39.3.2.2 フォワーダ #
ローカルDNSサーバは、要求に応答できない場合、要求をman 8 netconfig
netconfigを参照してください。
39.3.2.3 基本的なオプション #
このセクションでは、基本的なサーバオプションを設定します。
メニューから目的の項目を選択して、対応するテキストボックスに値を指定します。新しいエントリを追加するには、 を選択してください。39.3.2.4 ログ記録 #
DNSサーバがログに記録する内容とログの方法を設定するには、
を選択します。 に、DNSサーバがログデータを書き込む場所を指定します。システム全体のログを使用する場合は を、別のファイルを指定する場合は を選択します。別のファイルを指定する場合は、ログファイルの名前、最大サイズ(メガバイト(MB))、および保管するバージョンの数も指定します。ですから、このオプションを有効にするのはデバッグ時だけにすることをお勧めします。DHCPサーバとDNSサーバ間でのゾーン更新時のデータトラフィックをログに記録するには、 を有効にします。プライマリからセカンダリサーバへのゾーン転送時のデータトラフィックをログに記録するには、 を有効にします。図39.4「DNSサーバ: ログの記録」を参照してください。
には、さらに詳細なオプションが用意されています。 を有効にすると、「すべての」クエリがログに記録されるため、ログファイルが非常に大きくなる可能性があります。39.3.2.5 ACL #
このダイアログでは、アクセス制限を強制するACL(アクセス制御リスト)を定義します。
に個別名を入力したら、次の形式で、 にIPアドレス(ネットマスクは省略可)を指定します。{ 192.168.1/24; }
設定ファイルの構文に従って、アドレスの末尾にはセミコロンを付け、中カッコで囲む必要があります。
39.3.2.6 TSIGキー #
TSIG (トランザクションシグネチャー)の主な目的は、DHCPおよびDNSサーバ間で安全な通信を行うことです。39.8項 「安全なトランザクション」を参照してください。
TSIGキーを生成するには、
フィールドに個別名を入力し、キーを格納するファイルを フィールドに入力します。 をクリックすると、選択内容が確定されます。作成済みのキーを使用するには、
フィールドを空白のままにして、 で、そのキーが保存されているファイルを選択します。その後、 をクリックすると、入力内容が確定されます。39.3.2.7 DNSゾーン(セカンダリゾーンの追加) #
セカンダリゾーンを追加するには、
を選択し、ゾーンタイプに を選択し、新規ゾーンの名前を書き込み、 をクリックします。の下の サブダイアログで、セカンダリサーバがデータをプルするプライマリサーバを指定します。サーバへのアクセスを制限するために、リストから定義済みのACLを1つ選択します。
39.3.2.8 DNSゾーン(プライマリゾーンの追加) #
プライマリゾーンを追加するには、example.com
(サブネット192.168.1.0/24
内のホストをポイントするゾーン)を追加する際には、カバーされるIPアドレス範囲の逆引きゾーンも追加する必要があります。定義上、このゾーンの名前は、1.168.192.in-addr.arpa
となります。
39.3.2.9 DNSゾーン(プライマリゾーンの編集) #
プライマリゾーンを編集するには、
を選択し、テーブルからプライマリゾーンを選択し、 をクリックします。このダイアログには、 (最初に表示される)、 、 、 、および のページがあります。図39.5「DNSサーバ: ゾーンエディタ(基本)」に示す基本ダイアログを使用すると、ダイナミックDNSの設定と、クライアントおよびセカンダリネームサーバへのゾーン転送に関するアクセスオプションを定義できます。ゾーンの動的更新を許可するには、 および対応するTSIGキーを選択します。このキーは、更新アクションの開始前に定義しておく必要があります。ゾーン転送を有効にするには、対応するACLを選択します。ACLは事前に定義しておく必要があります。
ダイアログで、ゾーン転送を有効にするかどうか選択します。リストされたACLを使用して、ゾーンをダウンロードできるユーザを定義します。
- ゾーンエディタ(NSレコード)
図39.6「DNSサーバ: ゾーンエディタ(NSレコード)」を参照してください。
ダイアログでは、指定したゾーンの代替ネームサーバを定義できます。リストに自分が使用しているネームサーバが含まれていることを確認してください。レコードを追加するには、 にレコード名を入力し、 をクリックして確定します。図 39.6: DNSサーバ: ゾーンエディタ(NSレコード) #- ゾーンエディタ(MXレコード)
現行ゾーンのメールサーバを既存のリストに追加するには、対応するアドレスと優先順位の値を入力します。その後、図39.7「DNSサーバ: ゾーンエディタ(MXレコード)」を参照してください。
を選択して確定します。図 39.7: DNSサーバ: ゾーンエディタ(MXレコード) #- ゾーンエディタ(SOA)
このページでは、SOA (start of authority)レコードを作成できます。個々のオプションについては、例39.6「/var/lib/named/example.com.zoneファイル」を参照してください。LDAPを介して管理される動的ゾーンの場合、SOAレコードの変更がサポートされないので注意してください。
図 39.8: DNSサーバ: ゾーンエディタ(SOA) #- ゾーンエディタ(レコード)
このダイアログでは、名前解決を管理します。
では、ホスト名を入力してレコードタイプを選択します。 タイプは、メインエントリを表します。この値はIPアドレス(IPv4)でなければなりません。IPv6アドレスの場合は、 を使用します。 はエイリアスです。 および の各タイプを指定すると、 および の各タブで提供される情報に基づいて、詳細レコードまたは部分レコードが展開されます。この3つのタイプのは、既存のA
レコードに解決されます。 は逆引きゾーン用レコードです。これは、次の例のように、A
レコードとは反対です。hostname.example.com. IN A 192.168.0.1 1.0.168.192.in-addr.arpa IN PTR hostname.example.com.
39.3.2.9.1 逆引きゾーンの追加 #
逆引きゾーンを追加するには、以下の手順を実行します。
プライマリ転送ゾーンを追加していない場合は、追加して、
します。- 図 39.9: プライマリゾーンのレコードを追加 #
- 図 39.10: 逆引きゾーンの追加 #
逆引きゾーンを
すると、 タブに、 レコードタイプが表示されます。対応する と を追加してから、 でレコードを追加し、 で確認します。図 39.11: 逆引きレコードの追加 #必要に応じて、ネームサーバレコードを追加します。
正引きゾーンの追加後、メインメニューに戻って、編集用の逆引きゾーンを選択します。次に、タブ
で、チェックボックス にチェック印を入れ、正引きゾーンを選択します。これにより、正引きゾーンでのすべての変更が、逆引きゾーンで自動的に更新されます。39.4 BINDネームサーバの起動 #
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サーバは、このドメインからはアクセスできません。
ネームサーバを起動するには、systemctl start
named
ユーザとして、root
コマンドを入力します。systemctl status named
を使用して、ネームサーバ(呼びだされたネームサーバプロセス)が正常に起動したかどうかを確認します。サーバが正常に起動したらすぐに、host
またはdig
プログラムを用いてローカルシステム上でネームサーバをテストしてください。デフォルトサーバlocalhost
とそのアドレス127.0.0.1
が返されるはずです。これが返されない場合は、/var/run/netconfig/resolv.conf
に含まれているネームサーバエントリが誤っているか、同ファイルが存在しないかのいずれかです。最初のテストとして、host
127.0.0.1
を入力します。これは常に機能するはずです。エラーメッセージが表示された場合は、systemctl status named
コマンドを使用して、サーバが起動されていることを確認します。ネームサーバが起動しないか、予期しない動作をする場合は、journalctl -e
の出力を確認します。
プロバイダのネームサーバ(またはすでにネットワーク上で動作しているネームサーバ)をフォワーダとして使用する場合は、forwarders
の下のoptions
セクションに、対応するIPアドレスまたはアドレスを入力します。例39.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
を入力していつでも停止することができます。
39.5 /etc/named.conf環境設定ファイル #
BINDネームサーバ自体のすべての設定は、/etc/named.conf
ファイルに格納されます。ただし、処理するドメインのゾーンデータ(ホスト名、IPアドレスなどで構成されている)は、/var/lib/named
ディレクトリ内の個別のファイルに格納されます。この詳細については、後述します。
/etc/named.conf
ファイルは、大きく2つのエリアに分けられます。1つは一般的な設定用のoptions
セクション、もう1つは個々のドメインのzone
エントリで構成されるセクションです。logging
セクションとacl
(アクセス制御リスト)エントリは省略可能です。コメント行は、行頭に#
記号または//
を指定します。最も基本的な/etc/named.conf
ファイルの例を、例39.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"; };
39.5.1 重要な設定オプション #
- ディレクトリ "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に指示します。
53
はデフォルトポートであるため、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
を参照してください。
39.5.2 ログ記録 #
BINDでは、何を、どのように、どこにログ出力するかを詳細に設定できます。通常、デフォルト設定で十分です。例39.3「ログを無効にするエントリ」は、このようなエントリの最も単純な形式を示しており、ログを抑制します。
logging { category default { null; }; };
39.5.3 ゾーンエントリ #
zone "example.com" in { type master; file "example.com.zone"; notify no; };
zone
の後、管理対象のドメイン名(example.com
)を指定し、その後にin
と関連のオプションを中カッコで囲んで指定します(例39.4「example.comのゾーンエントリ」を参照)。「セカンダリゾーン」を定義するには、type
をsecondary
に変更し、このゾーンをprimary
として管理することをネームサーバに指定します(例39.5「example.netのゾーンエントリ」参照)。これが他のプライマリサーバのセカンダリサーバとなることもあります。
zone "example.net" in { type secondary; file "secondary/example.net.zone"; masters { 10.0.0.1; }; };
ゾーンオプション
- type primary;
primary
を指定して、BINDに対し、ゾーンがローカルネームサーバによって処理されるように指示します。これは、ゾーンファイルが正しい形式で作成されていることが前提となります。- type secondary;
このゾーンは別のネームサーバから転送されたものです。必ず
primary_servers
とともに使用します。- type hint;
ルートネームサーバの設定には、
hint
タイプのゾーン.
を使用します。このゾーン定義はそのまま使用できます。example.com.zone
ファイルまたは「secondary/example.net.zone」ファイルこのエントリは、ドメインのゾーンデータが格納されているファイルを指定します。セカンダリサーバの場合は、このデータを他のネームサーバから取得するので、このファイルは不要です。プライマリサーバとセカンダリサーバのファイルを区別するため、セカンダリファイルには、
secondary
ディレクトリを使用します。- primary_servers { SERVER_IP_ADDRESS; };
このエントリは、セカンダリゾーンにのみ必要です。ゾーンファイルの転送元となるネームサーバを指定します。
- allow-update {! *; };
このオプションは、外部の書き込みアクセスを制御し、クライアントにDNSエントリへの書き込み権を付与することができます。ただし、これは通常、セキュリティ上の理由で好ましくありません。このエントリがなければ、ゾーンの更新は拒否されます。
! *
によってそのような操作が禁止されるため、前述のエントリは同じものをアーカイブします。
39.6 ゾーンファイル #
ゾーンファイルは2種類必要です。一方はIPアドレスをホスト名に割り当て、もう一方は逆にIPアドレスのホスト名を提供します。
"."
は、ゾーンファイル内で重要な意味を持ちます。ホスト名の末尾にドット(.
)がない場合は、ゾーンが追加されます。完全なホスト名を完全なドメイン名とともに指定する場合は、末尾にドット(.
)を付けて、ドメインが追加されないようにします。"."の欠落または誤った配置は、ネームサーバ設定エラーの最も多い原因と考えられます。
最初に、ドメインexample.com.zone
に責任を負うゾーンファイルexample.com
について示します(例39.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::
| |
ここから、SOA (start of authority)制御レコードが始まります。
| |
| |
| |
| |
| |
SOAレコードの最後のエントリは、 | |
| |
MXレコードは、ドメイン | |
この行と次の行は、ホスト名に1つ以上のIPアドレスが割り当てられている実際のアドレスレコードです。ここでは、名前が 注記: IPv6の構文 IPv6レコードの構文は、IPv4と少し異なっています。断片化の可能性があるため、アドレスの前に消失したビットに関する情報を入力する必要があります。IPv6アドレスを必要な数の「0」で埋めるには、アドレス内の正しい位置に2つコロンを追加します。 pluto AAAA 2345:00C1:CA11::1234:5678:9ABC:DEF0 pluto AAAA 2345:00D2:DA11::1234:5678:9ABC:DEF0 | |
エイリアス |
擬似ドメインin-addr.arpa
は、IPアドレスからホスト名への逆引き参照に使用されます。このドメインの前に、IPアドレスのネットワーク部分が逆順に指定されます。たとえば、192.168
は、168.192.in-addr.arpa
に解決されます。例39.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.
$TTLは、このファイルのすべてのエントリに適用される標準のTTLです。 | |
この設定ファイルは、ネットワーク このレコード内のエントリの詳細については、例39.6「/var/lib/named/example.com.zoneファイル」を参照してください。 | |
この行は、このゾーンを担当するネームサーバを指定します。ただし、ホスト名はドメインと末尾の | |
この行、および次の行は、各ホスト上のIPアドレスを示唆するポインタレコードです。IPアドレスの最後の部分のみが、行の最初に入力され、末尾に |
通常、ゾーン転送は、異なるバージョンのBIND間でも問題なく行えるはずです。
39.7 ゾーンデータの動的アップデート #
「動的アップデート」という用語は、プライマリサーバのゾーンファイル内のエントリが追加、変更、削除される操作を指します。このメカニズムは、RFC 2136で規定されています。動的アップデートは、オプションのallow-update
またはupdate-policy
ルールを追加することで、各ゾーンエントリに個別に設定されます。動的に更新されるゾーンを手動で編集してはなりません。
サーバに更新エントリを転送するには、nsupdate
コマンドを使用します。このコマンドの詳細な構文については、nsupdateのマニュアルページ(man
8
nsupdate
)を参照してください。セキュリティ上の理由から、こうした更新はTSIGキーを使用して実行するようにしてください(39.8項 「安全なトランザクション」参照)。
39.8 安全なトランザクション #
安全なトランザクションは、共有秘密キー(TSIGキーとも呼ばれる)に基づくトランザクション署名(TSIG)を使用して実現できます。ここでは、このキーの生成方法と使用方法について説明します。
安全なトランザクションは、異なるサーバ間の通信、およびゾーンデータの動的アップデートに必要です。アクセス制御をキーに依存する方が、単にIPアドレスに依存するよりもはるかに安全です。
TSIGキーの生成には、次のコマンドを使用します(詳細については、man
tsig-keygen
を参照)。
>
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. ;};
このトピックについての詳細は、の下の『BIND Administrator Reference Manualupdate-policy
』を参照してください。
39.9 DNSセキュリティ #
DNSSEC、またはDNSセキュリティは、RFC 2535で規定されています。DNSSECで使用可能なツールは、BINDマニュアルで説明されています。
ゾーンが安全だといえるためには、1つ以上のゾーンキーが関連付けられている必要があります。キーはホストキーと同様、dnssec-keygen
によって生成されます。現在、これらのキーの生成には、DSA暗号化アルゴリズムが使用されています。生成されたパブリックキーは、$INCLUDE
ルールによって、対応するゾーンファイルにインクルードします。
dnssec-signzone
コマンドを使用すると、生成されたキーのセット(keyset-
ファイル)を作成し、それらを安全な方法で親ゾーンに転送し、署名することができます。これによって、/etc/named.conf
内のゾーンごとにインクルードするファイルが生成されます。
39.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に関する最新情報が含まれています。