図 大学組織（ドメイン的な見方）
分散システム
電子・情報工学系
新城 靖
<yas@is.tsukuba.ac.jp>
このページは、次の URL にあります。
http://www.hlla.is.tsukuba.ac.jp/~yas/coins/dsys-1998/1999-02-02
/dns.html
あるいは、次のページから手繰っていくこともできます。
http://www.hlla.is.tsukuba.ac.jp/~yas/coins/
http://www.hlla.is.tsukuba.ac.jp/~yas/index-j.html
名前サービスを提供するプロセスは、 名前サーバ(name server) 。
名前から名前を指している番号に変換することを 名前解決(name resolution) という。
名前サーバのクライアントとして名前解決をする部分を リゾルバ(resolver) という。
インターネットで使われている名前サービスは、 DNS(Domain Name System) 。
DNS では、膨大な数のホスト名を含む名前空間を木構造で管理する。
==階層的にドメイン（領域）に分割して管理する。
図 大学組織（ドメイン的な見方）
図 大学組織（普通の木）
名前空間を分割し、一部の権限を委任する。 分割されたものをさらに分割する。
→木構造。
スケーラビリティを実現するには、木構造にするしかない、とも言える。
必要に応じて、そのドメインを、さらにいくつかのドメインに分割して、その うちのいくつかについて、他の名前サーバに名前の管理を委任する。
自分では任せた名前サーバへのポインタだけを持つ。
委任された名前サーバは、その分割されたドメイン(サブドメイン)についての 権限を持つ。
分割されたドメインは、さらに分割され、また別の名前サーバに権限が委任さ れることがある。
図 インターネットのホスト名の名前 付けで使われている木構造
is.tsukuba.ac.jp」では、木の根から見た時、
jp,ac,tsukuba,is のように枝を探していくことを意味して
いる。これは、UNIXのファイル名とは解釈の順番が逆である。
UNIXのファイル名では、「/jp/ac/tsukuba/is」となる。
根の直下は、ISO (国際標準化機構, International Standardization
Organization ) が定めた
２文字による国別コード(country code)である。た
だし、歴史的な理由により、アメリカを中心として .com,.
edu,.gov,.net,.org,.mil などが現在でも使われている。日本の国別コー
ドは、jp である。jp の下には、次のような枝
（領域、ドメイン）がある。
筑波大学は、ac の下にくる。tsukuba.ac.jp
の下には、学内の組織を表わすな枝（領域、ドメイン）がある。
---------------------------------------------------------------------- <domain> ::= <subdomain> | " " <subdomain> ::= <label> | <subdomain> "." <label> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> <let-dig-hyp> ::= <let-dig> | "-" <let-dig> ::= <letter> | <digit> <letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case <digit> ::= any one of the ten digits 0 through 9 ----------------------------------------------------------------------
resolver の設定ファイルの例：
---------------------------------------------------------------------- /etc/resolv.conf domain is.tsukuba.ac.jp nameserver 130.158.80.245 nameserver 130.158.80.244 ----------------------------------------------------------------------
各名前サーバは、ゾーンと呼ばれる、木構造の節のデータ（Unixのディレクト リに相当）を保持する。
図? 名前サーバの動き
例：このクライアントが、「www.u-ust.ac.jp」というドメイ
ン名のホストの IP アドレスを調べる。
各ドメインの名前サーバは、 単に次の名前サーバを返すだけで、自分で最終的な答えが見つかるまで 繰り返さない。 (ローカルの名前サーバが非再帰的(non-recursive)、または反復的 (iterative)な要求を出している。)
１つのドメイン名をIPアドレスに変換するたびに、該当する名前サーバに要求 を送っていると遅い。 ルート・ドメインの名前サーバの負荷が重たい。
実際の名前サーバでは、 キャッシング(caching)、きゃっしんぐ を行なっていてる。
一度知った情報は、メモリ中に保存しておき、次に必要になった時には、それ を使う。（他の名前サーバには問い合わせを行なわない）。
キャッシュを持っていると、元の情報が更新され時に問題が起きる。 そこで、キャッシュには、 生存期間(TTL: time to live) が決められており、それを過ぎると自動的に捨てられる。
逆に考えると、この期限内では、たとえデータを更新したとしても、古いデー タが参照される。
トレードオフ。
DNS では、主にドメイン名を IP アドレスへ変換するが、これは ドメイン名ごとに IP アドレスのデータが定義されていることによる。 このような DNS で扱う１つひとつのデータを、 資源レコード(RR: resource recourd) という。
しかし、名前とＩＰアドレスの束縛は、必ず変化する。 キャッシュの内容を正しく保つためには、次のような技術が使われている。
名前サーバを複数用意しておくと、それらの名前サーバのうちどれか１つでも アクセスできれば、名前解決をすることができる。
名前サーバの種類：
プライマリの名前サーバは、ファイルからそのゾーンのデータを読み込む。
セカンダリの名前サーバは、プライマリの名前サーバや他のセ カンダリの名前サーバからデータをコピーする。
このコピーのことを ゾーン転送(zone transfer) という。
---------------------------------------------------------------------- adonis1% nslookup Default Server: orchid.jks.is.tsukuba.ac.jp Address: 130.158.86.241 > set type=soa> jks.is.tsukuba.ac.jp
----------------------------------------------------------------------
ホスト名からIPアドレスを引く普通の引き方を強調する時には 正引き という。
正引きは、A レコードを検索することで行なわれる。
引きには、PTR が検索される。
例 IP アドレス(数字は、全て 10 進数): YHM_Interaction2(` 12.34.56.78 ') のホストのドメイン名を調べるには、次のようなドメイン名の PTR レコード を検索する。 YHM_Interaction2(` 78.56.34.12.in-addr.arpa ')
逆に言えば、ルートさえ手動で設定すれば、他のドメインは設定しなくてもよ い。
名前サーバの設定ファイルから読み込ませる。
named.root: ---------------------------------------------------------------------- . 99999999 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. IN A 198.41.0.4 . 99999999 IN NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. IN A 128.9.0.107 .... . 99999999 IN NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. IN A 202.12.27.33 ----------------------------------------------------------------------ここで
99999999 は、このレコードの生存期間(TTL)が無限大
(いつまでも有効)という意味。
最後の M は、日本にある。
6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
The query would look like:
+---------------------------------------------------+
Header | OPCODE=SQUERY |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | |
+---------------------------------------------------+
Authority | |
+---------------------------------------------------+
Additional | |
+---------------------------------------------------+
The response from C.ISI.EDU would be:
+---------------------------------------------------+
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 | |
+---------------------------------------------------+
Additional | |
+---------------------------------------------------+
The header of the response looks like the header of the query, except
that the RESPONSE bit is set, indicating that this message is a
response, not a query, and the Authoritative Answer (AA) bit is set
indicating that the address RRs in the answer section are from
authoritative data. The question section of the response matches the
question section of the query.
If the same query was sent to some other server which was not
authoritative for SRI-NIC.ARPA, the response might be:
+---------------------------------------------------+
Header | OPCODE=SQUERY,RESPONSE |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | SRI-NIC.ARPA. 1777 IN A 10.0.0.51 |
| 1777 IN A 26.0.0.73 |
+---------------------------------------------------+
Authority | |
+---------------------------------------------------+
Additional | |
+---------------------------------------------------+
This response is different from the previous one in two ways: the header
does not have AA set, and the TTLs are different. The inference is that
the data did not come from a zone, but from a cache. The difference
between the authoritative TTL and the TTL here is due to aging of the
data in a cache. The difference in ordering of the RRs in the answer
section is not significant.
adonis-serv:/etc/named.boot ---------------------------------------------------------------------- ; ; Boot file for server jks.is.tsukuba.ac.jp. ; ; $Header: named.boot,v 2.0 98/03/16 01:13:32 root Exp $ ; directory /var/named ;domain jks.is.tsukuba.ac.jp ; forwarders 130.158.80.245 130.158.80.244 ; cache . named.root primary 0.0.127.in-addr.arpa named.local ; primary jks.is.tsukuba.ac.jp jks.zone ; primary 86.158.130.in-addr.arpa 130.158.86.rev primary 87.158.130.in-addr.arpa 130.158.87.rev ; secondary open-coins.jks.is.tsukuba.ac.jp 130.158.87.132 cache/open-coins.zone secondary 128.87.158.130.in-addr.arpa 130.158.87.132 cache/open-coins-128.rev ----------------------------------------------------------------------
adonis-serv:/var/named/jks.zone
----------------------------------------------------------------------
;
; jks.zone (jks.is.tsukuba.ac.jp)
;
; $Header: jks.zone,v 2.0 98/03/16 17:57:01 root Exp $
;
@ IN SOA jks.is.tsukuba.ac.jp. postmaster.jks.is.tsukuba.ac.jp.
(
199804262 ; Serial
10800 ; Refresh
3600 ; Retry
43200 ; Expire
86400 ; Minimum
)
IN NS orchid
IN A 130.158.86.241
IN MX 10 orchid.jks.is.tsukuba.ac.jp.
; aliases
localhost IN CNAME localhost.
www IN CNAME azalea-serv
orchid IN A 130.158.86.241
IN MX 10 orchid.jks.is.tsukuba.ac.jp.
azalea-serv IN A 130.158.86.242
IN MX 10 orchid.jks.is.tsukuba.ac.jp.
..
adonis-serv IN CNAME orchid
ugrad1 IN CNAME orchid
ugrad2 IN CNAME azalea-serv
$INCLUDE adonis.hosts
----------------------------------------------------------------------