] > アプリケーション

第 13 回 アプリケーション

本日の内容


このドキュメントは http://edu.net.c.dendai.ac.jp/ 上で公開されています。

13-1. DNS

DNS(Domain Name System) は IP アドレスを名前で読み替えるものです。 名前は階層化されており、各組織が管理するようになっています。

階層構造

インターネットのホスト名は階層的に管理されています。 例えば、 www.c.dendai.ac.jp. というような名前が付けられています。 ピリオドで終了する名前のことを絶対アドレスと呼ぶことがあり ます。 名前はピリオドで区切られ、右に行くほど管理規模が大きくなります。

C 科メディアセンターJPNICJPNIC ICANN(IANA)
wwwcdendaiacjp

ネームサーバの仕組み

ネームサーバは特定の組織の名前とその IP アドレスを保管していて、問い合 わせが来ると名前やIPアドレスを返します。 但し、他のネームサーバとも連係しており、自分のサーバ内にないデータは積 極的に他のサーバに問い合わせます。

他のネームサーバとの連係方法ですが、ルートサーバというもの が世界中に 13 台あり、そのアドレスリストが各ネームサーバに置かれていま す。 例えば、 www.c.dendai.ac.jp というアドレスを解釈できないネームサーバは 次のような動作をします。

  1. まずルートサーバに尋ねます。するとルートサーバは jp を管理している ネームサーバのアドレスを返して来ます。
  2. jp を管理しているネームサーバに問い合わせると、 dendai.ac.jp を管 理している電大メディアセンターの管理しているネームサーバのアドレスを返 します。
  3. 電大メディアセンターのネームサーバに問い合わせると、 C 科のネーム サーバのアドレスを返して来ます。
  4. C 科のネームサーバでは www.c.dendai.ac.jp のアドレスを管理してます ので、問い合わせに対して IP アドレスを返すことができます。

このようにすべての問い合わせはルートサーバから始まることになっているの で、ルートサーバが全滅したらインターネットの利用は大混乱になります。 そこで、ルートサーバは複数台あり、世界中に分散して管理されています。 なお、ネームサーバのデータには有効期限があり、一度問い合わせたデータは 有効期限内はキャッシュされます。

プロトコル

DNS の問い合わせ UDP または TCP の 53 番のポートに送られる。 送受信されるメッセージのフォーマットは同一で次の 5 つの部分に分けられ る。

  1. ヘッダ部
  2. 問い合わせ部
  3. 回答部
  4. 権威部
  5. 付加情報部

ヘッダ部

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
ID
QR OPCODE AA TC RD RA 0 0 0 RCODE
問い合わせ部のエントリ数
回答部のレコード数
権威部のレコード数
付加情報部のレコード数
ID
問い合わせ時に任意に決める識別子
QR
問い合わせなら 0、応答なら 1
opcode
0
標準的な問い合わせ
1
逆問い合わせ
2
サーバ状態の要求
AA
権威付きの応答
TC
メッセージが長かったため途中で切られたことを示す
RD
再帰の要求
RA
ネームサーバが再帰を可能であることを示す
RCODE
0
エラーなし
1
フォーマットエラー
2
サーバ障害
3
名前のエラー
4
未インプリメント
5
拒否

nslookup

nslookup はネームサーバに問い合わせをするプログラムです。 UNIX 系と Windows 2000, XP にあります。

基本的な使い方は次の通りです。


nslookup 名前

名前の後に特定のサーバを指定することができ、さらにオプションを指定する ことで、IP アドレス以外の項目を調べることもできます。


nslookup -query=ns c.dendai.ac.jp ns.dendai.ac.jp

bind

カルフォルニア大バークレー校で開発された DNS サーバは bind と呼ばれて います。 現在 ver. 9 になっています。 bind の管理は設定ファイルと Zone ファイルに分かれています。

設定ファイル

基本事項

設定ファイルは named.conf というファイルに記入します。基本的には bind のパッケージに付いてくる雛型ファイルを修正して使います。

特に重要なのが zone 指定です。


zone "ドメイン" {
   type タイプ名;
   file ファイル名;
   他の指定;
};

デフォルトで管理が必須なのは、以下のアドレスです。

  1. ルートサーバのアドレス
  2. localhost のアドレス
  3. 127/8 のアドレス(localhost は 127.0.0.1)
  4. 0/8 のアドレス(デフォルトは 0.0.0.0)
  5. 255/8 のアドレス(同一ネットワーク上の全てのホストは 255.255.255.255)

これらに関してはインストールする際に得られたファイルのままで問題ありま せん。 但し、ルートサーバのアドレスは更新されることがあるので、最新版を ftp://ftp.internic.org/domain/ から入手する必要があります。

ドメイン管理

さて、ドメインの管理ですが、正引きと逆引きというのがあります。 正引きとはホスト名から IP アドレスを調べることです。 一方逆引きは IP アドレスからホスト名を調べることです。 例えば、 dendai.ac.jp ドメインの元で c ドメインを管理し(つまり●. c.dendai.ac.jp の管理)、アドレスとし て 133.20.160.0/24 が与えられた(つまり 133.20.160.● )とします(上位管 理組織は 133.20.0.0/16 を管理しているとします)。 すると、 zone ファイルは基本的には次のようになります。


zone "c.dendai.ac.jp" {
   type master;
   file cドメインのzoneファイル名;
};
zone "160.20.133.in-addr.arpa" {
   type master;
   file サブネットのzoneファイル名;
};

このように基本的には . で区切られた一番左側の部分の管理をするのが DNS の仕事です。 したがって、IP アドレスも 8bit 区切りの管理が基本となります。 なお、このようにドメインを定義するファイルを持つサーバをマスター サーバと言います。

正引きの書式は理解できるとして、逆引きがどうしてこのようになるかは歴史 上の問題としか言いようがありません。

セカンダリサーバ

ネームサーバの障害は大きな影響を及ぼしますので、通常一つのドメインに対 して複数のネームサーバを設置します。 その際、全てを同一に保つため、一台だけマスターサーバを用意し(前述)、残 りはセカンダリサーバとして運用します。 セカンダリサーバはマスターサーバとバックアップ用の保存用ファイル名を指 定します。 なお、一つのサーバはドメイン毎にマスターにもセカンダリにもどちらにもな れます。

一般に上位ドメインのマスターサーバは下位ドメインのセカンダリサーバにな ると言う慣例があります。 つまり、 c.dendai.ac.jp のマスターサーバである ice-cream.c.dendai.ac.jp は net.c.dendai.ac.jp のセカンダリサーバになっ ており、また、 dendai.ac.jp のマスターサーバである ns.dendai.ac.jp は c.dendai.ac.jp のセカンダリサーバになっています。


zone "c.dendai.ac.jp" {
   type slave;
   file cドメインのzoneファイル名;
   masters { 
     ネームサーバ1の IP アドレス; 
     ネームサーバ2の IP アドレス; 
  };
};
zone "160.20.133.in-addr.arpa" {
   type slave;
   file 160 サブネットのzoneファイル名;
   masters { 
     ネームサーバ1の IP アドレス; 
     ネームサーバ2の IP アドレス; 
  };
};

Zone ファイル

ドメイン管理の定義を記すファイルです。 重要な項目に次のものがあります。

SOA
以下の項目を定義します。
  1. マスターネームサーバ
  2. 管理者メールアドレス(@ を . に替えて表記します)
  3. 丸カッコ内にシリアル番号、
  4. リフレッシュ時間(秒)
  5. リトライ時間(秒)
  6. 有効期間
  7. キャッシュ中の有効期間(Time To Live)
NS
正規ネームサーバアドレスを記述します。 ここにはマスターネームサーバの他、セカンダリサーバのアドレスも記述します。 NS で指定されていないネームサーバは Non-Authoritive(権威なし) になります。
A, AAAA
アドレス指定をします。 AAAA は IPv6 用の書式です。
PTR
アドレスからホスト名を指定します。
CNAME
CNAME は canonical name の略であるが、別名をつける際に使う
MX
電子メールの受け取りホストを定義します。MX では項目名の後に優先度 を示す値を記します。

ZONE ファイルの一般的な書式は次の通りです。


アドレス TTL(秒) IN 項目名 値

例えば次のようになります。


c.dendai.ac.jp. IN SOA ice-cream.c.dendai.ac.jp. hostmaster.ice-cream.c.dendai.ac.jp. (
                    200601111 28800 7200 2419200 86400 )
c.dendai.ac.jp. 259200 IN NS ice-cream.c.dendai.ac.jp.
c.dendai.ac.jp. 259200 IN NS ns.dendai.ac.jp.
c.dendai.ac.jp. 259200 IN MX 10 ice-cream.c.dendai.ac.jp.
ice-cream.c.dendai.ac.jp. 259200 IN A 133.20.160.1
p1.net.c.dendai.ac.jp. 259200 IN A 133.20.160.40
net.c.dendai.ac.jp. 86400 IN NS p1.net.c.dendai.ac.jp.
net.c.dendai.ac.jp. 86400 IN NS ice-cream.c.dendai.ac.jp.

ここでホストアドレスの後が.(ピリオド)で終っているのに注意します。 このようにピリオドで終っているアドレスを絶対アドレスと呼び ます。 一方、上の zone ファイルが named.conf で c.dendai.ac.jp の zone と 指定されている場合、ピリオドで終らないアドレスにはすべて c.dendai.ac.jp が付加されます。 またその zone で指定されたドメイン名を @ で表すこともできます。 さらに、同じアドレスに関して、二行目からはそのアドレス自体を省略できま す。 TTL の値は省略すると SOA レコードの TTL が採用されます。 したがって上記 zone ファイルは以下のように簡略表記できます。


@ IN SOA ice-cream hostmaster.ice-cream.c.dendai.ac.jp. (
                    200601111 28800 7200 2419200 86400 )
          IN NS ice-cream
          IN NS ns.dendai.ac.jp.
          IN MX 10 ice-cream
ice-cream IN A  133.20.160.1
p1.net    IN A  133.20.160.40
net       IN NS p1.net
          IN NS ice-cream

一方、逆引 160.20.133.in-addr.arpa ドメインの zone ファイルの例を示し ます。


@ IN SOA ice-cream.c.dendai.ac.jp. hostmaster.ice-cream.c.dendai.ac.jp. (
                    200601111 28800 7200 2419200 86400 )
          IN NS    ice-cream.c.dendai.ac.jp.
          IN NS    ns.dendai.ac.jp.
1         IN PTR   ice-cream.c.dendai.ac.jp.
net40     IN NS    p1.net.c.dendai.ac.jp.
40        IN CNAME 40.net40.160.20.133.in-addr.arpa.

おまけ 8bit単位以外のサブネットマスクで DNS を分散管理する方法

DNS は基本的にはピリオドで区切られたものを階層管理するため、 IP アドレ スをピリオドの区切り以外で階層管理することはサポートされてません。 しかし、次のようにすると階層管理することができます。 例えば、133.20.160.0/24 の管理者が 133.20.160.4〜7 までを他の管理者に 管理を委譲することを考えます。 この時、 160.20.133.in-addr.arpa の ZONE ファイルは次のようになります。


@ IN SOA ice-cream.c.dendai.ac.jp. hostmaster.ice-cream.c.dendai.ac.jp. (
                    200601111 28800 7200 2419200 86400 )
          IN NS ice-cream.c.dendai.ac.jp.
          IN NS ns.dendai.ac.jp.
1         IN PTR ice-cream.c.dendai.ac.jp.
lower     IN NS 下位管理のネームサーバ
          IN NS ice-cream.c.dendai.ac.jp.
4         IN CNAME 4.lower.160.20.133.in-addr.arpa.
5         IN CNAME 5.lower.160.20.133.in-addr.arpa.
6         IN CNAME 6.lower.160.20.133.in-addr.arpa.
7         IN CNAME 7.lower.160.20.133.in-addr.arpa.

ここで何をしているかと言うと、新たに lower.160.20.133.in-addr.arpa と いうサブドメインを作り、それを他の管理者に委譲します。 そして、その lower.160.20.133.in-addr.arpa の ZONE ファイルには次のよ うに書きます。


@ IN SOA 下位管理ネームサーバ hostmaster.ice-cream.c.dendai.ac.jp. (
                    200601111 28800 7200 2419200 86400 )
          IN NS 下位管理ネームサーバ
          IN NS ice-cream.c.dendai.ac.jp.
4         IN PTR host4.sub.c.dendai.ac.jp.
5         IN PTR host5.sub.c.dendai.ac.jp.
6         IN PTR host6.sub.c.dendai.ac.jp.
7         IN PTR host7.sub.c.dendai.ac.jp.

ここで、 host4.sub.c.dendai.ac.jp などの名前は任意です。 このように設定すると 133.20.160.4 の検索は次のような流れになります。

  1. 160.20.133.in-addr.arpa の Zone ファイルより 4.lower.160.20.133.in-addr.arpa であることがわかる。
  2. 160.20.133.in-addr.arpa の Zone ファイルより lower.160.20.133.in-addr.arpa のドメインのネームサーバが下位管理ネーム サーバであることがわかる。
  3. 下位管理ネームサーバにある lower.160.20.133.in-addr.arpa の Zone ファイルから 4.lower.160.20.133.in-addr.arpa の PTR の値が host4.sub.c.dendai.ac.jp であることがわかる。
  4. よって、 133.20.160.4 に対して、 host4.sub.c.dendai.ac.jp が結びつけられる。

13-2. HTTP

HTTP は Web サービスを実現するためのプロトコルで、 TCP の 80 番がサー ビスポートとして割り当てられてます。 HTTP はメッセージベースのプロトコルで、今までのプロトコルのようにバイ ト毎にフィールドが区切られているわけではなく、テキストファイルを相互に 送り合うことでやりとりします。 またサーバ/クライアント型のプロトコルです。

HTTP/1.0 は 1996 年に制定され、 HTTP/1.1 は 1999 年に制定されま した。 HTTP/1.0 はステートレスな(状態のない)プロトコルで、単純にクライアント の出す一つのリクエストに対して、単純に一つだけレスポンスを返します。 一方、HTTP/1.1 は Connection というメッセージを導入し、接続を継続する か切断するか選ぶことができます。 また、Host メッセージが追加され、一つのサーバが複数のサーバに見える ように動作するようにできます。

プロトコル

以下プロトコルを説明していきますが、基本的に HTTP/1.0 をベースにして説 明し、HTTP/1.1 の変更部分を補足します。

プロトコルに使われるメッセージのフォーマットは基本的には RFC1036 で規 定される形式で、これは電子メールの形式(RFC822)に準拠しています。 ただし、HTTP/1.0 ではリクエスト、レスポンスともメッセージの一行目に特 別な行を拡張します。 なお、RFC 1036 形式とは、ヘッダ部とボディ部が一つの空行で区切られており、 ヘッダ部は各行が「フィールド名:フィールドの値 CRLF」という形式になって いるものです。 ここで CR(復帰)は 0x0d, LF(改行)は 0x0a の文字コードで表される文字で、 この二文字の組でメッセージの改行を表します。 この改行の方式は Microsoft Windows のテキストファイルの改行と一致して います(MacOS や UNIX では異なります)。

リクエストメッセージ

HTTP/1.0

ヘッダの一行目は「リクエスト行」と呼ばれ、「メソッド(一つの 空白)リクエストURI(一つの空白)HTTPバージョンCRLF」という構造になってい ます。 「メソッド」には GET, HEAD, POST(すべて英大文字で表記) が定 義されてます。 GET メソッドは「リクエストURI」で示すデータを取り出すことを意味します。 「リクエストURI」 は /で始まる「絶対パス」と言う表現で指定するもので通 常は特定のファイルを指します。 「HTTPバージョン」は HTTP/1.0(英大文字のみ)です。 したがって、 index.html というファイルを要求するリクエスト行は次のよう になります。


GET /index.html HTTP/1.0

この後、 RFC1036 メッセージが続くことになりますが、POST メソッド以外は それほど重要な意味を持ちません。付けた方が良さそうなヘッダとしては User-Agent フィールド(利用者の使用するプログラムを名乗る)がありますが、 これは必須ではありません。 したがって、ヘッダ、ボディとも空で構わないので、区切りである空行のみが 最小の RFC1036 メッセージになります。 したがって、上記の index.html を要求する最低限のリクエストメッセージは 次のようになります。


GET /index.html HTTP/1.0
(空行)

POST メソッドでは値を送信しなければなりませんが、その場合、 Content-Length フィールドに送信バイト数を設定する必要があります。 内容は空行の後に記入します。したがって、 POST メソッドの場合の最小のメッ セージは次のようになります。


POST /prog.cgi HTTP/1.0
Content-Length: xxx
(空行)
(xxx バイトのデータ)
HTTP/1.1

HTTP/1.1 ではマルチホームと接続保持の機能が追加されたため、これらの指 定を RFC1036 メッセージとして含める必要があります。 このため HTTP/1.1 の最小のメッセージは以下のようになります。


GET /index.html HTTP/1.1
Host: ホスト名
Connection: close
(空行)

HTTP/1.1 では Host ヘッダのないメッセージには 400 Bad Request エラーメッ セージを返します。 また Connection: close メッセージのないメッセージでは自動的に接続が継 続されます。

レスポンスメッセージ

最小のリクエストメッセージはリクエスト行と空行のみで済みましたが、レス ポンスメッセージはそれほど簡単ではありません。 まずレスポンスメッセージの最初の行は「Status行」と呼ばれる 行が必要です。 これは「HTTPバージョン(空白)Statusコード(空白)理由を示す言葉CRLF」 という書式になっています。 ここでまず、HTTPバージョンは HTTP/1.0 または HTTP/1.1 になります。 一方、Statusコードは3桁の数字です。一番上の桁はおおまかな意味を表し、下の二 桁は通し番号を表します。但し、下二桁が 00 の状態はメタな意味(他に含ま れるメッセージを統括する意味)になってます。 Status コードの一番上の桁は次のような意味です。

1xx
情報(未使用)
2xx
成功
3xx
転送
4xx
クライアントの誤り
5xx
サーバの誤り

ここでは最小のサーバを作るだけのメッセージを紹介します。 重要なメッセージは 200 で、意味は Ok です。 400 は Bad Request という意味になります。 リクエストメッセージの構文がおかしい場合などはこれに当たります。 要求した情報がない場合も 400 BadRequest を返してもいいのですが、 404 Not Found という専用のメッセージが用意されています。 500 は Internal Server Error です。サーバがエラーを出さなければならな い状態ではこのエラーを返します。 但し、リクエストメッセージは正しいが、指定されているメソッドに対応して ない場合、501 Not Implemented を返すべきです。 つまり、最小のサーバが送り返す Status コードとその意味をまとめると次の ようになります。

200
Ok
400
Bad Request
404
Not Found
500
Internal Server Error
501
Not Implemented

この Ok などは「理由を示す言葉」として Status 行に埋め込まれます。

次に Status 行に続く RFC1036 メッセージですが、最低でも次のフィールド が必要です。

Date
情報を作成した日時(転送を始めた日時ではない)
Content-Length
情報の長さ
Content-Type
情報の型

Date フィールドには情報を作成した日時を入れます。書式は 「Sun, 06 Nov 1994 08:49:37 GMT」のようにします。 日時は日本標準時(JST)ではなく、必ず世界時(UT)で表現します。但し歴史的 理由から世界時を表す時は UT の代わりにGMT と表示します。

Content-Length は情報の長さを 10 進法で表現します。

Content-Type には送る情報の型を表示します。 これは RFC2046 で規定されているものです。 テキストファイルだったら text/plain、 HTML 文書なら text/html、JPEG 画 像だったら image/jpeg などと指定します。 Content-type が決まらない場合、デフォルト値 application/octet-stream を指定します。

特に Content-type が text の場合、文字コードが重要になります。 Shift_JIS(マイクロソフト漢字コード)のテキストファイルだと次のように指 定します.


Content-Type: text/plain ; charset=Shift_JIS

テキストファイルの漢字コードをファイルの内容から自動的に判別するには限 界がありますので、 Content-Type の text/plain のファイルの charset を サーバが自動的に決定することは難しいです。 一方、HTML 文書の場合、meta 要素により、 Content-Type を指定することができますので、 サーバ側の立場としては、文書中からHTTP-EQUIV 属性が Content-Type であ る meta タグを探し、 CONTENT 属性を得ること必要があります。 なお HTML 文書のデフォルトの文字コードは西ヨーロッパ圏の言語を表示でき る iso-8859-1 です。

補足

WWW の標準化団体 World Wide Web Consortium は HTTP/1.0 を使用しないよ うに勧めています。 これは HTTP/1.0 にはスケーラビリティとパフォーマンスに関して深刻な問題 を抱えているからで、新しいアプリケーションは HTTP/1.1 を用いるべきであ るとしています。

Apache

WWW サービスを行うサーバは HTTPD など呼ばれます。 これは UNIX 系の OS ではサービスを行うプログラムのことをしばしば daemon と呼ぶため、「プロトコル名+D」でそのサーバープログラムを意味し ます。

HTTPD で現在もっともポピュラーなのが Apache サーバーです。 これはもともと NCSA で開発されていた NCSA Httpd が元になっています。 最初は、これの修正パッチ(patch) というような意味で名付けられました。 現在は機能とスケーラビリティから世界中でもっとも多く使われています。

設定

Apache ver. 1 では httpd.conf というテキストファイルに設定項目を記入し ます。 Apache ver. 2 の設定ファイルは apache2.conf というファイルになっていま す。 基本的には一行に一項目、「項目名(空白)項目値」という書式で書きます。


ErrorLog /var/log/apache2/error.log

但し、まとまった項目を設定するため、タグでまとまりを囲む形式もあります。


<Directory /home/*/public_html>
        AllowOverride FileInfo AuthConfig Limit
        Options Indexes SymLinksIfOwnerMatch IncludesNoExec ExecCGI
</Directory>

認証、アクセス制限

アクセス制限を行うには

Tomcat

13-3. 付録

bind 関係

name.conf


// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the 
// structure of BIND configuration files in Debian, *BEFORE* you customize 
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";

// prime the server with knowledge of the root servers
zone "." {
	type hint;
	file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
	type master;
	file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
	type master;
	file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
	type master;
	file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
	type master;
	file "/etc/bind/db.255";
};

// zone "com" { type delegation-only; };
// zone "net" { type delegation-only; };

// From the release notes:
//  Because many of our users are uncomfortable receiving undelegated answers
//  from root or top level domains, other than a few for whom that behaviour
//  has been trusted and expected for quite some length of time, we have now
//  introduced the "root-delegations-only" feature which applies delegation-only
//  logic to all top level domains, and to the root domain.  An exception list
//  should be specified, including "MUSEUM" and "DE", and any other top level
//  domains from whom undelegated responses are expected and trusted.
// root-delegation-only exclude { "DE"; "MUSEUM"; };

include "/etc/bind/named.conf.local";

named.conf.options


options {
	directory "/var/cache/bind";

	// If there is a firewall between you and nameservers you want
	// to talk to, you might need to uncomment the query-source
	// directive below.  Previous versions of BIND always asked
	// questions using port 53, but BIND 8.1 and later use an unprivileged
	// port by default.

	// query-source address * port 53;

	// If your ISP provided one or more IP addresses for stable 
	// nameservers, you probably want to use them as forwarders.  
	// Uncomment the following block, and insert the addresses replacing 
	// the all-0's placeholder.

	// forwarders {
	// 	0.0.0.0;
	// };

	auth-nxdomain no;    # conform to RFC1035

};

坂本直志 <sakamoto@c.dendai.ac.jp>
東京電機大学工学部情報通信工学科