DNSサーバーをバインドする

このページでは、DNSプロトコルとBINDDNSサーバー DNSドメインを作成および管理するためのWebminモジュールと同様に説明されています。

ドメインネームシステムの概要を参照

コンテンツ

BINDDNSサーバーモジュール

BIND（Berkeley Internet Name Domain）は、Unixシステムで最も一般的なDNSサーバーです。何年にもわたっていくつかのバージョンがリリースされており、最新のものはバージョン9です。BINDDNSサーバーモジュール（サーバーカテゴリの下にあります）は、バージョン8および9の構成をサポートします。古いバージョン4は、構成ファイル形式が異なり、次のことができます。この章の後のセクションで説明するBIND4DNSサーバーモジュールを使用して構成できます。

BINDはほとんどすべてのUnixシステムで使用でき、オペレーティングシステムに関係なく同じように機能するため、この章の手順はLinuxだけでなく他のバージョンのUnixにも適用されます。 UnixおよびLinuxのほとんどのバージョンには、標準パッケージとしてBIND 8または9が含まれているため、インストールする必要はほとんどありません。モジュールがDNSサーバーを見つけられない場合は、メインページにエラーメッセージが表示されます。これが発生した場合は、オペレーティングシステムのCDまたはWebサイトでBINDパッケージを確認するか、http：//www.iscからソースをダウンロードしてコンパイルしてください。 .org/。

BINDのプライマリ構成ファイルは/etc/named.confであり、サーバーがホストするすべてのゾーンと、すべてのゾーンに適用されるグローバル構成設定が含まれています。各ゾーンのレコードは、通常/ var/namedディレクトリにある個別のファイルに保存されます。このWebminモジュールは、実行中のBINDプロセスと通信するのではなく、常にこれらのファイルすべてを直接更新します。つまり、BINDと通信してゾーンを動的に更新する他のプログラム（DHCPサーバーなど）を実行している場合は、これらの変更を妨げる可能性があるため、このモジュールは使用しないでください。ただし、この種の動的更新がアクティブになっているシステムはほとんどありません。

BINDのバージョン9には、バージョン8にはない機能がいくつかあります。このWebminモジュールでサポートされている最も重要なものはビューです。ビューは、一部のDNSクライアントにのみ表示されるゾーンのセットです。通常、すべてのクライアントは同じゾーンを認識しますが、BIND 9を使用すると、一部のドメインの表示を、IPアドレスで識別される特定のクライアントのみに制限できます。これは、DNSサーバーがインターネットに接続されている場合でも、内部ネットワーク上のシステムにのみ表示されるゾーンを作成する場合に役立ちます。

システムにBINDを設定したことがない場合は、モジュールに初めて入ると、メインページにDNSサーバーを設定するためのフォームが次のように表示されます。このフォームは、Webminがnamed.confという構成ファイルが存在しないことを検出した場合、または指定されたゾーンファイルディレクトリが存在しない場合にのみ表示されます。 BIND構成が有効であり、DNSサーバーがすでに実行されていることが確実な場合は、作成をクリックしないでください。名前付き.confファイルが上書きされるため、ボタンをクリックします。代わりに、 Module Configをクリックしてくださいリンクして、システムのすべてのパスが正しいことを確認します。

バインドインストール

システムにBINDを設定すると、下のスクリーンショットに示すようにメインページが表示されます。上部には、DNSサーバー全体に適用されるグローバルオプションを設定するためのアイコンの表があります。その下には、サーバーがホストする各ゾーンのアイコンがあり、BINDバージョン9を実行している場合は、ビューのアイコンが続きます。一番下には、現在のDNS構成を適用するかBINDサーバーを起動するためのボタンがあります。

初めてBINDを設定した場合は、おそらく1つのゾーンアイコン（ルートゾーン）のみが表示されます。 BINDパッケージを含む一部のLinuxディストリビューションには、ローカルホストおよび127.0.0.lループバックホスト名とIPアドレスを解決するために使用されるlocaldomainや127.0.0などのゾーンを定義する基本構成ファイルが付属しています。

DNSサーバーのメインページをバインド

新しいマスターゾーンの作成

マスターゾーンは、DNSサーバーが信頼できる情報源であるゾーンです。単一のゾーンが複数のサーバーによってホストされる場合がありますが、マスターは1つだけで、残りはすべてスレーブです。サーバーの構成に新しいマスターゾーンを追加する場合は、次の手順に従います。

example.comやinternalなどの新しいゾーンの名前を決定します。これが世界中の他のすべての人に表示されるインターネットドメインになる場合、ドメイン名はまだ他の人によって登録されていない必要があります。ただし、DNSサーバーがホストするように設定されるまで、通常は自分で登録することはできません。
モジュールのメインページで、新しいマスターゾーンの作成をクリックします。既存のゾーンの表の下にあるリンク。これにより、新しいゾーンの詳細を入力するための、下の画像に示されているページに移動します。
これをexample.comやfoo.com.auのようなフォワードゾーンにする場合は、ゾーンタイプのままにします。フィールドを転送に設定。ただし、IPアドレスからホスト名を検索するための逆引きゾーンである場合は、フィールドを逆引きに設定します。。
ドメイン名/ネットワーク フィールドに、末尾のドットなしでゾーンの名前を入力します。逆引きゾーンの場合は、192.168.1のようなネットワークアドレスを入力するだけです。ドメインが作成されると、Webminはこれを自動的にin-addr.arpa形式に変換します。
レコードファイル フィールドは、ゾーンのレコードを含む構成ファイルが保存される場所を制御します。自動に設定したままにすると、ファイル名は、モジュールの構成とnamed.confファイルのディレクトリ設定に基づいて自動的に決定されます。これは通常、最良のオプションです。これにより、レコードファイルが/ var/namedなどの既存のゾーンと同じディレクトリに作成されるためです。ただし、自動の選択を解除した場合オプションを選択し、代わりにファイル名を入力すると、ゾーンのすべてのレコードがそのファイルに書き込まれます。既存のファイルの名前を入力すると、ドメインの作成時に上書きされます。
マスターサーバー フィールドに、このゾーンのマスターDNSサーバーの完全ドメイン名を入力します。これは、serverのような短い名前ではなく、server.example.comなどのシステムの正規名である必要があります。このサーバー（および次のサーバーからの値
フィールド）は、新しいゾーンのSOAレコードを作成するために使用されます。
メールアドレス フィールドに、このゾーンの責任者の住所を入力します。アドレスに@記号を使用できます。これは、WebminがSOAレコードに含めるために自動的にドットに変換します。
更新時間 フィールドは、セカンダリサーバーがゾーンの更新についてこのマスターサーバーに確認する頻度を決定します。デフォルトは妥当ですが、ほとんど変更されないゾーンの場合は増やすか、頻繁に更新されるゾーンの場合は減らすことができます。
転送の再試行時間 フィールドは、ゾーン転送が失敗した後、再試行する前にセカンダリサーバーが待機する時間を決定します。
有効期限 フィールドは、ゾーンのセカンダリDNSサーバーがマスターからレコードを再転送する前にレコードをキャッシュする最大時間を制御します。
デフォルトの有効期間 フィールドは、明示的に設定されていないゾーン内のレコードのTTLを決定します。
作成をクリックしますページ下部のボタン。フォームが正しく入力されていて、ゾーンがサーバーにまだ存在していない限り、ゾーンに新しいレコードを追加するためのページが表示されます。
モジュールのメインページに戻ります。このページには新しいゾーンのアイコンが表示され、変更の適用をクリックします。下部にあるボタンを押してアクティブにします。

マスターゾーンの作成.png

新しく作成されたゾーンには、（テンプレートを設定していない限り）1つのレコードのみが含まれます。さらに追加するには、次のセクションの手順に従ってください。ドメインに基本レコードを設定したら、.comや.com.auなどの親ドメインを管理する機関に登録できます。一部のドメインオーソリティでは、少なくとも2つのサーバー（1つはマスターと1つはスレーブ）がないゾーンを登録し、それらのサーバーのゾーンにサーバーレコードに名前を付けることを許可しません。

レコードの追加と編集

バインド-マスターゾーンの編集

BIND DNSサーバーモジュールの最も便利な機能は、サーバーによってホストされているマスターゾーンのレコードを追加、編集、および削除する機能です。たとえば、ドメインexample.comにWebサーバーを設定する場合は、サーバーのIPアドレスを使用してwww.example.comのアドレスレコードを追加する必要があります。このような新しいレコードを追加するには、次の手順に従います。

モジュールのメインページで、追加するゾーンのアイコンをクリックします。これにより、以下に示すページが表示されます。その上部には、レコードタイプごとに1つずつ、アイコンのテーブルがあります。
追加するレコードの種類のアイコンをクリックします。最も一般的なタイプはアドレスです、IPアドレスをホスト名に関連付けます。 ＃レコードタイプを参照してくださいサポートされているすべてのレコードタイプの完全なリストについては、以下のセクションを参照してください。
アイコンをクリックすると、そのタイプの既存のすべてのレコードを一覧表示するページに移動します。リストの上には、新しいレコードを入力するためのフォームがあります。
名前フィールドに、ゾーン名を基準にした新しいレコードの名前を入力します。たとえば、レコードwww.example.comを追加する場合は、 wwwと入力するだけです。。ゾーンに関連していないことを示すために末尾にドットが付いている限り、完全なレコード名を入力することもできます。 www.example.comだけを入力しないでください、www.example.com.example.comに変換されるため、おそらくあなたが望むものではありません。
このレコードがゾーンの他の部分よりも頻繁に変更される場合は、存続時間を変更してください。 デフォルトのフィールド変更間の推定時間に。これにより、DNSクライアントおよび他のサーバーがレコードをキャッシュする期間が決まります。
アドレスレコードを追加する場合は、ホストの完全なIPアドレスをアドレスに入力します分野。他のタイプのレコードを追加するときに表示されるフィールドの説明とその意味については、以下の表を参照してください。
フィールドUpdatereverse？ アドレスレコードを追加するときにのみ表示されます。これは、ホスト名をIPアドレスに関連付ける逆引きゾーンでの対応するレコードの自動作成を制御します。当然、これは、入力したIPが、システムがプライマリリバースDNSサーバーであるネットワーク内にある場合にのみ実行できます。これにより、順方向ゾーンと逆方向ゾーンの同期が維持され、非常に便利です。はいの場合を選択すると、同じIPアドレスの逆引きゾーンに逆引きアドレスレコードがまだ存在しない限り、逆引きアドレスレコードが追加されます。多くの場合、名前ベースの仮想ホスティングに使用されるものなど、多くのホスト名が同じIPを持ちます。このような場合、リバースマッピングがすでに存在する場合は、リバースマッピングを変更したくありません。 *はい（および既存のものを置き換える）*オプションははいと同じように機能します、ただし、IPアドレスの逆レコードがすでに存在する場合は、新しいホスト名で更新されます。これは、置き換えたい既存のレコードがあることがわかっている場合に役立ちます。 いいえの場合が選択されている場合、可能な場合でもリバースアドレスは作成されません。
フォームへの入力が完了したら、[作成]をクリックします下部のボタン。正しく記入されている限り、レコードはフォームの下のリストに追加されます。ゾーンのレコードファイルに書き込む場合、Webminは、wwwと入力しただけでも、www.example.com。などのレコード名に完全な標準形式を使用します。
DNSクライアントや他のサーバーで検索できるように新しいレコードをアクティブ化するには、[変更の適用]をクリックする必要があります。モジュールのメインページのボタン。複数のレコードを追加または編集する場合は、通常、すべての変更が完了するまで待ってから、[適用]ボタンをクリックすることをお勧めします。利用可能な場合は、代わりに変更の適用を使用できます以下に示すマスターゾーンページの下部にあるボタン。これは、ndcコマンドを使用して、このゾーンのファイルのみを再読み取りするようにBINDに指示します。これは、ホストが多数のドメインであるシステムでははるかに高速です。

バインド-ゾーンにレコードを追加

上記の手順はアドレスレコードの追加に焦点を当てていますが、他の種類のレコードを転送ゾーンに追加するプロセスはほとんど同じです。 逆に更新しますか？ フィールドが存在せず、アドレス フィールドは、1つ以上の異なるフィールドに置き換えられます。 レコードタイプ 以下のセクションでは、Webminが認識している各タイプのレコードで使用できるフィールドについて詳しく説明します。

逆引きアドレスレコードを逆引きゾーンに追加する場合、形式はまったく異なります。住所 ホスト名の前にフィールドが表示されます、およびホスト名は、www.example.com。のように、常に末尾にドットが付いた標準形式で入力する必要があります。。 逆に更新しますか？ フィールドは更新しますか？に置き換えられます、対応するフォワードゾーンでのレコードの自動作成を制御します。ただし、既存の転送レコードを上書きするオプションはありません。同じ名前のレコードがすでに存在する場合は、はいであっても変更されません。が選択されています。

Webminを使用してゾーンにレコードが追加または更新されるたびに、そのシリアル番号が自動的にインクリメントされます。これは、アドレスレコードを追加するときに自動的に更新されるリバースゾーンにも当てはまります。その逆も同様です。これは、変更を適用すると、他のDNSサーバーが、新しいシリアル番号をキャッシュした古いシリアル番号と比較することで、ゾーンが変更されたことを検出できることを意味します。

ゾーン内の既存のレコードを編集するには、次の手順に従います。

モジュールのメインページで、編集するゾーンのアイコンをクリックすると、上のページが表示されます。
変更するレコードの種類のアイコンをクリックすると、ゾーン内のその種類のすべてのレコードを一覧表示するページが表示されます。または、すべてのレコードタイプをクリックすることもできますタイプに関係なく、ゾーン内のすべてのレコードのリストを表示するアイコン。
編集するレコードの名前をクリックします。ブラウザには、レコードの追加に使用されるものと同様のフォームが表示されますが、フィールドには既存の住所の詳細がすでに入力されています。
レコードの名前を変更するには、名前の内容を編集します分野。最初は末尾にドットが付いた標準形で表示されますが、必要に応じてドメインに関連する名前に変更できます。
存続時間を調整しますこのレコードに別のTTLを設定するか、デフォルトに設定するフィールドゾーンの他の部分と同じにします。
これがアドレスレコードの場合は、アドレスのIPを変更します分野。他のレコードタイプの場合、フィールドはレコード作成フォームのフィールドと同じであり、同じ意味を持ちます。
アドレスレコードの場合、フィールド Update reverse？ 表示されています。はいを選択する逆引きゾーンの対応するレコードの名前とアドレスが、この順方向レコードと一致するように変更されます。逆引きアドレスが同じネットワークに存在しないようにIPを変更すると、古い逆引きゾーンから削除され、新しい逆引きゾーンに追加されます（サーバーによってホストされている場合）。
リバースアドレスレコードの場合、フィールド Update forward？ 代わりにが表示されます。はいの場合を選択すると、このフォームで行った変更に一致するように、転送ゾーンの対応するアドレスレコードが変更されます。
保存をクリックしますボタンをクリックしてゾーンファイルのレコードを更新し、レコードタイプのリストに戻ります。
変更を有効にするには、[変更を適用]をクリックしますモジュールのメインページに戻るボタン。

ゾーンからレコードを削除するには、削除をクリックします保存の代わりに編集フォームのボタン。アドレスレコードの場合、逆に更新しますか？ フィールドがはいに設定されている、対応するリバースアドレスレコードも削除されます。それを除けば、レコードを削除するプロセスは、それがどのタイプであっても同じです。リバースアドレスレコードを削除する場合も同じことが起こります。前方に更新しますか？である限り、一致するアドレスレコードも削除されます。フィールドがはいに設定されている。

ゾーン内のレコードのリストは、最初はモジュール構成に従ってソートされます。これは通常、レコードが追加された順序で表示されることを意味します。これを変更するには、名前のような列見出しをクリックします。、住所または本名代わりに、その列で並べ替えます。ただし、並べ替えは一時的なものであり、メインページに戻ってゾーンを再度開くと失われます。永続的に変更するには、レコードを表示する順序を参照してください。 BINDDNSサーバーモジュールの構成のセクションのフィールド。

レコードタイプ

Webminは、BINDが認識しているすべてのレコードタイプをサポートしているわけではなく、最も一般的に使用されているレコードタイプのみをサポートしています。以下のリストは、サポートされているすべてのタイプをカバーし、それらが何に使用されるか、およびWebminでそのタイプのレコードを追加または編集するときに使用できるフィールドについて説明しています。各タイプ名の横には、レコードファイルでタイプを識別するためにBIND自体が使用するショートコードがあります。

アドレス（A）: アドレスレコードは、IPv4アドレスをホスト名に関連付けます。ホスト名を使用してHTTP、telnet、またはその他のプロトコルを介して接続できるようにするシステムには、クライアントがIPを検索できるようにアドレスレコードが必要です。 1つのホスト名に複数のアドレスレコードを含めることができます。これは、多くの場合、Webサイトの負荷を複数のサーバーに分散するために行われます。名前ベースのApache仮想サーバーをセットアップする場合など、名前は異なるがIPが同じであるこのタイプの複数のレコードを作成することも有効です。アドレスレコードを作成または編集する場合、フィールドアドレス ホスト名に関連付けられたIPを入力するためにが表示されます。 Update reverse？というラベルの付いたフィールドまた、適切な逆引きゾーンでの逆引きアドレスレコードの自動作成と変更を制御するものも表示されます。 レコードの追加と編集を参照してください詳細については、上記のセクションをご覧ください。
IPv6アドレス（AAAA）: IPv6アドレスレコードは、IPv6アドレスをAレコードと同様のホスト名に関連付けます。
ネームサーバー（NS）: このタイプのレコードは、ゾーンを担当するネームサーバーを定義します。すべてのゾーンには、それ自体に少なくとも1つのネームサーバーレコードが必要です。また、サブドメインを担当するDNSサーバーを指定する追加のレコードが含まれる場合があります。ゾーンにセカンダリDNSサーバーを設定する場合は、必ずマスターサーバーにゾーンのネームサーバーレコードを追加してください。この場合、レコードの名前は、example.com。などのゾーンの正規名になります。。このタイプのレコードを作成または編集する場合、 Name Serverというラベルの付いたフィールドが表示されます。これには、ゾーンを担当するDNSサーバーのIPアドレスまたはホスト名を入力する必要があります。ホスト名を入力する場合は、サーバーの一部のゾーンのアドレスレコードによって設定されたIPアドレスが必要です。
名前エイリアス（CNAME）: このタイプのレコードは、既存のアドレスまたはリバースアドレスレコードの追加の名前を作成します。 DNSクライアントがこのタイプのレコードのIPアドレスを要求すると、代わりに名前エイリアスが指すレコードのIPを取得します。この種のレコードは、名前ベースの仮想ホスティングを実行するWebサーバーなど、複数の異なる名前でアクセスできる必要がある単一のホストがある場合に役立ちます。これは複数のアドレスレコードを作成することでも実行できますが、ホストのIPアドレスが変更された場合に更新が容易になるため、単一のアドレスと複数の名前エイリアスを作成する方が柔軟性があります。 Name Aliasレコードを編集および作成するためのフォームには、 Real Nameというラベルの付いたフィールドが含まれています。。これには、エイリアスが指すレコードの正規名（webserver.example.com。など）を入力する必要があります。）、またはNameAliasレコードが含まれるゾーンに関連する短い名前を使用します。
メールサーバー（MX）: メールサーバーレコードは、SendmailやQmailなどのメール配信プログラムに、ドメインまたはホストにメールを配信するときに接続するシステムを通知します。このタイプのレコードがない場合、ドメインのメールは、ゾーン自体のアドレスレコードでIPが指定されているシステムに配信されます。 Webブラウザがhttp://www.example.com/だけでなくhttp://www.example.com/にも接続できるように、そのIPをWebサーバーのアドレスにしたい場合があるため、これは必ずしも望ましいことではありません。メールサーバーレコードは、example.comの電子メールのみを別のホストに送信し、他のすべてのトラフィックをWebサーバーに送信することで、この問題を解決できます。各メールサーバーレコードには優先度があり、どのメールサーバーを最初に試行するかをメール配信プログラムに指示します。優先度が最も低いレコードは、ドメインの電子メールを実際に受信して保存するシステムを指している必要がありますが、優先度が高いレコードは、通常、単にメールを中継するシステムを指します。配信プログラムは、最も低いものから順番にそれぞれを試行します。これにより、プライマリメールサーバーがダウンした場合でも、プライマリが復旧するまでメールを保持できるリレーにメールが送信されます。; メールサーバーレコードを追加または編集すると、2つの追加フィールドが表示されます。 1つ目はメールサーバーというラベルが付いています、および名前に入力されたドメインまたはホスト名のメールを受け入れることができるシステムの正規または相対ホスト名を入力する必要があります分野。 2番目のラベルは優先度です。、およびこの特定のメールサーバーの数値の優先度を指定するために使用する必要があります。通常、優先度5はプライマリメールサーバーに使用され、10はバックアップリレーに使用されます。ドメインにメールサーバーが1つしかない場合は、このフィールドに入力する番号は重要ではありません。 2つのサーバーが同じ優先順位を持つ可能性があります。その場合、1つがランダムに選択されて配信されます。メールサーバーレコードは、名前に*ワイルドカードを使用できます。これは、特定のメールサーバーがドメイン内のすべてのホストを担当していることをメールプログラムに示します。たとえば、*。example.comのような名前のレコードホスト名pc1.example.comおよびゾーン内の他のホストと一致します。これは、ドメイン内のワークステーションに直接配信されるメールを、代わりに中央のメールサーバーを経由するように強制する場合に役立ちます。 ワイルドカードを許可しない限り、Webminはワイルドカードの使用を許可しませんモジュール構成オプションがはいに設定されているただし、*BINDDNSサーバーモジュールの構成*セクションで説明されているように。
ホスト情報（HINFO）: このタイプのレコードは、特定のホストのハードウェアおよびオペレーティングシステムに関する情報を記録するために使用されます。たとえば、 server1.example.comというものを作成できます。 Linuxを実行しているx86PCです。ただし、これらが使用されることはめったになく、サーバーを乗っ取るために使用される可能性のある潜在的な攻撃者に情報を提供するため、実際にはセキュリティリスクと見なされます。ホスト情報レコードを作成または編集する場合、フィールドハードウェア およびオペレーティングシステム ホストのアーキテクチャとオペレーティングシステムの種類を入力するために表示されます。入力する値にはスペースを含めることはできません。通常、ハードウェアタイプおよびオペレーティングシステムの文字列では、_文字に置き換えられます。
テキスト（TXT）: テキストレコードは、ある種の任意のメッセージを名前に関連付けます。 TXTレコードは、SPFおよびDKIMなどのメール機能に所有権情報を提供するために使用できます。ただし、このようなコメントは、ドメイン内のレコードを検索できるインターネット上のすべてのユーザーが利用できるため、機密情報を含めるべきではないことに注意してください。フィールドメッセージ テキストレコードを入力または編集するときに表示されます。スペースを含め、好きなテキストを入力できます。
既知のサービス（WKS）: このタイプのレコードは、ホスト名、ポート、およびプロトコルを名前に関連付けます。これは、メールサーバーレコードの一般化されたバリアントと考えることができます。これは、どのホストが特定のドメインまたはホスト名に特定のサービスを提供するかをクライアントに通知します。ただし、実際にWKSレコードを検索するプログラムはほとんどないため、実際にはほとんど役に立ちません。これらのレコードの1つを追加または編集する場合、フィールドアドレス 、プロトコル およびサービス 利用可能です。 1つ目は、名前に入力したホストまたはドメインにサービスを提供するホストのIPアドレスを入力するためのものです。分野。 2つ目は、サービスが使用するネットワークプロトコル（TCPまたはUDP）を選択するためのものです。最後は、ホストが提供するサービスのポート番号または名前のリストを（/ etc / servicesファイルから）入力するためのものです。
責任者（PR）: このタイプのレコードは、特定のホストの責任者またはグループを指定するために使用されます。これらの各レコードには、電子メールアドレスと個人の名前を含むテキストレコードの名前の2つの値が関連付けられています。責任者の記録はめったに見られず、メール配信プログラムやインターネットクライアントによって使用されることはありません。 メールアドレス これらのレコードの1つを編集または追加するときに表示されるフィールドは、完全なアドレス（ [email protected] など）を入力するためのものです。）名前に名前が入力されているホストの責任者分野。 テキストレコード名 フィールドは、個人の本名を含むテキストレコードの相対名または正規名を入力するためのものです。
場所（LOC）: ロケーションレコードは、ホストの緯度と経度での物理的なロケーションを指定するために使用されます。それらはほとんど見られないため、多くのプログラムで使用されていません。ただし、多くの国にホストがある大規模な組織では役立ちます。ロケーションレコードを追加または編集すると、名前にホストのロケーションを入力するためのフィールド*Latitude andLongitude*が表示されます。分野。 _42 21 43.528 N 71 05 06.284 W 12.00m 30.00m10000.00m10.00m_のようにフォーマットする必要があります。
サービスアドレス（SRV）: このタイプのレコードは、ドメイン名、サービス名、およびプロトコルを特定のホストに関連付けるために使用されます。ホストに接続するだけでなく、特定のサービスとホスト名についてクライアントが接続するサーバーを指定できます。ある意味、それらはメールサーバーレコードに似ていますが、はるかに柔軟性があります。たとえば、example.comのPOP3サーバーが mail.example.comであることを指定できます。、ただし、Webサーバーは www.example.com 。執筆時点では、SRVレコードは主にWindowsクライアントシステムで使用されています。サービスアドレスレコードを追加または編集する場合、フィールドプロトコル およびサービス名 名前の近くに表示されますテキストボックス。プロトコルについては、メニューからTCPまたはUDPのいずれかを選択する必要があります。サービス名には、/ etc/servicesファイルからpop3などの既知の名前を入力する必要がありますまたはtelnet 。 SRVレコードを検索するために、クライアントはサービス名、プロトコル、および名前を組み合わせて、 ___ telnet .___ tcp.example.comのようなレコード名を取得します。。 Webminは、サービスアドレスレコードを編集または追加するときに自動的にこれを行いますが、このタイプのレコードを一覧表示するページに結合された名前が表示されます。 Webminはまた、サービスとプロトコルの前に_sを自動的に追加しましたが、SRVレコードが表示または編集されているときにそれらを非表示にします。これは、このタイプのレコードを作成または編集するときに、手動で入力する必要がないことを意味します。 優先度 このサーバーの数値の優先度を入力するには、フィールドを使用する必要があります。これは、メールサーバーレコードの優先度と同じ意味です。重量フィールドには、この特定のサーバーの重み付けが含まれている必要があります。同じ名前、プロトコル、およびサービス名のレコードが1つしかない場合は、ゼロが含まれている必要があります。重みを大きくすると、重みが小さいサーバーよりもこのサーバーを頻繁に試すようにクライアントに指示されます。 ポート フィールドには、クライアントがサーバー上で接続するためのポート番号が含まれている必要があります。これは、必ずしもサービスの標準ポートである必要はありません。 サーバー内フィールドに、実際にサービスを提供し、クライアントが実際に接続するシステムのホスト名またはIPアドレスを入力する必要があります。

リバースゾーンでWebminがサポートするレコードタイプは次のとおりです。

リバースアドレス（PTR）: 逆引きアドレスレコードは、ホスト名を逆引きゾーンのIPアドレスに関連付けます。 DNSクライアントがネットワーク内のIPアドレスからホスト名を検索できるようにするには、ホストごとにこのタイプのレコードを1つ作成する必要があります。ただし、ほとんどの場合、これはアドレスレコードを追加および編集するときにWebminによって自動的に行われます。独自のリバースアドレスレコードを作成する場合は、それらが一致するアドレスレコードと同期していることを確認してください。このタイプのレコードを追加または編集する場合、フィールドアドレス およびホスト名 が表示されます。 1つ目は、 192.168.1.10のような完全なIPアドレスを入力するためのものです。。これは、WebminによってDNSシステムが逆引きアドレスに内部的に使用するin-addr.arpa形式に自動的に変換されます。 2番目のフィールドは、pc1.example.com。などの標準形式でホスト名を入力するためのものです。、必ず最後にドットを付けてください。そうしないと、ホスト名が逆引きゾーンを基準にしてしまいます。これは間違いなくあなたが望むものではありません。
ネームサーバー（NS）: リバースゾーンのネームサーバーレコードは、フォワードドメインのレコードと同じ目的を持っています。つまり、ゾーンまたはサブドメインを担当するサーバーのIPアドレスまたはホスト名を他のDNSサーバーに通知します。これは、ゾーンのプライマリまたはセカンダリDNSサーバーごとに1つ追加する必要があることを意味します。このタイプのレコードを追加または編集するときに表示される*ゾーン名*フィールドは、サーバーが担当するゾーンの名前を入力するためのものです。これは通常、レコードを含むゾーンになります。ただし、逆引きアドレスレコードとは異なり、このフィールドは自動的にin-addr.arpa形式に変換されません。代わりに、1.168.192.in-addr.arpa。のような完全修飾形式で入力する必要があります。 192.168.1のネームサーバーを定義する場合通信網。 [*名前サーバー*]フィールドに、DNSサーバーのIPアドレスまたは標準形のホスト名（ns1.example.com。など）を入力する必要があります。。
名前エイリアス（CNAME）: このタイプのレコードは、リバースゾーンでもフォワードドメインとまったく同じように動作します。ただし、名前を入力する必要がありますおよび本名 Webminが変換しないため、in-addr.arpa形式の逆名のフィールド。名前エイリアスフィールドは、以下の*部分的な逆委任*セクションで説明されているように、部分的なサブネット委任を行うための逆ゾーンで最も役立ちます。

マスターゾーンの編集

Webminを使用して、有効期限や再試行時間、クエリを許可されているクライアントなど、マスターゾーン全体に適用される多くの設定を編集できます。これらの設定は、ゾーン内のすべてのレコードに効果的に適用されますが、一部（TTLなど）はレコードごとにオーバーライドできます。

Webminは、ゾーンパラメータという用語を使用して、プライマリネームサーバー、管理者の電子メールアドレス、再試行時間、有効期限など、ドメインのSOAレコードに保存されているすべての情報を参照します。これらはすべてゾーンの作成時に設定されますが、次の手順に従っていつでも編集できます。

モジュールのメインページで、編集するゾーンのアイコンをクリックします。
ゾーンパラメータをクリックしますアイコン。パラメータを編集するためのフォームが表示されます。
マスターサーバー DNSサーバーのインターネットホスト名が変更された場合にのみ、フィールドを編集する必要があります。末尾にドットを付けて、完全修飾ホスト名を入力します。
ゾーンの責任者のアドレスを変更するには、メールアドレスを編集します分野。含まれている@記号は、BINDの要求に応じて、SOAレコードで使用するために自動的にドットに変換されます。
更新時間 、転送の再試行時間 、有効期限 およびデフォルトの有効期間 フィールドはすべて、新しいマスターゾーンの作成のセクションで説明したのと同じ意味を持ちます。。ゾーン内のレコードが将来頻繁に変更される場合は、これらの時間を短縮することをお勧めします。ただし、新しい時間がはるかに短い場合でも、古い更新または有効期限が経過するまで、セカンダリサーバーおよびDNSクライアントによって変更が検出されない場合があります。これは、古い時間が経過するのを待ってから、マスターサーバーに再度確認して新しいサーバーを検出するためです。
保存をクリックします完了したら、ページの下部にあるボタンをクリックしてから、変更を適用します。モジュールのメインページに戻るボタン。フォームが保存されると、SOAレコードのシリアル番号が自動的にインクリメントされるため、ゾーンが変更されたセカンダリが作成されます。

マスターゾーン用に編集できる別のオプションセットがあり、ゾーンのセクションのnamed.confファイルに保存されています。これらは、ゾーン内のレコードのクエリ、ゾーン転送の実行、およびネットワークを介したレコードの更新を許可されるサーバーとクライアントを制御します。これらのオプションの中で最も便利なのは、変更が発生したときに通知する必要があるゾーンのスレーブDNSサーバーのリストを指定して、ゾーン転送を即座に実行し、同期を維持できるようにすることです。

これらのマスターゾーンオプションを編集するには、次のプロセスに従います。

モジュールのメインページで、編集するゾーンのアイコンをクリックします。これにより、図30-4に示すフォームが表示されます。
ゾーンオプションの編集をクリックしますアイコン。既存の設定を示すフォームが表示されます。
名前を確認しますか？ フィールドは、BINDがレコードファイルを読み取るときにこのゾーンのレコードに対して実行するチェックのレベルを決定します。使用可能なオプションは次のとおりです。
警告

無効なレコードが見つかった場合、システムログファイルにエラーが書き込まれますが、他のレコードの処理は正常に続行されます。

失敗

レコードが無効な場合、ゾーン全体が拒否されますが、他のゾーンは引き続き正常に処理されます。

無視

チェックはまったく行われません。

デフォルト

[ゾーンのデフォルト]ページのグローバルデフォルトが使用されます。設定されていない場合は、代わりにBINDに準拠したデフォルトが使用されます。これは、無効なレコードが検出された場合に失敗します。
ゾーン内のレコードが変更されたときにセカンダリサーバーに通知するには、スレーブに変更を通知しますか？を設定します。はいへのフィールド。 BINDは、ゾーンのネームサーバーレコードと、スレーブにも通知するのIPアドレスのリストを確認することで、どのスレーブに通知されるかを判断します。分野。ゾーンにセカンダリサーバーがある場合は、このオプションを必ずオンにする必要があります。
一部のシステムがゾーン内のレコードを動的に更新できるようにするには、更新を許可するに入力します IPアドレス、IPネットワーク（192.168.1.0/24など）およびBINDACL名のリストを含むフィールド。一致するホストのみがnsupdateなどのコマンドを使用してレコードを変更でき、リストが空のままの場合、更新はまったく許可されません。 Webminがレコードの編集にも使用されているゾーンの動的更新を許可するように注意する必要があります。動的に行われた更新は、このモジュールで行われた変更によって上書きされる可能性が非常に高く、その逆も同様です。
デフォルトでは、すべてのDNSクライアントとサーバーがゾーン内のレコードを検索できます。これは、潜在的な攻撃者に機密情報を提供する可能性があるため、内部ネットワークでのみ使用されるゾーンに必要なものではない場合があります。クエリを制限するには、クエリを許可するに入力します IPアドレス、IPネットワーク、およびBINDACL名のリストを含むフィールド。フィールドが空のままの場合、グローバルゾーンデフォルトページの同じ名前のフィールドによって、許可されるクライアントが決まります。
このドメイン内のすべてのレコードのゾーン転送の実行を許可されるクライアントとサーバーを制限するには、からの転送を許可すると入力します。分野。多くの場合、特にゾーンが非常に大きい場合や、攻撃者から隠したいレコードが含まれている場合は、セカンダリサーバーのみに転送を許可する必要があります。 IPアドレス、IPネットワーク、およびACL名のリストをフィールドに入力して、一致するクライアントのみに転送を制限します。空のままにすると、からの転送を許可します代わりに、[ゾーンのデフォルト]ページのフィールドが適用されます。
ゾーンが変更されたときに通知される追加のスレーブサーバーを指定するには、スレーブにも通知すると入力します。 IPアドレスのリストを含むフィールド。 BINDは通常、ネームサーバーレコードからゾーンのすべてのセカンダリサーバーのアドレスを処理しますが、これが常に完全であるとは限りません。
完了したら、[保存]をクリックしますページの下部にあるボタンをクリックして、変更内容でBIND構成ファイルを更新します。 変更の適用を使用する必要がありますモジュールのメインページにあるボタンをクリックして、モジュールをアクティブにします。

マスターゾーンが不要になった場合は、このWebminモジュールを使用して、マスターゾーンとそれに含まれるすべてのレコードを完全に削除できます。これを行うには、次の手順に従います。

モジュールのメインページで、編集するゾーンのアイコンをクリックします。
ゾーンの削除をクリックしますページ下部のボタン。
フォワードゾーンを削除する場合、[*他のゾーンのリバースレコードを削除しますか？*]フィールドは、このゾーンのすべてのアドレスレコードのホストされたリバースゾーンの一致するリバースアドレスレコードも削除するかどうかを制御します。これは通常、はいに設定しても安全です。、まったく同じIPアドレスとホスト名を持つレコードのみが削除されるため。
同様に、逆引きゾーンを削除する場合、[*他のゾーンの転送レコードを削除しますか？*]フィールドは、一致する転送レコードも削除する必要があるかどうかを決定します。
選択を行い、削除を続行することを確認したら、削除をクリックします。ボタン。 named.confファイル内のゾーンのエントリが削除され、そのレコードファイルが削除されます。

マスターゾーンを削除して再作成しなくても、マスターゾーンを同じ名前のスレーブゾーンに変換できます。これは、新しいサーバーが一部のドメインのマスターとして引き継ぐ場合、またはマスターサーバーとセカンダリサーバーが役割を切り替える場合に役立ちます。 スレーブゾーンの編集に関するセクションスレーブゾーンをマスターに変換する逆のアクションを実行する方法を説明します。これは、この状況で役立つ場合があります。

ゾーンを変換するには、次の手順に従います。

モジュールのメインページで、編集するゾーンのアイコンをクリックしてから、ゾーンオプションの編集をクリックします。アイコン。
スレーブゾーンに変換ボタンをクリックしたとき、named.confのゾーンのエントリはすぐに更新され、スレーブゾーンに変換されます。その後、ブラウザはモジュールのメインページに戻ります。
通常、すべてのスレーブゾーンには、ゾーン転送の実行に使用できるマスターサーバーのIPアドレスのリストがあります。変換されたゾーンの場合、スレーブゾーンのデフォルトのマスターサーバーでない限り、このリストは最初は空になります。モジュール構成オプションが設定されています。 *スレーブゾーンの編集*セクションの指示に従って、マスターサーバーのアドレスを正しく設定します。
変更を有効にするには、変更の適用をクリックしますモジュールのメインページにボタンを押します。

新しいスレーブゾーンの作成

スレーブゾーンまたはセカンダリゾーンは、DNSサーバーがゾーンのマスターサーバーからレコードのリストを取得するゾーンです。一般に、スレーブサーバーは、プライマリサーバーの負荷を軽減するため、またはサーバーがダウンした場合のバックアップとして機能するために使用されます。重要なゾーン（会社のインターネットドメインなど）の場合、Webサイトにアクセスでき、プライマリがダウンした場合でも電子メールを配信できるように、常に少なくとも1つのスレーブサーバーを用意する必要があります。

ドメインのセカンダリDNSサーバーは、通常、マスターと同じネットワーク上に配置しないでください。これにより、そのネットワークに障害が発生しても、両方がダウンすることはありません。多くのISPやホスティング会社は、顧客のドメインのセカンダリゾーンを独自のDNSサーバーで無料でホストします。 ISPがこのサービスを提供していて、インターネットドメインのセカンダリサーバーをセットアップする場合は、それを利用する必要があります。その場合、このセクションのほとんどはスキップできます。ただし、内部ドメイン用のスレーブサーバーを追加する場合、またはインターネットへの接続が多い大企業ネットワークを使用する場合は、以下の手順でセットアップ方法を説明します。

BIND DNSサーバーモジュールのメインページで、新しいスレーブゾーンの作成をクリックします。既存のゾーンのリストの上または下にリンクします。これにより、新しいドメインの詳細を入力するための以下のフォームが表示されます。
example.comのようなフォワードゾーンの場合、ゾーンタイプを設定します転送するフィールドゾーン名を[*ドメイン名/ネットワーク*]フィールドに入力します。 IPアドレスをネットワークのホスト名にマップする逆引きゾーンの場合は、逆引きを選択しますオプションを選択し、ネットワークアドレスを入力します（ 192.168.1 など））*ドメイン名/ネットワーク*テキストフィールドに入力します。
レコードファイル フィールドは、BINDがこのゾーンのレコードのキャッシュをファイルに保持するかどうか、保持する場合はそのファイルがどこにあるかを決定します。オプションがなしの場合が選択されている場合、マスターからDNSサーバーが転送するレコードはメモリにのみ保持され、サーバーの再起動時に失われます。これは、サーバーが実行する必要のあるゾーン転送の数が増えるため、マスターサーバーとスレーブサーバーの間に良好なネットワーク接続がある場合にのみ選択する必要があります。自動を選択した場合、Webminは、named.confファイル（通常は/ var / named）で指定されたゾーンファイルディレクトリにファイル名を生成します。サーバーがゾーン転送を行うときはいつでも、すべてのレコードが標準形式でこのファイルに書き込まれます。最後のオプションを選択した場合は、レコードを保存するファイルへのフルパスを横のフィールドに入力できます。これは、マスターゾーンとスレーブゾーンのレコードファイルを分離する場合に役立ちます。
マスターサーバー フィールドに、ゾーンのマスターDNSサーバーとその他のセカンダリサーバーのIPアドレスを入力します。 BINDは、ゾーン転送を実行するときにこれらのサーバーを順番に試行するため、マスターがリストの最初にある必要があります。サーバーがレコードの取得元を認識できるように、少なくとも1つのアドレスを入力する必要があります。
作成をクリックしますボタンをクリックして、新しいスレーブゾーンをサーバーの構成に追加します。ブラウザは、ゾーンのオプションを編集するためのページにリダイレクトされます。
モジュールのメインページに戻り、変更の適用をクリックしますメインページのボタンをクリックして、追加をアクティブにします。
マスターサーバーで、セカンダリサーバーのIPアドレスを使用してゾーンの新しいネームサーバー（NS）レコードを追加します。これは、レコードの追加と編集の手順に従うことで、Webminで簡単に実行できます。セクション。
ゾーン内のレコードへの変更をこのスレーブに通知するようにマスターDNSサーバーを構成します。 マスターゾーンの編集に関するセクションの手順方法を説明します。
これがインターネットドメインの場合は、新しいセカンダリサーバーの親ゾーンのレジストラに通知します。ほとんどの場合、ドメインのネームサーバーのリストを編集するためのオンラインフォームが用意されており、そこにセカンダリのIPを追加できます。これは、インターネット上の他のホストがスレーブサーバーの使用を認識し、マスターがダウンしているために必要です。

スレーブゾーン作成フォーム

スレーブゾーンに密接に関連する別のタイプのゾーンはスタブです。これらはスレーブゾーンに似ていますが、すべてのレコードではなく、マスターサーバーから転送されたネームサーバーレコードのみが含まれます。スタブゾーンが使用されることはめったにありませんが、サブドメインのゾーン内のネームサーバーレコードがサブドメイン自体で使用されるものと同じであることを確認するのに役立ちます。作成する手順は上記の手順とほぼ同じですが、手順1では、新しいスタブゾーンを作成するを使用する必要があります。代わりにメインページのリンク。

スレーブゾーンの編集

スレーブゾーンが作成された後でも、それに適用されるいくつかのオプションを編集することができます。当然、ゾーン内の実際のレコードを追加または編集する方法はありませんが、マスターサーバー、レコードファイル、およびクエリを許可したクライアントのリストを変更することはできます。これらの設定を変更するには、次の手順に従います。

モジュールのメインページで、編集するスレーブゾーンのアイコンをクリックします。以下のスクリーンショットに示すフォームがブラウザに表示されます。
ゾーンオプションまで下にスクロールしますページの下部にあるフォーム。
このゾーンの他のマスターサーバーとスレーブサーバーのリストを編集するには、[*マスターサーバー*]フィールドのIPアドレスを変更します。新しいセカンダリサーバーが追加された場合は、他のすべてのセカンダリでこのリストに追加して、そこからゾーン転送を実行できるようにする必要があります。マスターのIPアドレスが変更された場合は、リストを新しいアドレスで更新する必要があります。
サーバーがゾーン転送を断念するまで待機する時間を変更するには、デフォルトの選択を解除します。 最大転送時間の場合フィールドに入力し、その横のテキストボックスに分数を入力します。
レコードファイルの場合フィールドがなしに設定されている、このゾーンのマスターサーバーから転送されたレコードはメモリにのみ保持されます。ただし、ファイル名を入力すると、レコードは標準形式ではなくそのファイルに書き込まれます。これは、ゾーン転送を最小限に抑え、以下で説明するようにセカンダリサーバー上のレコードを表示できるため、最適なオプションです。
ゾーンが変更されたときにこのDNSサーバーに他のサーバーに通知させるには、スレーブに変更を通知しますか？を変更します。はいへのフィールド。これは、このサーバーからゾーン転送を実行する他のセカンダリサーバーがあり、マスターサーバーから更新通知を受信できない場合にのみ非常に役立ちます。通知するDNSサーバーは、ゾーンのネームサーバーレコードと[*スレーブにも通知する*]フィールドの内容から決定されます。
デフォルトでは、すべてのDNSクライアントとサーバーがゾーン内のレコードを検索できます。これを変更するには、[*クエリの許可*]フィールドにIPアドレス、IPネットワーク、およびBINDACL名のリストを入力します。フィールドが空のままの場合、グローバルゾーンデフォルトページの同じ名前のフィールドによって、許可されるクライアントが決まります。
このドメイン内のすべてのレコードのゾーン転送の実行を許可されるクライアントとサーバーを制限するには、からの転送を許可すると入力します。 IPアドレス、IPネットワーク、およびACL名のリストを含むフィールド。空のままにすると、代わりに[ゾーンのデフォルト]ページの[からの転送を許可する]フィールドが適用されます。
名前を確認しますか？などのフォームの他のフィールドおよび*Allowupdate from？*は、実際にはスレーブゾーンには使用されないため、変更しないでおくことができます。
変更が完了したら、[保存]ボタンをクリックします。入力に構文エラーがない限り、モジュールのメインページに戻ります。 変更の適用をクリックしますそこにあるボタンをクリックして、変更をアクティブにします。マスターサーバーが変更された場合でも、これによってゾーンの再転送が強制されるとは限らないことに注意してください。レコードファイルを使用するスレーブゾーンの場合、BINDは、ゾーンの有効期限が切れたとき、またはサーバーが変更の通知を受信したときにのみ転送を実行します。

スレーブゾーン編集フォーム

レコードファイルを使用するスレーブゾーンを編集する場合、Webminでレコードを参照することができます。スレーブゾーンのアイコンをクリックすると表示されるページの上部には、マスターゾーンフォームに表示されるものと同じように、レコードタイプのテーブルがあります。それぞれをクリックすると、セカンダリサーバーに認識されている、ゾーン内のそのタイプのレコードの名前と値が一覧表示されます。もちろん、それらを編集または追加することは不可能です。ドメインのレコードの信頼できるソースであるマスターサーバーで変更を行う必要があるためです。

システムがゾーンのスレーブサーバーとして機能するのを停止するには、BIND構成からシステムを削除する必要があります。ゾーン内のすべてのレコードがマスターサーバーからコピーされており、簡単に置き換えることができるため、これは一般的に安全な手順です。ただし、ゾーン内のネームサーバーレコードを更新し、システムがゾーンのセカンダリではなくなったことを親ドメインのレジストラに通知して、他のDNSサーバーがクエリのクエリに時間を浪費しないようにする必要があります。

スレーブゾーンを削除するには、次の手順に従います。

モジュールのメインページで、編集するスレーブゾーンのアイコンをクリックします。これにより、上のスクリーンショットに示されているフォームが表示されます。
削除をクリックしますページの右下隅にあるボタンをクリックすると、確認フォームが表示されます。
削除を押しますゾーンを削除する場合は、ボタンをクリックします。
ブラウザがモジュールのメインページに戻ったら、変更の適用をクリックします。削除をアクティブにします。
マスターサーバーで、このセカンダリサーバーのネームサーバー（NS）レコードをゾーンから削除します。
これがインターネットドメインの場合は、このセカンダリサーバーの削除を親ゾーンレジストラに通知してください。そうしないと、他のDNSサーバーが応答を提供できないときにドメイン内のレコードについてこれを照会しようとすると、問題が発生する可能性があります。

スレーブゾーンに対して実行できる最後のことは、それをマスターに変換することです。これは、レコードファイルを使用するゾーンでのみ可能であるため、Webminは将来そのファイルを表示および編集できます。このような変換を行う場合は、元のマスターサーバーがスレーブになるように変更されているか、ゾーンのホスティングを完全に停止していることを確認してください。2つのマスターが同じドメインにサービスを提供することはできません。

ゾーンを変換する手順は次のとおりです。

モジュールのメインページにあるアイコンをクリックします。
スレーブゾーンページの一番下までスクロールし、マスターゾーンに変換を押します。ボタン。これにより、named.confファイルがすぐに更新されてゾーンのタイプが変更されますが、その他の変更は行われません。
変換をアクティブにするには、変更の適用をクリックしますモジュールのメインページのボタン。
レコードの追加と編集のセクションの手順に従って、通常のマスターゾーンの場合と同じようにドメイン内のレコードを編集できるようになりました。。

フォワードゾーンの作成と編集

転送ゾーンは、DNSサーバーが、要求を行っているユーザーに代わってクエリを別のサーバーに転送するゾーンです。これらは、ゾーンが実際にこのサーバーのクライアントが到達できない別のサーバーによってホストされている場合に役立ちます。以下の「転送と転送の構成」セクションで説明されているように、非ホストゾーンに対するすべての要求を別のサーバーに転送するようにBINDを設定することができます。フォワードゾーンエントリは同じことを行いますが、単一のドメインに対してのみです。

設定するには、次の手順に従います。

モジュールのメインページで、既存のドメインアイコンのリストの上または下にある[*新しい転送ゾーンを作成する*]リンクをクリックします。これにより、ゾーン作成フォームが表示されます。
ゾーンタイプを設定しますいずれかの転送へのフィールドまたはリバース 、マスターゾーンとスレーブゾーンを作成するときのように。
転送ゾーンの場合は、そのフルネーム（末尾にドットを付けない）をドメイン名/ネットワークに入力します分野。逆引きゾーンの場合は、そのネットワークを入力します（ 192.168.1 など））代わりにフィールドに入力します-ゾーンが追加されると、Webminは自動的にin-addr.arpa形式に変換します。
マスターサーバー フィールドに、ゾーン内のレコードを検索するためにクエリできるDNSサーバーのIPアドレスのリストを入力します。これらはすべて、ドメインのマスター、スレーブ、またはフォワードホストである必要があります。アドレスがまったく入力されていない場合、BINDは、要求を別のサーバーに転送する代わりに、ゾーン内のレコードの通常のルックアップを常に実行します。これを使用して、単一ゾーンの[転送と転送]ページのグローバル転送設定を上書きできます。
作成をクリックしますボタンをクリックして、ゾーンをBINDの構成ファイルに追加します。ブラウザは、新しいドメインのオプションを編集するためのページに移動します。
モジュールのメインページに戻り、変更の適用を押します。ボタンを押してアクティブにします。

転送ゾーンを作成したら、次の手順に従って、ゾーンを削除するか、いくつかの設定を編集できます。

モジュールのメインページにあるゾーンのアイコンをクリックすると、ブラウザが小さなフォームに表示され、オプションを編集できます。
リクエストの転送先のDNSサーバーのリストを変更するには、マスターサーバーのIPアドレスを編集します分野。何も入力されていない場合、このドメインのレコードのリクエストは直接検索されます。
他のサーバーを試してみませんか？ フィールドがはいに設定されている、BINDは、リストされているサーバーのいずれにも接続できない場合、このゾーンの要求に対して通常の直接ルックアップを試行します。
保存をクリックしますボタンをクリックして変更を保存し、変更を適用しますメインページに戻ってアクティブにします。または、フォワードゾーンを削除するには、削除をクリックします次に削除もう一度確認ページで。

ルートゾーンの作成

はじめに説明したように、ルートゾーンは、DNSサーバーにインターネットルートサーバーを含めるために必要な情報を含むゾーンです。これがないと、サーバーでホストされているドメイン以外のドメインのレコードを解決することはできません。幸い、ほとんどの場合、Webminによって作成されたか、デフォルト設定の一部として含まれているBIND構成にすでに存在します。

インターネット以外での内部使用のみを選択したためにルートゾーンがまだ存在しない場合は、ルートゾーンを作成する必要がある場合があります。モジュールを初めてセットアップするときのオプションですが、システムをインターネットに接続しました。 BINDビューの使用で説明されているように、ビューが構成されている場合は、2番目のルートゾーンを追加することも役立ちます。セクション。

Webminでは、ルートゾーンがまだ存在しない場合、またはルートゾーンを含まないビューが存在する場合にのみ、ルートゾーンを作成できます。これは、そのようなゾーンが2つあるポイントがないためです。 1つ追加するには、次の手順に従います。

モジュールのメインページで、新しいルートゾーンの作成をクリックします。アイコン。
ルートサーバーをファイルに保存するに入力しますルートゾーンファイルに使用するファイル名のフィールド。すでに存在する場合、このフィールドにはすでにそのパスが含まれています。それ以外の場合は、/ var / named/db.cacheのように入力する必要があります。
ルートサーバーの取得 フィールドは、Webminがルートファイルをコピーする場所を制御します。選択肢は次のとおりです。*ルートFTPサーバーからダウンロード*これは、モジュールにrs.internic.netへのFTP接続を確立し、ファイルの最新バージョンをダウンロードするように指示するため、最適なオプションです。ただし、ファイアウォールが原因でシステムがFTPダウンロードを実行できない場合、これは機能しない可能性があります。 * Webminの古いルートサーバー情報を使用します*最初のオプションが機能しない場合は、このオプションを使用する必要があります。選択した場合、モジュールはWebminに付属するルートゾーンファイルのコピーを使用します。これは機能しますが、最新ではない可能性があります。 *ファイル内の既存のルートサーバー*手順2で入力したファイルがすでに存在する場合は、このオプションを選択する必要があります。ビューにルートゾーンを追加していて、そのルートゾーンがすでに別のビューに存在する場合は、ファイルを両方のゾーンで共有できるように、デフォルトで選択されます。
作成をクリックしますボタンをクリックしてゾーンを追加し、モジュールのメインページに戻ります。次に、変更の適用を押しますそれをアクティブにします。

ルートゾーンが追加されると、それを表すアイコンがメインページに表示されます。アイコンをクリックして削除を押すと削除できますボタン-ただし、これにより、ホストされていないインターネットドメインでのレコードのルックアップが上記のように機能しなくなる可能性があります。

編集ゾーンのデフォルト

新しいマスターゾーンのデフォルト

同様のレコードを含むゾーンを多数追加する場合、各ゾーンを作成した後で手動で追加するのは大変な作業になる可能性があります。たとえば、Webホスティング会社では、すべてのドメインにWebサーバーのIPアドレスのwwwアドレスレコードと、メールを中央サーバーに転送するメールサーバーレコードが含まれている場合があります。幸い、Webminでは、ゾーンテンプレートと呼ばれる、すべての新しいドメインに追加されるレコードのリストを作成できます。

テンプレートは1つ以上のレコードで構成され、各レコードには名前、タイプ、および値があります。アドレスレコードの場合、値は、ゾーンの作成時にユーザーが入力できることを示すオプションにすることができます。これは、新しいドメインのレコードの1つ（wwwなど）に固定アドレスがなく、ゾーンが追加されたときに簡単に設定できるようにする場合に便利です。テンプレートは、リバースゾーンにはあまり意味がないため、フォワードゾーンを作成する場合にのみ使用できます。

新しいゾーンのデフォルトの有効期限、更新、TTL、および再試行時間を編集することもできます。 Webminの初期デフォルトは妥当ですが、ネットワークに適していない可能性があります。これらのデフォルトを変更してテンプレートレコードを設定するには、次の手順に従います。

モジュールのメインページで、ゾーンのデフォルトをクリックします。アイコン。ページ上部の新しいマスターゾーンのデフォルトというラベルの付いたフォーム編集が必要なすべてのフィールドが含まれています。
更新時間を編集します、転送の再試行時間 、有効期限 およびデフォルトの有効期間 新しいゾーンのデフォルト時間を変更する場合は、フィールド。ただし、既存のマスターゾーンは、ここで行った変更の影響を受けません。
すべての新しいドメインが同じ人によって管理されている場合は、その人のアドレスをデフォルトのメールアドレスに入力します分野。これにより、マスターゾーン作成ページで毎回入力する必要がなくなります。
テンプレートレコード テーブルでは、新しいレコードを入力するために2つの空白行が表示されます。 2つ以上追加するには、このページを保存して再編集する必要があります。既存の行のレコードは、フィールドを変更するだけで編集したり、レコード名をクリアして削除したりできます。 レコード名の下列には、wwwやftpなど、ゾーンに関連するレコードの名前を入力する必要があります。ゾーン自体のレコード（ドメインのメールサーバーレコードなど）を作成するには、1つのドットを入力するだけです。 タイプの下列で、リストからレコードのタイプを選択します。 ＃レコードタイプを参照してくださいそれぞれの用途の詳細については、セクションを参照してください。その名前が示すように、値の下のフィールド列は、新しいレコードの値を入力するためのものです。アドレスタイプには、フォームからを選択できますこの場合、新しいドメインを作成するときにアドレスを入力できます。このアドレスは、このオプションが選択されているすべてのテンプレートレコードで使用されます。メールサーバーレコードの場合、優先度とサーバー名の両方をスペースで区切って入力する必要があります（例：_5 mail.example.com._）。他のすべてのタイプのレコードの値は、ゾーンにレコードを追加するときに使用されるのと同じ形式で入力する必要があります。
BINDで使用されるレコードファイル形式に精通している場合は、新しいゾーンに含めるレコードの独自のファイルを作成できます。 追加のテンプレートファイルにファイル名が入力されている場合フィールドに、その内容が新しいマスタードメイン用にWebminによって作成されたゾーンファイルに追加されます。
テンプレートレコードの追加が完了したら、[保存]をクリックしますページ下部のボタン。変更は、今後作成されるすべての新しいマスターゾーンに適用されます。

テンプレートを作成したので、作成する新しいマスターゾーンごとにテンプレートを使用するかどうかを選択できます。作成フォーム（新しいマスターゾーンの作成で説明）セクション）は、ゾーンテンプレートを使用しますか？というラベルの付いたフィールドです。、はいに設定されていますデフォルトでは、テンプレートレコードがある場合。その隣には、テンプレートレコードのIPアドレスという名前のフィールドがあります。、フォームからのレコードのIPを入力するために使用されますオプションが選択されています。テンプレートを使用することを選択し、IPアドレスが指定されていないレコードがある場合は、このフィールドに入力する必要があります。

デフォルトのゾーン設定

ゾーンのデフォルトの下部にありますこのページには、既存のすべてのドメインに適用されるいくつかのオプションがありますが、マスターゾーンの編集で説明されているように、ゾーンごとにすべて設定またはオーバーライドできます。セクション。サーバーへのクエリを許可するクライアントと、さまざまなドメインタイプのレコードに対して実行されるチェックの種類を制御できます。許可されるクライアントホストを制限できると特に便利です。これにより、DNSサーバーを使用して非内部クライアントを停止できます。ただし、インターネット上の他のDNSサーバーがそれらを検索できるように、サーバーによってホストされているマスターインターネットゾーンにすべてのユーザーがアクセスできることを確認する必要があります。

これらのグローバルオプションを変更するには、次の手順に従います。

モジュールのメインページで、ゾーンのデフォルトをクリックします。アイコンをクリックして、デフォルトのゾーン設定まで下にスクロールしますセクション。
DNSサーバーへのクエリを許可するホストを制御するには、クエリの許可を変更します。 リストへのフィールド下のテキストボックスに、IPアドレス、IPネットワーク（192.168.1.0/24など）およびACL名のリストを入力します。リストのどのエントリにも一致しないクライアントは、独自の個別の設定が許可されているゾーンでレコードを要求していない限り、拒否されます。
サーバーからのゾーン転送の実行を許可するホストを制御するには、からの転送を許可するを変更します。 リストへのフィールド下のテキストボックスにIPアドレス、IPネットワーク、ACL名のリストを入力します。 Only servers that are acting as secondaries for zones that this server hosts really need to be able to do transfers, so it is usually a good idea to enter just their IP addresses. If you are restricting queries, this field must be filled in so that hosts that cannot lookup records are not allowed to perform transfers either.
The fields Check names in master zones? and Check names in slave zones? control the checking of records in all zone files for master and slave zones respectively. The available options for each are:
Warn

If an invalid record is found, an error will be written to the system log file but processing of other records continues normally.

Fail

Invalid records cause the entire zone to be rejected, but other zones will still be processed normally.

Ignore

No checking is done at all.

Default

The default checking level is used, which is Fail 。
To have BIND check responses that it receives from other DNS servers, set the Check names in responses? field to Warn or Fail 。 The default is simply to pass potentially erroneous responses on to clients.
The Notify slaves of changes? field determines whether BIND sends a notification to all slaves of master zones hosted by this server when they change. To turn this on, select Yes - otherwise, select No or Default 。 Enabling notification is a good idea, as it ensures that secondary servers are kept in sync with the master.
完了したら、[保存]をクリックします button at the bottom of the page to update the BIND configuration file, and then the Apply Changes button on the module's main page to make the changes active. The new settings will apply to all zones that do not explicitly override them on their own options pages.

Configuring forwarding and transfers

BIND can be configured to forward all requests for zones that it is not the master or slave for to another DNS server. When doing this, it acts like a DNS client itself, accepting requests from real clients and then sending them off to another server or servers for resolution instead of carrying out the normal process of contacting the root zone servers and finding the correct server for the domain. This can be useful if your DNS server is unable to contact the rest of the Internet, but can still communicate with a DNS server that does have full network access. For example, it may be on an internal network behind a firewall that only allows connections to a limited set of destinations.

To set up forwarding, the steps to follow are:

On the module's main page, click on the Forwarding and Transfers icon.
In the form that appears, fill in the Servers to forward queries to field the IP addresses of DNS servers that requests should be sent to. BIND will try them in order until one returns a positive or negative a response. If the list is empty, the server will revert to the normal method of looking up records by contacting the root servers and so on.
If you want your server to attempt to resolve a client's query directly when it cannot contact any of the forwarding servers, set the Lookup directly if no response from forwarder はいへのフィールド。 This is only useful if your server is actually capable of doing lookups.
保存をクリックします button at the bottom of the page, and then hit Apply Changes back on the main page to make the new setting active. Assuming the forwarding list was filled in, your server will now send all client queries to the listed servers.

The same form also contains fields for configuring BIND's behavior when doing zone transfers. You can control how long it will wait for a transfer to complete, the protocol used for transfers and the number that can be active at the same time. To edit these settings, follow these steps:

On the module's main page, click on the Forwarding and Transfers icon.
By default, BIND will wait 120 minutes (2 hours) for a zone transfer from a master to complete. To change this, enter a different number of minutes into the *Maximum zone transfer time* field. This can also be set or overridden on a per-slave zone basis.
BIND versions before 8.1 only support the transfer of a single zone at a time. Because this can be slow when transferring many zones from the same master server, the *Zone transfer format* field can be set to Many to use a new format that combines multiple domains into the same transfer. If One at a time or Default is chosen, then each zone will be transferred separately. This is the best choice unless you are sure that all slave servers are running BIND 8.1 or above.
By default, your nameserver will not carry out more than 2 concurrent zone transfers from the same master server. To increase this limit, change the *Maximum concurrent zone transfers* field to something higher. This can speed up the process of transferring a large number of domains, but at the expense of putting a higher load on the master server.
保存をクリックします button when you are done making changes, and then Apply Changes on the main page to activate them. The new settings will apply to all subsequent zone transfers.

Editing access control lists

An access control list (or ACL) is list of IP addresses, IP networks or other ACLs that are grouped together under a single name. The ACL name can then be used when specifying the list of clients allowed to query, update or perform zone transfers from a zone. This can make be used to reduce the amount of duplication in your BIND configuration, and to make it clearer. For example, the ACL corpnet might match the IP networks 192.168.1.0/24 , 192.168.2.0/24 and 1.2.3.0/24 , which are all part of your company's network. When configuring who can query a zone, you could just enter corpnet instead of that list of network addresses. To view and edit ACLs in Webmin, the steps to follow are :

On the module's main page, click on the Access Control Lists icon. This will take you to a page listing existing ACLs and allowing the addition of one more. If you want to add more than one ACL, you will need to save the form and re-edit it to force the display of a new blank row.
To add a new ACL, find the blank row at the bottom of the table and enter a short name consisting of only letters and numbers in the ACL Name 桁。 Then in the field under *Matching addresses, networks and ACLs*, enter a list of IP addresses, IP networks and other ACL names that this new ACL will contain. IP addresses must be entered in their standard format like 192.168.1.1 , but hostnames are not allowed. IP networks must be entered in network/prefix format like 192.168.1.0/24 or 192.168.1/24 。 You can also precede any address, network or ACL name with a ! to negate it, so for example the entry !192.168.1.0/24 would match all hosts outside the_ 192.168.1 _network.
Existing entries in the list can be edited by changing their fields in the table, and ACLs can be deleted by clearing out the field containing their names.
When you are done adding and editing ACLs, click the Save ボタン。 To activate the changes, hit Apply Changes back on the main page. As soon as an ACL is created, it can be used in other query, transfer and update restrictions of other zones.

BIND has four built-in ACLs that can be used in all the same places that user-defined ACLs can. They are:

any: Matches any client address.
none: Matches nothing.
localhost: Matches the IP addresses of all network interfaces on your system. Even though it is called localhost, it doesn't just match 127.0.0.1.
localnets: Matches all clients on all networks that your system is directly connected to. BIND works this out by looking at the IP addresses and netmasks of all network interfaces.

Setting up partial reverse delegation

Partial reverse zone delegation is method for transferring the management of a small set of reverse IP addresses to another DNS server. Normally, reverse zones cover an entire class C network containing 256 addresses. However, many organizations have networks much smaller than this, containing maybe 16 or 32 addresses. Normally, this would make it impossible for the organization to manage its own reverse address mappings, as the addresses come from a network that is owned by an ISP or hosting company.

Fortunately, there is a solution - the ISP can set up Name Alias (CNAME) records in the reverse zone for the parent network that point to Reverse Address records in a special zone on the organization's DNS server. The parent zone must also contain a Name Server (NS) record for the special sub-zone that points to the customer's server, so that other DNS clients know where to look when resolving the Name Alias records.

An example may make this clearer - imagine for example than an ISP had granted addresses in the range 192.168.1.100 to 192.168.1.110 to Example Corporation, which owns the example.com domain. The company already runs its own DNS server to host the example.com zone, but wants to control reverse address resolution for its IP range as well. The ISP would create Name Alias records in the 192.168.1 zone pointing to the special sub-zone 192.168.1.100-110, which will contain the actual Reverse Address records named like 192.168.1.100-100.101. The ISP also needs to create a Name Server record for 192.168.1.100-110 which tells other servers that Example Corporation's DNS server should be used to find records under that zone.

Webmin handles reverse address delegation well, and automatically converts special network zones like 192.168.1.100-110 to and from the real zone names used by BIND such as 100-110.1.168.192.in-addr.arpa. The exact steps to follow on both the server that hosts the actual class C network zone and the server that a subset of it is being delegated to are :

Decide on the range of addresses that are being delegated, such as 192.168.1.100 to 192.168.1.110 。 Typically, the sub-zone name is based on the range of addresses being delegated, but this does not have to be the case as long as it is under the parent network domain.
On the server that hosts the class C network zone, add a Name Server record for 192.168.1.100-110 with the server set to the IP address or name of the sub-zone's DNS server.
For each address in the range, add a Name Alias record to the reverse zone named like 101.1.168.192.in-addr.arpa. with the Real Name set like 101.100-110.1.168.192.in-addr.arpa 。 As you can see, the alias points to a record inside the zone for the sub-network.
When all of the Name Alias records have been created, everything that needs to be done on this server is finished and you can hit Apply Changes 。
On the DNS server for the sub-network, create a new master zone for the reverse network 192.168.1.100-110 。 Webmin will automatically convert this to the correct in-addr.arpa format for you.
Add Reverse Address records to the new zone as normal for IP addresses like 192.168.1.100-110.101 。 Adding a record for the IP 192.168.1.101 will not work.
When you are done creating reverse records, click the *Apply Changes* button to make them active. You should now be able to look them up using a command like nslookup on the server for the parent network zone.

The instructions above can be used to delegate multiple ranges from a single class C network to several different DNS servers. There is no limit on the size of ranges, nor any requirement that they follow normal network block boundaries - however, for routing reasons most IP allocation is done in power-of-two sized blocks (like 4, 8, 16 and so on), which means that any sub-zone ranges will be the same size.

The only problem with reverse address delegation when using Webmin is that Reverse Address are not automatically created and updated when Address records are. This means that you will have to create all such records manually on the sub-zone server, as in the steps above.

One inconvenience in setting up partial reverse delegation is the number of similar Name Alias records that must be created on the parent network zone server. Fortunately, there is a simpler alternative - record generators. A generator is a special BIND configuration entry that creates multiple similar records using an incrementing counter. This module allows you to created and edit generators, by following these steps :

On the module's main page, click on the icon for the reverse zone that you want to create records in. This will typically be a class C network domain that is going to have a range of addresses delegated to some other Server.
Click on the Record Generators icon. This takes you to a page containing a table of existing generators, with a blank row for adding a new one.
In the empty row, select CNAME from the menu under the Type 桁。
Under the Range column, enter numbers for the start and end of the address range into the first two fields, such as 100 and 110 。 The third field is for entering the gap between each step, and should be left blank. If you were to enter 2, then the range would go 100 , 102 , 104 等々。
In the Address pattern field, enter _$_ (a single dollar sign). When the records are created, the $ will be replaced with the number of each record, which will in turn resolve to an IP address in the range. You could also enter $.1.168.192.in-addr.arpa. , which makes things more obvious but is longer to type.
In the Hostname pattern field, enter $.100-110 。 Similarly, the $ will be replace with the number of each record, which will resolve to something like 101.100-110. 1.168.192.in-addr.arpa. 。
If you like, enter a comment that describes what this generator is for into the Comment 分野。
保存をクリックします button, return to the module's main page and click on Apply Changes 。

A generator can replace the Name Alias records that the first set of instructions in this section tell you to create, so there is no need for them anymore. Note that the automatically generated replacements will not be visible or editable in the normal way, only through the Record Generators page.

Using BIND views

BIND version 9 introduced the concept of views, which are groups of zones that are visible only to certain DNS clients. Views can be used to hide internal zones from the Internet, to present the same zone in two different ways, or to stop non-local clients resolving non-hosted domains through your server. Every view has a unique name, and a list of matching IPs addresses and IP networks that determines which clients and servers it is visible to.

When it detects that you are running BIND 9, several additional features are available in the module. You can create views, move zones from one view to another, and choose which view zones are created in. On the main page, each current view is represented by an icon under Existing Client Views heading, and each zone icon has a label that indicates which view it is in.

If any views exist, then every zone must be in a view. Only if none are defined will Webmin allow the creation of zones outside views, as this is not supported by BIND. This includes the root zone, which must be available to a client for DNS requests for records in domains not hosted by this server to succeed. For this reason, it often makes sense to put the root zone in a view that is available to all clients.

To add a new view to your BIND configuration, the steps to follow are:

On the module's main page, click on the Create a new view link in the Existing Client Views セクション。 This will take you to a form for entering its details.
Enter a short alphanumeric name for the view (such as internal or everyone ) into the View name 分野。 Each view must have a unique name.
Leave the DNS records class field set to Default 。
If this zones in this view are to be visible to everyone, set the Apply this view to clients field to All clients 。 Otherwise, choose Selected addresses, networks and ACLs and enter a list of IP addresses, IP networks and BIND ACL names into the text box below. Only clients that match one of the entries in this list will have access to the view.
作成をクリックします button at the bottom of the form. You will be returned to the main page, which will include an icon for your new view.
Move any existing zones that you want to be in this view into it. A zone can be moved by clicking on its icon, then on *Edit Zone Options*, and then selecting the new view from the menu next to the Move to view button before clicking it. If this is your first view, all existing zones must be moved into it (or another view) before the new configuration will be accepted by BIND.
When you are done moving zones, click the Apply Changes button on the main page.

Once a view has been created, you can change the list of addresses and networks that it matches by clicking on its icon on the main page and updating the Apply this view to clients 分野。 Then hit the Save button followed by Apply Changes to make the new client list active.

A view can be deleted by clicking the Delete button on the same form. This will bring up a confirmation page that allows you to choose what should happen to the zones that it contains, if any. The available options are:

Delete totally: All zones in the view are deleted, along with their records files.
Move out of views: Zones in the view are moved out to the top level. This option should only be used when deleting the last view, for the reasons explained above.
Move to view: Zones are moved to a different existing view.

When one or more views have been defined on your system, you can choose which one to use when adding new zones. This is done using the Create in view field on the master, slave, forward and root zone creation forms, which allows you to select a view from its menu. Naturally, there is no option for creating a zone outside of any views as this is not allowed by BIND.

One common use of views is hiding internal zones from clients outside your internal network. This is a good way of hiding the structure of your network and the hosts on it from potential attackers. To set it up, the steps to follow are:

Create a new view called internal that matches clients on your internal LAN.
Create a second view called everyone that matches all clients.
Move any zones that are for internal use only into the internal 見る。 Zones for Internet domains such as example.com must not be put in this view, as that would make them inaccessible to the rest of the world.
Move all other zones (including the root zone) to the everyone 見る。

Views can also be used to prevent clients outside your network looking up non-hosted domains on your server, as follows:

Create a new view called internal that matches clients on your internal LAN.
Create a second view called everyone that matches all clients.
Move the root zone to the internal view, which will prevent the server from looking up records for non-local clients that require contact with the root servers.
Move all other zones to the everyone 見る。

モジュールアクセス制御

Like others, the BIND DNS Server module allows you to control which of its features are available to a particular Webmin user or group. This can be useful for giving people the rights to manage only records in their own zones and nobody else's. Even though this would normally require root access to the records files, with Webmin it can be granted to people without giving them level of power that a root login would allow.

Once you have created a user with access to the module as explained on WebminUsers, the steps to limit his access to only certain zones are:

Click on the BIND DNS Server next to the name of the user in the Webmin Users module. This will being up a page of access control options.
モジュール構成を編集できますか？を変更します いいえへのフィールド , so that the user is not allowed to change the paths that the module uses to named.conf and other files.
For the *Domains this user can edit *field, choose *Selected zones* and select the ones that you want him to have access to from the list to its right. If you want him to be able to edit almost all zones, it may be better to choose All except selected and select only those that he should not be allowed to manage records in. If your DNS server uses views, you can use the *Zones in view* options to allow or deny access to all zones in a view as well.
Change the fields Can create master zones? , *Can create slave/stub zones?*, Can create forward zones? and *Can edit global options?* to No 。
If you want Reverse Address records in zones that the user does not have access to to be updated by changes to Address records in zones that he does, set the *Can update reverse addresses in any domain?* field to Yes 。 This may not be a good idea from a security point of view though, as he would be able to change almost any existing Reverse Address record on your system. For that reason, I suggest that this field be set to No 。
To stop the user creating more than one Address record with the same IP, set the *Can multiple addresses have the same IP? field to *No 。 Even though creating multiple records is harmless, you may want to set this to No to prevent the user allocating the same IP twice.
Leave the Read-only access mode? field set to No 。 If it is changed to Yes , the user will only be able to view zones and records using the module, and not change anything. This might be useful for creating a different kind of restricted user though - one who can see all settings, but not edit them.
Leave the Can apply changes? field set to Yes , so that he can use the Apply Changes button to make his additions and modifications active.
Unless you want the user to be able to edit his records file manually, change the Can edit records file? いいえへのフィールド。 Most un-trusted users are not smart enough to perform manual editing.
The Can edit zone parameters? field determines if the user can see and use the Edit Zone Parameters icon for his domains. Setting this to Yes is quite safe, as the user can only harm his own zones by setting the parameters to silly values.
Similarly, the Can edit zone options? field determines if the Edit Zone Options icon is visible or not. You should set this to No , as it is possible for a user to create a syntax error in named.conf by improper use of the zone options form.
Unless you want the user to be able to delete his own domains, change the Can delete zones? いいえへのフィールド。 Users should contact the master administrator instead if they can to delete zones.
The Can edit record generators? field can be left set to Yes , as it simply allows the creation of multiple records at once. However, some users may get confused by this feature so it might be a good idea to change the field to No 。
The Can lookup WHOIS information? And *Can search for free IP numbers?* fields can also be left on Yes , as those features mere display information to the user.
Change the Can create and edit views? いいえへのフィールド , so that the user cannot manage BIND 9 views. If the user is allowed to create zones, you can use the *Views this user can edit and add zones to* field to limit those that he can create zones in.
Can create slave zones on remote servers? should be set to No , but this doesn't really matter as the user is not going to be allowed to create master or slave zones anyway.
Finally, click the Save button to make the new restrictions for the user active.