3 Minutes NetWorking
No.68

3Minutes NetWorking

第68回DNS(7) ゾーン転送

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

そりゃそうですね。

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

■ SOAレコードの役割

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

名前(Name)可変長そのドメインの名前
タイプ(Type)16ビットSOA
クラス(class)16ビットIN
TTL32ビットキャッシュ時間(秒)
RD長(RDLength)16ビットRDATAの長さ
RDATA可変長MNameネームサーバ名
RNameドメインの管理者
Serialゾーン情報のシリアル番号
Refresh更新までの時間
Retry更新の再試行間隔
Expire更新の終了時間
Minimum TTLリソースレコードの最小TTL

[Table64-05:SOAレコードの記述]

インター博士

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

  • MName = ns.3min.co.jp
  • RName = admin.3min.co.jp
  • Serial = 2003123101
  • Refresh = 3600
  • Retry = 900
  • Expire = 604800
  • Minimum TTL = 3600
インター博士

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

  • MName = ns.3min.co.jp
  • RName = admin.3min.co.jp
ネット助手

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

インター博士

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

  • Serial = 2003123101
ネット助手

バージョン?

インター博士

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

ネット助手

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

インター博士

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

ネット助手

なるほど。

  • Refresh = 3600
  • Retry = 900
インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

15分に1回?

インター博士

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

  • Expire = 604800
インター博士

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

ネット助手

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

インター博士

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

ネット助手

ははぁ。

インター博士

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

転送失敗時の流れ

[Figure68-01:転送失敗時の流れ]

インター博士

さて、最後はMinimum TTLだ。

  • Minimum TTL = 3600
インター博士

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

ネット助手

は、博士〜。

インター博士

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

ネット助手

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

インター博士

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

■ ゾーン転送

インター博士

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

[Figure68-02:ゾーン転送]

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

のーてぃふぁい?

インター博士

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

[Figure68-03:DNS NOTIFY]

ネット助手

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

インター博士

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

ネット助手

差分?

[Figure68-04:差分ゾーン転送]

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

なるほど。

■ ゾーン転送の注意点

インター博士

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

ネット助手

そうなんですか?

インター博士

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

jpドメイン

[Figure67-21:jpドメイン]

インター博士

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

ネット助手

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

インター博士

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

ネット助手

えへへ。

インター博士

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

ネット助手

ははぁ。

インター博士

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

ネット助手

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

インター博士

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

  • c:\> nslookup
  • Default Server: ns.3min.co.jp
  • Address: xxx.xxx.xxx.xxx
  • > ls -d 3min.co.jp
インター博士

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

ネット助手

そうなりますよね。

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

了解です。

インター博士

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

ネット助手

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

インター博士

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

ネット助手

うわ、悪辣だ。

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

プライマリサーバ
[Primary Name Server]
なお、マスターとスレーブという言い方もします。
セカンダリサーバ
[Secondry Name Server]
セカンダリは複数存在してもかまわない。
ネガティブキャッシュ
[Negative Cahce]
キャッシュサーバが持つ、「そのドメイン名は存在しない」という情報。
リゾルバからの問い合わせに対し、そのドメイン名がなかった場合、それをリゾルバに通知するとともに、「存在しない」というキャッシュを持つことにより、問い合わせの高速化をはかっている。
もっとも使用される
RFC1035で規定。
DNS NOTIFY
RFC1996で規定。
差分ゾーン転送
RFC1995で規定。
SCP
[Secure CoPy]
UNIXのネットワーク対応コピー用コマンドのRCPをSSHを使用してセキュリティを高めたもの。SSHの機能の一部。
TSIG
[Transaction Signature]
サーバとクライアント(プライマリとセカンダリ)で同じ暗号鍵を保有して、認証を行う方式。
RFC2845で規定。
ネット助手ネット君の今日のポイント
  • ネームサーバを複数台でバックアップする。
  • インターネット上でドメインを運用するならば最低2台のネームサーバ必要。
  • 元となるゾーン情報を持つネームサーバをプライマリサーバ、バックアップ側をセカンダリネームサーバと呼ぶ。
  • ゾーン情報の転送の情報がSOAレコードに明記されている。
  • SOAレコードのSerialを見て、ゾーン情報(すべてのリソースレコード)を転送する。
  • セカンダリサーバ以外にゾーン情報を転送しないようにしておくことが重要である。

3 Minutes NetWorking No.68

管理人:aji-ssz(at)selene.is.dream.jp