qmail のPOP認証にめちゃくちゃ時間がかかる人への解決策の案

あるとき（ずっとまえ）、Turbo Linux Server 6.5 を使っている間は全く問題なく使ってきたのですが、そのマシンが不調になりまして
Turbo Linux 7 Serverに移りました。
すると、環境の違いは多少なりありますが、遅くなったところが大きく２つ。
　１）Apache をローカルから開く時
　２）qmail へのログイン

Apacheのローカルログインが遅いのはホスト名解析の為だと言うことは動作から想像できます。
外部からはちゃんと普通に使えますから。
じゃあその場合、手っ取り早く　/etc/hosts　にクライアントの名前を登録してしまえば良いのです。
クライアントのIPを
10.0.0.200　　client_no_1
とか書いておけばそれは解決しました。

さて、問題はメールへのログインです。
私はtcpserver経由でpop before smtpを使っているのでその辺をいろいろと試してみました。

諸般の説明ではtcpserverがホスト名を調べる為に時間がかかってしまうという説明を見かけます。
tcpserverのタイムアウトには26秒で、それを回避するには-HRオプションをつけて起動させると良いと。

同様の事は私の過去の記録に触れています。ここにあるよ
とうぜんその設定をしてある上で認証が遅れているので、別の要因です。
そして待ち時間は1.5〜２分と、とても長い。

さて、結論から言いますと、サーバーが自分の名前を引こうとしていたのです。逆引きです。

私の場合は 10.0.0.100 がサーバーです。これを名前解決しようとしてるわけです。
そもそも通常ならhostsを見て解決してくれるべきなのです。
Apacheはちゃんと見てくれたのですが、tcpserverは見てくれないのでしょうか？
host.confでもちゃんとhostsから見るように指定してあるのに・・・・・

見てくれないなら、bindに登録してしまえ！！
ということで

/etc/named.conf
にはこんな感じで逆引きzoneを書き加えます。
   zone "0.0.10.in-addr.arpa" {
     type master;
     file "named.me";
   };
192.168.0.1の場合なら
   zone "0.168.192.in-addr.arpa"{
って感じですね。
そしたらzoneファイル次のように作ります

/var/named/named.me

   $TTL 86400
   @ IN SOA localhost. root.localhost. (
   20030408 ; Serial
   28800 ; Refresh
   14400 ; Retry
   3600000 ; Expire
   86400 ) ; Minimum
   IN   NS   localhost.
   100  IN  PTR   localhost.
 

100の数字は各自のサーバーのIPの最後の8ビットを入れてくださいね。
これで /etc/init.d/named restart
をかければホスト自身の逆引きはＯＫになるハズ。
私はこれで快調　快調・・・

遅れましたが、みなさん、メールサーバーを立ててる訳だから当然bindは動いてますよね？

Update 2003.4.8

※ ２００６年１月８日（日）早朝より
　なんだか日本の広範囲でqmailをtcpserverで使ってたマシンが上記のような認証で引っかかりはじめたようですね。急にです。
　自分の管理している会社のサーバー、それまで異常無く順調に動作していたグローバルなサーバーなんですが急に認証に時間がかかるようになってしまいました。
　半日かけてしらべてたけどどうもよくわからない。そうこうしているうちに別のグローバルサーバーも同じ現象になっているのに気づき、最初は故障を疑ってたんだけど２台いっしょってのでどうやらこの名前の認証の関連かなと思って・・・・・
　もともとグローバルなIPなので上記の問題はでなかったんだけど、急にダメになったらしい。
　このサーバーはNIC２枚でグローバルとローカルの併用。２台とも同じ。
　調査開始より６時間たった今、やっぱり上記の記事の黄色の部分を追加することで解決しました。やっぱりローカルアドレスを逆引きしはじめたんですね。
　それはそうと今日この現象が発生したマシンは日本内に結構多い様です。というのも、私が２台同時に発生し、このサイトへの検索キーワードもやけにqmailの110ポートの認証が遅いという項目がすごく増えてます。
　きっかけが何なのかわかりませんが、DNSが次の様なメッセージを大量に吐き出した頃からおかしくなってます。
　　 lame server resolving 'x.x.x.xx.in-addr.arpa' (in 'xx.in-addr.arpa'?): 192.175.48.42#53 　　・・・アドレスは伏せてます
　ローカルアドレスからの検索みたいに見せてるからアタックかなぁとも思うけど大量のログとともにqmail障害なんでたぶんこれ。
　対策後は問題ないけど、８日日曜、９日祝日の明けの10日あたりに結構困る会社があったりするんじゃないかなぁ？
　

ast Update 2006.1.8