1. No category

1
学生実験
5日目
DNS
IPネットワークアーキテクチャ
江崎研究室
2
DNS
Domain Name System
インターネット上の名前解決を実現
正引き
www.ee.t.u-tokyo.ac.jp
157.82.13.244
逆引き
3
名前空間
インターネットで唯一
ドメイン＝名前空間内の範囲
www.ee.t.u-tokyo.ac.jp の場合
. (root)
jp
ac
keio
com
u-tokyo
t
co
org
i
ee
www
fr
kr
go
mixi
info
4
ドメインの階層構造
. (root)
TLD (Top Level Domain)
com
fr
jp
info
org
SLD (Second Level Domain)
mixi
第3レベルドメイン
co
ac
co
waseda
u-tokyo
keio
s
t
i
arch
ee
keisu
www
5
DNSの動作原理
query
resolver
reply
DNSサーバ
DNSクライアント
6
課題(1) 動作確認
インターネットに接続されたホストにて、URLの
ホスト部の最も右に “.” を付けてウェブブラウ
ズした時に、ブラウザの挙動が異なるかどうか
確認しなさい。また、同様に、pingやその他のア
プリケーションを用いた場合の動作も確認しな
さい。
7
名前空間における検索
“.” root server
4
5
“jp” server
6
7
Cache
Server
2
8
10
1
3
12
9
11
“t.u-tokyo.ac.jp” root server
“ee.t.u-tokyo.ac.jp” server
resolver
詳細は教科書を参照すること
8
課題(2) リゾルバの確認
リゾルバ上のキャッシュサーバのIPアドレスは、UNIX
システムでは “/etc/resolv.conf” に登録されてい
る。このファイルを確認すること。また、このファイルを
編集し、誤ったIPアドレスが指定された場合、インター
ネットの利用にどのような影響が発生するか予想し、
実際に確認しなさい。
/etc/resolv.conf の編集方法:
/etc/resolvconf/resolv.conf.d/base に設定を記述（例: nameserver 8.8.8.8）
sudo resolvconf –u で/etc/resolv.confに反映される
9
DNSは分散データベース
それぞれのドメインを個別のDNSサーバが管理
ドメインごとにDNSサーバが必要になる
. (root)
jp
ac
keio
com
u-tokyo
t
co
org
i
ee
www
fr
kr
go
mixi
info
10
管理権限の委譲（delegation）
Zone delegation
u-tokyo zone コンテンツサーバ
Zone delegation
t zone コンテンツサーバ
Zone delegation
ee zone コンテンツサーバ
Zone delegation
u-tokyo ゾーン管理者による管理範囲
管理権限の委譲
t ゾーン管理者による管理範囲
管理権限の委譲
ee ゾーン管理者による管理範囲
11
プライマリ＆セカンダリ
DNSサーバが一台だと心許ない
プライマリDNSサーバ
a.k.a. マスターサーバ
オリジナル
ゾーンファイル
セカンダリDNSサーバ
a.k.a. スレーブサーバ
ゾーン転送
どちらかに問い合わせれられればOK
リゾルバ
コピー
ゾーンファイル
12
課題(3) digコマンドの利用
リゾルバとして稼働するホスト上で、名前解決
専用アプリケーション(dig)を利用して、DNSの
検索クエリを発行できる。digコマンドを利用し
てリゾルバとキャッシュサーバ間の通信を確認
しなさい。同時にwiresharkを実行し、どのような
パケットが流れているか確認しなさい。
13
課題(4) 名前解決の流れ確認
リゾルバとして稼働するUNIXシステムで、一時
的にキャッシュサーバの機能を扱えるdnstracer
を利用し検索状態を把握し、再帰的な検索が
行われていることを確認しなさい。
14
課題(5) DNSサーバの実行
リゾルバ、キャッシュサーバ、コンテンツサーバは、実態ではな
く機能なので、それぞれの機能を同一のホストで稼働させられ
る。
1) 各自のPCにDNSサーバ(bind)をインストールし、リゾルバ
キャッシュサーバが同時に稼働する構成にしなさい。
2) リゾルバより、検索クエリをキャッシュサーバに投げかけ、
キャッシュサーバが再帰的に検索することを確認しなさい。
また、キャッシュサーバが検索結果をキャッシュすることを
確認しなさい
15
キャッシュサーバの設定(1)
Bind9のインストール：
# apt-get install bind9
キャッシュサーバの設定：
/etc/bind/named.conf.optionsを編集
再帰検索を許可するよう設定する
編集例は実験webページの
TIPSを参照
設定ファイルのチェック：
$ named-checkconf /etc/bind/named.conf
Bind9の再起動：
# /etc/init.d/bind9 restart
次のスライドに続く
16
キャッシュサーバの設定(2)
キャッシュサーバの動作確認：
$ dig @127.0.0.1 [適当なドメイン]
キャッシュ状況の確認：
同じアドレスを複数回digした時に流れるパケットの様子を
tcpdumpやwiresharkで確認する
注) そのために存在するが滅多にアクセスしない名前を検索すること
17
課題(6) 規模性
DNSは階層構造を利用することで規模性を確
保できる。これをどのように実現しているか考察
しなさい。
18
課題(7) コンテンツサーバの設定
各自のPCでコンテンツサーバを設定しなさい。
19
コンテンツサーバの設定(1)
ゾーンの登録：
/etc/bind/named.conf を編集
ゾーンファイルを編集：
/etc/bind/master/zone を作成、編集
編集例は実験webページの
TIPSを参照
注) 後から再度編集する際は Serial の値に注意
設定ファイルのチェック：
$ named-checkzone (チェック対象のドメイン) /etc/bind/master/zone
Bind9の再起動：
# /etc/init.d/bind9 restart
次のスライドに続く
20
コンテンツサーバの設定(2)
Apache2のインストール：
# apt-get install apache2
コンテンツの準備：
/var/www/index.html を編集
ブラウザでhttp://localhost/index.htmlを指定して表示できるか確認
コンテンツサーバの動作確認：
自分または他のPCのブラウザから
ゾーンファイルで指定したドメインでコンテンツが表示できるか確認
21
SOAレコード
• Start of Authority
–
–
–
–
–
–
–
ゾーンにおけるプライマリサーバの指定(FQDNで)
ゾーン管理者のメールアドレス（”@””.”）
SERIAL…データベースのバージョン番号
REFRESH…セカンダリの更新確認間隔
RETRY…REFRESHに失敗したときの再試行周期
EXPIRE…セカンダリのデータ保持期間
MINIMUM…リソースレコードのデフォルトTTL
22
課題(8) レコードタイプの調査
教科書に載っているAレコード、AAAAレコード、NSレ
コード、SOAレコードの他にも様々なレコードタイプが
ある。他にどのようなレコードタイプがあるか調べなさ
い。また、それらのレコードタイプを各自のコンテンツ
サーバに設定し、利用してみなさい。
23
リソースレコード(RR)とレコードタイプ (抜粋)
レコードタイプ
意味
A
IPv4アドレス
AAAA
IPv6アドレス
NS
ドメインに対するDNSサーバの指定
SOA
ゾーン情報に対するパラメータの設定
CNAME
エイリアス
MX
ドメインに対するメールサーバの指定
PTR
逆引き用のホスト名
24
課題(9) 逆引きの調査
逆引きにはPTRレコードを利用するが、逆引き
がどのように動作するか調べなさい。