今日、インターネットやほとんどすべてのローカルネットワークは、実用的で信頼性の高いドメイン名サービス（DNS）に依存しています。ドメイン名サービス（DNS）とは、システム名をIPアドレスに変換したり、IPアドレスをシステム名に変換したりするサービスです。
ネットワークでDNSを簡単に利用するには、システム名をシステムの接続に必要なIPアドレスに変換するネームサーバーが必要です。また、ネームサーバーは、IPアドレスをシステム名に戻すこともできます。これは一般に逆引きと呼ばれています。
この章では、BIND、その設定ファイルの構造、BINDをローカルに、あるいはリモートから管理する方法などについて説明します。
BIND設定ツールというGUIを使用したBIND設定の手引きについては、オフィシャル Red Hat Linuxカスタマイズガイドを参照してください。BIND設定ツールを使用している場合には、手動でBIND設定ファイルを編集しないでください。手動で変更したものが、BIND設定ツールによって上書きされてしまうためです。
IPネットワークを利用したシステムがリモートマシンと接続するには、そのシステムがリモートマシンのIPアドレスを知らなくてはなりません。しかし、たいていのユーザーは、ホスト名や完全修飾ドメイン名（FQDN）などマシン名でシステムを指定して接続したいと考えるでしょう。さらに、多くのプログラムでは、さまざまな理由から、たとえばシステム名を変更せずにIPアドレスが変更できるよう、リモートシステムを参照する際の設定ファイル内でドメイン名を使用しています。この操作を簡単にするサービスがDNSです。通常この操作は、いくつかのドメインに対して権限を持つ中央サーバーで行われ、まだ知らない情報については、他のDNSサーバーを参照します。
DNSは、IPと名前の変換を行うネームサーバーデーモンを使用することにより動作可能になります。クライアントアプリケーションは、通常サーバーのポート53に接続されているネームサーバーに情報を要求します。ネームサーバーは、リゾルバライブラリに基づいてFQDNを解決しようとします。リゾルバライブラリには、以前のクエリによりホストが要求したか、キャッシュしたデータや名前についての権限のある情報が含まれているかもしれません。ネームサーバーのリゾルバライブラリに回答がない場合は、該当するFQDNにどのネームサーバーが権限と持っているのかを決定するためルートネームサーバーと呼ばれる他のネームサーバーに問い合わせます。そしてその情報を利用してその名前に対して権限のあるネームサーバーにクエリを行いIPアドレスを決定します。逆引きをを行う場合にも同じ手順が使われます。ただし、名前ではなく未知のIPアドレスでクエリが行われます。
インターネット上では、ホストのFQDNはいくつかのセクションに分解され、それらのセクションは、主幹、プライマリ枝、セカンダリ枝などを持つ木のような階層に編成されます。以下のようなFQDNを考えてみましょう。
ある特定のシステムを示すIPアドレスを見つけるためにFQDNをどのように解決したらよいかを考える場合、名前を右から左へ読まなくてはなりません。各階層はドット（.）によって分けられています。この例では、comがこのFQDNの最上位ドメインを示します。domain名は、comの下のサブドメインであり、salesは、domainの下のサブドメインです。FQDNの一番左の名前が、特定のマシンを識別するホスト名です。
ホスト名を除くすべてのセクションは、ゾーンと呼ばれ、特定のネーム空間を定義します。ネーム空間は、その左側に合わせてサブドメインの命名を制御します。この例には2つのサブドメインしかありませんが、使用しているネーム空間の構成によりFQDNには1つ以上いくつのサブドメインがあってもかまいません。
ゾーンは、ゾーンファイルを使うことによって、権限をもつネームサーバー上で定義されます。ゾーンファイルには、該当するゾーンのネーム空間、特定のドメインかサブドメインに使用されるメールサーバーなどさまざまな情報が記載されます。ゾーンファイルは、実際に権限を持ちファイルへの変更が行われるプライマリネームサーバー（マスターネームサーバーとも呼ばれる）とプライマリネームサーバーからゾーンファイルを受け取るセカンダリネームサーバー（スレーブネームサーバーとも呼ばれる）に保存されます。どのネームサーバーも、同時に異なったゾーンのプライマリネームサーバーやセカンダリネームサーバーとなることができ、複数のゾーンについて権限を持つと考えることができます。これはすべてネームサーバーの設定により異なります。
プライマリネームサーバー設定には4つのタイプがあります。
master あるネーム空間に対するオリジナルの権限あるゾーンレコードを保存し、そのネーム空間に関する回答を探している他のネームサーバーからの質問に回答します。
slave このサーバーに権限があると考えられているネーム空間に関して、他のネームサーバーからのクエリに回答します。しかし、スレーブネームサーバーは、ゾーン転送によりマスターネームサーバーからネーム空間情報を入手します。このとき、スレーブネームサーバーはマスターネームサーバーにあるゾーンに対するNOTIFY要求を送り、スレーブネームサーバーに転送を受け取る権限がある場合には、マスターサーバーは情報を送り返します。
caching-only 名前からIPへの解決を行うサービスを提供しますが、どのゾーンにも権限を持っていません。すべての解決に対して回答は一定期間メモリ内のデータベースにキャッシュされます。キャッシュ期間は通常検索されたゾーンレコードによって指定されます。これにより、最初の解決の後で他のDNSクライアントに対する解決がより迅速になります。
forwarding 解決を行うべきネームサーバーの一覧に要求を転送します。指定されたネームサーバーのうちどのネームサーバーも解決することができない場合、処理は停止し、解決は失敗します。
ネームサーバーは、上記のタイプのうち1つのタイプのものであってもかまいませんし、複数のタイプを共有していてもかまいません。たとえば、あるネームサーバーはあるゾーンではマスターであり、他のゾーンではスレーブであってもかまいませんし、転送解決だけを提供するものであってもかまいません。
Red Hat Linuxには、非常に人気の高い強力なオープンソースネームサーバーであるBINDが含まれています。BINDは、namedデーモンで名前解決サービスを提供します。BINDのすべての設定情報は、/etc/named.confファイルに保存されており、そのゾーンファイルは、/var/namedディレクトリに保存されています。これらのさまざまなタイプのファイルの構造とオプションは、BIND設定ファイル項に記載されています。
BINDバージョン9には、rndcと呼ばれるユーティリティが含まれており、namedデーモンの実行を管理することができます。rndcの詳細については、rndcの使用法項を参照してください。