DNSでは、全ての名前をファイルシステムのようにして管理する。 ファイルシステムでは、名前は、
/home/net/staff/kanayama
のように左から / をセパレータとして一意に決まる。同時に、
最初のセパレータ/はツリー構造の出発点であるルートの
意味も持つ。一方、DNSでは右から出発する。
summer.wakhok.ac.jp.
は、jp,ac,wakhok,summerの順に
より名前構造としては深い名前へと並び、ディレクトリ構造における
ルート/の役割は、一番右の .が持ち、.は
同時にセパレータとしての役割も持っている。ディレクトリに相当する
jpやwakhokという名前はドメインと呼ばれる。各
ドメインはより下位のドメインを含む（例えば、jpドメインは
acドメインを含む）。しかしながら、ドメインのサーバは下位の
全てのドメインのデータを持つわけではなく、下位のドメインの情報を
掌握するサーバのデータのみを持ち、そのドメイン内部のデータは
そのサーバが持つ。このように、ドメインは下位のドメインの情報を
最小化して持つので、ドメインという言葉に対して、実際にドメインの
サーバが管理する情報範囲をゾーンと呼ぶ。従って、各ドメインの
管理者が管理すべき情報はゾーンについての情報であることになるが、
少なくとも下位のサーバについての情報は含まれなければならない。
このことから、DNSサーバは任意に立ち上げても意味を持たず、
上部のゾーンへの登録が必要であることが分かる（勿論、勝手に立ち上げ
ても良いことを意味しない）。
DNSにおける名前（FQDN)は先に述べたように、厳密にはルートからの
順位を表す.を末尾に持つ。これはディレクトリ構造の
絶対パスに相当する。一方、我々は通常こうした絶対パスを使用せず、
summer.wakhok.ac.jpやsummer
のように末尾のルートドメインや自ドメイン名を省略して
利用しているが、これは一つにはデフォルトドメインが適用されて解釈
されていることと、DNS自身にある程度のドメイン名に対する補完機能が
あることに由来する。しかし、通常こうした利用では問題がなくとも、
複雑なドメイン構造を持たせた場合などには、こうした補完機能があだと
なり、DNSが混乱を来す場合があることを覚えておくことは重要である。
また、DNSサーバでホスト情報を記述する際には、この厳密なFQDNでの
指定が必要であることもこれに関連している。
DNSにおいて、ホスト情報を保持し、リクエストに対して情報を提供する
ものをDNSサーバ、あるいはネームサーバと呼んでいるが、
リクエストを出す側は一般にリゾルバと呼ばれ、通常ライブラリとして実装
されている。リゾルバは単にネームサーバに対して名前の解決のリクエスト
を出すだけで、基本的にはネームサーバが必要であれば上位の
サーバへのリクエストを出す。当然、外部への名前解決の第一歩は
初期においてはルートネームサーバ（.を管理するサーバ、
言わば世界の最初のサーバ）へのリクエストとなる。このために、ルート
ネームサーバは膨大なトランザクションを処理しなければならないので、
現在では多くのルートサーバが世界中で稼働している。同時に、こうした
名前解決が常にルートサーバに集中しないために、ネームサーバには
キャッシュと呼ばれる以前の名前解決の記憶を持つようになっている。
これはルートネームサーバを始めとする上位のサーバの負荷を下げる
ための賢い方法であるが、同時にこのことによってDNS情報がある時点で
変更された場合、それが直には反映されないことになることも注意して
おかなければならない。
通常、DNSにおいては名前からIPアドレスへの変換が主となるが、逆に
IPアドレスから名前への変換も提供されている。前者を表引きと呼び、
後者を逆引きと呼ぶこともある。IPアドレスをDNSのメカニズムで検索する
ためには、FQDNと同じ名前空間を考えれば良い。FQDNでは上位の
ものは右にあることを思い出せば、IPアドレスもより上位の区分を右に
配置すればDNSの検索アルゴリズムに適合することが分かる。例えば、
192.168.0 はDNS的には 0.168.192であることになる。
勿論、これだけではFQDNとの区別がつかないので、末尾に（上部に）
.in-addr.arpaを付け加えてホスト名と区別する。つまり、
0.168.192.in-addr.arpaがDNS的な192.168.0のゾーン
の名前になる訳である。
