おはようございます。谷川です。 あれから RFC 1034, 1035, 2181 を眺めながらいろいろ考えているうち に基本的な事に気がつきました。(ソースのハードルが高いので、何と か読まないですむようにしたい一心からです。)
もう一度 DNS問合わせの結果全体を見てみると、 % dig mx rohm.co.jp ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12961 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;rohm.co.jp. IN MX ;; ANSWER SECTION: rohm.co.jp. 600 IN MX 5 sfgw.rohm.co.jp. rohm.co.jp. 600 IN MX 10 mail.rohm.co.jp. ;; AUTHORITY SECTION: rohm.co.jp. 37754 IN NS ns.tokyo.spin.ad.jp. rohm.co.jp. 37754 IN NS ns.spin.ad.jp. ;; ADDITIONAL SECTION: ns.spin.ad.jp. 44476 IN A 165.76.4.2 ns.tokyo.spin.ad.jp. 52183 IN A 165.76.8.2 RFC 1034 では DNS問合せに対する MXの回答の ADDITIONAL SECTION に MXのアドレスを含めておくよう要求しています。次に発生することが予 見できる無駄な DNS問合わせを減らすための有効な手段です。 ほとんどの MX の問合わせに対してこの DNSサーバからは ADDITIONAL SECTION から MX の Aレコードが欠落した回答しか返ってきません。 短時間に連続して問合わせてみると、たまに思い出したかのように不完 全な情報が付加される時もあります。メールの送信や再送時のように時 間があいている場合はまず上記の MXのアドレスが欠落した状態になる ようです。 これは、 % dig mail.rohm.co.jp ;; ANSWER SECTION: mail.rohm.co.jp. 10 IN A 125.206.241.124 mail.rohm.co.jp. 10 IN A 202.33.138.44 mail.rohm.co.jp. 10 IN A 124.37.35.124 のとおり TTL が極端に短い設定になっている事が原因の副作用だと想 像できます。 たとえ TTL が 10秒であっても ADDITIONAL SECTION から MXの Aレコー ドが欠落した回答を返してしまうことはネットワーク管理者にとっては 非常に恰好悪い事です。 もしかして BIND じゃ無い*何か*なのかも知れません、、、(うへっ!) % dig @ns.spin.ad.jp mx rohm.co.jp % dig @ns.tokyo.spin.ad.jp mx rohm.co.jp と、直接ネームサーバに問合わせてても ADDITIONAL SECTION からは MXの Aレコードが欠落した回答となりますので言い訳はできないでしょ う。:-) sendmailは MXが同一ドメイン内の host であれば一回の MXの DNS問合 わせで MXの IPアドレスを取得しようとしているようです。不要な DNS問合わせを抑えるための RFC どおりの理に適った動作です。'host name lookup failure' と判断するのも納得できます。 MXが他ドメインにある場合には一回の DNS問合せで MXの IPアドレスを 得ることはできませんので、もちろん Aレコードを引き直します。 ここで sendmail に手を入れて MXが同一ドメイン内に存在することが 分かっていても一回だけ MXが他ドメインにある場合と同様に Aレコー ドを引き直すようにしてしまえば、とりあえず回避はできそうですが、 この回避策は DNSのトラフィックを押し上げてしまうので RFC的にも異 議ありとなりそうです。 Aレコードを引き直す代りに /etc/hosts を参照するのなら許してもら えそうです。 やはり想像どおり sendmail は堅くて頑固でまるで「おやじ」のような 奴です。曲ったことは大嫌いなところが憎めません。:-) これはインターネットのため、世界平和のためにも JENS(SpinNet)さん にお願いして直してもらうのが筋だと思うのですが、皆さんいかがなも のでしょうか? (何かしらの裏打ちがあれば、、、) # ソースを確認したわけでは無いので間違いがあればご指摘お願いしま # す。さらに qmail, postfix の挙動も気になるところです。 -- 谷川 達也 TANIKAWA Tatsuya mailto: tatsuy...@sannet.ne.jp PGP Key fingerprint = 1D 8D CB 10 8A 8B 67 B0 9A B9 9C 14 37 50 BC F5
