＞はい、１はその通りでございます。２と３の違いがよくわからずすみません。
＞現在はmacserver*1,maccliant*3,windowsXPclient*2という構成になっておりますので、名前解決ができると便利かなと考えたのがまず内部にDNSを使おうと考えたからで、これは２に近いかもしれません。３のDNSキャッシュサーバというのは例えば複数の端末が同じwebサイトを閲覧したときにWANへの無駄な読み込みを少なくするプロキシサーバのようなものなのでしょうか。あれば良いと考えておりますが、もちろんまだ設定は無いと思います。
外向けのコンテンツサーバ：LAN外部からの「外から見た自分のドメインに関する問い合わせ」にのみ答えるサーバです。LAN内部の情報は答えてくれませんし、自ドメイン以外に関する問い合わせにも答えません。
内向けのコンテンツサーバ：「LAN内部のみで使われるホスト名<->IPアドレスの対応表」を管理し、問い合わせに対して教えてくれるサーバです。LAN内部にあるクライアントに関する問い合わせにのみ返答し、LAN外部から来た問い合わせには返答しません。
内向けのキャッシュサーバ：LAN内部のクライアントからの「LAN外部の名前<->IPアドレスの問い合わせ(再帰検索)」を解決します。これは外部からの問い合わせには一切答えません。
bindではこれらを全部同じnamedで処理しちゃうので、動作がごっちゃになってる人が多いです。
djbdns(tinydns・dnscache)やnsd・unboundはコンテンツサーバのみ、キャッシュサーバのみ、という働きしかしません(出来ません)のでわかりやすいんですが……
bind8まではnamedを二つ立ち上げて、コンテンツサーバとキャッシュサーバとして動作していた(らしい。実はbind8は使ったことがない)のですが、bind9からはviewという機能で、アクセスして来たIPアドレスを判断基準として、キャッシュサーバとして振る舞うか否か、あるいはコンテンツサーバとして返すデータの中身を変えることが出来るようになりました。
aclとviewはこんな感じで記述します(鵜呑み禁止)。
acl internal {
127.0.0.0/8;#自分自身
192.168.1.0/24;#LAN内部
::1/32;#IPv6での自分自身
};
view "LAN"{
#内部向けのview。必ずこちらを先に書く。
match-clients {internal;}
#internalは上で定義したaclの名前。
#aclに書かれた問い合わせ元(=自分自身とLAN内部のクライアント)にのみ、このviewが使用される。
#aclを使わずに、ここにaclに書いたような条件を書いてもOK。
#LANからのアクセスなので再帰検索を許可します。
(略：その他の設定)
zone "example.com" {
(略)
#内向けのゾーンファイルを使用するように記述する。
};
zone "x.x.x.x.in-addr.arpa" {
(略)
#内向けの逆引きゾーンファイルを使用するように記述する。
};
}
view "INET" {
#外部向けのview。必ずこちらを後に書く。
#viewは複数定義出来る。評価は書かれた順番に行われ、一番はじめに適合したviewが使われる。
recursion no;
#外部からのアクセスなので再帰検索はしません。
(略：その他の設定)
zone "example.com" {
(略)
#外向けのゾーンファイルを使用するように記述する。
};
zone "x.x.x.x.in-addr.arpa" {
(略)
#外向けの逆引きゾーンファイルを使用するように記述する。
};
};
こんな感じでviewを定義してやることで、
・LAN内部と自分自身からの問い合わせについては再帰検索の結果も返すし内部の情報も返す
・それ以外からの問い合わせだった場合は自ドメインの外向けの情報(グローバルIPアドレスなAとかMXとかNSのレコード)のみ返す
という動作を実現できます。なので、ローカルIPアドレスで記述された内部向けのゾーンファイルと、グローバルIPアドレスで記述された外部向けのゾーンファイルの二種類が必要になります。
ちょっと文章の順番を変更します。
＞＞1.外向けのDNSコンテンツサーバのみ動かす。*.example.comに関する問い合わせに答える。管理するのは、このDNSコンテンツサーバだけ。
＞１は非常にシンプルな感じがします。
＞＞2.内向きのコンテンツサーバは置かず、*.localを使用して名前解決はBonjourにおまかせ(検索ドメインにlocal.を入れているので実質マシン名だけでアクセス出来る)。
＞＞サーバ以外はDHCPを使った動的IPアドレスでも問題無し。
＞２のBonjourが本当に判らなくて、解説書を読んでも、AppleTalkをTCP/IPに拡張したような、しかしAppleTalkのようにおしゃべりなプロトコルではないらしい。基本はLANだがAppleTalkのように外(WAN)にも出て行けるようだ。昔CiscoのルータにAppleTalkのゾーン作成などした記憶もありますが、10.6で完全にAppleTalkが消えて寂しいのはジジむさいでしょうか。しかし、時代の流れにはついていくつもりです。
名前解決だけがBonjourの機能ではありませんが、この際横に置いておきます。簡単に言えば、BonjourによるLAN内部の名前解決は、サーバによる集中管理ではなく、クライアントがお互いに呼び合うことで解決しています。内部の名前解決はBonjourで十分置き換え可能です。WindowsマシンにBonjourをインストールするのが嫌なら、Windowsマシンの台数が少ないようですし、いっそWindowsマシンについては昔懐かしいhostsファイルに書いてしまうというのも有りだと思います。
まぁとりあえず外に出るBonjourの事は忘れて、中でのみ使うようにしましょう。俺も中だけです。
＞＞3.DNSキャッシュサーバはルータにおまかせ(GoogleやOpenDNSでも可)。自ドメインの名前も問題無く解決出来る。ドメイン名でアクセスする場合は常に外からアクセ＞スする形になる。このキャッシュサーバはLAN内部にあるマシンの名前解決には使用されない。
＞３はとても新鮮です。Ciscoのルータでもできるでしょうか。古いモデルですが、知り合いの伝手から分けてもらえるものがあるので、できれば試してみたいです。
普通はブロードバンドルータが内向きに提供している機能です。ルータ自身が解決していることもあれば、外部のキャッシュサーバに問い合わせた結果を返すだけの物もあるようです。コンシューマ向けは後者じゃないかなー。
NTTが提供しているルータなら、備えている機能だと思います。試しにTerminalで
dig @192.168.1.1 www.apple.com. any
と実行してみてください(192.168.1.1はルータのLAN側IPアドレス)。キャッシュサーバが動いていれば、www.apple.comのCNAMEがwww.isg-apple.com.akadns.netである旨の結果が返ってくるはずです。
というか、今まで外のサイトにアクセスする時はどうしていたのかとお聞きしたいです。
＞＞4.ルータは外からの53/udpと53/tcpへの接続をサーバのIPアドレスの53/udpと53/tcpへ転送する。
＞４は具体的にどのようなメリットをもたらしますか。差し支えなければお教えいただけますでしょうか。
メリットというか、これをしないと外部からDNSコンテンツサーバへの問い合わせが届きませんので、誰もあなたのウェブサイトに辿り着けませんし、メールを送ることも出来ません。
