Domain Name System

名前解決 (name resolution)

ドメイン名

• すべての通信は IP アドレスに基づく
  
• 覚えにくい
  

名前解決(name resolution) とは、名前から IP アドレスを得ること

エンドユーザーから見た DNS サーバーの役割

• DNS (Domain Name System)
  
• DNS server: 名前の問い合わせ(query) に答えてくれる
  
• DNS client: DNS server に対して問い合わせを行うお客さん(client) # バソコンなど
  

DNS サーバーはどのようにして名前を解決しているか?

2種類の問い合わせと2種類の DNS サーバー

DNS サーバーに問い合わせるメッセージには2種類ある^注1。
(a) recursive query (再帰的問い合わせ)
(b) non-recursive query (非再帰的問い合わせ)

DNS サーバーの種類は基本的に2つである^注2。
(A) recursive name server (caching name server, non-authoritative name server)
(B) authoritative(権威) name server (non-recursive name server)

実際には次の組み合わせで使われる

recursive query → recursive name server
non-recursive query → authoritative name server

エンドユーザからは DNS サーバーのように見えるものとして
(C) DNS proxy server (DNS forwarder)

これはクライアントからのリクエストを単に他の recursive name server に回して答えを得る。
HGW(home gate way)による DNS サービスが該当する。

Recursive name server

再帰的問い合わせに答える。
DNS サーバーは、問い合わせられた名前に対して、(必要なら他の DNS サーバーにも自ら問い合わせて)可能な限り問い合わせに答える。それでも答えが得られない場合にはエラーを返す。
LAN 内部など限られたユーザーに対してサービスを行う^注3。

Authoritative name server

非再帰的問い合わせに答える。
DNS サーバーは、問い合わせられた名前に対して、自分の管理区域に存在する名前についてのみ答える。その名前が管理区域に存在しない場合には、他の DNS サーバーを紹介するかエラーを返す。
インターネットからの不特定ユーザーに対してサービスを行う。

DNS サーバーによる名前解決の実行例

図2のケースでは実際には図3のように他サーバーの支援を受けながらサービスを行う。

図2の "DNS server" は、図3では "Recursive name server" となっている。"recursive query" を受け付ける DNS サーバー(recursive name server)は、名前を解決し、その結果を(後の同じリクエストに対して高速に効率良く応答するために)メモリーに保存する。そのために "Caching name server" とも呼ばれる^注1。

図3の問い合わせのプロセスをもっと詳しく書くと次のようになる。

1. DNS client は recursive name server に対して ar.aichi-u.ac.jp の名前解決を依頼する。(recursive query)
   
2. recursive name server は root server に対して ar.aichi-u.ac.jp の名前解決を問い合わせる。(non-recursive query)
   
3. root server は他の適切な name server を紹介する (このケースでは a.dns.jp)
   
4. recursive name server は a.dns.jp に対して ar.aichi-u.ac.jp の名前解決を問い合わせる。(non-recursive query)
   
5. a.dns.jp は他の適切な name server を紹介する (このケースでは dns-b.iij.jp)
   
6. recursive name server は dns-b.iij.jp に対して ar.aichi-u.ac.jp の名前解決を問い合わせる。(non-recursive query)
   
7. dns-b.iij.jp は 202.250.160.40 であると答える
   
8. recursive name server は DNS client に 202.250.160.40 であると答える
   

ここに述べた問い合わせのプロセスは dig コマンドの結果である。その内容は、参考のために Appendix に示してある。

誤解を招く解説

ネットを検索してみると、iterative query と non-recursive query を同一視している解説が多い。名前解決のために問い合わせを繰り返す方法と、その中で行われる個々の問い合わせの種類を混同しているのである。この混同の源泉は次の Microsoft のページではないかと思われる。

• Recursive and Iterative Queries
  https://technet.microsoft.com/en-us/library/cc961401.aspx
  

iterative query = non-recursive query

It then uses an iterative (that is, a nonrecursive) query to the "com" DNS server to obtain a referral to the "microsoft.com" server.

• How DNS query works
  https://technet.microsoft.com/en-us/library/cc775637(v=ws.10).aspx
  

rfc1035 によれば、"iterative query" は問い合わせの種類としては存在しないのであり、これと rfc1035 に基づく "non-recursive query" を同一視はできない。
なお、"iterative query" は rfc1034 にも現れるが、問い合わせを繰り返すクライアントの振る舞いを指している。誤解を避けるためには、"iterative lookup" の方が良いと思える。この時に、クライアントは個々の DNS サーバーに対して "non-recursive query" を行う。

概念の混乱

筆者と似た問題意識を共有しているらしい記事。
さすがに、この分野のプロ集団(JPRS)の解説は注意深い

• 森下泰宏: 30分で学ぶDNSの基礎の基礎 ～DNSをこれから勉強する人のために～
  http://2014.seccon.jp/dns/dns_basics_in_30minutes.pdf
  
• 水野 貴史: 初心者のためのDNS運用入門 - トラブルとその解決のポイント -
  http://dnsops.jp/event/20130719/20130719-dns-beginners-guide-mizuno-2.pdf
  

Domain Name System

DNS(Domain Name System) は domain name から IP アドレスを得るための分散データベースシステムの名称である。
そのコンセプトは rfc1034 で、仕様は rfc1035 で説明されている。これらは古い RFC であるが、現在に至るも生き続けている。

ドメイン名

ar.aichi-u.ac.jp は、日本の(jp)、学術組織の(ac)、愛知大学(aichi-u)の中にある ar と名付けられたマシン。

ドメイン名はラベルと呼ばれる文字列をドット(".")で結んだ文字列である。
ラベルは、英字(大文字と小文字)、数字、ハイフン("-")で構成される。大文字と小文字は区別しない。また、ラベルは英数字で始まり^注1、英数字で終わる。各ラベルの文字数は最小1文字、最大63文字である^注2。(rfc1035)

ドメイン名空間

ドメイン名空間(domain namespace)

ドメイン名は図に示すように組織化されている。この図は木の枝分かれと似ているのでドメイン名の木(domain name tree)とも呼ばれる。頂点は木の根に相当するので、root と呼ばれる。

長方形または角丸長方形で囲まれている文字列はラベル、このうち角丸長方形で囲まれているのはホスト名である。
root のラベルは空文字列(長さ0の文字列)とみなす。

長方形で囲まれている箇所を(狭義の)ノードという。root から辿ったノードの深さ(途中のノードの個数)をドメインのレベルという。

recursive name server は名前解決のために、ドメイン名の木を root から辿る。
例えば ar.aichi-u.ac.jp の名前解決を要請された時には jp → ac → aichi-u の順で辿るのである。

ノード

ノード(node)

狭い意味では図6 の長方形で囲まれている箇所、広い意味では角丸長方形で囲まれている箇所(ホスト)を含む。

The domain name space is a tree structure. Each node and leaf on the tree corresponds to a resource set (which may be empty). The domain system makes no distinctions between the uses of the interior nodes and leaves, and this memo uses the term "node" to refer to both.

rfc1034

各々の(広義の)ノードはラベルを持つ。

RFC では特に断らない限り広義のノードを指しているようだ。

狭義のノードを表す用語は何か?
interior node → rfc1035, rfc6020
internal node
inner node
non-leaf node

他に "node" を含む用例:
root node → rfc1034
leaf node → rfc2065
the apex nodes of a subzone → rfc2065
the top node of the zone → rfc1034

他に
the top of the domain → rfc1034

グラフ理論だけで議論すると紛れる^注1
UFS(unix file system)の言葉で言えば、ファイルと空のディレクトリとの区別が付かないことになる

絶対ドメイン名

絶対ドメイン名(absolute domain name)
しばしば FQDN(fully-qualified domain name) と呼ばれる。他に "complete domain name" とも呼ばれる。

或るノードの絶対ドメイン名とは、そこから root の方向に辿ったラベルをドット(".") で繋げた文字列である。その際、root は空ラベル(長さ 0 のラベル)を持つとみなす。
例えば

jp.
ac.jp.
aichi-u.ac.jp.
ar.aichi-u.ac.jp.

DNS サーバーへの問い合わせには絶対ドメイン名に相当するバイナリデータが使われている。

ネットワークアプリケーションが要求するドメイン名は root node からの相対ドメイン名であることが多い。つまり末尾に "." を付けない^注1。これもまた FQDN であると言われることがある。

ルートノードのテキスト表現として長さ0の文字列(空ラベル)が使われることもあれば^注2、unix のファイルシステムのアナロジーから "." が使われることもある^注3。

unix のファイルシステム(UFS)との類似性

DNS		→	UFS
non-leaf node	→	directory
host		→	file
"."		→	"/"
絶対ドメイン名	→	絶対パス
相対ドメイン名	→	相対パス

DNS データベースの設定において、ドメイン名をどのように表現するかは、使用しているソフトウェアに依存する。 Plan9 のネットワークデータベースが要求するドメイン名は、どれも root からの相対ドメイン名である。他方 BIND では絶対ドメイン名も相対ドメイン名も使用される。

相対ドメイン名

相対ドメイン名(relative domain name) or PQDN(partially-qualified domain name)

domain namespace の或るノード(起点ノード)から見た相対的な位置を表す。
例えば "jp." を起点ノードとすると "aichi-u.ac.jp." の相対ドメイン名は "aichi-u.ac" である。
相対ドメイン名の末尾には "." を付けない^注1。

相対ドメイン名は(曖昧性が発生するので)DNS の問い合わせには使われない。

ドメイン

ドメインを以下のように定義する^注1。

ドメイン名空間のノードの1つをAとする。ノードAに対応するドメインAとは、ノードAおよびノードAの下方(root node の反対側)にあるノードの集合である。ノードAのドメイン名をもってドメインAのドメイン名とする。

例えば図6において、ノードAのドメイン名を "ac.jp." とする。この場合、ドメインAには以下のノードが含まれる。

ac.jp.	aichi-u.ac.jp.	www.aichi-u.ac.jp.	ar.aichi-u.ac.jp.	u-tokyo.ac.jp.

"root domain" という言い方は避けたほうが良い。なぜなら、名前空間の全体を指すと理解されるから。そうでないなら "root node" と言うべきであろう。

サブドメイン

ドメインAがドメインBのサブドメインであるとは、A が B に(真部分集合として)含まれること

A ⊊ B

子ドメイン

親ドメイン(parent domain)、子ドメイン(child domain)

ドメインAがドメインBの子ドメインであるとは、A は B のサブドメインであり、かつドメインのレベルが1つだけ大きいこと。
このとき B は A の親ドメインであると言う。

ドメイン名と IP アドレス

vega.aichi-u.ac.jp も aichi-u.ac.jp も IP アドレス 202.16.124.3 を持つ。
vega はホスト名。aichi-u.ac.jp は愛知大学のドメイン名であるが、それ自体ホストではない。愛知大学のドメイン名が vega と同じ IP アドレスを持つことによって arisawa@vega.aichi-u.ac.jp の代わりに arisawa@aichi-u.ac.jp と書くことができる。

ドメイン名管理の階層構造

管理の委任(delegation)による。ar.aichi-u.ac.jp を例に採ると

• IANA(The Internet Assigned Numbers Authority): 管理の元締め。ICANN から管理の委任を受けている。世界的な組織
  
• JPRS(Japan Registry Servce): IANA から jp domain の管理を任せられている。
  
• NII(National Institute of Informatics = 国立情報学研究所): JPRS から ac.jp domain の管理を任せられている。
  
• 愛知大学: NII から aichi-u.ac.jp の管理を任せられている。
  

そして ar は筆者のサーバーであり、愛知大学から管理を任せられている。

管理の委任の最も重要な内容は、domain name と IP address
ドメイン名の重複は許されないので、世界的な組織(および管理を委任された機関)によって厳重に管理されている。

Domain と Zone

管理区域(zone)
1 つの zone には複数の name server を置きサービスを安定させる。 (primary and secondary)^注1

DNS domain とは domain name で表されている領域
DNS zone とは domain name で表されている管理領域 (管理の視点から領域が分割されている)
zone は name server で管理される。この name server は必ずしも管理の対象となっている zone 内に置く必要はない^注2。

組織領域があって domain name があるとする立場

A domain name is an identification string that defines a realm of administrative autonomy, authority or control within the Internet.

Wikipedia "domain name"

domain と zone の関係を示す良い図がネット上にあったので紹介する。

• 佐藤新太: ゾーンとは
  http://www.atmarkit.co.jp/fnetwork/dnstips/008.html
  

管理データの内容

• name server RRs: zone のサーバーの一覧 (サーバー毎に1つの RR)
  
• SOA RR: (すべてのサーバーに対して共通の) zone management parameters
  

rfc1034 の説明

The authoritative data for a zone is simply all of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom edge of the zone.

Though logically part of the authoritative data, the RRs that describe the top node of the zone are especially important to the zone's management. These RRs are of two types: name server RRs that list, one per RR, all of the servers for the zone, and a single SOA RR that describes zone management parameters.

rfc1034

Root Zone

IANA が管理している。

root zone は root server で管理されている。root server は "jp" や "com" など、次のレベルのドメイン(top level domain)の名前とアドレスを管理している。
インターネットを支える root server の重要性により、現在は世界中に 13 のルートサーバーが存在し、同一のサービスを行っている。
ルートサーバーの IP アドレスの一覧が手に入れば、原理的には、世界中の全てのサーバーの IP アドレスがわかる。
ルートサーバーの IP アドレスは変化することがあるので、recursive name server の管理者は、BIND など DNS サーバーソフトウェアに添付されているルートサーバーの一覧を更新する必要がある。

ルートサーバーの一覧は IANA から手に入る。

• Root Servers
  https://www.iana.org/domains/root/servers
  

Top Level Domain

TLD の一覧も IANA から手に入る。

• Root Zone Database
  http://www.iana.org/domains/root/db
  

Whois Database

Web のブラウザからは

• http://whois.jprs.jp (JPRS の管理分のみ)
  
• http://whois.icann.org/en
  

unix 系の OS であれば、whois コマンドがある。
実行例

-bash$ whois aichi-u.ac.jp
[ JPRS database provides information on network administration. Its use is    ]
[ restricted to network administration purposes. For further information,     ]
[ use 'whois -h whois.jprs.jp help'. To suppress Japanese output, add'/e'     ]
[ at the end of command, e.g. 'whois -h whois.jprs.jp xxx/e'.                 ]

Domain Information: [ドメイン情報]
a. [ドメイン名]                 AICHI-U.AC.JP
e. [そしきめい]                 あいちだいがく
f. [組織名]                     愛知大学
g. [Organization]               Aichi University
k. [組織種別]                   大学
l. [Organization Type]          University
m. [登録担当者]                 YM26826JP
n. [技術連絡担当者]             FM2826JP
n. [技術連絡担当者]             GS3718JP
p. [ネームサーバ]               dns-b.iij.ad.jp
p. [ネームサーバ]               dns-c.iij.ad.jp
s. [署名鍵]
[状態]                          Connected (2016/07/31)
[登録年月日]                    1993/07/23
[接続年月日]                    1994/01/13
[最終更新]                      2015/08/01 01:05:15 (JST)

-bash$

Appendix

ネームサーバーの動作のトレース

ここでは dig によるネームサーバーの動作をトレースしてみる。
途中経過に関心がないなら

dig ar.aichi-u.ac.jp

-bash$ dig +norec ar.aichi-u.ac.jp @a.root-servers.net

; <<>> DiG 9.8.3-P1 <<>> +norec ar.aichi-u.ac.jp @a.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7875
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 13

;; QUESTION SECTION:
;ar.aichi-u.ac.jp.		IN	A

;; AUTHORITY SECTION:
jp.			172800	IN	NS	g.dns.jp.
jp.			172800	IN	NS	f.dns.jp.
jp.			172800	IN	NS	e.dns.jp.
jp.			172800	IN	NS	d.dns.jp.
jp.			172800	IN	NS	c.dns.jp.
jp.			172800	IN	NS	b.dns.jp.
jp.			172800	IN	NS	a.dns.jp.

;; ADDITIONAL SECTION:
g.dns.jp.		172800	IN	A	203.119.40.1
f.dns.jp.		172800	IN	A	150.100.6.8
f.dns.jp.		172800	IN	AAAA	2001:2f8:0:100::153
e.dns.jp.		172800	IN	A	192.50.43.53
e.dns.jp.		172800	IN	AAAA	2001:200:c000::35
d.dns.jp.		172800	IN	A	210.138.175.244
d.dns.jp.		172800	IN	AAAA	2001:240::53
c.dns.jp.		172800	IN	A	156.154.100.5
c.dns.jp.		172800	IN	AAAA	2001:502:ad09::5
b.dns.jp.		172800	IN	A	202.12.30.131
b.dns.jp.		172800	IN	AAAA	2001:dc2::1
a.dns.jp.		172800	IN	A	203.119.1.1
a.dns.jp.		172800	IN	AAAA	2001:dc4::1

;; Query time: 80 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Wed Oct 28 21:05:38 2015
;; MSG SIZE  rcvd: 430

-bash$ dig +norec ar.aichi-u.ac.jp @a.dns.jp

; <<>> DiG 9.8.3-P1 <<>> +norec ar.aichi-u.ac.jp @a.dns.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14577
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;ar.aichi-u.ac.jp.		IN	A

;; AUTHORITY SECTION:
aichi-u.ac.jp.		86400	IN	NS	dns-b.iij.ad.jp.
aichi-u.ac.jp.		86400	IN	NS	dns-c.iij.ad.jp.

;; Query time: 13 msec
;; SERVER: 2001:dc4::1#53(2001:dc4::1)
;; WHEN: Wed Oct 28 21:06:35 2015
;; MSG SIZE  rcvd: 81

-bash$ dig +norec ar.aichi-u.ac.jp @dns-b.iij.ad.jp

; <<>> DiG 9.8.3-P1 <<>> +norec ar.aichi-u.ac.jp @dns-b.iij.ad.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55211
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;ar.aichi-u.ac.jp.		IN	A

;; ANSWER SECTION:
ar.aichi-u.ac.jp.	28800	IN	A	202.250.160.40

;; AUTHORITY SECTION:
aichi-u.ac.jp.		28800	IN	NS	dns-b.iij.ad.jp.
aichi-u.ac.jp.		28800	IN	NS	dns-c.iij.ad.jp.

;; Query time: 15 msec
;; SERVER: 2001:240:bb81::2:14#53(2001:240:bb81::2:14)
;; WHEN: Wed Oct 28 21:07:11 2015
;; MSG SIZE  rcvd: 97

-bash$

dig の +norec の指示は、recursion をしないことを意味する。これは authoritative name server にリクエストする場合に指定する。+norec の指示がない場合には dig は recursive answer を要求するが、authoritative name server は recursion を拒否し、non-recursive な要求と解釈して回答する。

問い合わせの回答での flags:

• qr (query(0) or response(1))
  
• aa (authoritative answer)
  
• rd (recursion desired)
  
• ra (recursion available)
  
• tc (truncated)
  

疑問: a.dns.jp は何故 ADDITIONAL SECTION で dns-b.iij.ad.jp. と dns-c.iij.ad.jp. の IP アドレスを知らせなかったのだろう?

recursive name server による iterative lookup (図3) が可能であるには、lookup の各々のステップで次に問い合わせを行う name server の IP アドレスが必要である。この name server が問い合わせの対象となる domain の内部にあれば、その IP アドレスも知らせないと lookup が行き詰まる。つまり ADDITIONAL SECTION が必要である。

外部にあればどうか? この例の

aichi-u.ac.jp.		86400	IN	NS	dns-b.iij.ad.jp.

次の記事が面白い

• 森下泰宏: 教科書には載っていないDNS — キャッシュDNSサーバーの憂鬱
  http://dnsops.jp/event/20130719/20130719-undocumented-DNS-orange-3.pdf
  

DHCP からの情報を見る

OSX の場合には次の方法で DHCP から得られる情報を調べることができる。

-bash$ ipconfig getpacket en0
op = BOOTREPLY
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 3811290754
secs = 0
ciaddr = 0.0.0.0
yiaddr = 192.168.0.249
siaddr = 192.168.0.6
giaddr = 0.0.0.0
chaddr = 20:c9:d0:8b:2:b5
sname = hebe
file =
options:
Options count is 8
dhcp_message_type (uint8): ACK 0x5
lease_time (uint32): 0xe10
server_identifier (ip): 192.168.0.6
subnet_mask (ip): 255.255.255.0
router (ip_mult): {192.168.0.1}
domain_name_server (ip_mult): {192.168.0.6}
nb_over_tcpip_node_type (uint8): 0x2
end (none):
-bash$

筆者は、Plan9 のネットワークデータベースで指定した dnsdomain が DHCP に反映されているか否かを調べるために、ここで述べたコマンドを実行した。結論として、反映されていないようだ。

探索ドメイン

DHCP からの探索ドメインリスト

DHCP を通じて探索ドメインのリストをクライアントに渡すことができる。(rfc3397)
Plan9 の DHCP サーバーは渡さないので、渡すように書き変えようかと思ったが、手が止まった。
本当に良いことなのか?

DHCP の設定とクライアントマシンの設定が異なった場合、どうなるのか?
rfc3397 には、クライアントマシンの設定が DHCP によって上書きされてはならないと書かれている。それでも混ぜ合わせ方が問題で評価の順序もあろう。そうした複雑さが災いをもたらすことは十分に考えられる。

探索ドメインの追加方式: OSX 方式

• OS X Lion: About search domains and name lookups
  https://support.apple.com/en-ap/HT200303
  

探索ドメインの追加方式: RFC1535 方式

• A Security Problem and Proposed Correction With Widely Deployed DNS Software
  https://www.ietf.org/rfc/rfc1535.txt
  

OSX の探索ドメインの設定と現在値

OSX では探索ドメインの設定は

システム環境設定 → ネットワーク環境 → 詳細 → DNS → 探索ドメイン

他方、探索ドメインの現在の値を見る方法は3通りある。

1. システム環境設定から辿った探索ドメインの値
   
2. /etc/resolv.conf の内容
   
3. networksetup コマンド
   

-bash$ cat /etc/resolv.conf
search local aichi-u.ac.jp
nameserver 192.168.0.6
nameserver 2402:6b00:22cd:bf80:1266:82ff:fe0c:ed18
-bash$

resolv.conf には次のコメントが付いている。

#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#

unix では伝統的に resolv.conf を通じて name server と search domain を設定してきたが、OSX では unix に慣れている管理者を相手に、単に見るだけの窓口として resolv.conf が存在する。

OSX では networksetup コマンドが存在する。使用例は

-bash$ networksetup -getsearchdomains Wi-Fi
local
aichi-u.ac.jp
-bash$

マニュアルには

networksetup -getsearchdomains networkservice

なお、networksetup コマンドでも探索ドメインを設定できる。その場合

networksetup -setsearchdomains Wi-Fi local aichi-u.ac.jp