この章ではドメインネームシステム (DNS) の構造と概要を説明します。
DNS の利用で最も一般的で重要なことは、ネットワークをグローバルなインターネットに接続することです。インターネットに接続するためには、親ドメインの管理者にネットワークの IP アドレスを登録してもらう必要があります。
この章の内容は次のとおりです。
ドメインネームシステム (DNS) は、標準 TCP/IP プロトコル群のひとつのアプリケーション層プロトコルです。このプロトコルによって DNS ネームサービスが実現します。DNS ネームサービスはインターネットで使用されるネームサービスです。
ここでは、DNS の基本的な概念について説明します。説明に際しては、ネットワークの管理 (特に TCP/IP) に精通していて、NIS+ や NIS といった他のネームサービスについての知識があることを前提とします。
DNS の初期設定と構成については、第 4 章「DNS の管理 (手順)」を参照してください。
DNS、NIS+、NIS、FNS には同じような機能があり、時として異なる構成要素を定義するのに同じ用語を使用している場合がありますが、この章では、ドメインやネームサーバーといった用語は DNS の機能に合わせて定義しています。
DNS はインターネット上の複雑で全世界的なコンピュータの階層をサポートしますが、それ自身の基本機能は非常に簡単なものです。すなわち、TCP/IP に準拠したネットワークに「名前のアドレス解決」を提供するということです。名前のアドレス解決は「マッピング」ともいい、あるコンピュータのホスト名をインデックスとして用い、その IP アドレスをデータベースから見つけだすプロセスのことです。
名前のアドレスマッピングは、ローカルマシンで実行されているプログラムが遠隔コンピュータにアクセスする必要があるときに行われます。ほとんどの場合、このプログラムでは遠隔コンピュータのホスト名はわかっても、その場所を特定できません。特に遠隔マシンが自分のサイトから何マイルも離れた他の会社にある場合には場所を特定できません。プログラムは遠隔マシンのアドレスを得るために、ローカルマシン上で動作している DNS ソフトウェアに要求を送ります。このときのローカルマシンを「DNS クライアント」と呼びます。
ローカルマシンは、「DNS ネームサーバー」に要求を送ります。DNS ネームサーバーは 分散型 DNS データベースを保持しています。NIS+ の host または ipnodes テーブル、あるいはローカルの /etc/hosts ファイル、/etc/inet/ipnodes ファイルも同様の情報、すなわち、ホスト名、ipnodes 名、IPv4、IPv6 のアドレス、その他コンピュータの特定のグループに関する情報を保持していますが、DNS データベースのファイルはそれらと異なる部分が多くあります。ネームサーバーはローカルマシンが遠隔マシンの IP アドレスを検索または解決するための要求の一部として、送信する自分自身のホスト名を使用しますが、ネームサーバーは、そのホスト名も利用します。そして、要求したホスト名が DNS データベースにあれば、その IP アドレスがネームサーバーによってローカルマシンに返されます。
次の図に、DNS クライアントのローカルネットワーク上で行われるクライアントとネームサーバーの間での名前のアドレスマッピングを示します。
ホスト名がネームサーバーの DNS データベースになければ、そのマシンは権限の外側にある、すなわち、DNS の用語でいう「ローカル管理ドメイン」の外側にあることを意味します。このように、各ネームサーバーは、ローカル管理ドメインに対して権限があるとされています。
幸い、ローカルネームサーバーでは、ルートドメインネームサーバーのホスト名と IP アドレスのリストを保持しています。ローカルネームサーバーは、ローカルマシンからの要求を「ルートドメインネームサーバー」に転送します。ルートネームサーバーは、DNS 階層とインターネットで詳しく説明しているように、大きな組織のドメインに対して権限があります。その階層は、上下逆のツリー構造で編成された UNIX のファイルシステムに似ています。
各ルートネームサーバーでは、会社、大学、またはその他大規模な組織における最上位のドメインネームサーバーのホスト名と IP アドレスを管理しています。ルートネームサーバーは、ホスト名と IP アドレスがわかっているすべての最上位のネームサーバーにローカルマシンからの要求を送信します。要求されたホストの IP アドレスを最上位のネームサーバーのどれかが持っている場合、その情報がローカルマシンに返されます。最上位のサーバーが要求されたホストに関する情報を持っていない場合、情報がわかっている第 2 レベルのネームサーバーに要求が渡されます。このようにローカルマシンからの要求は組織の巨大なツリー構造の下へ向かって順に渡されます。最終的に、ローカルマシンからの要求に関する情報がデータベースに格納されているネームサーバーが IP アドレスを返します。
次の図に、ローカルドメインの外側での名前のアドレス解決を示します。
DNS から見ると「管理ドメイン」は 1 つの単位として管理されるマシン群を構成しています。このドメインに関する情報は、ドメインに対して権限を持つ 2 つ以上のネームサーバーによって管理されます。DNS ドメインはマシンを論理的にグループ分けしたものですが、小規模のビジネスにおいて全マシンが Ethernet に接続されている場合のように、ドメインのグループがマシンの物理的グループと対応している場合もあります。同様に、ローカルの DNS ドメインには、大学の大規模なネットワークのすべてのマシンが入っていることがあります。これらのマシンは、コンピュータサイエンスの学科や管理部門に属しています。
たとえば、Ajax という会社がサンフランシスコとシアトルの 2 つのサイト持っているとします。そして、Retail.Sales.Ajax.com. ドメインがシアトルにあり、Wholesale.Sales.Ajax.com. がサンフランシスコにあるとします。また、Sales.Ajax.com. ドメインが 2 つの市に分かれているとします。
各管理ドメインは、固有のサブドメイン名を持たなければなりません。さらに、ネットワークをインターネットに接続するのであれば、そのネットワークの属する管理ドメインはすでに登録されたものでなければなりません。ドメイン名とドメインの登録の詳細については、インターネットへの参加の節を参照してください。
すでに説明したように、管理ドメイン内のネームサーバーは、DNS データベースを保持しています。また、このネームサーバーは in.named デーモンを実行して DNS サービスを実装します。in.named は、パブリックドメインの TCP/IP プログラムであり、Solaris オペレーティング環境に含まれています。
in.named デーモンは、カリフォルニア大学バークレー校で開発されたので、Berkeley Internet Name Domain service (BIND) と呼ばれることもあります。
各ドメインには、マスターサーバーが 1 つと、バックアップ用のスレーブサーバーが 1 つ以上必要です。マスターサーバーとスレーブサーバーの詳細については、DNS の実装を参照してください。
in.named デーモンを正しく機能させるには、1 つの構成ファイルと 4 つのデータファイルが必要です。
マスターサーバーの構成ファイルは、/etc/named.conf です。この構成ファイルには、ドメイン名と、ホスト情報を含むファイル名が記述されています。named.conf ファイルの詳細については、named.conf ファイルを参照してください。
内部で一貫性が取れていれば、ゾーンデータファイルには何でも好きな名前を付けることができます。名前の付け方への柔軟性が高いために、他のサイトで作業をしたり、DNS 間連の各種マニュアルを参照する場合に、混乱を招くことがあります。
たとえば、Sun のマニュアルや大多数の Solaris サイトで使われているファイル名は、『DNS and BIND』(Paul Albeltz & Criclcet Liu 著、浅羽登志也/上水流由香監訳 、アスキー出版局、1995年) で使われているファイル名とは異なります。そしてこれら 2 派の命名方法は、『Name Server Operations Guide for BIND』に記載されているパブリックドメインの命名方法とも若干の相違があります。
さらに、本書とその他の DNS 関連のマニュアルでは、説明にはファイルの主な役割を表す総称名を使い、コード例ではファイルに対して具体的な固有の名前を使っています。たとえば、Solaris のネームサービスに関するマニュアルでは、ファイルの機能や役割を説明する場合は hosts という総称名を使い、コード例では db.doc や db.sales といった名前を使っています。
必要なデータファイルは次のとおりです。
/var/named/named.ca。named.ca ファイルの詳細については、named.ca ファイルを参照してください。内部で一貫性が取れていれば、このファイルには任意の名前を付けることができます。
/var/named/hosts。hosts ファイルの詳細については、hosts ファイルを参照してください。
hosts という名前はファイルの役割や内容を表す総称名です。ただし、この総称名をそのまま使うと /etc/hosts と紛らわしいので、この種のファイルは hosts 以外の名前にします。最も一般的な名前の例は、db.domainname です。たとえば、doc.com ドメインの hosts ファイルの名前は db.doc となります。
ドメイン内に複数のゾーンがある場合は、各ゾーンに 1 つずつ hosts ファイルを置き、各ゾーンの hosts ファイルには一意の名前を付けなければなりません。たとえば、doc.com と sales.doc.com に分けられている DNS ドメインであれば、一方の hosts ファイルの名前は db.doc、もう一方の名前は db.sales とします。
/var/named/hosts.rev。hosts.rev ファイルの詳細については、hosts.rev ファイルを参照してください。
hosts.rev という名前は、ファイルの役割や内容を表す総称名です。ドメイン内に複数のゾーンがある場合は、各ゾーンに 1 つずつ hosts.rev ファイルを置き、各ゾーンの hosts.rev ファイルには一意の名前を付けなければなりません。たとえば、DNS ドメイン内に doc.com と sales.doc.com という 2 つのゾーンがある場合は、1 つを doc.rev、もう 1 つを sales.rev という名前にするとよいでしょう。
/var/named/named.local。named.local ファイルの詳細については、named.local ファイルを参照してください。内部で一貫性が取れていれば、このファイルには任意の名前を付けることができます。
インクルードファイルは、DNS データファイルの中の $INCLUDE() 文で指定された任意のファイルです。$INCLUDE ファイルを使ってデータを型ごとに別々のファイルに分割しておくと便利です。$INCLUDE ファイルを参照してください。
参考のため、次の表では上で述べた BIND ファイル名を比較します。
表 3–1 ファイル名
Solaris |
O'Reilly / その他 |
カリフォルニア州立大学バークレイ校 |
ファイルの内容と役割 |
---|---|---|---|
/etc/named.conf (全て同じファイル名) |
BIND 8.1 では新たに named.conf ファイルを追加して、従来の named.boot ファイルと置きかえる。この構成ファイルにはセキュリティ、スタートアップオプション、ロギングが追加されている。このファイルによって、稼動中のサーバーの種類を指定して、すべてのゾーンまたはサーバーではなく、ゾーンごとまたはサーバーごとにオプションを選択的に適用する。ドメイン名とデータファイル名が記述されている |
||
/etc/resolv.conf (全て同じファイル名) |
各クライアント (DNS サーバーを含む) 上に存在するファイル。DNS 情報を探すためにクライアントが照会するサーバーを示す |
||
named.ca |
db.cache db.root |
root.cache |
ルートサーバー名とそのアドレスがリストされている |
総称名: hosts 例: db.docdb.sales |
総称名: db.domain 例: db.movie、 db.fx |
総称名: hosts 例: ucbhosts |
サーバーがサービスを提供するローカルゾーン内のマシンに関する全データが格納されている |
総称名: hosts.rev 例: doc.rev |
総称名: db.ADDR 例: db.192.249.249 db.192.249.253 |
hosts.rev |
逆変換 (アドレスから名前への変換)を行うための特殊ドメイン in-addr.arpa. 内のゾーンを指定する |
named.local |
総称名: db.cache 例: db.127.0.0 |
named.local |
ローカルループバックインタフェース (ローカルホスト) 用のアドレスを指定する |
$INCLUDE ファイル (全てで同じ規則) |
データファイル内の $INCLUDE() 文によって指定されるファイル |
「ドメイン名」とは、ローカルネットワークの中で DNS 管理ファイルを共有する複数のシステムを 1 つのグループとして扱って、そのグループに付けた名前のことです。ドメイン名は、ネットワーク情報サービスデータベースが正常に動作するために必要です。
DNS がデフォルトで使用するドメイン名は resolv.conf ファイルに指定されています。
resolv.conf ファイルがない場合、あるいは resolve.conf ファイルにデフォルトのドメイン名が指定されていない場合で、しかも、エンタープライズレベルで使っているネームサービスが NIS+ または NIS のどちらかである場合は、Sun が実装する DNS はそれらのサービスからデフォルトのドメイン名を取得します。
resolv.conf ファイルがない場合、あるいは resolv.conf ファイルにドメイン名が指定されていない場合で、しかも、NIS+ と NIS のどちらも使っていない場合は、そのドメインを指定するすべてのマシンに resolv.conf ファイルを追加するか、LOCALDOMAIN
環境変数を設定しなければなりません。
各種 DNS 関連ファイルを使用する場合、ドメイン名の末尾のドットには次のような規則があります。
hosts、hosts.rev、named.ca、named.local の各データファイルの中では、ファイル名の末尾にドットを付けます。たとえば、sales.doc.com. は、これらのファイルの中では有効です。
named.boot ファイルまたは resolv.conf ファイルの中では、ドメイン名の末尾にドットを付けません。たとえば、sales.doc.com は、これらのファイルの中では有効です。
あるマシンを DNS クライアントにするには、「リゾルバ」を実行する必要があります。リゾルバはデーモンでも単一のプログラムでもなく、アプリケーションによって使用される動的ライブラリルーチンの集合です。マシン名を知る必要があるときに、このライブラリが使用されます。リゾルバの機能はユーザーの照会を解決することです。このために、リゾルバはネームサーバーに照会します。するとネームサーバーは要求された情報か、または他のサーバーに照会する旨を返します。一度リゾルバを設定すれば、そのマシンはネームサーバーに DNS サービスを要求できるようになります。
DNS ネームサーバーは、いくつかのファイルを使用して、そのデータベースを読み込みます。リゾルバのレベルでは、必要な情報を取得できるサーバーのアドレスを登録するファイル (/etc/resolv.conf) が必要です。リゾルバは resolv.conf ファイルを読み取り、ローカルドメインの名前とネームサーバーの位置を見つけます。リゾルバはローカルドメイン名を設定し、リゾルバルーチンに指示して、登録されたネームサーバーに情報を照会させます。通常、ネットワーク上の各 DNS クライアントシステムの /etc ディレクトリには、resolv.conf ファイルがあります。クライアントに resolv.conf ファイルがない場合は、デフォルトにより IP アドレス 127.0.0.1 にあるサーバーが使用されます。
リゾルバがホストのアドレス (またはアドレスに対応する名前) を探さなければならないときには、照会パッケージを構築し、/etc/resolv.conf に登録されたネームサーバーにこれを送信します。サーバーは、その照会にローカルに応答するか、または他のサーバーのサービスを使ってリゾルバに答えを返します。
あるマシンの /etc/nsswitch.conf ファイルで hosts:dns (または hosts 行に dns を含む別のパターン) が指定されていると、リゾルバのライブラリが自動的に使用されます。nsswitch.conf ファイルが dns より前に、他のネームサービスを指定した場合、最初にそのネームサービスに対してホスト情報を問い合わせ、要求されたホストの情報が見つからなかった場合にだけリゾルバのライブラリが使用されます。
たとえば、nsswitch.conf ファイル内の hosts の行で hosts:nisplus dns と指定されている場合、ホストの情報を得るために NIS+ ネームサービスが最初に検索されます。NIS+ で情報が見つからない場合は、DNS リゾルバが使用されます。NIS+ や NIS といったネームサービスではそれ自身のネットワーク内にあるホストに関する情報だけを保持しているため、スイッチファイルに hosts:nisplus dns 行を指定すると、ローカルホストの情報に対しては NIS+ が使用され、インターネット上の遠隔ホストの情報に対しては DNS が使用されることになります。
DNS クライアントには、次の 2 種類があります。
クライアント専用
クライアント専用の DNS クライアントは in.named を実行せず、代わりにリゾルバを参照します。リゾルバはドメインに対するネームサーバーのリストを保持しているので、リゾルバに問い合わせが転送されます。
クライアント兼サーバー
クライアント兼サーバーの DNS クライアントは、クライアントマシンのリゾルバによって転送されてきた問い合わせを解決するために in.named で提供されるサービスを使用します。
resolv.conf ファイルの機能については、resolv.conf(4) のマニュアルページを参照してください。
resolv.conf ファイルの設定方法については、resolv.conf ファイルの設定を参照してください。
BIND 8.1 では、新たに構成ファイル /etc/named.conf を追加して、/etc/named.boot ファイルと置き換えました。/etc/named.conf ファイルは、マスター、スレーブ、キャッシュ専用のネームサーバーを確立します。また、サーバーが権限を持つゾーンを指定し、どのデータファイルから初期データを取得するかを指定します。
/etc/named.conf ファイルには、次の機能を実装するための文が含まれます。
アクセス制御リスト(ACL) によるセキュリティ。このリストには、NIS+ ホストが読み取り権と書き込み権を持っている IP アドレスの集まりが定義されている
ロギング動作の指定
この構成ファイルは、サーバーの起動スクリプト /etc/init.d/inetsvc によってデーモンが起動されるとき、 in.named によって読み取られます。そして、in.named が他のサーバーや、指定されたドメインのローカルデータファイルに対して実行されるようにします。
named.conf ファイルは、いくつかの文とコメントで構成されています。文はセミコロンで終わります。一部の文には、文のブロックを記述することができます。ブロック内の各文もセミコロンで終わります。
表 3–2 named.conf で使用する文acl |
アクセス制御に使用する、IP アドレスの一致リストを名前を付けて定義する。アドレスの一致リストは、1 つ以上の IP アドレス (ドット形式の 10 進表記) または IP 接頭辞 (ドット形式の 10 進表記の後にスラッシュとネットマスクのビット数が付く) を示す。名前を付けたIP アドレスの一致リストは、他の場所で使用する前に acl 文で定義されている必要がある。前方参照は不可 |
include |
include 文がある箇所にインクルードファイルを挿入する。include を使用することで、より管理しやすいまとまりに構成情報を分割することができる |
key |
特定のネームサーバーでの認証と承認に使用される鍵の ID を指定する。server 文を参照 |
logging |
サーバーが記録するログの種類とログメッセージの送り先を指定する |
options |
グローバルなサーバー構成のオプションを制御して、他の文に対するデフォルト値を設定する |
server |
遠隔ネームサーバーに関して、指定された構成オプションを設定する。すべてのサーバーに対してではなく、サーバーごとに選択的にオプションを適用する |
zone |
ゾーンを定義する。すべてのゾーンに対してではなく、ゾーンごとに選択的にオプションを適用する |
options { directory "/var/named"; datasize 2098; forward only; forwarders { 99.11.33.44; }; recursion no; transfers-in 10; transfers-per-ns 2; allow-transfer { 127.0.1.1/24; }; }; logging { category queries { default_syslog; }; }; include "/var/named/abcZones.conf" // マスターファイルの名前 zone "cities.zn" { type master; file "db.cities.zn"; }; zone "0.0.127.in-addr.arpa" { type master; file "db.127.cities.zn"; }; zone "168.192.in-addr.arpa" { type master; file "db.cities.zn.rev"; }; zone "sales.doc.com" { type slave; file "slave/db.sales.doc"; masters { 192.168.1.151; }; }; zone "168.192.in-addr.arpa" { type slave; file "slave/db.sales.doc.rev"; masters { 192.168.1.151; }; }; |
大規模な会社であれば、多くのドメインをサポートしており、ローカルな名前空間が構成されていることでしょう。次の図に、ある会社に存在するドメインの階層構造の例を示します。この会社の最上位のドメイン、すなわちルートドメインは ajax.com で、その下に sales.ajax.com、test.ajax.com、manf.ajax.com の 3 つのサブドメインがあります。
DNS クライアントは、そのドメインをサポートしているサーバーだけにサービスを要求します。クライアントの必要としている情報がそのドメインサーバーにない場合、要求は親サーバーに転送されます。親サーバーは、1 つ上の階層のドメインサーバーです。要求が最上位のサーバーに達した場合、最上位のサーバーはクライアントのドメインが有効かどうか調べます。ドメインが有効でない場合、サーバーは「not found」というメッセージをクライアントに返します。ドメインが有効な場合、最上位のサーバーはそのドメインをサポートしているサーバーに要求を転送します。
次の図に示したドメインの階層は、グローバルなインターネット上でサポートされる巨大な DNS 名前空間の「枝葉」のようなものです。
それは、ピリオド (.) で表されるルートディレクトリと、最上位のドメインの階層 2 つ (組織的なものと地理的なもの) で構成されます。次の図の com ドメインは、インターネットに存在する最上位の組織ドメインの 1 つです。
現在、組織的な階層の名前空間は、次の表に示した最上位のドメインに分けられます。将来、これ以外にも最上位の組織ドメインが追加される可能性があります。
表 3–3 インターネットの組織ドメイン
ドメイン |
目的 |
---|---|
com |
営利団体 |
edu |
教育機関 |
gov |
行政機関 |
mil |
軍事組織 |
net |
ネットワークサポートセンター |
org |
非営利団体 |
int |
国際組織 |
地理的な階層においては、各国に対して 2、3 文字の識別子が割り当てられ、それが、各国に対する公式名として用いられます。たとえば、イギリス国内のドメインは、uk という最上位のドメインのサブドメインになります。日本国内のドメインは、jp のサブドメインで、他の国に関しても同様です。
インターネットのルートドメイン、すなわち最上位のドメイン (組織的および地理的) は、様々なインターネット運営体によって管理されています。規模にかかわらずネットワークを有する人は、そのネットワークのドメイン名を組織的な階層か地理的な階層に登録することによってインターネットに参加できます。
DNS ドメインはドメイン名を持つ必要があります。インターネットに接続しないで、ネームサービスとして DNS を使用する場合は、ドメインやサブドメインに任意の名前を付けることができます。ただし、インターネットに参加する場合は、そのドメイン名をインターネット運営体に登録する必要があります。
インターネットに参加する場合は、次の手順に従います。
上記のことを行うには、次の 2 つの方法があります。
適切なインターネット運営体またはその代理団体と直接連絡をとる方法
インターネットサービスプロバイダ (ISP) と契約する方法。ISP は、コンサルティングから実際の接続まで広範なサービスを提供している
ドメイン名は、DNS 名前空間全体でのドメインの位置を表します。それは UNIX のファイルシステムでパス名がファイルの位置を表しているのと同じです。ローカルドメインが登録されると、そのドメイン名は所属するインターネットの階層の名前に追加されます。たとえば、図 3–5 で示した Ajax ドメインはインターネットの階層である com の一部として登録されました。したがって、そのインターネットドメイン名は ajax.com となります。
次の図に、ajax.com ドメインがインターネット上の DNS 名前空間のどこに位置しているのかを示します。
ajax.com のサブドメインには、次のような名前があります。
sales.ajax.com test.ajax.com manf.ajax.com |
DNS ではドメイン名を大文字にすることは可能ですが、必須ではありません。次に、マシン名とドメイン名の例を挙げます。
boss.manf.ajax.com quota.sales.ajax.com |
インターネットでのドメインの管理は、ドメイン内のホスト名に対する権限を各ドメインに保証し、各ドメインがそれより下位のレベルに権限を委任することによって行われます。したがって、com ドメインはそのドメイン内のホスト名に対して権限があります。また com ドメインは、ajax.com ドメインに対して編成の権限を与え、そのドメイン内の名前に対する権限を委任します。それを受けて ajax.com はドメイン内のホストに名前を割り当て、sales.ajax.com、test.ajax.com、manf.ajax.com の各ドメインの編成を承認します。
ドメイン名にローカルドメインから DNS のルートドメイン (.) までのすべての DNS のドメインが含まれているとき、そのドメイン名は「完全指定されている」といいます。概念的には、完全指定ドメイン名は、UNIX ファイルの絶対パス名と同様に、ルートへのパスを示しています。しかし、完全指定ドメイン名を読む場合、左から右に進むにしたがって最下位から最上位となります。したがって、完全指定ドメイン名は次のような構文になっています。
ajax ドメインとそのサブドメインの完全指定ドメイン名は、次のとおりです。
ajax.com. sales.ajax.com. test.ajax.com. manf.ajax.com. |
ここで、各名前の一番右に付けられたドット (.) に注意してください。
ドメインの DNS サービスは、ネームサーバーの集合で管理されます。ネームサーバーは、単一のドメインまたは複数のドメイン、あるいは複数のドメインとその下のサブドメインの一部または全部を管理できます。あるネームサーバーによって管理される名前空間の一部は、「ゾーン」と呼ばれます。したがって、ネームサーバーはゾーンに対して権限があるといわれます。ネームサーバーの責任者は、「ゾーン管理者」とも呼ばれます。
ネームサーバーのデータベース内のデータは、「ゾーンファイル」と呼ばれます。ゾーンファイルの 1 つには、IP アドレスとホスト名が格納されています。ftp または telnet のようなユーティリティでホスト名を用いて遠隔ホストに接続しようとすると、DNS は名前のアドレスマッピングを実行し、ゾーンファイルの中でホスト名を探して、IP アドレスに変換します。
たとえば、上の図で示した Ajax ドメインは、最上位のドメイン (Ajax) 、4 つのサブドメイン、そして 5 つのサブサブドメインから構成されます。このドメインは、4つのゾーンから構成されます。 したがって、Ajax ネームサーバーは、Ajax、Sales、Retail、Wholesale の各ドメインからなるゾーンを管理します。Manf と QA の両ドメインは、自分自身のネームサーバーからサービスを受ける特殊なゾーンです。Corp ネームサーバーは Corp、Actg、Finance、Mktg ドメインからなるゾーンを管理します。
DNS データベースには、マシンのホスト名を見つけだすキーとして IP アドレスを用いるゾーンファイルもあります。このファイルで IP アドレスのホスト名解決が可能になります。このプロセスを、「逆解決」または、より一般的には「逆マッピング」と呼びます。逆マッピングは基本的にはメッセージを送ってきたマシンの識別情報を確認したり、ローカルホスト上での遠隔操作を許可したりするために使用されます。
in-addr.arpa ドメインは、DNS 名前空間において概念的な存在であり、認証 (許可) のためにドメインでなく IP アドレスを用います。このドメインは、ゾーンの一部ですが、これによってアドレスから名前のマッピングが可能になります。
DNS ドメイン名は、一番左が最下位のサブドメイン、一番右がルートとして読まれるので、in-addr.arpa ドメインでも、IP アドレスは最下位のレベルからルートになるように理解されます。すなわち、IP アドレスは逆転します。たとえば、あるホストの IP アドレスが 192.168.21.165 であるとします。in-addr.arpa ゾーンファイルでは、そのアドレスは 165.21.168.192.in-addr.arpa. と記述されます。ここで最後のドットは、in-addr.arpa ドメインのルートを示しています。