DNS (Domain Name System)

分散システム

                                       電子・情報工学系
                                       新城 靖
                                       <yas@is.tsukuba.ac.jp>

このページは、次の URL にあります。
http://www.coins.tsukuba.ac.jp/~yas/coins/dsys-2004/2004-12-14
あるいは、次のページから手繰っていくこともできます。
http://www.coins.tsukuba.ac.jp/~yas/
http://www.is.tsukuba.ac.jp/~yas/index-j.html

■分散システム

複数の構成要素（コンピュータ）から構成される
ネットワークで接続されている
使っている人には、あるレベル１台の集中システムのように見える。

最後の性質が大事である。

インターネット用のソフトウェアは、多くの場合、分散システムとしての性質を求められる。LAN用のソフトウェアや閉じた広域ネットワーク用分散システムとしての性質を求められることがある。(落ちたら終りで許されることもある。)

インターネット上で成功した次の２つのソフトウェアは、分散システムとしての性質も持つ。

DNS(Domain Name System)
ニュース・システム

◆分散システムの利点

安い－－マイクロプロセッサ
速い－－並列処理
本質的に分散－－ＷＷＷ、電子メール
がんばれば、信頼性を高くできる
システムの一部が故障しても、全体は動き続ける
段階的成長が可能。毎年買い足し。

◆分散システムの弱点

ソフトウェア技術が遅れている
ネットワークが飽和することがある
セキュリティの確保が難しい

◆分散システムの設計目標

透明性
フォールト・トレランス
スケーラビリティ
性能（並列処理）

◆スケーラビリティ

構成要素の数が増えた時にどうなるか。 10台で動くものが100台、1000台で動くか。

◆トレードオフ

完全を目指そうとすると、急激にコストが高くなる。

実用になり、かつ、利益に見合うコストで実現できる範囲を探すことが大事になる。

◆分散システムを実現するための技術

木構造を使う
- スケーラビリティ
- 管理の手間の分散、設定個所を少なくする
キャッシング
複製
トレードオフ
ディジタル署名

このような技術が、DNS、ニュース・システム、ＷＷＷ、ＳＳＬなどでどのように使われているかについて述べる。

■ホストの名前

◆名前、アドレス

コンピュータの世界では、ある物を指し示すための情報という意味の類語:

識別子(ID, Identifier)
名前(name)
ハンドル(handle)
アドレス(address)
ポインタ(pointer)
参照(reference)
場所(location)

■ＤＮＳ

◆名前、アドレス

コンピュータの世界では、ある物を指し示すための情報という意味の類語:

名前(name)
識別子(ID, Identifier)
ハンドル(handle)
参照(reference)
ポインタ(pointer)
アドレス(address)
場所(location)

◆名前サービス

名前サービスとは、高レベルの名前を低レベルの名前に変換するサービス。

高レベルの名前: 文字列、人間が解釈できる
低いレベルの名前: 整数、コンピュータにとって都合がよい

名前サービスを提供するプロセスは、 名前サーバ(name server) と呼ばれる。

名前から名前を指している番号に変換することを 名前解決(name resolution) という。

名前サーバのクライアントとして名前解決をする部分を リゾルバ(resolver) という。

◆DNS

インターネットで使われている名前サービスは、 DNS(Domain Name System) と呼ばれている。

DNS では、膨大な数のホスト名を含む名前空間を木構造で管理する。

==階層的にドメイン（領域）に分割して管理する。

◆ドメイン＝＝木構造

図　大学組織（ドメイン的な見方）

図　大学組織（普通の木）

◆木構造の必然性

初期のシステムは、ホスト名とＩＰアドレスの対応を平らな名前空間（flat namespace）で管理していた。その内容は、NIC (Network Information Center)が管理していた。

利点

名前が短い

欠点

大量のマシンにたいして名前を付けられない。

名前の衝突。名前の衝突。同じ名前を取り合いになる。
NICの負荷が重たい。
最新のホスト名の一覧表の維持が困難になった。最新版のコピーがネットワークを重たくした。

1990年、137,000 台まで増えた所で、ＤＮＳに切り替えられた。

名前空間を分割し、一部の権限を委任する。分割されたものをさらに分割する。

→木構造。

自然な考え方。

スケーラビリティを実現するには、木構造にするしかない、とも言える。しかし

◆ドメイン名の数

2004年12月ごろの名の統計
	ドメイン名	数
.com	3193万
.net	511万
.org	320万
.biz	106万
.info	284万
.edu	7400
.jp	62万

.jp は地域型含む。

第二レベルのドメインの数。ホストの数はもっと多い。

http://jpinfo.jp/stats/ JPドメイン名に関する統計 by JPRS http://www.zooknic.com/Domains/counts.html by Zooknic.

◆権限の委任

あるドメインには、それを統括するような名前サーバを置く。

必要に応じて、そのドメインを、さらにいくつかのドメインに分割して、そのうちのいくつかについて、他の名前サーバに名前の管理を委任する。

自分では任せた名前サーバへのポインタだけを持つ。

委任された名前サーバは、その分割されたドメイン(サブドメイン)についての権限を持つ。

分割されたドメインは、さらに分割され、また別の名前サーバに権限が委任されることがある。

◆ドメイン名の表記方法

図インターネットのホスト名の名前付けで使われている木構造

たとえば、「is.tsukuba.ac.jp」では、木の根から見た時、 jp,ac,tsukuba,is のように枝を探していくことを意味している。これは、UNIXのファイル名とは解釈の順番が逆である。 UNIXのファイル名では、「/jp/ac/tsukuba/is」となる。

◆ドメイン名の表記方法の問題点

ルートを表わす記号がないので、相対名と絶対名の区別ができない。 (Unix のファイル名には、相対パス名と絶対パス名の区別がある。)
右から左より左から右の方が便利。

イギリスは、一時期(1990年ごろ？)、左から右を使っていた。ある時に、インターネット／アメリカに合わせた。

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

◆オルタネート・ルート問題

インターネットのドメイン名の根は、１つしかない。１３個のサーバにコピーが世界各地にある。

もし、別の根の情報を持つサーバがあれば、どうなるのか。

オルタネート・ルート（alternate roots）。

◆ドメイン名の種類

ccTLD (country code Top Level Domain): ISO (国際標準化機構, International Standardization Organization ) が定めた２文字による国別コード(country code)を使う。日本の国別コードは、jp。
gTLD (generic Top Level Domain): ccTLD 以外。.com,. edu,.gov,.net,.org,.mil などが現在でも使われている。

jp の下には、次のような枝（領域、ドメイン）がある。

ac: 学校関係(主に大学)、学術研究機関
ad: ネットワーク管理、JPNICの会員
co: 会社
ed: 児童、生徒などの教育・育成を行う組織。
go: 政府機関、国立の施設
gr: 任意団体
ne: インターネット接続サービス・プロバイダ
or: 法律に基づく団体
都道府県の名前: 地方自治体、個人。

◆汎用JPドメイン名

jp の下に、上のような属性を持たない第２レベルドメイン名（SLD：Second Level Domain）も使えるようになった。

汎用JPドメイン名(JPNIC)

◆ICANN

ICANN（Internet Corporation for Assigned Names and Numbers）

インターネットにおけるドメイン名や IPアドレスを調整するための非営利法人。1998年に設立。

以前は、IANA（Internet Assigned Numbers Authority）。

2000年に始めての理事選挙があった。

◆新しいドメイン

2000年11月16日に新しく7つのトップ・レベル・ドメインが作られた。

.aero
.biz
.coop
.info
.museum
.name
.pro

ICANN New TLD Program http://www.icann.org/tlds/

あと3つ増やす計画が 2002 年10月に発表された。

A Plan for Action Regarding New gTLDs (by Stuart Lynn, ICANN President)

■ＤＮＳの仕組み

DNS は、世界中に分散された多くの名前サーバが協調しあって、全体として一つの巨大な名前空間を実現している。

リゾルバ
名前サーバ

◆名前解決

ホスト名をＩＰアドレスに変換すことを、名前を解決する（resolve）という。名前を解決するモジュールを resolver という。

resolver の設定ファイルの例：

/etc/resolv.conf:
----------------------------------------------------------------------
% cat /etc/resolv.conf 
search coins.tsukuba.ac.jp
nameserver 130.158.86.1
nameserver 130.158.86.2
% 
----------------------------------------------------------------------

◆分散されたサーバとゾーン

各名前サーバは、ゾーンと呼ばれる、木構造の節のデータ（Unixのディレクトリに相当）を保持する。

下の節の名前サーバが動いているホストの名前
IPアドレス

１つの名前サーバは、このようなゾーンのいくつかを管理することがある。

DNS のドメインとゾーンの関係

◆名前サーバの動き

図? 名前サーバの動き

例：このクライアントが、「www.u-ust.ac.jp」というドメイン名のホストの IP アドレスを調べる。

クライアントの内部にリンクされたリゾルバは、ローカルの名前サーバに、そのドメイン名を送る。
ローカルの名前サーバは、ルート・ドメインの名前サーバに、このドメイン名を送る。
ルート・ドメインの名前サーバは、自分ではIPアドレスを答えずに代わりにjp ドメインの名前サーバのIPアドレスを返す。
ローカルの名前サーバは、今度は、それを使ってjpドメインの名前サーバに、ドメイン名を送る。
jpドメインの名前サーバは、自分ではIPアドレスを答えずに代わりに ac.jp ドメインの名前サーバのIPアドレスを返す。
ローカルの名前サーバは、ac.jpドメインの名前サーバに、ドメイン名を送る。
ac.jpドメインの名前サーバは、自分ではIPアドレスを答えずに代わりに u-ust.ac.jp ドメインの名前サーバのIPアドレスを返す。
ローカルの名前サーバは、u-ust.ac.jpドメインの名前サーバに、ドメイン名を送る。
u-ust.ac.jpドメインの名前サーバは、そのドメイン名のIPアドレスを返す。
ローカルの名前サーバは、リゾルバにそのIPアドレスを返します。

ローカルの名前サーバは、答え(IPアドレス)が見つかるまで繰り返し名前サーバに要求を送る(リゾルバが再帰的(recursive)な要求を出している)。

各ドメインの名前サーバは、単に次の名前サーバを返すだけで、自分で最終的な答えが見つかるまで繰り返さない。 (ローカルの名前サーバが非再帰的(non-recursive)、または反復的 (iterative)な要求を出している。)

◆キャッシング

１つのドメイン名をIPアドレスに変換するたびに、該当する名前サーバに要求を送っていると遅い。ルート・ドメインの名前サーバの負荷が重たい。

実際の名前サーバでは、 キャッシング(caching) を行なっていてる。

一度知った情報は、メモリ中に保存しておき、次に必要になった時には、それを使う。（他の名前サーバには問い合わせを行なわない）。

◆寿命

名前とＩＰアドレスの束縛は、あまり変化しないので、キャッシングが非常に有効に機能する。

しかし、名前とＩＰアドレスの束縛は、必ず変化する。キャッシュを持っていると、元の情報が更新され時に問題が起きる。

キャッシュの内容を正しく保つためには、次のような技術が使われている。

データに生存期間（TTL, Tive To Live）が付けてある。
生存期間が過ぎたデータは、捨てられる。

参考

逆に考えると、この期限内では、たとえデータを更新したとしても、古いデータが参照される。

トレードオフ。

◆資源レコード

DNS では、主にドメイン名を IP アドレスへ変換するが、これはドメイン名ごとに IP アドレスのデータが定義されていることによる。このような DNS で扱う１つひとつのデータを、 資源レコード(RR: resource recourd) という。

表？ DNSでよく使われる資源レコード

--------------------------------------------------------------------
資源レコード	意味
--------------------------------------------------------------------
A		アドレス
CNAME		正式名
HINFO		ホスト情報
MX		電子メールの送り先
NS		名前サーバ
PTR		ポインタ
SOA		権限開始
--------------------------------------------------------------------

◆複製(replication)

１つのドメインについて、名前サーバは、普通は必ず２つ以上動作させる。

名前サーバを複数用意しておくと、それらの名前サーバのうちどれか１つでもアクセスできれば、名前解決をすることができる。

名前サーバの種類：

プライマリ(primary、マスタ): あるドメインについて最終権限を持っている。世界でひとつだけ。
セカンダリ(secondary): プライマリのコピー(複製、replication)を持つ。

プライマリの名前サーバは、ファイルからそのゾーンのデータを読み込む。

セカンダリの名前サーバは、プライマリの名前サーバや他のセカンダリの名前サーバからデータをコピーする。

このコピーのことを ゾーン転送(zone transfer) という。

◆複製管理のパラメタ

ゾーン転送を制御するパラメタは、SOA レコードに含まれている。


% nslookup 
Note:  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
> coins.tsukuba.ac.jp
Server:         130.158.86.1
Address:        130.158.86.1#53

coins.tsukuba.ac.jp
        origin = orchid-a.coins.tsukuba.ac.jp
        mail addr = root.coins.tsukuba.ac.jp
        serial = 2002101600
        refresh = 10800
        retry = 1800
        expire = 1209600
        minimum = 604800
>

serial: セカンダリ名前サーバがゾーン転送の時に、データが更新されたかどうかを判定する時に比較される番号。プライマリでデータを更新したら、忘れずに増やさなければならない。
refresh: セカンダリ名前サーバは、ここで示された秒数ごとに、ゾーン転送を行ないデータを更新する。
retry: リフレッシュしようとした時、転送元の名前サーバが落ちていたら、ここで示された秒数ごとに再実行する。
expire: ゾーン転送で得たデータを、転送元の名前サーバが落ちていても、ここで示された秒数は保持する。
minimum ttl: ネガティブキャッシュの生存期間。「ドメイン名が見つからない」という情報を、ここで指定された秒数だけ保持する。

minimum ttl は、レコードのデフォルトの最小生存期間として使われることがある。 (個別のレコードごとにも ttl を設定できる)

◆逆引き

ホスト名をIPアドレスへ変換するのではなく、逆にIPアドレスをホスト名へ変換することを 逆引き とい。

ホスト名からIPアドレスを引く普通の引き方を強調する時には 正引き という。

正引きは、A レコードを検索することで行なわれる。

引きには、PTR が検索される。

例 IP アドレス(数字は、全て 10 進数):


12.34.56.78

のホストのドメイン名を調べるには、次のようなドメイン名の PTR レコードを検索する。


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月に変更された。それまでは、同じ建物、同じサブネットにあった。

◆ルート・サーバへの攻撃

2002年10月には、１３個のルート・ドメインのサーバに対して攻撃が行われた。ほとんど効かなかった。

◆要求と応答の中身の例


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
...
----------------------------------------------------------------------

◆まとめ

ＤＮＳに見られる分散システム構築の技術

木構造で管理
- ホスト名のスケーラビリティ、名前の衝突回避。
- 管理の手間の分散
- ルートだけを手動で設定する
- forwarders で階層の上位の名前サーバの負荷を軽減する。
キャッシング
複製
トレードオフ(TTLの範囲で古いデータが見えることを許容している)。

Last updated: 2004/12/12 20:19:54

Yasushi Shinjo / <yas@is.tsukuba.ac.jp>