どさにっきクラウド 〜2009年8月中旬〜

by やまや
<< = >>

2009年8月18日(火)

unbound

_ いじり中。いや、キャッシュ DNS を置き替えようとかそういう目的ではなく。つーか、うちのはとっくの昔に置き替え済みだし。

_ unbound は応答が複数レコードあった場合、何度問い合わせても常にキャッシュに入ったときの順番で応答する、よーするにラウンドロビンが機能しない、という仕様。これ、なんとかならんかな、とソースを覗いてみる。

_ んー、そんなにめんどくさくなさそう。応答すべき内容を格納してる構造体から実際に DNS 応答を生成してる部分のところにちょちょいとパッチを当てて完了。

_ で、コンパイルして試してみる。……あれー? 変わんないよ? なんで?

_ 調べてみると、応答に複数のレコードが含まれる場合でも、rep->an_numrrsets の値がそのレコード数じゃなくて 1 になってる。乱数で応答順をずらそうにも、1個しかなければ変わりようがない。なんで? answer section のレコード数だけでなく、authority section のレコード数も同様。なのに、additional section につっこむレコード数は実際の値になってる。よーわからん。なんでこれで動いちゃうの? って、実際これで動いてるんだから、わしが見てるところがおかしいのか。

apache のコメント

_ 会社でハマってる人がいた。httpd.conf や .htaccess の正しいコメントの書き方。

# comment
Directive arg
間違ったコメント。
Directive arg     # comment
前者のようにコメントはディレクティブとは別に独立した行に書かなければならない。後者のように書くと、# comment という文字列はコメントではなく Directive の引数の一部として認識される。ので、引数チェックにひっかかってエラーになるかもしれないし、任意の数の引数を取るようなディレクティブだと何も起きない(ように見える)かもしれない)。

_ で、そのハマり主にツッコミを入れておいた後、そういえばこれ、場合によってはもしかしたらセキュリティ的にまずいことが起きるかもなー、と気がついた。たとえば、もともと

Allow from 192.0.2.1 192.0.2.2
となっていた設定から、192.0.2.2 は不要になったとしてコメントアウトしたいとする。で、不用意に
Allow from 192.0.2.1 # 192.0.2.2 はもういらない
とか書いちゃうと、許可してるホストは 192.0.2.1 のひとつではなく、「192.0.2.1」、「#」、「192.0.2.2」、「はもういらない」という4ホストからのアクセスを許しちゃうことになる。コメントアウトしてアクセスできないようにしたつもりの 192.0.2.2 が依然アクセスできるまま、というのはよろしくない。「#」「はもういらない」というわけわからんホスト名は実際には存在しないから問題ないように見えるけど、HostNameLookups off の設定でもこいつらのせいで DNS 問い合わせが発生してしまう。しかも困ったことに、この間違いは気づきにくい。

_ まあ、たぶんそうなるだろうというだけで、ほんとにそういう動作をするという確認はしてないけどね。もしかしたら fool-proof で allow/deny に限っては # 以降を無視する、とかいうコードになってるかもしれんし。


2009年8月19日(水)

unbound でラウンドロビン

_ きのうのつづき。えー、ちゃんとラウンドロビンできました。きのういじってた関数ではなく、その関数から呼ばれる下請け関数をいじるのが正解でした。

_ ということで、 パッチ

% dig +short @127.0.0.1 chaos txt version.bind
"unbound 1.3.3"
% dig +short @127.0.0.1 www.yahoo.co.jp | head -1
203.216.227.176
% dig +short @127.0.0.1 www.yahoo.co.jp | head -1
203.216.247.249
% dig +short @127.0.0.1 www.yahoo.co.jp | head -1
124.83.147.203
てな感じで、応答順が毎回変わる。

_ ……なーんて、実用には使えません。unbound はポート番号や query id のランダム化のために自前の乱数関数を持ってるけど、その関数を使うために必要な乱数状態の変数がパッチを当てた場所では入手できないので(毎回初期化するのもアホだし)、ふつーに random(3) を使ってる。が、random() はスレッドセーフではなく、unbound はスレッドを使っている:-)。どーせいいかげんなんで srandom() もサボり。つーことで、もし実戦投入するつもりがあるなら乱数まわりをちゃんと書き直しましょう。つーか誰か直して。

_ ちなみに djbdns の dnscache もラウンドロビンしません。

repeat

_ csh のビルトインに repeat という便利なコマンドがありまして。

% repeat 5 echo hoge
hoge
hoge
hoge
hoge
hoge
つまり指定したコマンドを指定回数だけ繰り返す、という単純なものなんだけど、いろいろテストしたりするときなんかはわりと重宝する。上の unbound のパッチを書いたときも dig を繰り返し実行させるのに使った。

_ なんかおかしい。

% repeat 5 echo hoge | cat
hoge
hoge
hoge
hoge
hoge
アボート(coreを出力しました)
パイプでうしろになんかつなげると死ぬ。そのうしろにあるコマンドをちゃんと実行した後で死んでるというのが律儀というか何というか。

_ FreeBSD 6.4、7.1 の tcsh 6.15.00 だと死ぬけど、5.4 の tcsh 6.13.00 だと死なないので、バージョンが上がる過程でどっかエンバグされたっぽい。


2009年8月20日(木)

nsd でラウンドロビン

_ コンテンツサーバではラウンドロビンする必要性はそんなに高くないんだけど、でもラウンドロビンしないキャッシュサーバと組み合わさると目も当てられない悲惨な偏り方になるので、できないよりはできた方がいい。つーことで、 きのうの unboundに続いて nsd でもラウンドロビンさせてみた。unbound と違ってこっちはふつーに random(3) で問題ないので、そのまま実戦投入可、のはず。

_ ちなみに、djbdns の dnscache はラウンドロビンしないけど、tinydns の方はやってくれます。


<< = >>
やまや