ドメイン(=domain)とは、「範囲」や「領域」を表す言葉です。インターネットでは、それぞれの組織（会社や学校、プロバイダなど）に属するネットワークに対して、階層的な方法で付けられた名前がドメイン名です。ドメイン名のトップレベルには、.comや.org、.netなどの組織の種類を表すものと、.jpや.krなどのように国を表すものがあります。トップレベルドメインの下にxxxx.comやxxxxx.orgといった会社や団体のドメインが所属します。会社や団体のドメインの下に、更に部署や地域、製品などに関連したサブドメインを作ることができ、これらのドメインやサブドメインの下にwwwやnsなどのマシン（サーバ）を表す名前が割り当てられます。「ドメイン名」は、「www.orquesta.org」のように、個々のサーバを表す場合と「orquesta.org」のように組織全体を表す場合があります。個々のサーバを表すドメイン名をFQDN（Fully Qualified Domain Name）と呼んで区別することもあります。

　DNSはドメイン・ネーム・システムの頭文字を取ったもので、ドメイン名とIPアドレスを対応付けるための仕組みです。たとえば、この記事を書いている時点ではwww.orquesta.orgというドメイン名が203.191.253.79というIPアドレスに対応づけられています。このようにドメイン名をIPアドレスに変換（正引き）するのがDNSの最も重要な機能です。逆にIPアドレスからドメイン名に変換（逆引き）する機能もありますが、こちらは必ずしも設定する必要はなく、付加的な情報として扱われる場合が多いです。
　DNSのもう1つの重要な機能は、メールアドレスとメールサーバを結びつけることです。メールサーバは、宛先がinfo＠orquesta.orgのメールをどどこに送ればよいのかをDNSに問い合わせてメールを処理します。

　DNSサーバには2つの役割があります。1つは、組織内のクライアントコンピュータからの、インターネット上のあらゆるドメイン名に関する問い合わせを受け付けることです。DNSサーバーは、自分が知っているドメイン名についてはそのIPアドレスを返しますが、知らないドメインについてはそのドメインのネームサーバ（＝元締め）に問い合わせを行ってIPアドレスを調べます。たとえば、www.street.jpというドメイン名についてクライアントから問い合わせがあった場合、DNSサーバがそのIPアドレスを知らなければ、street.jpのネームサーバにwww.street.jpのIPアドレスをたずねます。street.jpのネームサーバのIPアドレスを知らなければ、jpのネームサーバにstreet.jpのネームサーバのIPアドレスをたずねます。このようにネームサーバを上位に辿っていくと、ルートサーバに行き着きます。ルートサーバは、すべてのトップドメインのネームサーバを知っているので、何度か問い合わせを繰り返すことによって、目的のIPアドレスにたどり着くことができます。通常、クライアントからの問い合わせに答えるDNSサーバはプロバイダが用意してくれていて、ブロードバンドルータの中継機能を使って問い合わせを行います。
　DNSサーバーのもう1つの役割は、自ドメインのネームサーバとして、他のドメインからの問い合わせに答えることです。orquesta.orgのネームサーバは、他のドメインのDNSサーバからwww.orquesta.orgのIPアドレスをたずねられるので、その問い合わせ対して203.191.253.79というIPアドレスを返します。レジストラで自分のドメイン名を取得した場合、このネームサーバをどこかに用意しなければなりません。レジストラやプロバイダが（有料または無料の）オプションとしてDNSサーバを提供している場合もあります。ここでは、Mac miniを orquesta.biz というドメインのネームサーバとして設定する方法を説明します。

　ネームサーバは、耐障害性を向上させるためにプライマリとセカンダリを用意することになっています（セカンダリは複数の設置が可能）。プライマリネームサーバには、そのドメインに関するドメイン名の情報が書かれたゾーンファイルを置きます。セカンダリネームサーバには、プライマリネームサーバのIPアドレスだけを指定し、ドメイン名の情報はプライマリネームサーバからゾーン転送によって取得します。
　多くの場合、ドメインのレジストラでは、取得したドメインに対するネームサーバ設定するウェブページを用意しています。このページでプライマリネームサーバとセカンダリネームサーバのIPアドレスを設定すると、このドメインに関する問い合わせがこれらのネームサーバに送られるようになります。
　耐障害性の観点から、プライマリとセカンダリは異なるネットワークに設置すべきです。同じネットワークに設置すると、そのネットワークに障害が生じた場合にどちらのネームサーバにもアクセスできなくなってしまうからです。自宅や社内ネットワークにプライマリを置いている場合は、ホスティングサービスを使ってセカンダリを運用したり、知人やグループ会社、互助会などにセカンダリの運用を依頼する方法があります。ただし、セカンダリの設定を改竄されると偽サイトへの誘導やメールを横取りすることなどもできてしまうので、依頼先は慎重に選ぶ必要があります。

DNSサーバ一般にnamed（dはデーモンの頭文字）と呼ばれていて、もっとも有名なプログラムがBIND（Berkeley Internet Name Domain）です。Mac OS X10.5 (Leopard)には、このプログラムが既にインストールされているので、次のような設定ファイルを準備して起動すればネームサーバとして機能します。

BINDに制御メッセージを送る際に使われる暗号化の鍵です。ルート権限でrndc-confgenというプログラムに -a オプションをつけて実行すると、このファイルが生成されます。
/etc/rndc.keyの内容は次のようなものです。
このファイルは、デフォルトで次のような内容になっています。
このネームサーバでorquesta.bizというドメインを管理する場合、次のようなセクションを上のファイルに追加します。
「zone  "orquesta.biz"」は、orquesta.bizというドメインのゾーンに関する設定であることを示しています。次のINはインターネットを表しています（省略可）。typeはプライマリネームサーバの場合はmaster、セカンダリの場合はslaveを指定します。fileはゾーンファイルの名前を指定します。

ファイルを保存したらnamed-checkconfコマンドでnamed.fonfの内容をチェックします。書式に誤りがなければ何も表示されません。
optionsセクションでdirectoryが"/var/named" に設定されているので、このディレクトリに次のようなゾーンファイル(orquesta.biz.zone)を作成します。
■$ORIGIN
最初の行の$ORIGIN では、ゾーンの起点名を指定します。ゾーンファイルでは、ドット(.)で終わらない名前は省略形とみなされ、起点名が補われます。たとえば、一番下の行のwwwはwww.orquesta.biz.と同じです。

■$TTL
$TTLではゾーンの生存期間（Time To Live）のデフォルト値を設定します。このネームサーバに問い合わせを行ったDNSサーバは、この値に基づいてキャッシュの有効期限を決めます。TTLの値は、各レコードごとに指定することも可能です。

■SOAレコード
　SOA（Start Of Authority）レコードは、このネームサーバがこのドメインの「元締め」であることを示すものです。行頭の@は起点名に置き換えられ、このSOAレコードがorquesta.biz.ドメインに関するものであることを示します。次のINはインターネットを表していて、省略可能です。SOAの後のns.orquesta.biz.はorquesta.biz.ドメインのプライマリネームサーバ（つまりこのサーバ）の名前です。その後のtakegata.veltec.co.jp.は、このゾーンの管理者のメールアドレスを表しています。ただし、アットマーク(@)の変わりにドット(.)を使います。また、最後にドットが必要なことも注意してください。
　続くカッコの中は、シリアル番号、リフレッシュ時間、リトライ時間、期限切れまでの期間、ネガティブキャッシュの時間です。シリアル番号は、このファイルを編集して保存するたびに値を増やします。その他の設定は、ほとんどの場合はこのままでOKです。

■NSレコード
NSレコードは、このドメインのネームサーバを登録します。上の例では、ns.orquesta.biz.（プライマリネームサーバ）とj-webapp.zone-express.jp.（セカンダリネームサーバ）の2つのサーバが登録されています。

■MXレコード
MXレコードは、このドメインのメールサーバを登録します。MXの後の値(10)はメールサーバの優先順位で、冗長性確保のために複数のメールサーバを登録した場合に値の小さい方が優先されます。

■Aレコード
名前からIPアドレスのマッピングを登録します。上の例では、ns.orquesta.biz.という名前（FQDN）のサーバに116.58.176.51というIPアドレスが割り当てられています。

■CNAMEレコード
CNAME（Canonical NAME）レコードでは、サーバに対する別名を登録します。上の例では、ns.orquesta.biz.というサーバにwww.orquesta.biz.という別名を割り当てています。

named-checkzoneコマンドでゾーンファイルの記述内容をチェックすることができます。
Leopardでは、LaunchDaemonsでBINDを起動するための.plistファイル(org.isc.named.plist)が予め用意されています。launchctl の load サブコマンドでBINDを起動し、-w オプションでOSブート時の自動起動を設定することができます。
BINDが起動しているかどうかは、launchctl の list サブコマンドで確認できます。下の例では、BINDのラベル名（org.isc.named）をgrepで検索しています。
起動したBINDがドメイン名の問い合わせに対して正しく応答するかどうかをnslookupで確認します。
上の例では、www.orquesta.bizというドメイン名（FQDN）をlocalhostに問い合わせています。同じことをdigで確認するには次のようになります。
ゾーンファイルの内容を修正した場合は、シリアルの値を増加させてBINDを再起動します。BINDの再起動はlaunchctlでstopサブコマンドを使います。
.plistでOnDemandがfalseに設定されている（＝常駐）ので、停止後すぐに起動します（BINDを停止させるにはunloadサブコマンドを使います）。

ネームサーバをプライベートIPのマシンで運用している場合は、ルータでSTATIC
NATを設定する必要があります。DNSが使用するポートは53番で、プロトコルはTCPとUDPです（問い合わせにはUDPを使い、セカンダリへのゾーンの転送にTCPを使います）。ここで使っているMac miniのIPアドレスは192.168.1.10なので、TCPの53番ポートとUDPの53番ポートへのアクセスを192.168.1.10に転送するようにルータのSTATIC NATを設定します。

セカンダリを運用するサーバ（ここでは j-webapp.zone-express.jp）のnamed.confに次のようなセクションを追加します。
セカンダリを運用するサーバでBINDを再起動してnslookupで動作を確認します。
ドメインを取得したレジストラでネームサーバの設定を行います。設定の結果がプロバイダのDNSサーバに反映されるまでにはしばらく時間がかかります（1時間〜3時間？）。設定が反映されるまでにかかる時間はプロバイダによって異なります。つまり、「あるプロバイダのユーザはアクセスできるのに、別のプロバイダのユーザはアクセスできない」という状況が有り得ます。利用しているプロバイダのDNSが更新されたかどうかはnslookupで調べることができます。
上の例では、問い合わせ先のDNSサーバを指定していないのでデフォルトのサーバ（192.168.1.1）が使われています。これはルータのIPアドレスで、ルータはnslookupからの問い合わせをプロバイダのDNSに転送し、結果をnslookupに返します。上の例では、Mac miniのBINDで設定したIPアドレスが返ってきていないので（おそらくレジストラがデフォルトで設定しているレジストラ内部のアドレス）まだ設定が反映されていないということが分かります。しばらく時間を置いて再度nslookupを実行し、BINDで設定したIPアドレスが返ってくれば設定は完了です。