はじめに
DNSについて何となくでしか理解していなかったので、今回「DNSがよくわかる教科書」を読みました。忘れないように備忘録として残しておきます。少しでも参考になればと思います。
1. DNSが作られた背景(ざっとですが)
インターネットが始まった当初は**「HOSTS.TXT」というテキストファイルに、全てのホストのIPアドレスとホスト名の対応を記載。この方式は現在も多くのシステムでサポートされており、HOSTSファイルに相当するファイルが存在。IPアドレスはインターネット全体で共有されているため、どの機器がどのIPを使っているか、インターネット全体で統一的に管理する必要あったのだ。そのため、HOSTSファイルは名前や番号が重複しないように、1つの組織が一元管理している。しかしインターネットの発展により、HOSTSファイルにIPアドレスの反映をするのに時間がかかるようになった。そこで採用されたアイデアが「階層化」と「委任」**という、分散管理の仕組み。
階層化と委任のメリット
①管理を分散することで、それぞれの管理者の負担を軽減できる
②組織そのものの成長/変化に柔軟に対応できる
2. 用語
ドメイン : インターネットでは分割されたそれぞれの名前空間の範囲 (例：example)
ドメイン名 : その範囲を識別するために付けられた名前 (例:example.co.jp)
*ドメイン名は、WebページのURLやメールアドレスの一部として使われる
サブドメイン
- 独自ドメインを分割するために任意で設定するドメイン名
- そのドメインの管理者が自由に作ることができる
- 作成したサブドメインを他者に委任するかどうかも管理者が決めることができる
DNS(Domain Name System)
- それぞれの階層の管理者から必要な情報を入手してドメイン名の階層構造をたどり、最終的な答えであるIPアドレスを得る
- ドメイン名の階層ごとに管理者に問い合わせて、委任が行われていれば「この人に委任している」という情報をもらい、最終的な管理者にたどりつけばそこで必要な情報をもらえる
ゾーン : 委任によって管理を任された範囲
ネームサーバ(権威サーバーともいう)
① そのゾーンに存在するホストのドメイン名とIPアドレスを管理
② 委任の情報を管理
ICANN(Internet Corporation for assigned Names and Numbers)
役割
- インターネットの識別子の管理・調整
- DNSのルートサーバーシステムの運用・調整
- 上記2つの技術的機能に関するポリシーの策定・調整
レジストリ
- ICANNから認定を受け、ドメイン及びDNS情報のDB管理や整理をする管理組織
- ドメイン名を使えるようにするためにはレジストリに対して「このドメイン名を使いたい」という登録申請する
- レジストリは、その内容が登録用件を満たしているかを審査・確認、レジストリが管理するデータベースに登録することで、申請者がドメイン名を使う権利を得る
役割
①レジストリDBの運用管理
②ポリシーに基づいた登録規則の策定
③登録申請の受付
④Whoisサービスの提供
⑤ネームサーバーの運用
⑥情報発信/教育啓発活動
Whois
- ドメイン名やIPアドレスのレジストリが管理する登録、割り当て情報をインターネットに公開し、利用者が参照できるようにするサービス
レジストリとTLDの関係
各TLDには、レジストリが存在する。そして、それぞれのレジストリがTLDを管理し、管理のポリシーや登録規則を定めている。TLDは大きく以下の2つ。
① ccTLD : 国や地域ごとに割り当てられる (ex: .jp, .uk)
② gTLD : 国や地域によらない (ex: .com, .net, .org, .biz)
レジストラ
レジストリと登録者の間に入って、ドメインの登録申請を受けたり、その申請内容を審査したりドメインのDBへの情報登録を行なったりする業者
(例) お名前.com
役割
①登録者からの登録申請の受付
②レジストリDBへの登録依頼
③Whoisサービスの提供
④登録者情報の管理
3種類の構成要素とその役割
DNSの名前解決における役割分担は以下の３種類
(1) 情報が欲しい人 ： スタブリゾルバー
(2) 情報が欲しい人からの依頼を受けて、名前解決をする人 : フルリゾルバー
(3) 情報を提供する人 : 権威サーバー
(1)スタブリゾルバー
・名前解決の窓口
(2)フルリゾルバー
①名前解決を実行する
②名前解決の際に得られた情報を蓄える(キャッシュ)
(3) 権威サーバー
- ネームサーバー = 権威サーバー
- フルリゾルバーからの問い合わせを受けて、自分が保持している情報を応答する
- スタブリゾルバーやフルリゾルバーは問い合わせの際、知りたい情報の名前(ドメイン名)と種類(タイプ)を指定する
- 権威サーバーはこれらの2つの情報をもとに、自分が保持している情報の中から、目的の情報を見つけ出す
- 権威サーバーはそのゾーンの設定内容を「リソースレコード」という形で保持。
3. ドメイン名を使えるようにするには
登録者が行うこと
①自分のドメイン名を取り扱うネームサーバをインターネット上で動かす
②登録したドメイン名に関する情報を①で動かしたネームサーバに設定する
③ネームサーバがインターネットから聞かれたことに答えられるか確認する
(＋α) DNSを動かすために必要なこと
-
自分のドメイン名をインターネットで使えるようにする
→権威サーバーを動かすことで、自分のドメイン名をインターネットで使えるようにする -
インターネットで使われているドメイン名を自分が使えるようにする
→特にフルリゾルバーを動かすことで、インターネットで使われているドメイン名を自分が使えるようになる -
DNSを動かし続け、可用性を高める
→権威サーバやフルリゾルバーは一度動かせば良いのではなく、問題なく動いているかを確認したり、外部からの攻撃に供えたりして、動かし続ける必要がある
4.リソースレコード
# リソースレコード
ドメイン名 TTL クラス タイプ データ
# 例
jprs.jp 300 IN A 113.44.56.78
リソースレコードのタイプ
| タイプ | 指定される内容 |
|---|---|
| A(エー) | そのドメイン名のIPv4アドレスを指定 |
| AAAA(クワッドエー) | そのドメイン名のIPv6アドレスを指定 |
| NS(エヌエス) | そのゾーンの権威サーバーのホスト名を指定 |
| MX(エムエックス) | そのドメイン宛の電子メールの配送先と優先度を指定 |
リソースレコード
| タイプ | 内容 |
|---|---|
| SOAリソースレコード | ゾーンの管理に関する基本的な情報 |
| NSリソースレコード | 委任いん関する情報 |
| Aリソースレコード | ドメイン名に対するIPv4アドレス |
| AAAAリソースレコード | ドメイン名に対するIPv6アドレス |
| MXリソースレコード | メール配送に関する情報 |
| CNAMEリソースレコード | ドメイン名に対する正式名 |
| TXTリソースレコード | 任意の文字列 |
| PTRリソースレコード | IPアドレスに対するドメイン名 |
5. DNSの動作状況を確認するためのコマンド
digコマンドとdrillコマンド
基本的な構文
dif/drill [option] [@サーバー] ドメイン名 [タイプ] [クラス]
*[]は省略可能
*@サーバー : 問い合わせ先のサーバーをドメイン名またはIPアドレスで指定
# 例 (DNSメッセージの確認可能)
$ dig @8.8.8.8 www.google.com IN A
ネームサーバ変更されたかの確認
$ dig ドメイン名 ns +short
終わりに
DNSの最低限の知識はカバーできたかと思います。もう少し読み込んで更新できたらと思います。
とてもわかりやすい1冊でしたので、DNSのこと知りたいという方には今回の参考書をお勧めします。