どうして BIND では、forward last の指定ができないのでしょう?
named.conf 内に書かれた zone に無ければ forwarders に聞きにいく
というのは、とても自然なことに思うのですが…
# forwarders を先に見に行くとうれしい場合ってあるのか?
--
池田研二 稲城駅前在住
In article <86isp3x...@poe.mob.or.jp>
IKEDA Kenji <noro...@mob.or.jp> writes:
> 質問というより、ほぼグチに近いものですが、
> どうして BIND では、forward last の指定ができないのでしょう?
forward last って、何なんでしょう?
> named.conf 内に書かれた zone に無ければ forwarders に聞きにいく
> というのは、とても自然なことに思うのですが…
> # forwarders を先に見に行くとうれしい場合ってあるのか?
bindって、slave になっていて、cache があるはずなのに
forwarders を見に行くんですか。
forwarders を使わない、という話はありますか。
bind を2個あげて、
1つは、forwarders して受信用、
もう1つは、forwarders なしで世界への発信用
とすると、いいのかもしれないけれど、2個あげるのもね。
\\ 新城 靖 (しんじょう やすし) \\
\\ 筑波大学 電子・情報 \\
In article <YAS.03Au...@kirk.is.tsukuba.ac.jp>,
y...@is.tsukuba.ac.jp (Yasushi Shinjo) wrote:
> forward last って、何なんでしょう?
named.conf の options で指定する foward の話です。
options {
...
[ forward ( only | first ); ]
...
};
ってヤツですね。first か only を指定できますが、なんで last が無いんだ
ろうという…
> bindって、slave になっていて、cache があるはずなのに
> forwarders を見に行くんですか。
まず、この「slave」って、どっちの意味ですか?
type slave な zone のことですか?
それとも、遥か昔にあった slave オプション(今の forward only)のことですか?
> forwarders を使わない、という話はありますか。
は? あぁうぅ… ここにはありませんとしか…
> bind を2個あげて、
> 1つは、forwarders して受信用、
> もう1つは、forwarders なしで世界への発信用
> とすると、いいのかもしれないけれど、2個あげるのもね。
??? ゾーンを提供するゾーンサーバーと、クライアントからの再帰問合せを処
理するキャッシュサーバーを分けるという話ですか?
そらまぁ、分けるのが普通だとは思いますが、今回の話とはまったく関係あり
ません。つか、今回はゾーンサーバーの話はしてません。
--
池田研二 稲城駅前在住
> どうして BIND では、forward last の指定ができないのでしょう?
>
> named.conf 内に書かれた zone に無ければ forwarders に聞きにいく
> というのは、とても自然なことに思うのですが…
>
> # forwarders を先に見に行くとうれしい場合ってあるのか?
Forwardingが行なわれる場合(つまり,自分がauthoritativeな情報を持ってい
ないzoneへの再帰問い合わせを受けとり,キャッシュにもなかった場合)に,
・forward first … forwarders に再帰問い合わせをforwardし,
forwardersが失敗したら自分で反復問い合わせを行なう.
・forward only … forwarders に再帰問い合わせをforwardし,
forwardersが失敗したらそのまま失敗を返す.
ですよね.池田さんのおっしゃるforward lastってのは,
「まず自分で反復問い合わせを行ない,失敗したらforwardersに問い合わせる」
ことを期待されてるんでしょうか?
また,この場合に,「named.conf 内に書かれた zone」がどう効いてくるんで
しょう? 自分がmasterやslaveであるzoneに関しては,forwardingは行なわれ
ないですよね?
IKEDA Kenji <noro...@mob.or.jp> writes:
> ??? ゾーンを提供するゾーンサーバーと、クライアントからの再帰問合せを処
> 理するキャッシュサーバーを分けるという話ですか?
> そらまぁ、分けるのが普通だとは思いますが、今回の話とはまったく関係あり
> ません。つか、今回はゾーンサーバーの話はしてません。
ってことは,named.confにはzone type masterもslaveもstubも無くて,type
forwardかtype hintだけなんですよね.type hintはスタート時にしか使わな
いでしょうから,池田さんの「グチ」は「グローバルなoptionで指定した
forwardersよりtype forwardのzoneを優先して欲しい」という解釈で良いです
か?
前田敦司
> 池田さんのおっしゃるforward lastってのは,
> 「まず自分で反復問い合わせを行ない,失敗したらforwardersに問い合わせる」
> ことを期待されてるんでしょうか?
やりたいことはそうです。詳しくは <86k7k5y...@poe.mob.or.jp> を。
結論からすると、bind ではできません。ただ、forward first って、何が嬉
しいのかなと、グチが…
先のを投稿した後、つらつら考えるに、hint に書かれた root server 群が、
アクセスするには遠い(ないしは高価な)ネットワーク上にあり、forwarders
に書かれたサーバーに再帰問合せする方が近い(ないしは安価な)環境のための
仕組みなのでしょうね。うちと逆。つうか、FW 内に大規模なネットワーク持っ
てるところって、どこもうちと同じなんじゃなかろうか?
> ってことは,named.confにはzone type masterもslaveもstubも無くて,type
> forwardかtype hintだけなんですよね.
作りたいキャッシュサーバーは 2種類で、
A. 中が見えればいい type hint (+0.0.127.in-addr.arpa) だけのもの
B. 外も見せたい type hint + forwarders のもの
です。で、B が、『まず自分で反復問い合わせを行ない、失敗したら
forwarders に問い合わせる』のタイプです。
もちろん、A は簡単に実現できます。問題は B。
上に「できません」と書きましたが、不本意な方法を使えばできます。
1. options の forwarders に、外を引けるキャッシュサーバーを指定。
2. type hint な指定は無し。(意味がないから)
3. XXXX.JP 等のゾーンの slave になる。
でも、3. を実現するには XXXX.JP 等のゾーンの master に、zone transfer を
許可する必要があります。が、そんなことはしたくはないのです。
# このあたりが我儘かなぁ。でも、当該組織のトップドメインのゾーンサーバー
# を管理している部署と、全国にある B タイプのキャッシュサーバーの管理
# 部署はまるで違うわけで、こんなことで、allow-transfer { any; }; にし
# とくのはアレだし、B タイプのキャッシュサーバーが増減するたび記述を修
# 正するってのも…
type hint が任意のゾーンで指定できればいいのですが、少なくとも
bind-8.3.4 は、"." 以外のゾーンを認めてません。
# type stub でも AXFR を投げてるような。その後、SOA と NS を別途取りに
# 行くようですが。
仮に type ns のようなゾーン種があり、そのゾーンに権威を持つ NS のアド
レスを直指定できれば、話は簡単なのですが…
で、それよりも何よりも、
options { forward last; forwarders {...}; ... };
zone "." { type hint; ... };
ができれば、一番簡単なんですよね。なにより、管理しなきゃいけない情報は
内部ルートサーバーと、forwarders の2種のアドレスだけ。もちろん中だけで
いいなら、内部ルートサーバーのアドレスだけでいい。タイプ A と B の違い
も一目瞭然。とても見通しのいいnamed.conf になるんだけどなぁ。
…ということで、あのグチに継がるわけです。
で、他にもそう感じてる人はいないんだろうか、と。
# FW 内から外の名前が引けなきゃいけないのかといわれると…
# でも、あると便利なんですよ。
--
池田研二 稲城駅前在住
> > 池田さんのおっしゃるforward lastってのは,
> > 「まず自分で反復問い合わせを行ない,失敗したらforwardersに問い合わせる」
> > ことを期待されてるんでしょうか?
>
> やりたいことはそうです。詳しくは <86k7k5y...@poe.mob.or.jp> を。
この記事は読めませんでしたので,推測で書きます.
> 結論からすると、bind ではできません。ただ、forward first って、何が嬉
> しいのかなと、グチが…
>
> 先のを投稿した後、つらつら考えるに、hint に書かれた root server 群が、
> アクセスするには遠い(ないしは高価な)ネットワーク上にあり、forwarders
> に書かれたサーバーに再帰問合せする方が近い(ないしは安価な)環境のための
> 仕組みなのでしょうね。うちと逆。つうか、FW 内に大規模なネットワーク持っ
> てるところって、どこもうちと同じなんじゃなかろうか?
ようするに,FW内だけで(root-servers.netとは別のツリーの)コンテンツサー
バを立てることは,あまり考慮していないんだと思います.
forward onlyは「外へ引きに行くにはforwarders経由でしかできない」場合.
forward firstは「外へ引きに行った結果は,なるべくforwardersでキャッシュ
したい(その方が速い)けど,forwardersが落ちている場合はしかたないから自
分で引きに行くことができる」場合.
中を引く場合(というか,ドメインによってルートサーバが異なる場合)の話は,
あまり考えていないんじゃないかと.
> A. 中が見えればいい type hint (+0.0.127.in-addr.arpa) だけのもの
> B. 外も見せたい type hint + forwarders のもの
>
> です。で、B が、『まず自分で反復問い合わせを行ない、失敗したら
> forwarders に問い合わせる』のタイプです。
>
> もちろん、A は簡単に実現できます。問題は B。
>
> 上に「できません」と書きましたが、不本意な方法を使えばできます。
>
> 1. options の forwarders に、外を引けるキャッシュサーバーを指定。
> 2. type hint な指定は無し。(意味がないから)
> 3. XXXX.JP 等のゾーンの slave になる。
> でも、3. を実現するには XXXX.JP 等のゾーンの master に、zone transfer を
> 許可する必要があります。が、そんなことはしたくはないのです。
確かにそんなのは嫌ですよね.独立して管理できるにこした事はない.
(別解1)
1. type hintな(Aのタイプの)キャッシュサーバを別に立てる.
2. Bのサーバでは,type forwardで,内部の名前は1に聞きに行く.
というのはどうでしょう?
あるいはもうあっさり,
(別解2)
・djbdnsのdnscacheを使う.
が簡単な気がします.
echo 1 > env/FORWARDONLY
root/servers/@ にforwardersのリストを書く
root/servers/local.domain にlocal.domainのルートサーバのリストを書く
で良いですよね.
キャッシュならBINDから乗り換えても他のマシンの設定は全く変える必要がな
いし.
> # FW 内から外の名前が引けなきゃいけないのかといわれると…
> # でも、あると便利なんですよ。
外が引きたいのは当然だと思います.BINDでもその辺は考慮していると思う.
ただ,「中だけのDNSサーバを立てる」というのが考慮されてないだけで.
前田敦司
> この記事は読めませんでしたので,推測で書きます.
http://groups.google.co.jp/groups?hl=ja&selm=86k7k5yb1s.fsf%40poe.mob.or.jp
です。oe=UTF-8 とか oe=UEC-JP とかを加えた方がいいかもしれません。
> 中を引く場合(というか,ドメインによってルートサーバが異なる場合)の話は,
> あまり考えていないんじゃないかと.
そうなんでしょうねぇ。DNS&BIND には内部ルートを立てる話が載ってるくら
いなのに、どうして…
> (別解1)
> 1. type hintな(Aのタイプの)キャッシュサーバを別に立てる.
> 2. Bのサーバでは,type forwardで,内部の名前は1に聞きに行く.
> というのはどうでしょう?
あ、いいですね。この方が簡単だ。
A は普通のところ。事業部・部門・建屋・フロア・マシン毎に必要なだけ上げます。
広報されてる内部ルートサーバーのアドレスだけ知ってれば誰でも動かせます。
B は特殊なところ。外を見に行くんなら、ドメイントップのゾーンサーバー
(コンテンツサーバー)や forwarders に指定できるサーバーのアドレスの追っ
かけくらいしてね、と。
といったところを考えていたのです。A は山程のに対し、B を必要とするとこ
ろは少ないはず。B は 近くの A を使って内部の名前を解決すればいいですね。
たぶん、森氏が、<80wunzy...@kurishna.tri.asanuma.co.jp> で教えてく
れていた方法がこれなのかな? あの時は理解できなかったのですが。
http://groups.google.co.jp/groups?hl=ja&selm=80wunzypwf.fsf%40kurishna.tri.asanuma.co.jp
> (別解2)
> ・djbdnsのdnscacheを使う.
> が簡単な気がします.
FORWARDONLY=1 で使うと、@ に再帰検索投げることしかしなくなり、他のデー
タは見なくなります。なので、こういう場合は fwdzone patch を使う必要が
あります。この patch を当てると、ゾーン毎に反復か再帰かを明示的に決め
られるのでとてもスッキリはします。が、djbツールは敷居が高いし、UN*X系
以外では使えないので、他人に使えとはなかなか… 自分で使う分には楽でい
いんですけど。
ありがとうございます。かなり光明が見えてきました。
# でも、「他んところでは困ってないのかなぁ?」という疑問はあいかわらず…
--
池田研二 稲城駅前在住
> http://groups.google.co.jp/groups?hl=ja&selm=86k7k5yb1s.fsf%40poe.mob.or.jp
>
> です。oe=UTF-8 とか oe=UEC-JP とかを加えた方がいいかもしれません。
読めました.未着なのかと思ってましたが,過去の記事でしたか.
お手数をおかけしました.
> > (別解1)
> > 1. type hintな(Aのタイプの)キャッシュサーバを別に立てる.
> > 2. Bのサーバでは,type forwardで,内部の名前は1に聞きに行く.
> > というのはどうでしょう?
>
> あ、いいですね。この方が簡単だ。
少しはお役に立てたようで嬉しいです.(森さんの焼き直しだったかも知れま
せんが.)
> > (別解2)
> > ・djbdnsのdnscacheを使う.
> > が簡単な気がします.
>
> FORWARDONLY=1 で使うと、@ に再帰検索投げることしかしなくなり、他のデー
> タは見なくなります。
このあたり,よく知りませんでした.
http://www.geocrawler.com/mail/msg.php3?msg_id=5020014&list=514
によると,@以外の(ドメインごとの)サーバも指定できるみたいですが,再帰
検索しかしなくなるんですね.
複数のキャッシュにフォワードするようにするなら,けっきょく(別解1)と同
じですね.
> # でも、「他んところでは困ってないのかなぁ?」という疑問はあいかわらず…
fwdzone.patchを要求した人とかは同じように困ってるんでしょうねえ.
(例えばステートフルなFWを使って)どのマシンからでも直接外へ問い合わせが
できるなら,「内部はこのルートサーバ群へ,それ以外はroot-servers.netへ」
という設定がdnscacheならできますね.
前田敦司
>> FORWARDONLY=1 で使うと、@ に再帰検索投げることしかしなくなり、他のデー
>> タは見なくなります。
> このあたり,よく知りませんでした.
> http://www.geocrawler.com/mail/msg.php3?msg_id=5020014&list=514
> によると,@以外の(ドメインごとの)サーバも指定できるみたいですが,再帰
> 検索しかしなくなるんですね.
うう。間違ってそうです。なんかそう思い込んでましたが、根拠となるものが
見つからない…
--
池田研二 稲城駅前在住
私の場合は、たまたま情報システム部がゾーン転送を許可していたので
slaveで設定しちゃいました。というか、そういう経験を過去にした
人間に聞いて、同じ事を行っただけです。
個人的にはきれいな解決方法じゃないと思っているし、なんかスマートな
ほかの方法はないかしらん、と未だ思っております。