■ プライマリとセカンダリ

ネット君。DNSは非常に重要なサービスだな。

え、えぇ。博士はそうおっしゃってますよね。

うむ。何回かそういう風に言っている。それは何故だ？

最も使用され、インターネットの根幹だから、ですよね。

そう、Webでも、メールでも、現在の多くのインターネットでのサービスは、すべてドメイン名での提供が一般的だ。
言うならば、インターネットサービスでのインフラだ、ということだ。

いんふらすとらくちゃー。

うむ。そのインフラだ。
さてさて、ここで問題だ。DNSサービスを行うネームサーバはとても重要だ。このサーバがなければドメイン名の名前解決ができない。

そりゃそうですね。

つまり、このネームサーバが何らかの障害で壊れてしまったりすると、とても困るわけだ。
では、このネームサーバの障害に対応するためにはどうする？

え？ え〜っと……。
祈る？

そう。「ネームサーバが壊れませんように」と祈ることはとても大事だ。
信仰こそ力なり。

え…、あ…、本当にそうなんですか？

もちろんだ。ただ、残念ながら世の中の責任者はネームサーバがダウンしたのは神の手抜きのせいとは見てくれない。

ま、まぁ。そうですよね。

なので、それ以外の対策をしておかなければならない。つまりバックアップとなるサーバを設置しておくわけだ。ネームサーバがダウンした場合、そちらを使用してもらえばよい。

２台用意しておいて、どちらかを使ってもらうんですね。

そういうことだ。インターネット上でドメインを管理する場合最低２台のネームサーバを使うことが必須となっている。
だが、もう１つ、わざわざ２台設定するのは手間がかかる。

手間がかかるって…。だって、障害に対応するためなんでしょう？それぐらいは我慢しないと。

確かにそういわれればそうなのだが。
手動で２台とも同じ設定をした場合、ミスもあるかもしれないし、修正する場合両方とも直さなければならない。これは手間だ。

そうかもしれませんね。
じゃあ、手動じゃなくて、自動化するってことですか？

その通り。
１台だけ設定し、バックアップ用のサーバはその情報をコピーして使用する。

なるほど。そうすれば２台とも同じ情報を持つことになりますね。

うむ。コピー元のネームサーバをプライマリサーバ、コピーするバックアップのサーバをセカンダリサーバと呼ぶ。

ぷらいまり、と、せかんだり。

■ SOAレコードの役割

ネット君。ネームサーバが管理する範囲のことをなんと言った？

管理範囲ですか？ ゾーンですよね。

うむ。つまりプライマリからセカンダリへゾーンの情報を送るわけだな。
この結果プライマリとセカンダリは同じ情報を持つことになる。

ゾーンの情報って、具体的にはなんなんです？

プライマリサーバが持つすべてのリソースレコードだな。簡単に言うと。
これをゾーン転送と呼ぶわけだが、これにはSOAレコードが重要な役割を果たしている。

SOAレコード？ すたーとおぶおーそりてぃ、でしたっけ？
なんに使うかよくわからなかったリソースレコードだった気が。

そう、SOAレコードはドメイン名の問い合わせ、応答というDNSの通常のサービスにはまったく使われない。
このゾーン転送の際に使用されるものなのだ。

これがSOAレコードの中身だ。重要なのは、RDATAのところだな。
簡単な例を出しつつ、説明していこう。

まずは一番上、MNameとRNameだな。MNameはそのドメインを管理するネームサーバ、一般的にはプライマリサーバを書く。
RNameは、ドメインの管理者のメールアドレスだ。

この場合、ns.3min.co.jpがネームサーバで、admin.3min.co.jpが管理者のメールアドレスですね。
でも、変なメールアドレスですね？

あぁ、この場合@もドットで書くのだよ。なので実際のメールアドレスはadmin@3min.co.jpだな。
次はSerial。もっとも重要な値と言ってもいいだろう。これはゾーン情報のバージョンだ。

バージョン？

そうだ。Serialの値を見て、ゾーン情報が新しいか古いかを判断する。詳しくは次の転送の時に話そう。
ともかく、一般的には、年・月・日・変更回数、の10桁の値で書くことが多い。

ん〜っと。つまり。「Serial = 2003123101」だと、2003年12月31日・変更1回目、ですか？

そういうことだ。同じ日にまたゾーン情報を変更した場合、「Serial = 2003123102」になる。

なるほど。

次の２つは、更新についての情報だ。Refreshはゾーン転送の間隔を秒数で表している。この例の場合、3600秒、つまり1時間に1回ゾーン転送を行う、という意味になる。

かならず1時間なんですか？

そういうわけではない。状況によって変更する。
そして、RetryはRefreshによってゾーン転送が出来なかった場合、再試行する時間だ。

Refreshによってゾーン転送が出来なかった場合ってのは、先ほどの例でいえば、1時間に1回のゾーン転送ができなかった、ってことですよね。

そうだ。その場合、例で言えば900秒、つまり15分後に再度転送を試みるわけだな。

15分に1回？

いや、15分後に1回こっきりだ。連続しては行わない。次のRefresh間隔を待つことになる。

Expireは有効期限だ。そのゾーン情報の有効期限を示し、これを過ぎた場合、セカンダリサーバはDNSに応答しなくなる。

やめちゃうんですか？ 古い情報とはいえ、持っているのに？

そうだ。古くて不正確な情報を提供するよりは応答しなくなった方がいい、という考えなのだな。
この例の場合、604800秒だから、1週間だな。

ははぁ。

つまり、ゾーン転送失敗時のタイムスケジュールはこんな形になるわけだ。

さて、最後はMinimum TTLだ。

これなんだが。いまいち使い方がよくわからん。

は、博士〜。

リソースレコードのTTLを指定する、という説明もあるし。
ネガティブキャッシュの保持時間だという説明もあるし。

どっちにしろキャッシュの保持時間ってことですか？

そういうことだ。ゾーン転送には特に関係のない値だな。

■ ゾーン転送

さて、実際のゾーン転送だが。
これは図で説明しよう。

あぁ、書き忘れた。
通常、ゾーンの転送はTCPで実施されることが多い。

UDPで行うDNSのサイズ、512バイトを超えるからですか？

そうだな。すべてのリソースレコードとなると、512バイトでは足りないことが多いからな。
これがもっとも使用されるゾーン転送方式だ。 ▼ link

最も使用されるとは、なんか含みのある言い方ですね。

うむ。他にもある。
まずはこの方式の変形を２つ紹介しよう。1つ目はDNS NOTIFYという方式。 ▼ link

のーてぃふぁい？

「告知」「通知」という意味だ。動作はこうなる。

は〜。プライマリから「通知」するから、DNS NOTIFYですか。

そういうことだ。
そしてもう１つは、差分ゾーン転送。 ▼ link

差分？

この２つは、サーバがそれに対応していなければならない。

なるほど〜。もともとの方式を改良して、使いやすくしているんですね。

うむ。
他には、SCPやFTPを使う方式や、データベースソフトを使うという方式もある。

ははぁ〜、もともとDNSは分散型データベースでしたよね。それをデータベースソフトでやっちゃうって方式もあるってことですか。

そういうことだな。
ともかく、プライマリ・セカンダリ間のゾーン転送のポイントは先ほども言ったがSOAのSerialだな。

Serialを見て、ゾーン情報を転送するかしないか決めるわけですからね。

うむ。ゾーン情報を書き換えることは実施したが、SOAのSerialの更新を忘れるなんてことが、よくあったりするわけだ。

あはは、それだとセカンダリに転送されませんよね。

うむ。そのせいで、ゾーン情報を変えたのに、問い合わせの結果は変わってない、なんてことが起きたりするのだよ。

なるほど。

■ ゾーン転送の注意点

このゾーン転送にはいくつか注意点がある。
まず、リゾルバはそのネームサーバがプライマリかセカンダリか区別しないという点が１つ。

そうなんですか？

うむ。
例えば、前回使った画像を見てもらおう。jpドメインのネームサーバ群だな。

NSレコードを問い合わせているが、さて、どれがプライマリネームサーバだ？

え？ A.DNS.jpじゃないんですか？

う。しまった。本当にA.DNS.jpなのだが、それはネット君。単に先頭だから選んだだろう？

えへへ。

SOAレコードを見れば、一応プライマリサーバがわかるが、通常は教えてもらったネームサーバから任意に選んで使用する。特にプライマリサーバを選んで使うわけではない。

ははぁ。

その選んだサーバが応答しない場合、他のネームサーバを使用する、という形になっているだけだ。
使う側は区別しない、ということを覚えておきたまえ。

プライマリとかセカンダリとかは、あくまでもこちらの事情ってことですね。

うむ。それと、ゾーン転送のセキュリティが問題だ。
例えば、nslookupで擬似的にゾーン情報を要求できる。

3min.co.jpのネームサーバに対し、ゾーン情報を要求した。
これにネームサーバが従った場合、すべてのレコードが手に入るな。

そうなりますよね。

結果、存在するホストとそのIPアドレスが知られてしまうということになる。
これは好ましくない。

そうなんですか？ 何故です？

なんらかの攻撃の呼び水になる可能性があるからだ。
セキュリティの基本の１つは「知られていない所には攻撃されない」という考えがある。

まぁ、そうですよね。
名前もIPアドレスも知らないホストに攻撃はしかけられませんよね。

もちろん、知らなくても攻撃できる手段はあるが、知られないにこしたことはない。
よって、セカンダリサーバからの要求にのみゾーン転送を許可する設定をしなければならない。

なるほどなるほど。そうすればセカンダリ以外はゾーン情報を入手できないわけですね。

そういうことだ。先ほどのnslookupの 「ls -d」コマンドも使えなくなるしな。
この設定は非常に重要なので忘れないように。

了解です。

だが、しかし。これだけでは完全に防ぐことができない。

そうなんですか？ でも、セカンダリ以外はゾーンを転送してもらえないんでしょ？

うむ、それは確かにそうだが、セカンダリサーバに偽装した攻撃者がいるかもしれない。

うわ、悪辣だ。

なので、それに対応して、TSIGなどを使用してそのような「なりすまし」も防いだりもする。 ▼ link

ちゃんと対応手段があるんですね。

そういうことだな。 では今回はこれで終わりにしよう。まだまだDNSの話がもうちょっと続くぞ。

いぇっさ〜。
３分間ネットワーキングでした〜♪