DNSの基本
Webサイトやメールで使う、ドメイン名…
それらドメイン名を扱うシステムが、DNSサーバ。
使う分には理解してなくても問題ない DNS だけど、SEでさえ挙動を理解してない人が多い。
以下は、そういう人たちにイチから説明するのに、自分がどれだけ理解してるかまとめるためのメモ。
簡潔に知りたい場合は、下記 JPNIC の説明が分かりやすいと思う。
> ドメイン名のしくみ - JPNIC
…さて。
極簡単な略歴
1960年代 後半 - ARPA という組織(後に DARPA と改称)が ARPAnet の実験的運用を開始。
1970年代 hosts というテキストファイルで名前解決されていた。
1980年代 前半 - TCP/IP プロトコル群が開発された。
1984年 DNS の RFC が発表された(その後書き直され、2011年現在も拡張中)。
1988年 DARPA が実験終了を決定。国防総省がARPAnetを解体開始。
DNS とは
DNS は Domain Name System の略で、ドメイン名をIPアドレスに、IPアドレスをドメイン名に変換するシステムのこと。
hosts では数千台=数千行となり、1台増えるたびに数千台のアクセスが必要となる。
そのトラフィックも問題だし、数千ものホスト名が全部被らないようにするのも問題となっていた。
常に最新版が必要だけど、更新をサボる管理者がいると新しいサーバにアクセスできない人がでてくる弊害があった。
DNS は、そんな問題を解消するために分散データベースとして生まれた。
ドメイン名の考え方
ドメインは、ツリー構造をイメージして設計されている。
"www.example.co.jp" とあれば、日本の会社である example の www というホストという意味になる。
一番上 (root) は、空っぽであることが RFC で予約されている。
それを明確にしたドメインだと "www.example.co.jp." と、最後はドットで終わる。
これが本来の FQDN という書き方で、適当な検索サイトや、メールアドレスのドメイン末尾にドットをつけても、問題なく動作するのが分かってもらえると思う。
国や組織のタイプ、社名や人名など、様々な要素を組み合わせて、数億ものホスト名が全部被らないようにできるようになった。
DNSへの問い合わせシーケンス
ブラウザで http://www.example.co.jp./ を入力した場合の挙動を書く。
ブラウザは、OSに対して www.example.co.jp. を IP アドレスに変換するように指示する。
OSは、リゾルバを使って www.example.co.jp. を IP アドレスに変換するように動く。
リゾルバは（大概のデフォルト設定ならば）最初に hosts ファイルから探す。
なかったら domain や search などで指定された文字列も足してみて、もっかい探す*1。
なければ、ネットワーク設定から DNS のIPアドレスを探し出してきて、そこへ問い合わせを送る。
ここまでは、クライアント（パソコン）側の話。
問い合わせを受け取った DNS サーバは、まずルート DNS へ問い合わせを送る。
ルート DNS は gTLDや ccTLDしか知らない。
なので「こっちに聞けよ」というフラグを入れて ccTLD である jp ゾーンを管理するサーバの IP アドレスを返す。
ヒントを貰ったDNSサーバは、jp ゾーンを管理する DNS に、同じように問い合わせをだす。
jp ゾーンを管理しているサーバも co までしか分からんので、同じフラグを入れて、co.jp. を管理している DNS の IP アドレスを返す。
めげずに co.jp. ゾーンを管理する DNS に同じ問い合わせを送る。
今度も同じように example.co.jp. の管理 DNS サーバを教えてくれる。
example.co.jp. ゾーンの管理 DNS サーバは、初めて「知ってるよ、これだ！」とばかりに、覚えておく時間まで指定して 対象の IP アドレスを教えてくれる。
メモったら、初めてクライアント…というか、リゾルバに IP アドレスを返す。
ここまでが、DNSサーバの話。
ずーっと応答を待ってたリゾルバは、情報を貰うとすぐに OS へ報告する。
OS は、その IP アドレス 80 番ポートに…
と、処理が続く。
ついでに、IPアドレスからホスト名を探す "逆引き" の場合、上記のままでは不都合があるので、多少特殊な処理が必要になる。
逆引きは arpa の in-addr というゾーンで管理されている。
192.168.0.1 とか ::1 とかいう IP アドレスを逆引きしようと思ったら、次のように組み立てなおす必要がある。
1.0.168.192.in-addr.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
それだけでなく、リソースレコードも PTR を指定する必要がある。
nslookup コマンドは、IPアドレスを指定すると勝手に整形する上、リソースレコードも修正してくれるので楽。
自分で直接引くときには、以下のように指定する。
c:\> nslookup -type=PTR 1.0.168.192.in-addr.arpa.
c:\> nslookup -type=PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
DNS サーバのメモリ使用量について
これに書いてある…と言えれば良かったんだけど…
この問題に関しては、役に立ちそうに無い。
大体の見積もり方については、こんな考え方で合ってると思う。
- 純粋に named を起動させた時のメモリ使用量
これは、バージョンによって変わる。当然。
OS によっても変わるかも…
実際に起動させてみなきゃ、基本となる使用量は分からない。
- 扱うゾーンの数
設定するゾーンにあるラベルの平均的な文字数(byte)を、ゾーンの数でかけると出てくるサイズ。
大雑把な見積もりとしては細かすぎる気もする…。
設定ファイルに扱うゾーンとカラのゾーンファイルだけつくって、そのサイズを見ればいいかな？
- ホスト名の数
扱う文字（ホスト名やIPアドレスなどの数字）を全部メモリに展開するので、文字数は見積もりに必須。
example.co.jp. ゾーンならば、www と ftp と mail があるだけと仮定した場合に…
（(ゾーンの文字列)+(www)+(ftp)+(mail)）*文字のバイト数 = （(14*3)+3+3+4）*8 で 416 バイトくらい。
SOA とかは、扱うゾーン数に含むと考えて、それくらいしかメモリを使わない気がする。
- 更新数
古いバージョンだと、更新するたび際限なくメモリを新しく使うものもあったりする。
最近のであれば、大体新旧2つの管理対象となるので、起動時のメモリ使用量から2倍は余裕をみなきゃだめ。
named プロセスのメモリ使用量は、カバーしようとしたら大変なことになった*2ので割愛。
自動起動
そうそう、自動起動を忘れてた。
電源ボタンを押して OS が起動したとき、自動でプロセスをあげなきゃいけないはず。
設定方法は各OS毎にまちまちなので割愛。
RedHut 系 Linux なら…
# chkconfig on named
で済むかな？
用語
SOA
Start of Authority の略。
ゾーン名、ホスト名、管理者のメールアドレス、シリアル番号、リフレッシュ間隔、リトライ間隔、期限切れ時間、ネガティブキャッシュTTLが設定される。
- ゾーン名
対象ゾーン。
@ で省略されること多し。
- ホスト名
DNS のホスト名。
- 管理者のメールアドレス
そのまんま。
- シリアル番号
数値を大きくすることで更新を知らせる。
日付+2桁が定番。
- リフレッシュ間隔
Slave DNS が、シリアル番号の更新を確認する間隔。
- リトライ間隔
Slave DNS が、シリアル番号の更新を確認できない場合にリトライする間隔。
- 期限切れ時間
Slave DNS が、最終的にすべてを諦める時間。
- ネガティブキャッシュTTL
問い合わせがあっても、無いものは無いよと返した情報についてキャッシュする時間。
これがないと、登録前に引いた情報が残って、いつまで経ってもアクセスできない端末が出てくる可能性がある。
逆引き
IP アドレスからホスト名を引くこと。
Webサイトだと、無くても困らないことが多い。
でも ISP が、利用者に対して払い出す IP アドレスには、付けるのが普通。
グローバルアドレスを利用者に払いだすと、たくさん登録が必要になる。
$GENERATE は、偉大。
でも、多すぎるとにメモリ使用量がパンパンに… orz
gTLD
ジェネリックトップレベルドメインの略。
.com や .org など、国別になっていないトップレベルドメイン*3のこと。
ccTLD
カントリーコードトップレベルドメインの略。
日本なら .jp とか、世界中の国毎に割り当てがある。
リゾルバ
ネームサーバをアクセスするクライアント…と、バッタ本（DNS & BIND 第4版）には書いてある。
これでは意味がわからないと思う。
僕にはよくわからない(^^;
要は、ドメイン名を入れるとIPアドレスが返ってくるプログラムのこと。
ブラウザやメールクライアントが、直接 hosts を調査したり名前解決しなくても済むのは、リゾルバがあるおかげ。
リゾルバの設定次第で、hosts を優先させたり、DNS を優先させたりできる。
リソースレコード
DNS で引きたい名前が、IPアドレスなのかホスト名なのか、それ以外なのか…
そういったリソースのタイプ毎に指定する
アドレスレコード…は、Aレコードと呼ぶ。名前に対して IPv4 アドレスを返す。
IPv6アドレスのアドレスレコード…は、AAAAレコードと呼ぶ。名前に対して IPv6 アドレスを返す。
別名レコード…は A レコードにつける別名。名前に対して名前を返す。
PTRレコード…は pointer の略で逆引き用。IPアドレスに対して名前を返す。
A レコードと AAAA レコードは、同じゾーンファイルに記述する。
PTR レコードは IPv4 と IPv6 で異なるゾーンファイルを作成する。
ルートDNS
世界で13組存在する、基幹となる DNS サーバ。
こいつが壊れると、文字通りインターネットが崩壊する。
もちろん、キャッシュに存在したり、IPアドレスでサーバを覚えていたらアクセスはできるけど…キャッシュはいずれ消えるし、IPアドレスを覚えてる人なんて少数派。
それだけ重要なので、実は IP anycast 技術で 200 台以上が運用されていると聞く。
ラベル
ラベルは、ドットで区切った部分それぞれの名前のこと。
example.co.jp とあれば、3つのラベルで構成されている。
各ラベルは、最長 63 文字まで。
ラベル数は、最大 127 個まで。
ドメイン名自体、最長で 255 文字まで(ドットを含む)。
メールアドレスになると、最長で 256 文字まで(ドットなど記号を含む)。
たとえば、250文字のドメイン名でメールを出そうとした場合…
アットマークを含めて 251文字になるので、ユーザを示すアットマークの前には、5文字しか使えない。
ゾーン
特定のラベル配下をまとめて扱うときの、ひとつの単位。
www.example.co.jp. は example.co.jp. ゾーンのホストという。
同様に example.co.jp. は、co.jp. ゾーンのホストとなる。
ホストはゾーンに成りえるし、ゾーンでもホストがひとつだけという状況もある。
このゾーンの考え方があることで、たとえ一気に 1000 台増えても、常にゾーン管理者が最適と思うタイミングに、最新の情報で、必要なサーバだけにアクセスできるようになった。
設定ファイル
named の挙動を決める設定ファイルは、BIND の場合、デフォルトで named.conf になる。
named.conf で、どんなログを出力するのか、どのディレクトリをホームとするのか、どんなゾーンを扱うのか、その扱い方は MASTER/SLAVE どちらなのか…等を記述する。
ゾーンファイル
named.conf に記載されたゾーンの中身（ホストの名前）を書くファイル。
example.co.jp. ゾーンなら、www とか ftp とか mail とか？
他にも「キャッシュはどれくらいの時間、保持して欲しいか」とかも書く。
