この “ブログ” では，情報通信技術を中心とする各種のみじかい調査結果や解説をとりあげます．
この “ブログ” の目的については 「DNS (Domain Name System, ドメイン名システム) はインターネットにおけるコンピュータのホスト名やドメイン名と IP アドレス等とのマッピングを管理するシステムである． ホスト名やドメイン名だけでなく，Web サーバ，SIP サーバや他のさまざまな資源の検索のためにも使用することができる．
IETF (http://www.ietf.org/) において 1983 年 11 月に RFC 882 (P. Mockapetris: DOMAIN NAMES–CONCEPTS and FACILITIES) によって最初に発行され，1987 年 11 月に RFC 1034 (P. Mockapetris 著: Domain Names – Concepts and Facilities) および RFC 1035 (P. Mockapetris 著: Domain Names – Implementation and Specification) において標準 (Standard) となった．この節の記述はおもに RFC 1034 に基づいている．
1. DNS の要素
DNS は次の 4 個の主要な要素からなっている．
- (1) ドメイン名空間 (Domain Name Space)
- ドメイン名空間は木構造の空間であり，葉をふくむ木のそれぞれのノードにラベルがつけられている．ルート・ノードには空のラベルがつけられている．各ノードがドメイン名に対応しているが，完全なドメイン名 (Fully-Qualified Domain Name, FQDN) は当該ノードからルートのすぐ下位のノードまでのラベルを "." をはさんでならべたものである．ドメイン名空間の例を前記の RFC 1035 から引用する (図 1)．ここで最下位のノード XX に対応するドメイン名は XX.LCS.MIT.EDU である．
- (2) 資源レコード (Resource Record, RR)
-
特定のドメイン名に属する資源を記述したものを資源レコード RR (resource record) という．1 個のドメイン名に対して資源レコードは 0 個以上の任意個存在しうる．資源の型としてはホスト・アドレス (A と略称)，メール交換 (mail exchange，MX と略称)，名前スペース・ポインタ (他の名前スペースへのポインタ，PTR と略称) などがある．資源レコードはこの型のほか，資源のクラス，TTL (time to live)，RDATA (クラス依存のデータ) をふくんでいる．RR の例を前記の RFC 1034 から引用する．
ISI.EDU. MX 10 VENERA.ISI.EDU. MX 10 VAXA.ISI.EDU. VENERA.ISI.EDU. A 128.9.0.32 A 10.1.0.52 VAXA.ISI.EDU. A 10.2.0.27 A 128.9.0.33 | | +---------------------+------------------+ | | | MIL EDU ARPA | | | | | | +-----+-----+ | +------+-----+-----+ | | | | | | | BRL NOSC DARPA | IN-ADDR SRI-NIC ACC | +--------+------------------+---------------+--------+ | | | | | UCI MIT | UDEL YALE | ISI | | +---+---+ | | | | LCS ACHILLES +--+-----+-----+--------+ | | | | | | XX A C VAXA VENERA Mockapetris図 1 ドメイン名空間の例 - (3) 名前サーバ (Name Servers)
- 上記の木構造に関する情報を保持するサーバである．通常，名前サーバが直接保持しているのは部分木だけであり，それ以外は他のサーバへのポインタをもっている．クライアントは名前サーバに対しては UDP または TCP による質問をおくることでドメイン名に関連づけられた情報を求めることができる．この質問の仕様に関しては 2 節において述べる．また，名前サーバのアーキテクチャについては 3 節において述べる．
- (4) 解決器 (Resolver)
- 名前サーバから情報をとりだして，クライアントからの質問にこたえるプログラムである．
2. 名前サーバへの質問
前記の RFC 1034 によると，前記のように，クライアントは名前サーバに対しては UDP または TCP による質問をおくることでドメイン名に関連づけられた情報を求めることができる．この質問に対して名前サーバはその答え，他の名前サーバへのリダイレクション，またはエラーを返す．質問の形式としてはつぎのものがある．
- (1) 標準質問
-
ドメイン名，型，クラスを指定して，それにマッチする RR を求める．たとえば型が A であれば，指定したドメイン名のもとにあるホストの RR (アドレスをふくむ) が返される．型が A でなくてもドメイン名とアドレスとを結びつけている RR が付加情報として返されることもある．
標準質問とそれに対する答えの例を前記の RFC 1034 から引用する (図 2)．
質問: QNAME=SRI-NIC.ARPA, QTYPE=A +---------------------------------------------------+ Header | OPCODE=SQUERY | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Answer | <empty> | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ 答え: +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | | 86400 IN A 10.0.0.51 | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+図 2 標準質問とそれに対する答えの例 - (2) 逆質問 (オプショナル)
- 資源を指定してドメイン名 (複数のこともある) を求める．
3. 名前サーバのアーキテクチャ
前記の RFC 1034 によると，名前サーバがもつデータベースは zone とよばれる部分に分割することができる．Zone ごとにことなる名前サーバによって管理することができる．データベースはクラスごとに分けることもできるし，木構造を分割することもできる．木構造を分割するときは，名前サーバの構成も木構造になる．上位の名前サーバが答えられない質問は下位の名前サーバによって答えられる．Zone の分割によって新たに必要になる “つなぎ” の情報も RR の形式で格納される．前記のドメイン名空間の名前サーバのわりあての例を前記の RFC 1034 から引用する (図 3)．
|(C.ISI.EDU，SRI-NIC.ARPA
| A.ISI.EDU)
+---------------------+------------------+
| | |
MIL EDU ARPA
|(SRI-NIC.ARPA, |(SRI-NIC.ARPA, |
| A.ISI.EDU | C.ISI.EDU) |
+-----+-----+ | +------+-----+-----+
| | | | | | |
BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
|
+--------+------------------+---------------+--------+
| | | | |
UCI MIT | UDEL YALE
|(XX.LCS.MIT.EDU, ISI
|ACHILLES.MIT.EDU) |(VAXA.ISI.EDU，VENERA.ISI.EDU，
+---+---+ | A.ISI.EDU)
| | |
LCS ACHILLES +--+-----+-----+--------+
| | | | | |
XX A C VAXA VENERA Mockapetris
図 3 標準質問とそれに対する答えの例
ここで括弧内に示されているのが名前サーバであり，木のそれ以下の部分が zone である．
4. 解決器
前記の RFC 1034 によると，解決器は名前サーバとユーザ・プログラムとをインタフェースするプログラムである．単純な場合には，解決器はユーザ・プログラムから要求をうけとって，名前サーバからえられる情報をユーザ・プログラムが受け取れる形式に変換して返す．解決器はユーザ・プログラムと同一のマシン上に存在する．ネットワーク遅延や名前サーバの負荷を考慮して応答時間を短縮するのは解決器の役割である．
5. DNS を使用したメールのルーティング
DNS を使用したメールにおける通信相手の発見およびルーティングに関しては 1986 年 1 月に発行された IETF の標準 RFC 974 (STD 14) (C. Partridge: Mail routing and the domain system) に記述されている (ただし，この RFC は SMTP (別項参照) の RFC である RFC 2821 によっておきかえられている)．このメール・ルーティングの機能は DNS に当初から組み込まれていた．
6. DNS を使用した Well Known Service の検索
DNS においては，FTP, SMTP, HTTP などのいわゆる well-known services を検索する機能がサポートされている．すなわち，前記の RFC 1035 においては WKS (Well Known Services) RR が定義されている．WKS RR には次の 3 個の要素がふくまれる: IPv4 アドレス，プロトコル，ビットマップ．IPv4 アドレスはサーバのアドレスをあらわし，プロトコルは TCP, UDP などの IP プロトコルをあらわす．ビットマップの各ビットはそのプロトコルを使用する well-known service に対応し，そのサーバがそのサービスを提供しているかどうかがあらわされる．たとえば 26 番めのビットが ON であれば，ポート 25 のサービスすなわち SMTP が提供されていることをあらわす．
しかしながら，WKS RR はあまりひろく使用されていない (RFC 2219)．また，WKS RR によって指定できるサービスは well-know services に限られている．従って，1989 年 10 月に発行された IETF 標準 RFC 1123 (STD 3) (R. Braden: Requirements for Internet hosts -- application and support) においては WKS RR のかわりに MX RR を使用するのがよいとされているが，さらに 1997 年 10 月に発行された RFC 2219 (BCP 17) (M. Hamilton, R. Wright: Use of DNS Aliases for Network Services) においては MX RR もあわせて将来は SRV RR によって置き換えられるべきだとしている．
7. DNS を使用したサーバの検索
DNS を利用してサービス (サーバ) を検索する方法に関しては，2000 年 2 月に発行された IETF の提案標準 (Proposed Standard) である RFC 2782 (A. Gulbrandsen, P. Vixie, L. Esibov: A DNS RR for specifying the location of services (DNS SRV)) に記述されている．このサービス検索機能は当初の DNS においては想定されていなかったが，WWW などにおいて必要とされて標準化されたものである．
この標準書においては SRV RR という，サービスを記述する新たな RR を導入することによって，DNS をサービス検索に使用することを可能にしている．たとえば，この方法を使用して LDAP サービスを検索できるようにすることができる． SRV RR はつぎのような形式をしている．
Service._Proto.Name TTL Class SRV Priority Weight Port Target
_Service._Proto.Name の部分において特定の場所における特定のサービスが指定される．_Service はサービスをあらわす名前であり，_Proto はプロトコルをあらわす名前であり，Name はこの RR が参照するべきドメイン名である．LDAP サービスの検索においては _Service._Proto.Name のところにたとえば _ldap._tcp.example.com を指定する．Priority と Weight は検索の順序等にかかわるパラメータであるが，ここでは説明を省略する．Port はそのサービスが使用するポート番号，Target はそのサービスが使用するドメイン名である．
このドメイン名はさらに A RR や CNAME RR など，他の RR を参照することによって IP アドレスと対応づけることができる．サービス (サーバ) はドメイン名 (またはそれに対応する IP アドレス) とポートの組によって同定される．従って，1 台のサーバで同一ポート番号で複数のサービスをおこなう場合には，そのサーバに対して複数のドメイン名および IP アドレスをわりあてる必要がある．このようなサービスは WWW などにおいてはしばしばおこなわれている．しかし，このようなサービスのオーバーローディングによって DNS に必要以上の負荷をかけることになる． RFC 2782 にはつぎのような例があげられている．
$ORIGIN example.com.
@ SOA server.example.com. root.example.com. (
1995032001 3600 3600 604800 86400 )
NS server.example.com.
NS ns1.ip-provider.net.
NS ns2.ip-provider.net.
; foobar - use old-slow-box or new-fast-box if either is
; available, make three quarters of the logins go to
; new-fast-box.
_foobar._tcp SRV 0 1 9 old-slow-box.example.com.
SRV 0 3 9 new-fast-box.example.com.
; if neither old-slow-box or new-fast-box is up, switch to
; using the sysdmin's box and the server
SRV 1 0 9 sysadmins-box.example.com.
SRV 1 0 9 server.example.com.
server A 172.30.79.10
old-slow-box A 172.30.79.11
sysadmins-box A 172.30.79.12
new-fast-box A 172.30.79.13
; NO other services are supported
*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .
ここでは example.com というドメインにおいて，_foobar というサービスが TCP を使用し，old-slow-box.example.com (IP アドレスは 172.30.79.11), new-fast-box.example.com (IP アドレスは 172.30.79.13), sysadmins-box.example.com (IP アドレスは 172.30.79.12), server.examples.com (172.30.79.10) という 4 つのサーバにおいてサービスされていることを表している．ポート番号はいずれも 9 である．
8. DNS を使用した資源の検索
DNS を使用してより柔軟に URI などの資源を検索するために，1997 年 5 月に発行された IETF 標準 RFC 2141 (R. Moats 著: URN Syntax) において NAPRT RR が導入され，2000 年 9 月に発行された IETF 標準 RFC 2915 (M. Mealling, R. Daniel: The Naming Authority Pointer (NAPTR) DNS Resource Record) において NAPTR が定義しなおされた．さらに，NAPTR は 2002 年 10 月に発行された IETF 標準 RFC 3403 (M. Mealling: Dynamic Deletation Delivery System (DDDS) Part Three: The Domain Name System (DNS) Database) において再定義された．
この NAPTR RR を使用することによって正規表現にもとづく書き換え規則を定義することができ，この書き換え規則によって既存の文字列をドメイン名や URI に書き換えることができる．この書き換えは再帰的に適用することができる．NAPTR を使用することによって，ドメイン名の構文にしたがう資源の検索にとどまらず，DNS を使用して URI をふくむ広範な資源名の検索が可能になる．
NAPTR RR はつぎのような形式をしている．
Domain TTL Class NAPTR Order Preference Flags Service Regexp Replacement
ここで Domain は検索のキーとなるドメイン名である．Order, Preference は検索の順序を決めるパラメータであり，Flags は書き換えを制御するフラグである．Service は書き換えの結果として利用できるサービスを指定する．Regexp と Replacement との組によって書き換え規則が規定される．すなわち，Regexp は書き換え前の文字列にマッチするパタンを正規表現によって記述したものであり，Replacement が書き換えの結果をあらわす． 前記の RFC 2915 にはつぎのような例があげられている．
http.uri.arpa. IN NAPTR
;; order pref flags service regexp replacement
100 90 "" "" "!http://([^/:]+)!\1!i" .
ここで正規表現 !http://([^/:]+)!\1!i は /http:\\/\\/([^\\/:]+)/\\1/i と等価である．この規則に www.foo.com を適用すると，次のような結果がえられる．
www.foo.com.
;; order pref flags service regexp replacement
IN NAPTR 100 100 "s" "http+I2R" "" _http._tcp.foo.com.
IN NAPTR 100 100 "s" "ftp+I2R" "" _ftp._tcp.foo.com.
_http._tcp.foo.com を指定して SRV RR を検索することによって，必要な結果がえられる．RFC 2915 には他にも例があげられているが，ここでは省略する．
