2006年04月18日

DNS の詳細

法人向けプロバイダで労働してます。
そのプロバイダでさえ、DNS のことを厳密に理解している人は少なそうなので、
今回書いてみようかなーと思ってみました。

細かいことは自分で調べてもらうとして、
知ってないと調べられないことを書いてみましょう。
技術者の人が読めば「へー、そうだったのか!」と思うこと間違いなし。
# だといいなー(笑)
一般には語られないことを語ります。
書きやすいので、文書は断定形な感じで書きます。
なるべく理解しやすいように順番に書きますが、たまに前後しちゃうところはご愛嬌☆


1. DNS はツリー構造となっている。TLD といわれる .com や .net や .jp をまとめる
"." (ドット) 言われる最上位のドメインが存在することを理解すること。
通常は "." は略されているが、正しくは .com. .net. .jp. (最後に "." がつく) であると理解しておく。
よって、シングルツリー構造となっている。

2. DNS は分散システム。この分散は「委任」によって成り立っている。
シングルツリー構造であるため、ツリーの上位のものが下位に「委任」することで、
分散システムとなる。

3. DNS のプロトコルとして UDP を使うのはよく知られているが、
クエリーの回答に 512 byte を超える場合は TCP での回答となる。

4. UDP/TCP のプロトコルを理解していれば当然だが、
TCP での通信はコストが高く、頻繁に通信が必要となる DNS では好ましくない。
一般にはゾーン転送以外では TCP が使われないような、
ゾーン情報とするのが好ましい。(あまり語られないがこれは本当に重要)

5. ツリーの最上位はルートサーバといわれる 13 台のサーバで成り立っている。
この 13 台は今後増えることは (現状のプロトコル仕様では) まずない。
なぜなら、3. で語った DNS のプロトコルとして UDP で収まるのがこの台数だから。
14 台以上になると、TCP での通信となってしまう。

6. 13 台のサーバで成立っている、といわれているが、
本当に 13 台なわけではなく、実サーバとしては大量にある。
そのコア技術としては、エニイキャストがよく語られる。
また、語られないが、間違いなくネットワークロードバランシングも
用いられていることが想像される。

7. エニイキャストって何よ、という質問に回答するのは難しい。
(理解するためには実設定を想像できないとつらいから)
簡単にいうなら、一つの IP アドレスが複数のネットワークに存在する状態。
たとえば、違う会社で同じプライベートアドレスを利用していると思うけれど、
それをインターネットでやるということ。
これは specific に host ルーティングを書くことで実装されていると思われる。
(実設定は想像でしかないので念のため)

8. ネットワークロードバランシングは、BIG-IP (一番有名) などの
負荷分散機器を利用して、その機器に実 IP を割り当て、
その機器が複数のサーバにパケットを賢く転送するという技術。
まぁ、今はかなり有名なので、知らないなら調べてください。

9. というわけで、ルートサーバは 13 個のホスト名 (FQDN) と IP アドレスの組であって、
実サーバはいっぱい。(実際に何台あるかは誰もしらなそう。。。)
なので、なかなか落ちないので (落ちないようにみんな全力なので) とりあえず安心して、
委任されたドメイン名を各ネームサーバが答えれば、DNS という分散処理システムが出来上がる。
ちなみに委任は NS レコードによって行われる。
委任したサーバと委任されたサーバで NS レコードが違うのは「正しくない、好ましくない」状態。
だけど、動くので、そういう設定をたくさん見かける。

10. とはいえ、ドメイン名を持っている人は、「委任をしてもらった記憶ってないけど?」と
思う人もいると思うけれど、たとえばお名前 .com とかでドメインを取得すると、
「ネームサーバ」を設定するところがあって、それが「委任の依頼」にあたる。
(そんなことはかかれてないけれど、挙動としてはそういうこと)
というわけで、ルートドメインは ICANN (だったかな?) が管理してるので、
それが TLD を決め、TLD の下のドメインは TLD で委任されてる。
ということは、(ありえないけど) ICANN が私に .k-square. を委任したら、
その TLD を私が使えるようになるし「管理できるようになる (管理しないといけなくなる)」

11. TLD の委任の情報は whois で出てくるものと同値。
whois はドメインの情報を教えてくれるけれど、その中のネームサーバについては、
委任の状況を示したものなので、TLD からしたに降りてくるには dig / nslookup で
ルートドメインから降りてくるよりは whois 使ったほうが楽。

12. とはいえ、ルートドメインから TLD への委任は dig / nslookup で調べて頂戴。
(どこかに URL がありそうだけど面倒だから各自調べてください)

13. 9.〜11. をまとめるとドメインでの NS と whois に登録するネームサーバはあわせなさいってこと。

14. ところで、DNS サーバっていうのは二種類あって、コンテンツサーバとキャッシュサーバがある。
キャッシュサーバは
「プロバイダなどで指定される DNS サーバでがんばって名前を解決してくれるサーバ」
(再起解決をしてくれる)
コンテンツサーバは
「おもにキャッシュサーバに応答してくれるサーバで、名前解決はあまりがんばってくれずに、
自分の知っていることだけに答えるサーバ」(再起解決をしてくれない)

15. なんで二種類あるのかっていうと、結局負荷分散。
キャッシュサーバは名前解決を頑張るから、結構負荷が高い。
コンテンツサーバは知ってることだけを応えるから負荷が低い。
で、コンテンツサーバだけで、基本的には名前は調べていける。
だって、委任はコンテンツサーバで成立っているので、問題ない。
とはいえ、クライアント全員で一生懸命ルートドメイン→TLD→下位ドメイン→リソースレコード
って引いていくと面倒だし、トラフィックも増えてなんだかよろしくない。
ので、それらを解決するためにキャッシュサーバがあるわけ。
キャッシュサーバは名前どおり、DNS クライアントとコンテンツサーバをつなぐ DNS サーバ、
だと思うと正解で、クライアントが質問すると全て調べて応えてくれる優しい人。
普通のクライアントはキャッシュサーバの存在を前提にしてあるので、
キャッシュサーバ無いと普通の人は名前解決不能 (自分で反復解決できる人以外は死亡。。。)

16. で、実際はどうなの?っていうと、キャッシュサーバとコンテンツサーバは一緒のことも多い。
設定すればいいだけなので、コンテンツサーバはキャッシュサーバにもなるし、
キャッシュサーバもコンテンツサーバにできる。
(ドメイン持ってないとルートドメインしか応えないからいみないけど)
さすがにルートサーバとかは世界中から query されて負荷が高いから純粋なコンテンツサーバ。

17. キャッシュサーバとコンテンツサーバが理解できたところで、
コンテンツサーバは誰に対しても解答する必要があるけれど、
キャッシュサーバは自分の回答したいクライアントにだけ応えれば問題ないことが分かる。
(分からなかったら分かるまで 15. を読むこと)
なのでー、大手はキャッシュサーバは自分のネットワークからのみ回答して、
そのほかの IP アドレスからのクエリーは無視したりするように DNS サーバを構成してます。
逆にだれでも使えるキャッシュサーバは Open DNS といわれちゃって、
「なんだよ、大手のくせにたいしたことねーなー」とかに思われることもあります。
中小企業で外向きはコンテンツサーバ、内向きはキャッシュサーバとして構成した
DNS とか見かけると、感心しちゃったりします。( これは私(笑)がそう思うってだけですけど )

18. ところで、DNS と聞くとプライマリ・セカンダリって聞くけど?
っていうのは、これはまったく気にする必要なし。
勝手にプロバイダとかがそう記載しているだけで、何の区別もない!のが正解。
プロバイダとかの使い分けのポリシーで決まります。
なんというか、二口ガスコンロがあって強火が可能なものをプライマリ、
強火ができないものをセカンダリといってるようなもの。
どっちもコンロであるし機能は変わんないでしょ?
利用者からは master / slave とかわかんないし。
後述の master / slave とごっちゃに考えてる人も多いので、いまここで理解しましょう。
プライマリ / セカンダリを master / slave と考えるならそれはそういう誤用をしている人 / 場所なので、
(誤用でもないけど、厳密に理解するためにここではそう考えておいてください。)
それはそのままにして、えらそうに知識を振りかざさずに
「この人 / ここはそーいう使い方だ」と思えばおっけー。

19. じゃぁ、master / slave ってなにさー?
っていうのは DNS サーバソフトウェアの
「リソースレコードの設定をできるサーバかできないサーバかの違い」
です。
たとえば BIND なら、master 側でゾーンのリソースレコードを設定できますが、
slave 側では master の設定を継承するだけ。
ちなみに Windows のアクティブディレクトリとか使うと、
(設定によっては) マルチマスタなので、全 DNS (DC) が master サーバです。
ってことを考えると、プライマリとかセカンダリとクライアント側で言い分ける\n 意味のなさを理解してみたりします。

20. ぜんぜん話は変わるけれど、DNS プロトコルは port 53 の UDP / TCP を使います。
これは有名。
で、知ってない人は知っててほしいですが、UDP には「セッションとかいう概念はありません」
UDP 上で実装することは可能ですが、UDP にはないってことを知っておきましょう。
ってことは、DNS の帰りの UDP パケットとソース port 53 発の UDP パケットは区別つきません。
おおっとー。
というわけで、stateless (static) なパケットフィルタはソース port 53 の UDP パケットを通します。
(通さなかったら DNS 引けないので)
ので、これを利用したフィルタ回避方法が一時期 (いまも?) 流行ったので、
statefull (dynamic) なパケットフィルタでは、ソース port 53 の UDP パケットを破棄することがあります。
( drop / reject としてはおおむね drop が多いように見受けます)
ので、レスポンスタイムとか、ゾーン転送のソースポート設定によっては statefull パケットフィルタとかで
ガシガシとめられちゃうので、DNS サーバでのソースポート指定とかは、なるはやで消しちゃいましょう。
分かりづらい問題になりますよー。
(dig で -b 0.0.0.0#53 とか使ってのきりわけが必要になるので、多くの人がはまります)

21. 最後ですが、ドメイン名には "_" (アンダーバー) が使えません。
SRV レコードなどに使うので、DNS サーバとかで使えるようになってますが、
RFC 的には使えないことになってるので使わないようにしましょう。
Windows で DNS 立てるときは要注意です。

22. 言い忘れましたがリソースレコードとは A レコードとか NS レコードとか PTR とか CNAME とかです。

Posted by k-square : 22:03 | Network | コメント (2)