Logo address

Domain Name System

名前解決 (name resolution)

ドメイン名

IP アドレスはインターネット通信の基本である。
わかりやすい名前が欲しい ⇒ domain name が考え出された
しかし、依然として IP アドレスはインターネット通信の基本である。

図1: 名前解決

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

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

エンドユーザー環境からは名前解決のために DNS サーバーの支援を受ける。

図2: DNS サーバーへの問い合わせ

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 サービスが該当する。


注1: リクエストメッセージの中に RD(recursion desired) bit が存在する。この有無で分類する。(rfc1035)
注2: サーバーの役割に基づく分類である。括弧内に他の言い方を示す。複数の言い方がされるのは、実行される仕事の何に注目しているかが文脈で異なるからである。DNS における name server であることを明確にするために "DNS server" と書く場合も多い。DNS を論じている場面で単に "name server" と言えば DNS の NS 属性の値(これは "authoritative name server" に限定される)を指す事が多いので注意が必要である。

Recursive name server

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


注3: recursive name server をインターネットに公開すると、キャシュ汚染のリスクを負う。
IP アドレス 8.8.8.88.8.4.4 で公開されている Google の Public DNS server は recursive name server であり、Google は、これを汚染から守るための努力と研究をしている。次の URL に詳しい。

Authoritative name server

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

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

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

図3: DNS サーバーによる名前解決

図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 に示してある。


注1: 名前を解決するソフトウェアを resolver と言う。従って recursive server は resolver の一種であるが、単に resolver と言うと stub-resolver を指す事が多い。stub-resolver は DNS client 側のライブラリの一種で、単にリクエストを recursive server に回すだけの役割を担っている。recursive server のように自分で名前を解決する resolver は full-service resolver と言う。(rfc1123)

誤解を招く解説

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

図4: Microsoft による解説

さらに同社の他のページでは
iterative query = non-recursive query
であるかの様に解説している注1

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


注1: Microsoft のページをみると ("non-recursive" ではなく) "nonrecursive" が使われている。ここでは "non-recursive" を使う。この方が一般的である。

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

概念の混乱

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

Domain Name System

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

ドメイン名

ドメイン名(domain name)

図5: ドメイン名の例

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

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

注1: rfc1035 ではラベルは英字で始まるとされたが、rfc1123 では英数字に緩和された。なお IPv4 アドレスとの区別は、最後のラベルを見る。ICANN は TLD(トップレベルドメイン) 名を管理しており、数字で始まる TLD 名を許可しない。
注2: 他に絶対ドメイン名の全長に対する制限(255B)やサーバに送るリクエストの全データ数から来る制約(512B)がある。

ドメイン名空間

ドメイン名空間(domain namespace)

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

図6: domain namespace

長方形または角丸長方形で囲まれている文字列はラベル、このうち角丸長方形で囲まれているのはホスト名である。
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)の言葉で言えば、ファイルと空のディレクトリとの区別が付かないことになる


注1: 何を議論しているかが問題である。実際の名前空間を問題にしているのか、それとも抽象化された名前空間を議論しているのか?

絶対ドメイン名

絶対ドメイン名(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.
が絶対ドメイン名である。
(広義の)ノードは絶対ドメイン名と1対1に対応する。

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

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

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


注1: 例えば URL の記述では http://ar.aichi-u.ac.jp が正しく、http://ar.aichi-u.ac.jp. はエラーになる。 他方では http://www.apple.com. はエラーにならない。この現象は name server の設定に依存していると思える。
注2: Plan9 のネットワークデータベース
注3: BIND など多数の unix 系のソフトウェア

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: 相対ドメイン名で起点ノードが明示的に指定されていない場合は、暗黙の起点ノードが存在すると考えられる。例えば暗黙の起点ノードが root node であるとか、/etc/resolv.conf や DHCP で指定されている探索ドメインリストの中のドメイン名であるとか。unix では BIND (のライブラリ)が resolver として使われていることが多い。その場合暗黙の探索ドメインリストが存在するので厄介である。探索ドメインリストが存在する場合に相対ドメイン名を使うと意図しない結果をもたらすことがある。(rfc1535)

ドメイン

ドメインを以下のように定義する注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.
つまり "ac.jp." ドメインには ".ac.jp." で終わるすべてのノードと "ac.jp." ノードが含まれることになる。

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

サブドメイン

サブドメイン(subdomain)

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

A ⊊ B

子ドメイン

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

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

ドメイン名と IP アドレス

vega.aichi-u.ac.jpaichi-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 と書くことができる。


注1: 他の言い回しもあるが、結果的には同じだと思う。

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

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

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

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


注: IP address の交付は他の組織、日本の場合には JPNIC が行っている。重複を防ぐ必要があり、階層的な管理の委任方式を採用している。

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 の関係を示す良い図がネット上にあったので紹介する。

図7: domain と zone


注1: or, master and slave
"primary and secondary" と言うと1つづつと誤解されるかもしれないが、大きなサイトでは多数の name server を動かしている。その意味では "master and slave" の方が適切かもしれない。
注2: 例えば aichi-u.ac.jp のネームサーバーは iij.ad.jp に置かれている。(図3を見よ)

管理データの内容

リソースレコード(RR)
zone 内の(広義の) node に関する RR
内容は2種

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 から手に入る。

Top Level Domain

TLD(Top level domain)
ccTLD (country-code TLD) 2文字
gTLD (generic TLD) 3文字以上

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

Whois Database

管理を委任された責任者は Whois Database で分かる。

Web のブラウザからは

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:

詳しくは rfc1035

疑問: 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-b.iij.ad.jp. の IP アドレスを知らせてもらえなくても iterative lookup が成功したのは、dns-b.iij.ad.jp. の IP アドレスは root から再び iterative lookup を繰り返して得られるからである。(読者は実際に試してみよ)

次の記事が面白い

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 方式

ドメイン名が2つ以上のラベル含む場合には探索ドメインを追加しない。(Plan9 も同じ立場を採っている)
この方式は OSX Lion 以降の修正で採用

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

ドメイン名が2つ以上のラベル含む場合にも探索ドメインを追加するが、探索の範囲をローカルドメインに限定すべし。また探索ドメインを追加するまえに、root 相対ドメイン名である可能性を確認すべし。

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
となっている。ここで networkservice として「Wi-Fi」が指定されたのは、「ネットワーク環境」の「Wi-Fi」における探索ドメインを調べたいからである。

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

networksetup -setsearchdomains Wi-Fi local aichi-u.ac.jp
のように行う。