DNS 1
ドメインネームシステム基本設定

講義

DNS (Domain Name System) の目的,仕組みを学習し, ドメイン,ゾーンの概念を理解する.実際にサブドメインに を管理するネームサーバを設定する.

背景

IP(第 3 層)の接続設定が完了した時点で接続されたすべてのホストは IP アドレスで お互いに通信ができる状態になる.しかし IP アドレスは数字の羅列であり覚えにくい. そこでドメイン名と呼ばれる "www.cc.u-tokai.ac.jp" などのアルファベットの名前を IP アドレスに対応させる仕組みが考えだされた.この対応を管理するしくみが DNS である. この例で,wwwはウェブサーバの計算機名,ccは総合計算センター, u-tokaiは東海大学,acは学術機関,jpは日本であることを示す. 組織の意味の単位と対応していて覚えやすい.

1970 年代,インターネットの前身である ARPAnet では単純にホスト名とその IP アドレスの対応表をすべての計算機に配布する方式であった. この方式では計算機の数が増えると以下の理由で破綻する.

これらの問題点を克服するために DNS が設計された.DNS は以下のような目的をもって設計されている.

ドメインの階層構造

ドメイン名は図 9.1 に示すような階層構造をもつ.

ドメイン名
図 9.1 ドメイン名

図のトップレベルの "" は内容が空のラベルである.

ある節点からルートまでのすべての節点を順に "." でつないだものを 完全ドメイン名とよぶ.例えば図中の bosei の完全ドメイン名は bosei.cc.u-tokai.ac.jp である. 各節点で直接の子供の節点の名前の重複さえおきないようにしておけば, 全体で完全ドメイン名が一意につけられることが保証される. 例えば cc.u-tokai.ac.jp と jt.u-tokai.ac.jp の両方に www というホストが あっても,それぞれの中で一意であれば完全ドメイン名は www.cc.u-tokai.ac.jp, www.jt.u-tokai.ac.jp となり区別できる. この仕組みで名前の管理を下位組織に任せても全体としての一意性を確保する ことができる.

ドメインとゾーン

DNS を理解する上で重要なのはドメインとゾーンという用語の違いを正しく理解する ことである.

ドメインという用語の意味は図 9.2 の木構造でいう部分木に 対応するもので,ac.jp ドメインを例にとると, ルートからたどって jp, ac と来た節点が ac.jp ドメインのルートとなり, ac.jp ドメインはそのルートと子孫すべての節点を含む.

ドメイン
図 9.2 ドメイン

ある節点をルートとするドメインに対してその子をルートとするドメインを サブドメインとよぶ.図 9.2 では u-tokai.ac.jp は ac.jp ドメインの サブドメインである.

DNS とはあるドメインのホストの情報(IP アドレスなど)を管理する 分散データベースである.複数存在するデータベースサーバのそれぞれをネームサーバとよぶ. ゾーン とはあるネームサーバが直接管理する単位をさす言葉である.

無数に存在するすべてのドメインごとにネームサーバが稼働しているわけではない. 例えば jt.u-tokai.ac.jp ドメインのサブドメインとして lab1.jt.u-tokai.ac.jp, lab2.jt.u-tokai.ac.jp という サブドメインがあったとしてもそれぞれが小規模なものであれば 個別にネームサーバを稼働させるのではなくjt.u-tokai.ac.jp ドメインを担当しているネームサーバがまとめて情報を管理するほうが 都合が良い場合もある.一方,yamamotolab というサブドメインは 比較的規模が大きく組織が別であり直接管理しにくい,という場合を考える.

DNS ではこのような場合に委任という仕組みを用いて 管理作業を分散することができる.これを表したものが 図 9.3 である.委任はドメイン単位で行われる. jt.u-tokai.ac.jp ドメインを委任されたネームサーバは yamamotolab.jt.u-tokai.ac.jp サブドメインを適当なネームサーバに 委任し,そのネームサーバを記録する. この場合は jt.u-tokai.ac.jp ゾーンを管理する ネームサーバ,yamamotolab.jt.u-tokai.ac.jp ゾーンを管理する ネームサーバを稼働させ,それぞれの組織で運用すればよい (一台のサーバで複数のゾーンを管理することもできる).

ゾーン
図 9.3 委任によるゾーンの分割

各ゾーンには担当するドメインが決まっている.jt.u-tokai.ac.jp ゾーンは jt.u-tokai.ac.jp ドメインを担当するのだが,このドメインの すべてのホストの情報を管理しているわけではない.委任済みの yamamotolab サブドメイン以下の情報は持たないことに注意する.

委任機能は,全体として巨大なデータベースとなる ドメイン情報の管理作業を組織の形態に合わせて分散管理できるように するための工夫である.

問い合わせ

情報の保管場所については上で説明したが,情報が分散しているために 問い合わせには工夫が必要である.DNS の設計目的で挙げた 「ネットワークのどこからでも全体を参照できる」を以下のように 実現している.

再帰解決と反復解決

DNS はいろいろな情報を管理できるが,ドメイン名からそのホストの IP アドレスを引き出すという利用がほとんどである.以降,この利用法に 限って説明する.ドメイン名から IP アドレスを得ることを名前解決とよぶ.

上で説明したように各ネームサーバは自分のドメインの全ての情報を保持している のではない.委任しているサブドメインについては委任先のネームサーバのみの情報が 記録されており,次にどこに聞けばいいのかがわかるようになっている.

自分のネームサーバに仕事を委任しているのは親ネームサーバであるから, 正しく自分に仕事を分け与えることができるのは親サーバということになる.

全てのサーバの親,DNS 名前空間全体のルートを管理するサーバに 名前解決を問い合わせる場合を考える.問い合わせられたドメイン名の ルートに近いほうから見ることで,ネームサーバは自分が管理しているドメイン名か 委任しているドメイン名かを判断することができる.自分が管理している 場合は直接答え,委任先にある場合は委任したネームサーバを答える.

これを数回繰り返すことで必ず目的のドメイン名の情報を得ることができる.

しかし,常に最上位のネームサーバにすべての処理をさせていては 最上位のネームサーバの負荷が問題になることは明らかである. そこで実際には再帰解決反復解決 を組み合わせることで上位のネームサーバの負担を軽減している.

再帰解決とは,問い合わせに対して複数のネームサーバへの調査が必要になったとき, それらの繰り返しを自分が行って最終結果だけを質問者に返す方式である. ユーザが直接問い合わせるネームサーバはこの方法で処理を行う. ユーザからは自分が設定したネームサーバに問い合わせたら,そのネームサーバが 答えを返すように見える.実際にはその間に設定したネームサーバが繰り返し他のネームサーバに 問い合わせを行い,結果をユーザに報告しているのである.

反復解決とは,問い合わせられたドメイン名が自分の管理するゾーンのものであれば 答えを返し, 委任したドメインのものであれば委任したドメインを担当するネームサーバ を答えるだけで処理を終了する方法である.上の再帰解決処理 を行っているネームサーバから問い合わせられたネームサーバはこの方式で答える.

まとめると,以下のようになる

  1. 最初に計算機のネットワーク設定を行うときにネームサーバを設定する (第 4 回実習
  2. あるドメイン名の IP アドレスを知りたいとき,設定されているネームサーバ にドメイン名の問い合わせを行う.

再帰解決を行うのはユーザが最初に直接聞く,ホストに設定された ネームサーバのみで,そのネームサーバから問い合わせを受けたネームサーバは反復解決を行う.

DNS では上位ネームサーバが再帰解決を行わないで負荷の軽い反復解決のみを行うこと, キャッシュを適切に保持することで上位ネームサーバの負担を軽減している.

ドメイン名から IP アドレスを調べることそ正引きという. 正引きとは逆に IP アドレスから ドメイン名を調べることを逆引きという. DNS では正引きだけでなく同じ仕組みを利用した 逆引きも実装されている.今回は逆引きの設定に関しての説明は省略する.

実習

実習 0.

本実験では IP による接続の設定(OSI第3層)が完了していることが前提である. 床から出ている有線ケーブルを各 PC に接続せよ.

各 pc の名前を,班番号の 2 桁表記を A とすると 各班の教卓に向かって左側から pcA1, pcA2,...,pcA4 とする.

キーボード左上のシールの番号の下2桁の数字がxx とすると,その計算機の IP アドレスを 172.17.2.xx とする.

他の情報は全てのホストで共通である. サブネットマスクは 255.255.0.0, デフォルトゲートウェイは 172.17.254.254, 優先DNSサーバのアドレスは 172.17.254.254, として設定せよ.

この状態で教卓のホスト pc151:172.17.2.60/16, pc152:172.17.2.61/16 への接続ができるか ping で調査せよ.

今回と次回の実験では上記のIPアドレスを最後まで使用する. この設定は今回と次回すべての実習の前提条件なので全班が設定を終了することを 確認する.

実習 1.

各 pc を教卓の DNS サーバのクライアントとして設定する.

DNS の設定の前に各ホストに DNS の設定に合わせたホスト名を設定する. この実習では各ホストのホスト名を班の机の左から pcA1, pcA2,...,pcA4 とする. 管理者権限が必要なので,ターミナルで su - コマンドを入力し, スーパーユーザになってから以下のコマンドを実行せよ. (AXは自分のホストに合わせる)

na-xxx# hostname pcAX

この作業のように今回の実習では管理者権限が必要な 操作が多いのでターミナルで su - コマンドを入力し,スーパーユーザに なっておくと作業が楽である.

教卓の DNS サーバ pc151 の IP アドレスは 172.17.2.60 である. 各 PC の最初に問い合わせる DNS サーバとしてこのサーバを設定する. GUIを使用して,システム>設定>ネットワーク接続,から DNSサーバを設定することができるが, 今回はターミナルから設定を行う. この作業は簡単で, /etc/resolv.conf の内容を以下の内容に変更すればよい. 管理者権限が必要なので,スーパーユーザ権限のあるターミナルで gedit 等でファイルの内容を以下のものに変更する.

nameserver 172.17.2.60

これで各計算機の最初に問い合わせるネームサーバが教卓の pc151 に設定された. 実験 1 では実習室のすべてのホストが 1b202.jt.u-tokai.ac.jp ドメインの 直下に存在する.例えば pcA1 の完全ドメイン名は pcA1.1b202.jt.u-tokai.ac.jp となる.

ドメイン名から IP アドレスを調べるのに nslookup コマンドを使用する. 以下のコマンドを実行すると,各ホストに設定されたネームサーバ (現段階ではpc151)に対して pc151.1b202.jt.u-tokai.ac.jp の IP アドレスの問い合わせを行う.

nslookup pc151.1b202.jt.u-tokai.ac.jp

pc151.1b202.jt.u-tokai.ac.jp, pc152.1b202.jt.u-tokai.ac.jp, pc153.1b202.jt.u-tokai.ac.jp と自班の pcA1.1b202.jt.u-tokai.ac.jp, pcA2.1b202.jt.u-tokai.ac.jp, pcA3.1b202.jt.u-tokai.ac.jp, pcA4.1b202.jt.u-tokai.ac.jp に対して nslookup を実行し,結果を確認せよ.

ping pc151.1b202.jt.u-tokai.ac.jp

を実行し,IP アドレスではなく DNS 名で ping が可能なことを確認せよ. 同様に自班の稼働している計算機に対して DNS 名を指定して ping を行え.

参考:実習1の教卓の設定

実習 1 用 named.conf.local

実習 1 用 db.1b202

実習 1 用 db.17

実習 2.

実習 2. では,各班の pcA1 でネームサーバを起動し, 自分の班のホストからなるゾーンを管理する.

DNS サーバのインストール

各班の pcA1 に DNS サーバである bind9 をインストールする.

今回は Synaptic パッケージマネージャを使う代わりにターミナルからのコマンド でインストールを行う方法を説明する.ターミナルを起動し,以下のコマンドを入力せよ.

nauser@na-000:~$ sudo apt-get update

apt コマンド群はソフトウェアの依存関係を管理し,あるソフトウェアをインストールしたい 時に必要なソフトウェアをチェックし,自動的にインストールするためのシステムである. Synaptic はこれを GUI を通して利用するソフトウェアである. apt-get update は Synaptic における「再読み込み」ボタンを押すことに相当する.

bind9 パッケージをインストールするには以下のコマンドを入力する. インストール後,自動的にサーバは稼働状態になる.

nauser@na-000:~$ sudo apt-get install bind9

計算機管理作業を業務として行う場合は CUI で作業を行う利点がある.

実習 2. は教卓のネームサーバから 各班の pcA1 へ権威を委任する設定に変更した後行う.合図があってから 以下の実習を進めよ.

A を各班の班番号の 2 桁表現とすると,実習室全体のドメイン 1b202.jt.u-tokai.ac.jp のサブドメインとして班の数だけ サブドメイン gA.1b202.jt.u-tokai.ac.jp を作る. pcA1, pcA2, pcA3, pcA4 の完全ドメイン名はそれぞれ pcA1.gA.1b202.jt.u-tokai.ac.jp, pcA2.gA.1b202.jt.u-tokai.ac.jp, pcA3.gA.1b202.jt.u-tokai.ac.jp, pcA4.gA.1b202.jt.u-tokai.ac.jp となる.教卓サーバの担当ドメインのうち,各班にあたる gA.1b202.jt.u-tokai.ac.jp サブドメインを,それぞれの班の 1 号機 pcA1.gA.1b202.jt.u-tokai.ac.jp に委任するように教卓側で設定する. pcA1 で稼働しているネームサーバで pcA1.gA.1b202.jt.u-tokai.ac.jp, pcA2.gA.1b202.jt.u-tokai.ac.jp, pcA3.gA.1b202.jt.u-tokai.ac.jp, pcA4.gA.1b202.jt.u-tokai.ac.jp の IP アドレスが解決できるように設定する.

pcA1 にインストールされた DNS サーバである bind9 の最も基本的な 設定ファイルは /etc/bind/named.conf である.これは以下の内容になっている (// で始まる行はコメントなので省略)

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

上記 3 つのファイルを読み込むという設定である. 今回は named.conf.local に設定を追加する.

今回は gA.1b202.u-tokai.ac.jp ドメイン に対する問い合わせを処理する設定を行う.このドメインに対する 問い合わせの答えを記述するファイルを /etc/bind/db.gA とする. この場合以下の行を named.conf.local の最後に挿入する必要がある.

zone "gA.1b202.jt.u-tokai.ac.jp" {
        type master;
        file "/etc/bind/db.gA";
};

最後に /etc/bind/db.gA を記述する.このファイルの内容は以下の ようにすればよい.図中のWWWXXXYYYZZZ はそれぞれ pcA1,pcA2,pcA3,pcA4 の IP アドレスとする.

$TTL    604800
@       IN      SOA pcA1.gA.1b202.jt.u-tokai.ac.jp. root.pcA1.gA.1b202.jt.u-tokai.ac.jp. (
                2013061001  ; Serial
                    604800  ; Refresh
                     86400  ; Retry
                   2419200  ; Expire
                    604800 ); Negative Cache TTL
;
@       IN      NS      pcA1.gA.1b202.jt.u-tokai.ac.jp.
pcA1    IN      A       172.17.2.WWW
pcA2    IN      A       172.17.2.XXX
pcA3    IN      A       172.17.2.YYY
pcA4    IN      A       172.17.2.ZZZ

図 9.4 db.gA

named.conf.local からこのファイルが使われるのは gA.1b202.jt.u-tokai.ac.jp ドメインへの問い合わせがあったときである. 上記の "@" は問い合わせのドメイン gA.1b202.jt.u-tokai.ac.jp を表す省略記法である.

SOA(Start of Authority)レコードの意味は, pcA1.gA.1b202.jt.u-tokai.ac.jp が問い合わせドメイン(gA.1b202.jt.u-tokai.ac.jp) のネームサーバであること,root@pcA1.gA.gA.1b202.jt.u-tokai.ac.jp がこのドメインの管理者のメールアドレスであること,シリアル番号が 2013061001 であること(日付の後に更新番号を書いたものとすることが多い)を示す. ドメイン名の最後にピリオドがある場合は完全ドメイン名であることを示し, ピリオドがない場合(この例では最後の 4 行のpcA2, pcA3, pcA4 )は担当ドメイン .gA.1b202.jt.u-tokai.ac.jp が後ろに付加される.その他の数値は 一度得た情報の有効期間等の制御に使う数値である.ドメイン名の最後にピリオドが あるかないかで全く意味が異なるので注意を要する.

図 9.4 の

@       IN      NS      pcA1.gA.1b202.jt.u-tokai.ac.jp.

の行は NS レコードとよばれ, @ つまり gA.1b202.jt.u-tokai.ac.jp のネームサーバが pcA1.gA.1b202.jt.u-tokai.ac.jp であることを示す.

pcA1    IN      A       172.17.2.WWW(pcA1 の IP アドレス)
pcA2    IN      A       172.17.2.XXX(pcA2 の IP アドレス)
pcA3    IN      A       172.17.2.YYY(pcA3 の IP アドレス)
pcA4    IN      A       172.17.2.ZZZ(pcA4 の IP アドレス)

の行は A レコードとよばる.最初の項目のドメイン名がピリオドで終わっていないので 当該ドメイン名が後に付加される.結局 pcA1.gA.1b202.jt.u-tokai.ac.jp, pcA2.gA.1b202.jt.u-tokai.ac.jp, pcA3.gA.1b202.jt.u-tokai.ac.jp, pcA4.gA.1b202.jt.u-tokai.ac.jp の IP アドレスを記述している.最初に名前解決を依頼したホストは 最終的にこのレコードにたどり着くことで IP アドレスを得る.

db.gA ファイルを変更した場合は シリアル番号を 1 増やして保存し, 以下のコマンドで bind9 を再起動する.

nauser@na-000:~$ sudo service bind9 restart

bind9 の起動,再起動に失敗したときは /var/log/syslog にログが残るので 確認せよ.

bind9 を再起動してもシリアル番号が増加していないと変更は 反映されない.この授業ではシリアル番号を 8 桁の変更日 と末尾 2 桁のその日の中でのバージョン番号で構成することで, 変更後に値が増加するように管理する.

ここまでの設定が完了すれば pcA1 のネームサーバの働きにより pcA1.gA.1b202.jt.u-tokai.ac.jp, pcA2.gA.1b202.jt.u-tokai.ac.jp, pcA3.gA.1b202.jt.u-tokai.ac.jp, pcA4.gA.1b202.jt.u-tokai.ac.jp の名前解決ができるはずである.(ネームサーバは 172.17.2.60 のまま変更なし) nslookup を用いて確認せよ.

nslookup で正しい IP アドレスの取得ができていることを確認した後, 自班の稼働している計算機に対して DNS 名を指定して ping を行え.

参考:実習2の教卓の設定

named.conf.local は実習 1 と同じ

実習 2 用 db.1b202

実習 2 用 db.17

課題

第 8 回課題「DNS基本設定」 を提出せよ.


Updated in June 12, 2010, index.html, Yamamoto Hiroshi