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