ドコモメール問題 解決編

ドコモのメール受信できない問題、一定の解決をみました。

結論からいうと、セカンダリDNSサーバの設定がよろしくなかった模様。

・セカンダリDNS側の設定が、セカンダリDNSとして機能していない
・メールサーバがセカンダリDNSにMXレコードを問い合わせした際に、Non Authoritive Answers:を返していた
・SendMailの仕様としてプライマリ（セカンダリ）DNSがNon Authoritive Answersを返す場合はメールを送信しない模様。

今回は、プライマリDNS側では、セカンダリDNSへのゾーン転送を試みていた。
ところが、セカンダリDNS側で設定をしていなかったので、自身を該当ドメインのセカンダリDNSとして返答していない（Non Authoritive)という状況でした。

問い合わせ参照したDNSサーバが、対象メールサーバに関してNon Authoritive Answersを返す場合に、メールサーバがメールを送信しない、というコトが結びつくのに時間がかかりました・・・。

ドコモ以外のキャリア／ISPのサーバでも同じ状況（セカンダリに問い合わせした場合）だったにも関わらず問題無かったのは、ドコモだけ厳密にやってる、ということなのかな・・・。


ということで、コトはドコモだけの問題ではなかった訳ですが、現象面からしつこくテストした状況からは、再現性があるのはドコモだけでした。冗長性に配慮してセカンダリDNSはISPやIDC側、はたまた別のネットワーク事業者に委託している場合があるので（今回もそうでした）、確認が必要ですね。

＜ドメイン作ったときのチェックリストと備忘録＞
○プライマリ側でやること
・セカンダリDNSへのゾーン転送を許可しているか（named.confのallow-transferセクション）を確認する
・ゾーンファイルを変更してBINDを再起動したときに、セカンダリDNSに変更通知が出ていること、エラーが発生していないことを確認する
・ログファイルはデフォルトではnamed.run。
・変更通知ログは、インクリメントしたserial値で正しいバージョンが読み込まれているか確認する
・ログを見るときのポイントは「notify（変更通知）」「AXFR（ゾーン転送開始）」をキーワードに探す。
・セカンダリ側が正しく設定されている場合は、AXFRが記録されているはず。

○セカンダリ側でやること
・プライマリDNSからのゾーン転送の設定を行っているか、どうか
・ゾーンファイルが転送されて作成されているか、どうかを確認する

○全般的な確認方法
・nslookupもしくはdigコマンドでプライマリDNS、セカンダリDNSを指定してMXレコード（メールサーバの場合）を引く。このときにAuthoritive Answerで帰るかどうかを確認する。
・digコマンドだと、DNSサーバ上にキャッシュされている情報があとどれくらいで変更されるか（TTL）を確認することができて、精神衛生的に安心。

社内ネットワークからだと、nslookup/digコマンドで参照するDNSサーバを指定できない（社内ネットワーク端末からインターネット側へのDNSリクエストを禁止している）ケースが多数と思われる（うちのネットワークもそうだった）。

こういうときのために外部ネットワーク（インターネット側）に自由に使える端末（サーバ）持ってると便利。
今回も会社からはダメで自宅端末からアレコレ確認してようやく実情がわかりました・・・。

うーん、どういう名目で調達するかな・・・。仕事には必要なんだがなあ。