このドキュメントは http://edu.net.c.dendai.ac.jp/ 上で公開されています。
DNS(Domain Name System) は IP アドレスを名前で読み替えるものです。 名前は階層化されており、各組織が階層管理するようになっています。
インターネットのアドレスの名前は階層的に管理されています。 ここで言うアドレスとは、例えば www.c.dendai.ac.jp というような名前のこ とです。 名前はピリオドで区切られ、区切り毎に管理されます。 また、 右に行くほど管理規模が大きくなります。
| C 科 | メディアセンター | JPNIC | JPNIC | ICANN(IANA) |
| www | c | dendai | ac | jp |
ネームサーバは特定の組織に属する名前とその IP アドレスを保管していて、問い合 わせが来ると名前やIPアドレスを返します。 但し、他のネームサーバとも連係しており、自分のサーバ内にないデータは積 極的に他のサーバに問い合わせます。
他のネームサーバとの連係方法ですが、ルートサーバというもの が世界中に 13 台あり、そのアドレスリストが各ネームサーバに置かれていま す。 そしてこのルートサーバがアドレスの検索の起点になります。 例えば、 www.c.dendai.ac.jp というアドレスを解釈できないネームサーバは 次のような動作をします。
このようにすべての問い合わせはルートサーバから始まることになっているの で、ルートサーバが全滅したらインターネットの利用は大混乱になります。 そこで、ルートサーバは複数台あり、世界中に分散して管理されています。 なお、ネームサーバのデータには有効期限があり、一度問い合わせたデータは 有効期限内はキャッシュされます。
DNS の問い合わせメッセージは UDP または TCP の 53 番のポートに送られま す。 送受信されるメッセージのフォーマットは同一で次の 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 | ||||||
| 問い合わせ部のエントリ数 | |||||||||||||||
| 回答部のレコード数 | |||||||||||||||
| 権威部のレコード数 | |||||||||||||||
| 付加情報部のレコード数 | |||||||||||||||
DNS は一度検索したアドレスはキャッシュで持ちます。 もし、キャッシュに入っているアドレスを他から検索された場合、キャッシュ に入っている内容を返します。 但し、キャッシュに入っているデータか、オリジナルのデータなのかを区別す るため、アドレスの管理組織が認定したネームサーバには権威が 与えられます。 DNS に問い合わせた結果が権威あるサーバからの返答は Authoritive answer と呼ばれ、権威の無いサーバのキャッシュからの返答は Non-authoritive answer と呼ばれます。
nslookup はネームサーバに問い合わせをするプログラムです。
基本的な使い方は次の通りです。
nslookup 名前
名前の後に特定のサーバを指定することができ、さらにオプションを指定する ことで、IP アドレス以外の項目を調べることもできます。
nslookup -query=ns c.dendai.ac.jp ns.dendai.ac.jp
また、
DNS の再帰問い合わせを手動でやってみましょう。
カルフォルニア大バークレー校で開発された DNS サーバは bind と呼ばれて います。 現在 ver. 9 になっています。 bind の管理は設定ファイルと Zone ファイルに分かれています。
設定ファイルは named.conf というファイルに記入します。基本的には bind のパッケージに付いてくる雛型ファイルを修正して使います。
特に重要なのが zone 指定です。
zone "ドメイン" {
type タイプ名;
file ファイル名;
他の指定;
};
管理が必須な基本的なアドレスには、以下ものがあります。
これらに関しては基本的にはインストールする際に得られたファイルのままで 問題ありません。 但し、ルートサーバのアドレスは更新されることがあるので、最新版を 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 アドレスも同 様です。 したがって、IP アドレスも 8bit 区切りごとに管理すると楽です。 なお、このようにドメインを定義するファイルを持つサーバをマスター サーバあるいはプライマリサーバと言います。
ネームサーバの障害は大きな影響を及ぼしますので、通常一つのドメインに対 して複数のネームサーバを設置します。 その際、全てを同一に保つため、一台だけマスターサーバを用意し(前述)、残 りはセカンダリサーバとして運用します。 セカンダリサーバはマスターサーバのデータをバックアップしてサービスしま す。 そのため、設定にはマスターサーバのアドレスと、バックアップ用の保存用ファ イル名を指定します。 なお、一つの bind サーバは設定する各ドメイン毎にマスターにもセカンダリ にもどちらにもなれます。
一般に上位ドメインのマスターサーバは下位ドメインのセカンダリサーバにな ると言う慣例があります。 つまり、 c.dendai.ac.jp のマスターサーバである cserv3.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 アドレス;
};
};
このように named.conf ファイルにはドメインの名前の定義と、定義ファイル やマスターサーバのIPアドレスなどが入ります。
Zone ファイルとはドメイン管理の内容を定義するファイルです。 重要な項目に次のものがあります。
ZONE ファイルの一般的な書式は次の通りです。
アドレス TTL(秒) IN 項目名 値
例えば次のようになります。
c.dendai.ac.jp. IN SOA cserv3.c.dendai.ac.jp.
hostmaster.cserv3.c.dendai.ac.jp.
( 200601111 28800 7200 2419200 86400 )
c.dendai.ac.jp. 259200 IN NS cserv3.c.dendai.ac.jp.
c.dendai.ac.jp. 259200 IN NS ns.dendai.ac.jp.
c.dendai.ac.jp. 259200 IN MX 10 cserv3.c.dendai.ac.jp.
cserv3.c.dendai.ac.jp. 259200 IN A 133.20.160.54
netrouter.net.c.dendai.ac.jp. 259200 IN A 133.20.160.43
net.c.dendai.ac.jp. 86400 IN NS netrouter.net.c.dendai.ac.jp.
net.c.dendai.ac.jp. 86400 IN NS cserv3.c.dendai.ac.jp.
ここでホストアドレスの後が.(ピリオド)で終っているのに注意します。 このようにピリオドで終っているアドレスを絶対アドレスと呼び ます。 なお、このファイルにはいくつかの特別なルールがあります。 まず、上の zone ファイルが named.conf で c.dendai.ac.jp の zone と 指定されている場合、ピリオドで終らないアドレスにはすべて c.dendai.ac.jp が付加されます。 またその zone で指定されたドメイン名を @ で表すこともできます。 さらに、同じアドレスに関して行が連続する時、二行目からはそのアドレス自 体を省略できます。 TTL の値は省略すると SOA レコードの TTL が採用されます。 したがって上記 zone ファイルは以下のように簡略表記できます。
@ IN SOA cserv3 hostmaster.cserv3.c.dendai.ac.jp. (
200601111 28800 7200 2419200 86400 )
IN NS cserv3
IN NS ns.dendai.ac.jp.
IN MX 10 cserv3
cserv3 IN A 133.20.160.54
netrouter.net IN A 133.20.160.43
net IN NS netrouter.net
IN NS cserv3
ここで、 net.c.dendai.ac.jp のマスターサーバは netrouter.net.c.dendai.ac.jp です。 cserv3.c.dendai.ac.jp はセカンダリサーバになります。 但し、 cserv3 は上位サーバなので、再帰的に検索されると cserv3 の方が netrouter より先に検索されます。 そのため、セカンダリサーバが上位の時、下位ドメインのネームサーバに関す る情報を記述しておく必要ガあります。
一方、逆引 160.20.133.in-addr.arpa ドメインの zone ファイルの例を示し ます。
@ IN SOA cserv3.c.dendai.ac.jp. hostmaster.cserv3.c.dendai.ac.jp. (
200601111 28800 7200 2419200 86400 )
IN NS cserv3.c.dendai.ac.jp.
IN NS ns.dendai.ac.jp.
54 IN PTR cserv3.c.dendai.ac.jp.
net40 IN NS netrouter.net.c.dendai.ac.jp.
40 IN CNAME 40.net40.160.20.133.in-addr.arpa.
DNS は基本的にはピリオドで区切られたものを階層管理するため、 IP アドレ スをピリオドの区切り以外で階層管理することはサポートされてません。 しかし、次のようにすると階層管理することができます。 例えば、133.20.160.0/24 の管理者が 133.20.160.4〜7 までを他の管理者に 管理を委譲することを考えます。 この時、 160.20.133.in-addr.arpa の ZONE ファイルは次のようになります。
@ IN SOA cserv3.c.dendai.ac.jp. hostmaster.cserv3.c.dendai.ac.jp. (
200601111 28800 7200 2419200 86400 )
IN NS cserv3.c.dendai.ac.jp.
IN NS ns.dendai.ac.jp.
54 IN PTR cserv3.c.dendai.ac.jp.
lower IN NS ns.sub.c.dendai.ac.jp.
IN NS cserv3.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 ns.sub.c.dendai.ac.jp. hostmaster.cserv3.c.dendai.ac.jp. (
200601111 28800 7200 2419200 86400 )
IN NS 下位管理ネームサーバ
IN NS cserv3.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 の検索は次のような流れになります。
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 では異なります)。
メッセージはヘッダとボディに分割されます。 ヘッダとボディの区切りは空行で認識されます。 ヘッダ部分の文法は決まっており、基本的には「フィールド名:値」という行 の集まりになっています。 但し、値が長いとき、継続行を置くことができます。 これは、先頭文字の空白の後に、残りの値を記入するものです。 フィールドには「Date」「Content-type」など電子メールでも HTTP でも使用 するものがあります。 なお、ボディの文法は Content-Type により与えられ、さらに読み込みバイト 数として Content-Length を使用します。 但し、ボディ部分はプロトコルで解釈すしません。
ヘッダの一行目は「リクエスト行」と呼ばれ、「メソッド(一つの 空白)リクエスト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 ではマルチホームと接続保持の機能が追加されたため、これらの指 定を 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 コードの一番上の桁は次のような意味です。
ここでは最小のサーバを作るだけのメッセージを紹介します。 重要なメッセージは 200 で、意味は Ok、つまり成功したことを指します。 400 は Bad Request という意味になります。 リクエストメッセージの構文がおかしい場合などはこれに当たります。 要求した情報がない場合も 400 BadRequest を返してもいいのですが、 404 Not Found という専用のメッセージが用意されています。 500 は Internal Server Error です。サーバがエラーを出さなければならな い状態ではこのエラーを返します。 但し、リクエストメッセージは正しいが、指定されているメソッドに対応して ない場合、501 Not Implemented を返すべきです。 つまり、最小のサーバが送り返す Status コードとその意味をまとめると次の ようになります。
この Ok などは「理由を示す言葉」として Status 行に埋め込まれます。 例えば、正常なレスポンスでは Status 行は以下のようになります。
HTTP/1.0 200 Ok
次に Status 行に続く RFC1036 メッセージですが、最低でも次のフィールド が必要です。
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 を用いるべきであ るとしています。
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>
アクセス制限を行うには、管理者が Apache2.conf に書く方法と、各ディレク トリで設定する方法があります。
<Directory ディレクトリ名>
Options Indexes FollowSymLinks MultiViews ExecCGI
AllowOverride None
Order deny,allow
deny from all
allow from ドメイン名やアドレス
</Directory>
アドレスには 133.20.0.0/255.255.0.0 などネットマスクで有効な部分を指定
することができる。
また、 .dendai.ac.jp などドメイン名も上位のみを指定できる。
Order deny,allow deny from all allow from ドメイン名やアドレス
もしユーザパスワード認証を行う場合は違う設定をする必要があります。 以下は管理者用、.htaccess どちらも共通です。
コマンドを実行すると二回パスワードを聞いてきます。htpasswd パスワードファイル ユーザ名 但し、初回のみhtpasswd -c パスワードファイル ユーザ名
AuthUserFile パスワードファイルの位置 AuthGroupFile /dev/null AuthName "Please enter your ID and password" AuthType Basic require valid-user
// 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";
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 };