🚀 go-pugleaf

$B?7>k!wC^GHBg3X>pJs$G$9!#$3$s$K$A$O!#(B

In article <86isp3xrmr.fsf@poe.mob.or.jp>
	IKEDA Kenji <noroi-fj@mob.or.jp> writes:
> $B<ALd$H$$$&$h$j!"$[$\%0%A$K6a$$$b$N$G$9$,!"(B
> 	$B$I$&$7$F(B BIND $B$G$O!"(Bforward last $B$N;XDj$,$G$-$J$$$N$G$7$g$&(B?

forward last $B$C$F!"2?$J$s$G$7$g$&!)(B

> named.conf $BFb$K=q$+$l$?(B zone $B$KL5$1$l$P(B forwarders $B$KJ9$-$K$$$/(B
> $B$H$$$&$N$O!"$H$F$b<+A3$J$3$H$K;W$&$N$G$9$,!D(B
> # forwarders $B$r@h$K8+$K9T$/$H$&$l$7$$>l9g$C$F$"$k$N$+(B?

bind$B$C$F!"(Bslave $B$K$J$C$F$$$F!"(Bcache $B$,$"$k$O$:$J$N$K(B 
forwarders $B$r8+$K9T$/$s$G$9$+!#(B

forwarders $B$r;H$o$J$$!"$H$$$&OC$O$"$j$^$9$+!#(B

bind $B$r#28D$"$2$F!"(B
    $B#1$D$O!"(Bforwarders $B$7$F<u?.MQ!"(B
    $B$b$&#1$D$O!"(Bforwarders $B$J$7$G@$3&$X$NH/?.MQ(B
$B$H$9$k$H!"$$$$$N$+$b$7$l$J$$$1$l$I!"#28D$"$2$k$N$b$M!#(B

$B!@!@!!?7>k!!Lw!!!J$7$s$8$g$&!!$d$9$7!K!!!@!@(B
$B!@!@!!C^GHBg3X!!EE;R!&>pJs!!!!!!!!!!!!!!!@!@(B

さすがに BIND4 の記憶はもうなかったり… 8 か 9 で願います。

In article <YAS.03Aug13004124@kirk.is.tsukuba.ac.jp>,
	yas@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 を２個あげて、
>     １つは、forwarders して受信用、
>     もう１つは、forwarders なしで世界への発信用
> とすると、いいのかもしれないけれど、２個あげるのもね。

??? ゾーンを提供するゾーンサーバーと、クライアントからの再帰問合せを処
理するキャッシュサーバーを分けるという話ですか?
そらまぁ、分けるのが普通だとは思いますが、今回の話とはまったく関係あり
ません。つか、今回はゾーンサーバーの話はしてません。

-- 
池田研二  稲城駅前在住

IKEDA Kenji <noroi-fj@mob.or.jp> writes:

> 	どうして 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 <noroi-fj@mob.or.jp> writes:

> ??? ゾーンを提供するゾーンサーバーと、クライアントからの再帰問合せを処
> 理するキャッシュサーバーを分けるという話ですか?
> そらまぁ、分けるのが普通だとは思いますが、今回の話とはまったく関係あり
> ません。つか、今回はゾーンサーバーの話はしてません。

ってことは，named.confにはzone type masterもslaveもstubも無くて，type
forwardかtype hintだけなんですよね．type hintはスタート時にしか使わな
いでしょうから，池田さんの「グチ」は「グローバルなoptionで指定した
forwardersよりtype forwardのzoneを優先して欲しい」という解釈で良いです
か?

				前田敦司

In article <m3k79ii6z9.fsf@maedapc.cc.tsukuba.ac.jp>,
	MAEDA Atusi <maeda@cc.tsukuba.ac.jp> wrote:

> 池田さんのおっしゃるforward lastってのは，
> 「まず自分で反復問い合わせを行ない，失敗したらforwardersに問い合わせる」
> ことを期待されてるんでしょうか? 

やりたいことはそうです。詳しくは <86k7k5yb1s.fsf@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 内から外の名前が引けなきゃいけないのかといわれると…
# でも、あると便利なんですよ。

-- 
池田研二  稲城駅前在住

IKEDA Kenji <noroi-fj@mob.or.jp> writes:

> > 池田さんのおっしゃるforward lastってのは，
> > 「まず自分で反復問い合わせを行ない，失敗したらforwardersに問い合わせる」
> > ことを期待されてるんでしょうか? 
> 
> やりたいことはそうです。詳しくは <86k7k5yb1s.fsf@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サーバを立てる」というのが考慮されてないだけで．

				前田敦司

On 13 Aug 2003 15:59:41 +0900,
	In article <m3d6fahwki.fsf@maedapc.cc.tsukuba.ac.jp>,
	MAEDA Atusi <maeda@cc.tsukuba.ac.jp> wrote:

> この記事は読めませんでしたので，推測で書きます．

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 を使って内部の名前を解決すればいいですね。

たぶん、森氏が、<80wunzypwf.fsf@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系
以外では使えないので、他人に使えとはなかなか… 自分で使う分には楽でい
いんですけど。


ありがとうございます。かなり光明が見えてきました。

# でも、「他んところでは困ってないのかなぁ?」という疑問はあいかわらず…

-- 
池田研二  稲城駅前在住

IKEDA Kenji <noroi-fj@mob.or.jp> writes:

> 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ならできますね．

				前田敦司

On 13 Aug 2003 18:17:09 +0900,
	In article <m3znidhq7e.fsf@maedapc.cc.tsukuba.ac.jp>,
	MAEDA Atusi <maeda@cc.tsukuba.ac.jp> wrote:

>> FORWARDONLY=1 で使うと、@ に再帰検索投げることしかしなくなり、他のデー
>> タは見なくなります。

> このあたり，よく知りませんでした．
> http://www.geocrawler.com/mail/msg.php3?msg_id=5020014&list=514
> によると，@以外の(ドメインごとの)サーバも指定できるみたいですが，再帰
> 検索しかしなくなるんですね．

うう。間違ってそうです。なんかそう思い込んでましたが、根拠となるものが
見つからない…

-- 
池田研二  稲城駅前在住

谷口@葛飾区　です。

私の場合は、たまたま情報システム部がゾーン転送を許可していたので
slaveで設定しちゃいました。というか、そういう経験を過去にした
人間に聞いて、同じ事を行っただけです。
個人的にはきれいな解決方法じゃないと思っているし、なんかスマートな
ほかの方法はないかしらん、と未だ思っております。


IKEDA Kenji wrote:

> On 13 Aug 2003 15:59:41 +0900,
> 	In article <m3d6fahwki.fsf@maedapc.cc.tsukuba.ac.jp>,
> 	MAEDA Atusi <maeda@cc.tsukuba.ac.jp> wrote:
> 
> 
>>この記事は読めませんでしたので，推測で書きます．
> 
> 
> 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 を使って内部の名前を解決すればいいですね。
> 
> たぶん、森氏が、<80wunzypwf.fsf@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系
> 以外では使えないので、他人に使えとはなかなか… 自分で使う分には楽でい
> いんですけど。
> 
> 
> ありがとうございます。かなり光明が見えてきました。
> 
> # でも、「他んところでは困ってないのかなぁ?」という疑問はあいかわらず…
>