D. J. Bernstein [Translated into Japanese by MAENO Toshinori] Internet publication djbdns
1. DNS キャッシュを DNS サーバから分離することの重要性
DNS キャッシュ には常に DNS サーバとは別の IP アドレスをもたせるべきです。 言いかえると、 /etc/resolv.conf に書かれている IP アドレスは NS レコードに表われる IP アドレスとはけして一致してはいけないのです。
このように分離することは DNS を運用する上での正しい方法だと広く知られています。
DNS and BIND 本の第三版でも以下のように書かれています。 Securing Your Name Server, page 255:
Some of your name servers answer nonrecursive queries from other name servers on the Internet, because your name servers appear in NS records delegating your zones to them. ... You should make sure that these servers don't receive any recursive queries (that is, you don't have any resolvers configured to use these servers, and no name servers use them as forwarders).
参考訳
あなたのネームサーバの中にはインターネットの他のネームサーバからの非再帰問合せに答えるものがあるはずである。なぜなら、あなたのゾーンを委譲するためのNS レコードにそのサーバ名が書いてあるのだから。これらのサーバは再帰問合せをけして受け取らないようによく注意すべきである。 (つまり、これらのサーバを使うようにリゾルバを設定してはならないし、ネームサーバのフォワーダとして指定してはならない。)
ひとびとを脅して djbdns を使わせないように なんだって言うような BIND 推進者の Brad Knowles さえ 2002 年 11 月の発表のスライド 45 で、サーバとキャッシュを分けるべきことを認めているのは興味深いことです。
Split functions onto separate machines or IP addresses. Authoritative servers should be authoritative-only. ... Recursive/caching servers should not be authoritative.
2002年 12月には遂に BIND 会社も同様のことを言っている声明を出した: (which has always separated its own f.root-servers.net server from its caches)
Although BIND can provide both functions (authoritative and non-authoritative) in single instance, ISC recommends always separating these two functions. In other words, you should run one server for your authoritative zones, and another that caches non-authoritative data.
BIND を使っていて、キャッシュとサーバを同じ IP アドレスに設定するという間違いを犯しているなら、直すのです。 段階を追って修正する方法は djbdns に置きかえる方法にあります。もし、置き換えないとしても、間違いは正すべきです。
Unfortunately, the idea of combining a cache with a server hasn't been stamped out yet. Brad Knowles はおなじ発表の スライド 74 で "djbdns Con" として、 dnscache と tinydns は 同一の IP アドレス上で実行できない分離されたプログラムであるという事実をあげています。 BIND 会社のソフトウェアインストール説明書では疑うことを知らない利用者に対してキャッシュとサーバを同じ IP アドレスで動かすようにしむけています。
このページの残りではキャッシュとサーバを分離することが重要である理由をいくつか説明しています。
1.1. セキュリティ(安全性)と信頼性
攻撃者があなたの DNS キャッシュを乗っ取ってしまったとしましょう。 もし、おなじプログラムが DNS サーバでもあったら、攻撃者は検索によって取りこまれる DNS データだけではなく、 外部に提供される DNS データまで自由にできるのです。 攻撃者はあなたのサイトから外部にでていくウェッブ接続を別のところへ誘導できるだけでなく、 あなたのサイトへ入ってくるはずのウェッブ接続も別のところへ誘導できるのです。
別の例として、ローカルユーザがあなたの DNS キャッシュを扱かいきれないくらいの仕事をさせて、あふれさせてしまったとしましょう。 DNS サーバもそのプログラムで実行されていたら、あなたのサイトから外部のウェッブが見られなくなるだけでなく、 (訳注：DNS サーバにアクセスできなくなるために) 外部からあなたのサイトのウェッブに接続できなくなるかもしれません。
DNS キャッシュと DNS サーバとを分離することで、 DNS キャッシュでの問題から DNS サーバを守ります。 逆のこと(DNS サーバの問題からキャッシュを守る)もあります。
これが RFC 2010 と RFC 2870 で、ルートサーバの運用者に分離キャッシュを使うように言っている理由であり、 "DNS and BIND" 本が『すべて』のサーバ運用者に分離キャッシュを使うように言っている理由であります。 本の言葉を借りると、この分離は "eliminates a major vector of attack." となります。
1.2. モジュラリティ(分割構造)
ほとんどの DNS キャッシュプログラムはただひとつの仕事、つまり DNS データを検索することしかしません。 データを公表することはしません。 DNS キャッシュと DNS サーバを分離することにより、 DNS サーバに影響を与えることなしに DNS キャッシュソフトウェアを簡単に置きかえることができるようになります。 (Analogy: Apache サーバには影響を与えることなく、 Squid に換えて別の HTTP キャッシュを使うようにできる。)
同様に、ほとんどの DNS サーバプログラムもただひとつの仕事、データを公表することしかしません。 それらはキャッシュではありません。 DNS キャッシュと DNS サーバを分離することにより、 DNS キャッシュに影響を与えることなしに DNS サーバソフトウェアを簡単に置きかえることができるようになります。 (Analogy: Squid には影響を与えることなく、 Apache サーバに換えて別の HTTP サーバを使うようにできる。)
要約すると、分離によってソフトウェア選択の自由度が増えるのです。 サーバとキャッシュをくっつけたモノリシックなプログラムにしばり付けられる必要はないのです。 RFC 1035 の 6 ページにある図をみてみましょう: "user program" (クラアント), "resolver" (キャッシュ), "name server" (サーバ) に対して、異なるソフトウェアを選べるのです。
この自由度が増えたことにより、DNS 実装者間での競争がしやすくなります。 新しい DNS サーバを書くことが容易になります。 サーバの実装者はキャッシングの複雑さに悩む必要がないからです。 同様に 新しい DNS キャッシュを書くことが容易になります。
この競争によりソフトウェアはより速く発展します。 それにより、実装者は気をゆるめられません。 長い間にはすべての人が modularity, flexibility, competition, evolutionからの利益を受けます; あなたが今現在はモノリシックなサーバ兼キャッシュプログラムに満足しているとしても、モジュラリティを支援すべきです。
2003-08-10 訳：前野年紀 (2010-05-12 移転）