DNSについて
日時:
ドメインとドメイン名とその構造
example.comやwww.example.co.jpのような文字列はドメイン名と呼ばれる.人間にとって比較的分かりやすいドメイン名にIPアドレスを紐づけることで,そのサーバをドメイン名で見つけられる.
- ドメイン名はURLやメールアドレスの中に見ることができる.
- https://example.com や [email protected]など
- .(ドット)で区切られたjp,co,exampleというそれぞれの文字列をラベルといい,それらが指し示す領域(名前空間)のことをドメインという.
- ドメイン名の最後にもルートドメイン(後述)を表す.が存在するが,しばしば省略する.「www.example.co.jp.」というのが省略しない形.ルートドメインのラベルは長さ0の文字列.
- ドメインはルートドメインを頂点とする木構造を作る.ドメイン名は各ドメインを識別するための文字列になっている.ドットの左のラベルが指すドメインがそのドットの右のラベルが指すドメインの子になっている.
- あるドメインに対してその子孫のドメインのことをそのサブドメインという.
- 例:www.example.co.jpではexampleが示すドメインはjpのサブドメイン.jpが示すドメインはルートドメインのサブドメイン.
- ドメイン名は大文字小文字を区別しない.example.comもExAMplE.CoMも同じ.
TLD(Top Level Domain)とはドメイン名の一番最後につくcomとかnetなどで表される(ルードドメインのちょうど一つ下の)ドメインのこと.
- gTLD (Generic top-level domains) は一般的な?TLD(例:com,net,org,info)のこと.誰でも取れるものが結構ある.業種制限などで取れないものもある.
- ccTLD (Country code top-level domain) は国を表しているTLD(例:jp,uk,de)のこと.その国の居住実態が必要なものも多いが,その中の一部(meなど)はその国に住んでなくても取れるようになってる.
TLDの子のドメイン(*.example.comだったらexampleのドメイン)は2LD(セカンドレベルドメイン)と呼ばれる.
- ここに属性を意味する文字列を付けているもの(jpドメインなら*.ac.jp,*.co.jp,*.lg.jpなど)もある.これらはそれ相応の組織じゃないと登録できない.
- 同様にexample.co.jpのexampleは3LD(サードレベルドメイン)と呼ばれる.
ゾーンについて
そのドメイン名をネットワークで使えるようにするための仕組みとして,DNSがある.
DNSではドメインの木構造に合わせた管理・委任の仕組みを備えている.全てのドメインの情報を一元的に一か所で管理するわけではなく,各ドメインに対応させて情報を分散管理させる仕組みになっている.
- abc.example.comを例にとる.ルートドメインの管理者が全てのドメインとIPアドレスの対応の情報を持っているわけではない.example.comのようなcomドメイン以下の情報はすべてcomドメインの管理者に委任している.「com以下のドメインの情報はcomドメインの管理者に任せている」という情報はルートドメインの管理者が保持する.
- 一方で,comドメインの管理者もすべてのcomドメインのサブドメインの情報を管理しているわけではなく,同様にexample.com以下のドメインに関してはexample.comの管理者に管理を委任している.「example.com以下のドメインの情報はexample.comドメインの管理者に任せている」という情報はcomドメインの管理者が保持する.
- example.comのドメインの管理者はabc.example.com以下のドメインを別の管理者に委任しているかもしれないし,そうでないかもしれない(設定による).いずれにせよ,このように情報の管理は階層化されている.
- このように,DNSの委任によって区切られた管理の単位をゾーンという.
- ごちゃごちゃ書いたが,ゾーン,ドメイン,ドメイン名についての説明はJPRS用語辞典(https://jprs.jp/glossary/)の図がわかりやすい.
- この委任によって生まれたゾーンも木構造を作る.
- 各ゾーンに対し,そのゾーンの情報と委任したゾーンの委任情報はそのゾーンの権威サーバによって保持される.
権威サーバはそのゾーンの情報と委任したゾーンの委任情報をリソースレコード(各ドメインに関連付けられた情報)として保持する.
リソースレコードの概要
例えばcomドメインを含むゾーンの権威サーバでの
- example.comに関する情報は委任しており,委任先の権威サーバはns1.example.comとns2.example.comである(注:普通は複数ある).
- ns1.example.comのIPv4アドレスは192.0.2.59でIPv6アドレスは2001:db8:94d2::d12:2023
- ns2.example.comのIPv4アドレスは192.0.2.60でIPv6アドレスは2001:db8:94d2::d12:2024
といった内容を含んだリソースレコードをテキスト形式で表すと以下のようになる.
example.com. 86400 IN NS ns1.example.com.
example.com. 86400 IN NS ns2.example.com.
ns1.example.com. 86400 IN A 192.0.2.59
ns2.example.com. 86400 IN A 192.0.2.60
ns1.example.com. 86400 IN AAAA 2001:db8:94d2::d12:2023
ns2.example.com. 86400 IN AAAA 2001:db8:94d2::d12:2024
一般に,リソースレコードをテキスト形式で表すと以下のようになる.
NAME TTL CLASS TYPE RDATA
- NAME:このリソースレコードに関係するノードの名前.多くはドメイン名が入る.
- TTL:このリソースレコードをキャッシュして良い時間.秒単位.
- CLASS:プロトコル群を指定する.基本IN.
- TYPE:リソースレコードの種類.いっぱいある.例を挙げる.
- A:NAMEのIPv4アドレスを指定.
- AAAA:NAMEのIPv6アドレスを指定.
- NS:NAMEのゾーンの権威サーバを指定.
- RDATA:TYPEやCLASSに応じたそのデータ.
名前解決
DNSの重要な役割の一つにドメイン名から対応するIPアドレスを見つけ出す名前解決がある.名前解決の流れは以下のとおり.
- 基本的な3つの構成要素
- スタブリゾルバ:ブラウザなどに名前解決の手段を提供する.ただし,これが直接名前解決をするわけではなく,名前解決を次のフルリゾルバに依頼する(名前解決要求).普段使っているPC上のOSに大体入っている.この三つの中では利用者に一番近いところにある存在.
- フルリゾルバ:DNSにおける名前解決を行う.二つの役目がある.
- スタブリゾルバから名前解決要求(後述の手順の2番)を受けたら,名前解決をし,その結果をスタブリゾルバに返す.
- 名前解決の結果を蓄える(キャッシュする).
- 権威サーバ(先述したもの):自分が委任を受けたゾーンの情報と自分が委任したゾーンの委任情報を持つ.jpドメインやルートドメインを管理している権威サーバのほうがより多くの情報を管理するために,より重要.ルードドメインを管理するルートサーバは世界に13クラスタだけ存在する(参考:ルートサーバ https://jprs.jp/glossary/index.php?ID=0100).
いくつか別の名称もある.
- フルリゾルバ:キャッシュDNSサーバ,ネームサーバ,DNSサーバ
- 権威サーバ:権威DNSサーバ,ゾーンサーバ,ネームサーバ,DNSサーバ
www.example.comというドメインを例にした,名前解決の手順とそれを表した図のは以下のようになる.
| |--------->| .ドメイン(ルートドメイン)の
| |<---------| 権威サーバ
| |
| |--------->| .comドメイン(ルートドメイン)の
ブラウザ等 ⇌ スタブリゾルバ ⇌ | フルリゾルバ |<---------| 権威サーバ
| |
| |--------->| .example.com(ルートドメイン)の
| |<---------| 権威サーバ
- ブラウザ等のプログラムがwww.example.comの名前解決のためにスタブリゾルバを呼び出す.
- スタブリゾルバ自体は名前解決をせず,フルリゾルバに代わりに名前解決をするよう要求する(名前解決要求).
- フルリゾルバには過去に依頼されて得た応答結果を保持する仕組み(キャッシュ)がある.依頼されたフルリゾルバは,キャッシュを調べ,www.example.comに対応するIPアドレスの情報があるかを確認する.あればそれをスタブリゾルバに返す(この場合はここで名前解決終了).なければ次の4番へ.
- フルリゾルバはルートゾーンの権威サーバ(特にこれをルートサーバという)のIPアドレスなどの情報をあらかじめ持っている.これをもとに,ルートサーバにwww.example.comのIPアドレスを問い合わせる.
- ルートサーバはcomドメイン以下の情報はcomドメインのゾーンの権威サーバに委任していたため,その委任先の権威サーバのIPアドレスなどの情報を返す.
- フルリゾルバはその情報をキャッシュする.そして,その情報をもとに,comドメインのゾーンの権威サーバにwww.example.comのIPアドレスを問い合わせる.
- comドメインのゾーンの権威サーバはexample.comドメインに関する情報をexample.comドメインのゾーンの権威サーバに委任していたため,その委任先のサーバのIPアドレスなどの情報を返す.
- フルリゾルバはその情報をキャッシュする.そして,その情報をもとに,example.comドメインのゾーンの権威サーバにwww.example.comのIPアドレスを問い合わせる.
- example.comドメインのゾーンの権威サーバはwww.example.comドメインのIPアドレスの情報を保持していた(もしこれを別の権威サーバにさらに委任していたらまた今までのような手続きを繰り返す).その情報をフルリゾルバに返す.
- フルリゾルバはその情報をキャッシュする.結果が返ってきたため,それをスタブリゾルバに返す.その時間の間は再びwww.example.comの問い合わせが来たときはこのキャッシュした値を返す(上で述べた3番の手続き).
- スタブリゾルバはそのIPアドレスを呼び出し元のプログラム(ブラウザなど)に返す.
- そのIPアドレスを用いてwww.example.comにアクセスする.
このようにして,www.example.comのIPアドレスを得ることができる.
もしexample.comのドメイン名を登録申請し,サイトを立ち上げるためにwww.example.comというドメインを何かしらのウェブサーバに対応させるには以下の手続きをする.
- comを含むゾーンの権威サーバにexample.comの権威サーバの情報を登録する.
- www.example.comに関連付ける情報(ウェブサーバのIPアドレスなど)をexample.comを含むゾーンの権威サーバに登録する.
DNSは浸透しない
TTLの時間が経てばフルリゾルバのキャッシュは消える.そしたら再度権威サーバに問い合わせが行く.そのため,サイトをのっけてたサーバを移行してIPアドレスが変わったとしても,移行後も少なくともそのTTLの時間が経てばここの世にあるフルリゾルバは全て正しい値に更新されている.浸透するという表現に値するような手続きはない.
レジストリとレジストラおよびリセラ
ではexample.comといったドメインを登録申請する.その時対峙するのがレジストラ.
- ICANNの子会社PTIという組織が運用するIANAがドメイン名の管理全般を統べる.
- ただし,各TLDの管理は別の組織に委任している.その委任された組織をレジストリ (レジストリデータベースと区別してレジストリオペレータとも) という.
- 例えばcomやnetドメインはVerisignによって, jpドメインはJPRSによって管理・運用されている.つまり,VerisignとJPRSはレジストリである.
- レジストリはいくつかの役割を持つ.
- 各ドメインの登録者の情報を集めたレジストリデータベースの管理.
- 登録者からドメイン名の登録申請を受け付け,それを審査し,登録する場合はレジストリデータベースに情報を登録する.
- それらの登録情報をWhois情報として公開する.
- そのドメインが関わる名前解決に必要な権威DNSサーバを管理・運用する.例えばcomのTLDを管理するレジストリはexample.comに関する情報(例えばexample.comのゾーンのネームサーバのIPアドレスなど)を,comの権威DNSサーバに保持しておくことで,上で説明した名前解決の問い合わせが来たときに,答えられるようにしておく.
- 利用者は直接レジストリからTLDを使いたい旨の申請をするのではなく,レジストラと呼ばれる組織を通してそれを行う.
-
図で表すと以下の通り.リセラと呼ばれる,レジストラとの間をさらに取り次ぐ組織を通じて登録申請を行う場合もある.
レジストラを通じて登録申請する場合: 登録者 ---> レジストラ ---> レジストリ さらにリセラを通じて登録申請する場合: 登録者 ---> リセラ ---> レジストラ ---> レジストリ
- レジストリは一つのTLDに対して一つだが,仲介するレジストラは基本的に沢山ある.レジストラによって値段やサービス,登録可能なTLDが異なる.
参考文献
- Mockapetris, P., "Domain names - concepts and facilities", RFC 1034, 1987, https://www.rfc-editor.org/info/rfc1034
- Mockapetris, P., "Domain names - implementation and specification", RFC 1035, 1987, https://www.rfc-editor.org/info/rfc1035
- Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, 2019, https://www.rfc-editor.org/info/rfc8499
- 株式会社日本レジストリサービス(JPRS)渡邉結衣・佐藤新太・藤原和典, 『DNSがよくわかる教科書』, SBクリエイティブ, 2018
- mochikoAsTech, 『DNSをはじめよう ~基礎からトラブルシューティングまで~ 改訂第2版』, 2019
- JPRS用語辞典, https://jprs.jp/glossary/