図 大学組織（ドメイン的な見方）
分散システム
電子・情報工学系
新城 靖
<yas@is.tsukuba.ac.jp>
このページは、次の URL にあります。
http://www.hlla.is.tsukuba.ac.jp/~yas/coins/dsys-2002/2003-02-18
あるいは、次のページから手繰っていくこともできます。
http://www.hlla.is.tsukuba.ac.jp/~yas/coins/
http://www.hlla.is.tsukuba.ac.jp/~yas/index-j.html
最後の性質が大事である。
インターネット用のソフトウェアは、多くの場合、分散システムとしての性質 を求められる。LAN用のソフトウェアや閉じた広域ネットワーク用分散システ ムとしての性質を求められることがある。(落ちたら終りで許されることもある。)
インターネット上で成功した次の２つのソフトウェアは、分散システムとして の性質も持つ。
構成要素の数が増えた時にどうなるか。 10台で動くものが100台、1000台で動くか。
実用になり、かつ、利益に見合うコストで実現できる範囲を探すことが大事に なる。
名前サービスを提供するプロセスは、 名前サーバ(name server) と呼ばれる。
名前から名前を指している番号に変換することを 名前解決(name resolution) という。
名前サーバのクライアントとして名前解決をする部分を リゾルバ(resolver) という。
インターネットで使われている名前サービスは、 DNS(Domain Name System) と呼ばれている。
DNS では、膨大な数のホスト名を含む名前空間を木構造で管理する。
==階層的にドメイン（領域）に分割して管理する。
図 大学組織（ドメイン的な見方）
図 大学組織（普通の木）
名前空間を分割し、一部の権限を委任する。 分割されたものをさらに分割する。
→木構造。
自然な考え方。
スケーラビリティを実現するには、木構造にするしかない、とも言える。
しかし、.com は、2002年10月ごろ 2200万。全体 3100万の70%をしめる。
(http://www.domainstats.com/)
.jp は、49万個登録されされている。
JINIC/JP ドメイン名に関する統計
http://www.nic.ad.jp/ja/stat/dom/index.html)
http://www.icann.org/tlds/
あと3つ増やす計画が 2002 年10月に発表された。
A Plan for Action Regarding New gTLDs (by Stuart Lynn, ICANN President)
インターネットのドメイン名の根は、１つしかない。 １３個のサーバにコピーが世界各地にある。
もし、別の根の情報を持つサーバがあれば、どうなるのか。
オルタネート・ルート（alternate roots）。
必要に応じて、そのドメインを、さらにいくつかのドメインに分割して、その うちのいくつかについて、他の名前サーバに名前の管理を委任する。
自分では任せた名前サーバへのポインタだけを持つ。
委任された名前サーバは、その分割されたドメイン(サブドメイン)についての 権限を持つ。
分割されたドメインは、さらに分割され、また別の名前サーバに権限が委任さ れることがある。
図 インターネットのホスト名の名前 付けで使われている木構造
is.tsukuba.ac.jp」では、木の根から見た時、
jp,ac,tsukuba,is のように枝を探していくことを意味して
いる。これは、UNIXのファイル名とは解釈の順番が逆である。
UNIXのファイル名では、「/jp/ac/tsukuba/is」となる。
ドメイン名の種類:
jp。
.com,. edu,.gov,.net,.org,.mil などが
現在でも使われている。
jp の下には、次のような枝（領域、ドメイン）がある。
jp の下に、上のような属性を持たない第２レベルドメイン名
（SLD：Second Level Domain）も使えるようになった。
インターネットにおけるドメイン名や IPアドレスを調整する ための非営利法人。1998年に設立。
以前は、IANA（Internet Assigned Numbers Authority）。
2000年に始めての理事選挙があった。
---------------------------------------------------------------------- <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: ---------------------------------------------------------------------- % cat /etc/resolv.conf search coins.tsukuba.ac.jp nameserver 130.158.86.1 nameserver 130.158.86.2 % ----------------------------------------------------------------------
各名前サーバは、ゾーンと呼ばれる、木構造の節のデータ（Unixのディレクト リに相当）を保持する。
図? 名前サーバの動き
例：このクライアントが、「www.u-ust.ac.jp」というドメイ
ン名のホストの IP アドレスを調べる。
各ドメインの名前サーバは、 単に次の名前サーバを返すだけで、自分で最終的な答えが見つかるまで 繰り返さない。 (ローカルの名前サーバが非再帰的(non-recursive)、または反復的 (iterative)な要求を出している。)
１つのドメイン名をIPアドレスに変換するたびに、該当する名前サーバに要求 を送っていると遅い。 ルート・ドメインの名前サーバの負荷が重たい。
実際の名前サーバでは、 キャッシング(caching) を行なっていてる。
一度知った情報は、メモリ中に保存しておき、次に必要になった時には、それ を使う。（他の名前サーバには問い合わせを行なわない）。
しかし、名前とＩＰアドレスの束縛は、必ず変化する。 キャッシュを持っていると、元の情報が更新され時に問題が起きる。
キャッシュの内容を正しく保つためには、次のような技術が使われている。
逆に考えると、この期限内では、たとえデータを更新したとしても、古いデー タが参照される。
トレードオフ。
DNS では、主にドメイン名を IP アドレスへ変換するが、これは ドメイン名ごとに IP アドレスのデータが定義されていることによる。 このような DNS で扱う１つひとつのデータを、 資源レコード(RR: resource recourd) という。
名前サーバを複数用意しておくと、それらの名前サーバのうちどれか１つでも アクセスできれば、名前解決をすることができる。
名前サーバの種類：
プライマリの名前サーバは、ファイルからそのゾーンのデータを読み込む。
セカンダリの名前サーバは、プライマリの名前サーバや他のセ カンダリの名前サーバからデータをコピーする。
このコピーのことを ゾーン転送(zone transfer) という。
---------------------------------------------------------------------- % nslookupNote: nslookup is deprecated and may be removed from future releases. Consider using the dig or host programs instead. Run nslookup with the -sil[ent] option to prevent this message from appearing. > set type=soa
----------------------------------------------------------------------
ホスト名からIPアドレスを引く普通の引き方を強調する時には 正引き という。
正引きは、A レコードを検索することで行なわれる。
引きには、PTR が検索される。
例 IP アドレス(数字は、全て 10 進数):
のホストのドメイン名を調べるには、次のようなドメイン名の PTR レコード を検索する。12.34.56.78
78.56.34.12.in-addr.arpa
逆に言えば、ルートさえ手動で設定すれば、他のドメインは設定しなくてもよ い。
名前サーバの設定ファイルから読み込ませる。
---------------------------------------------------------------------- % cat /var/named/named.ca ... . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ... . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 % ----------------------------------------------------------------------
最後の M は、日本にある。 J が、2002年11月に変更された。 それまでは、同じ建物、同じサブネットにあった。
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.
orchid-a:/etc/named.conf
----------------------------------------------------------------------
...
options {
directory "/var/named";
query-source address * port 53;
};
zone "." IN {
type hint;
file "named.ca";
};
zone "coins.tsukuba.ac.jp" IN {
type master;
file "coins.zone";
allow-transfer {130.158.86.2; 130.158.68.20;
130.158.68.21; 130.158.71.54;
130.158.176.189; };
};
zone "86.158.130.in-addr.arpa" IN {
type master;
file "coins.rev";
allow-transfer {130.158.86.2; 130.158.68.20;
130.158.68.21; 130.158.71.54;
130.158.176.189; };
};
...
----------------------------------------------------------------------
orchid-a:/var/named/coins.zone
----------------------------------------------------------------------
$TTL 86400
$ORIGIN coins.tsukuba.ac.jp.
@ IN SOA orchid-a.coins.tsukuba.ac.jp. root.coins
.tsukuba.ac.jp. (
2002101600 ; serial (d. adams)
10800 ; refresh
1800 ; retry
1209600 ; expiry
604800 ) ; minimum
IN NS orchid-a.coins.tsukuba.ac.jp.
IN NS orchid-b.coins.tsukuba.ac.jp.
IN MX 10 smtpgwin.cc.tsukuba.ac.jp.
@ IN NS kasumi.cc.tsukuba.ac.jp.
@ IN NS utogwgw.gssm.otsuka.tsukuba.ac.jp.
orchid-a IN A 130.158.86.1
orchid-b IN A 130.158.86.2
orchid-c IN A 130.158.86.3
...
www IN CNAME orchid-a
ftp1 IN CNAME orchid-b
www2 IN CNAME orchid-e
www3 IN CNAME orchid-e
...
adonis1 IN A 130.158.86.21
adonis2 IN A 130.158.86.22
adonis3 IN A 130.158.86.23
...
----------------------------------------------------------------------