佐藤 緩奈（地球および惑星大気科学研究室 B4） DNS 佐藤 緩奈（地球および惑星大気科学研究室　B4） 一元的　様々な減少がひとつの根本的原理によって 成り立つこと 3/1/2017 フッター

もくじ DNS とは DNS の役割 DNS のしくみ ドメイン名空間 権限委譲 ゾーンとレコード 名前解決のながれ 正引き 逆引き ITPASS サーバの DNS に関する仕事 まとめ hostsファイルのような対照表を管理する専用サーバ＝DNSサーバ（ネーム・サーバ）に情報を集約して、名前解決が必要なクライアントやアプリケーションから問い合わせをさせよう、という発想である。これにより、データ管理はDNSサーバだけで行えばよいことになる 2 2

Domain Name System の略 ドメイン名と IP アドレスを対応づける(名前解決)ためのしくみ 3 DNSとは Domain Name System の略 ドメイン名と IP アドレスを対応づける(名前解決)ためのしくみ 　　　　　ドメイン名・・・人間用のインターネット上の住所 　　　　　　　　　　　　　例＜itpass.scitec.kobe-u.ac.jp＞ 　　　　　IP アドレス・・・機械用のインターネット上の住所 　　　　　　　　　　　　例＜133.30.109.22＞ 3 3

・各クライアントごとに hosts ファイル（単純な対照表）で情報を管理 DNSの役割 DNS 登場以前の初期のネットワーク ・インターネットのように不特定多数が参加することを考慮する必要がなかった ・ネットワークの規模も小さかった ・各クライアントごとに hosts ファイル（単純な対照表）で情報を管理 (例) 127.0.0.1       localhost 192.168.1.10    host1 192.168.1.1     gw 10.1.210.10     www

DNSの役割 インターネットという規模になると ・不特定多数のホストが参加 ⇒ 各ホストに名前解決の情報を持たせることは非現実的 ・接続する機器が増える度に hosts ファイルを書き直す必要がある ・ホストの IP アドレスが変わる度に書き直す必要がある ⇒ユーザの負担があまりにも大きくなってしまう ⇒もっと一元的な方法が必要 　　　　DNS の導入 DNS　によるデータ管理 ・hosts のような対照表を管理する, 専用のサーバ (DNS サーバ) に 　情報を集約し，各ホストが問い合わせをする．

6 DNSの役割 名前解決の課題 世界中の登録されたホストの名前が被らないようにしなければならないので ホスト命名規則を用いて, ユニーク性を保証することが必要 ⇒ ドメイン名空間(ドメインツリー)の導入 6 6

DNSのしくみ DNSの命名規則 ドメイン名 「インターネット上の住所表示」 URL（ホームページのアドレス）やメールアドレスなどの一部分として使われており、インターネット上のコンピュータを識別するための名前 引用　http://atnetwork.info/tcpip2/tcpip209.html

DNSのしくみ DNSツリー構造（ドメイン名空間） その構成は、ルートを頂点とした階層構造を持っており, 「.」で いくつかの階層に区切られる。 (例) www.yahoo.co.jp 最上部：ルートDNSサーバー トップレベルドメインと呼ばれるDNSサーバー トップレベルドメインと呼ばれるDNSサーバー 第２レベルドメインと呼ばれるDNSサーバー 第３レベルドメインである各組織のDNSサーバー 引用　http://win.kororo.jp/archi/tcp_ip/dns.php

「yahoo.co.jp」など、上位ドメイン名を付けたものと区別す DNSのしくみ　ノード ルート 枝分かれで階層になっている部分が「ドメイン」で, 「yahoo.co.jp」など, 上位ドメイン名を付けたものと区 別するために 「ノード」とも呼ばれる. com fr jp ac ne co Kobe-u eng scitec 「yahoo.co.jp」など、上位ドメイン名を付けたものと区別す るために「ノード」とも呼ばれる。 itpass itpass :ノード 9 9

各ノードでは, 自身の管理するドメイン内情報と下位のドメインの DNS サーバの情報しか分からないので, クライアントが DNS に問い合わせる際には 階層を上位から順にたどる必要がある. 引用　http://atnetwork.info/tcpip2/tcpip209.html

DNSのしくみ 各階層ごとにグループとしての意味を持たせ下位のドメインやホスト名 を管理する分散型の構造になっている.⇒負荷分散 　各階層ごとにグループとしての意味を持たせ下位のドメインやホスト名　　 を管理する分散型の構造になっている.⇒負荷分散 　　ドメイン以下のことはそれぞれの組織に任せてしまった方が管理効率　　 は向上するため, 上位ドメインからサブドメインに対する「管理権限の　　　 委譲」を行う 権限委譲とは ドメインを複数のサブドメインに分割し, それぞれのサブドメインに関する 管理を委任すること (例)　yahoo.co.jpドメインは, co.jpドメイン（を管理するDNSサーバ）から管 理権限を委譲されている.

12 DNS のしくみ - ゾーンとレコード 「ゾーン」 DNS サーバがドメインを管理する範囲 「レコード」 ゾーンに含まれるデータの単位.ホスト名と IP アドレスの対応の情報だけでなく, ホスト名のエイリアス（別名）など様々な情報を扱う. DNS のしくみ - ゾーンとレコード 引用　http://www.atmarkit.co.jp/fnetwork/dnstips/008.html 12

CNAME Canonical NAME」つまり「標準名」 教会法の MX mail exchange レコード 代表的なものは以下の 6 種類 A ホスト名から IP アドレスへの対応 PTR IP アドレスからホスト名への対応 NS ドメインの DNS サーバ名を指定する SOA ゾーン（ドメイン）情報を記載する CNAME ホスト名の別名(エイリアス)を正規名へ変換する MX ドメインとメールアドレスを対応付ける A address PTR pointer NS name server SOA start of authority CNAME Canonical NAME」つまり「標準名」 教会法の MX mail exchange 3/1/2017 フッター

NSレコード ドメインとそのドメインの DNS サーバを指定するレコード.このレコードによって, サブドメインの存在とその DNS サーバへ権限委譲が確認できる. ドメイン名 TTL 　　　ネットワーククラス NSレコード 　　DNSサーバ名 　. 　　　29145 　　　　 IN 　　　 NS 　　　A.ROOT-SERVERS.NET. (例１) ルートドメイン（.）の担当が DNS サーバ「A.ROOT-SERVERS.NET.」であることを表している. DNS サーバ dns.my_domain.co.jp. 内のゾーン定義ファイルには「my_domain.co.jp. は自分の管理だ」ということを示すために NS レコードを記述する。 一方で、ドメイン「co.jp.」側から見れば「my_domain.co.jp.」はサブドメインですから、DNS問い合わせを適切に導かなくてはなりません。そこで「co.jp.」を管理している DNS サーバ内のゾーン定義ファイルでは、「co.jp. ドメイン空間の一部である my_domain.co.jp. サブドメインは dns.my_domain.co.jp. の担当だ」ということを示すために NS レコードを記述します。

SOAレコード ゾーン（ドメイン）情報を記載する @ IN　 SOA　　 dns.company.co.jp.　　　postmaster.company.co.jp. （20091218001 ; Serial 　　　　　　10800 ; Refresh 　　　　　　　3600 ; Retry 　　　　　604800 ; Expire (例) 引用　http://atnetwork. info/tcpip2/tcpip211.html ●MNAME(dns.company.co.jp.)　　　　　　　ドメインを管理するDNSサーバ名を表す　　 ●RNAME(postmaster.company.co.jp.)　　ドメイン管理者のメールアドレス.「＠」の代わりに「.」を使う ●SERIAL（シリアル番号）　　　　　　　　　　　ゾーンファイルのバージョンを表す数字.この数字が大きい　　　　　　　　　　　　　　　　　　　　　　　　　　　ほど新しいバージョンであることを意味する. 以下３つはセカンダリDNSサーバがプライマリのネームサーバから入手したゾーン情報を, どう扱うかを指定するもの。各データはそれぞれ秒数で指定される. ●REFRESH（更新間隔）　　　　　　　　　　　　ゾーン情報をリフレッシュするまでの時間を秒で指定する. ●RETRY（転送再試行時間）　　　　　　　　　　REFRESHでゾーン情報の更新ができなかった場合に,　　　　　　　　　　　　　　　　　　　　　　　　　　　　再試行を試みる周期を秒で指定する. ●EXPIRE(レコード有効時間)　　　　　　　　　ゾーン情報のリフレッシュができない状態が続いた場合の　　　　　　　　　　　　　　　　　　　　　　　　　　　ゾーン情報の有効時間を秒で指定する. 権威を持つDNSサーバ以外のDNSサーバでは、一 度応答したDNSクエリを保存し、次回同様の問い合 わせが来た際に、自らが保存しているデータから返 答することで、レスポンス速度を向上させています。 このデータを保存することをキャッシュといいます。 シリアル番号：BINDでは「日付+通し番号 :YYYYMMDDXX」の形式が一般的です。 リフレッシュとは　DHCPサーバーからネットワーク設 定情報を取得し直すこと Dynamic Host Configuration Protocol インターネットなどのネットワークに一時的に接続す るコンピュータに、IPアドレスなど必要な情報を自動 的に割り当てるプロトコル。

DNS サーバの種類 プライマリDNS とセカンダリDNS 「キャッシュ」という機能です。 DNSサーバは一度検索した内容を一定期間記憶しておき ます。これを「キャッシュ」と言います。たとえば、一度 www.so-net.ne.jpを検索すると、次にxxx.ne.jpを検索した 場合、「．（ルート）」や「.jpのDNSサーバ」に問い合わせを かけず、直接「.ne.jpのDNSサーバ」に問い合わせを行いま す。 また、www.so-net.ne.jpを検索した後に、再度www.so- net.ne.jpを検索した場合、 パソコンが参照しているDNS サーバは、DNSの問い合わせを行わずに「キャッシュから」 前回の検索結果と同じ結果を返します。 この機能により、上位のDNSサーバの負荷を軽減していま す

ゾーン転送 ゾーン転送では, SOA レコード中の Serial の値が大きくなっていれば更新されていると見なしてゾーン転送を開始する. 管理者がプライマリDNSにゾーン情報を設定しておけば, 後は自動的に他のセカンダリDNS に反映されるようになっている. 引用 http://atnetwork.info/tcpip2/tcpip215.html

A(adress) レコードと PTR(pointer) レコード 正引き・・・ホスト名から IP アドレスを求めること（A レコード） 逆引き・・・IP アドレスよりホスト名を求めること（PTR レコード） 引用　http://win.kororo.jp/archi/tcp_ip/dns.php

A(adress) レコード 正引きの方法 DNS の名前解決は, ドメインツリーに沿って行われる. Web ブラウザがユーザーに URL を入力されて, DNS サーバが A レコード情報を返答するとそのホスト名から IP アドレスを取得できる.

正引きの方法 （例）｢www.calbee.co.jp｣ ホスト名から IP アドレスを求める 　　　 「ルート」や 「.（ドット）」 で表現されるルートドメインが存在する. ☆問合せの流れ 　「ルートネームサーバ」 →「.jp ドメインの DNS サーバ」 →「.co.jp ドメインの DNS サーバ」 →「calbee.co.jp ドメインの DNS サーバ」 正引きの方法　

21 名前解決のながれ 再帰検索と反復検索 ルート jp co.jp company.co.jp www.company.co.jp 名前解決のながれ　再帰検索と反復検索 クライアントが問合せを行う DNS サーバと, ドメインツリー上の DNS サーバでは, 振舞い方が違う. 反復検索 自身が管理しているゾーン情報のみ返答し, 他のサーバへ問い合わせを行わない. ＊「company.co.jp」から上位の DNS サーバが行う動作. 再帰検索 名前が解決するまで他のサーバに対して検索を行い，最終結果を返させる． ＊クライアントが問合せを行う「dns.shop.co.jp」の　DNS サーバが行う動作 ルート jp dns.shop.co.jp 利用者 co.jp company.co.jp www.company.co.jp 21 21

リゾルバ リゾルバ（resolver） ドメイン名を元にIPアドレスの情報を検索したり, IP アドレスからドメイン名の情報を検索する名前の解決（name resolution）を行うクライアント フルサービス・リゾルバ 「dns.shop.co.jp」のように再帰検索によって完全に DNS 解決を行えるリゾルバ スタブ・リゾルバ 「dns.shop.co.jp」などへ要求を送るだけのDNSクライアント（多くの場合は, 皆さんが使用しているクライアントPCやメール・サーバなど） スレーブサーバ 他の DNS サーバからドメインに関する情報をコピーして利用するタイプの DNSサーバ.元になる DNS 情報を提供してくれるサーバをマスタサーバと呼ぶ.スレーブサーバは, データのバックアップや負荷の分散を目的としている. 勝手なスレーブサーバ構築などに対処する方法とし て、ゾーン転送の制限がある。 ゾーン転送を制限し てしまえば、ゾーン情報（具体的には db.sample の ような定義ファイルの内容）を読み出すことができなく なる。

逆引きの方法 ログにアクセス元のIPアドレスしか分からなかったら どうでしょうか？ 逆引きの方法　 逆引きとは…DNS を使って IP アドレスからドメイン名を求めること （例） IPアドレス　「192.168.1.10」　では　「10.1.168.192.in-addr.arpa」と表記 逆順 逆引きのゾーンを表すサブドメイン名 逆引き用のドメインツリー 「DNS の逆引き」のメリット ・サーバのログ解析などに便利 デメリット ・サーバ側で逆引きできないとアクセスをさせない設定をしているところがある ・DNS への負荷が大きくなる ・逆引き登録されていないホストからは spam メールで無くても受け取ることが出来ない ログにアクセス元のIPアドレスしか分からなかったら どうでしょうか？ 　IPアドレスだけでは、単なる数字の羅列で、どのコ ンピュータからアクセスしてきたのか、どのサイトから アクセスしてきたのかを分析する際に便利が悪いで す。 ログ解析とは 自社のウェブサイトに訪問した人が、「どこから訪れ たか」や、「サイト内での行動履歴」、各ページの 「ページビュー」や「ユニークユーザー数」などを解析 すること。 引用　http://www.atmarkit.co.jp/fnetwork/rensai/dns01/dns01.html

24 ITPASS サーバの DNS に関する仕事 フルサービスリゾルバである キャッシュ専用 DNS サーバ キャッシュ専用 DNS サーバーは、他の DNS サーバからすべての DNS 情報を取得する． ある一定の時間、以前問い合わせた内容を保存しておく． ゾーン転送を実行しない． どのゾーンについても権限を及ぼさない． 24 24

25 キャッシュに以前の問い合わ せが残っている場合は直接答 えを返す． DNS 情報がない場合には他 の DNS サーバにききにいく． ITPASS サーバの DNS に関する仕事 www.google. co.jp?のIPアドレスは何? キャッシュに以前の問い合わ せが残っている場合は直接答 えを返す． DNS 情報がない場合には他 の DNS サーバにききにいく． ルート www.google.co.jp は 66.249.89.104 jp ac kobe-u www.google.co.jp は 66.249.89.104ですよ scitec 25 25

26 まとめ DNS とは ドメイン名と IP アドレスを対応付けるしくみのこと． ドメイン名空間 ルート(根)とドメイン(枝)からなる木構造．これによってネームサーバの負担やホスト名の 一意性などの問題を解決． レコード －　ホスト名と IP アドレスの対応などの情報を扱うデータの単位 名前解決 ツリー構造をたどり, 各DNSサーバに問い合わせる ITPASS サーバは… DNS に関してはキャッシュ専用サーバとして機能 26 26

27 参考文献 2011 ITPASS セミナー「DNS」のおはなし」 https://itpass.scitec.kobe-u.ac.jp/seminar/lecture/fy2011/111028/pub/ ・　2010 ITPASS セミナー「DNS」 https://itpass.scitec.kobe-u.ac.jp/seminar/lecture/fy2009/091016/pub/ DNS の仕組みの基本を理解しよう http://www.atmarkit.co.jp/fnetwork/rensai/dns01/dns01.html ・　DNS Tips http://www.atmarkit.co.jp/fnetwork/dnstips/index.html ・　Network Cisco http://atnetwork.info/tcpip2/tcpip214.html ・　Server Architecture http://win.kororo.jp/archi/tcp_ip/dns.php ・　キャッシュ専用 DNS サーバ http://publib.boulder.ibm.com/html/as400/v4r5/ic2962/info/RZAISCACHEO.HTM ・　DNSの概要 ドメインとゾーン ネームサーバ 委任 http://park12.wakwak.com/~eslab/pcmemo/dns/index.html 27 27

28 付録: ルートサーバの運用機関 http://www.nic.ad.jp/ja/dom/system.html 28 ルートサーバー 運用組織 所在地 A VeriSign, Inc. 米国バージニア州 B 南カリフォルニア大学情報科学研究所(ISI) 米国カリフォルニア州 C Cogent Communications D メリーランド大学 米国メリーランド州 E 米航空宇宙局(NASA)エイムズ研究所 F Internet Systems Consortium, Inc.(ISC) G 米国防総省ネットワークインフォメーションセンター H 米陸軍研究所 I Autonomica ストックホルム J K Reseaux IP Europeens -Network Coordination Centre(RIPE NCC) ロンドン L Internet Corporation for Assigned Names and Numbers(ICANN) M WIDEプロジェクト 東京 http://www.nic.ad.jp/ja/dom/system.html 28 28

ご静聴ありがとうございました。 29 29