morimorihogeです．最近は遠征回すくらいしかできてないので元帥維持は諦めました．
10年前くらいの若かりし頃に設定した（ような気がする）サーバがまだ元気に動いていて，この度IIJさんのオープンリゾルバ対策に引っかかってハマったので共有しておきます．
概要
IIJのDNSサーバがセキュリティ対策の一環として，オープンリゾルバ対策を2013年12月2日の12:00に行いました．
その影響で，IIJをプロバイダとして使っていないサーバでIIJのDNSサーバを使っていた場合，インターネット接続周りの不具合が発生します．
詳細は以下の参考サイトをアクセスして下さい．
参考： 「昔IIJを使っていた人」にお願いです – オープンリゾルバ対策
対象となる可能性があるサーバ
参考ページに技術的な部分は書かれているので割愛しますが，基本的には「2000年台中盤までくらいのインターネットが比較的牧歌的だった時代に設定されたサーバ」や「ネットワークやサーバをあまり理解していない人がWeb上の古い情報を頼りに設定したサーバ」が臭いです．
今回僕が対応したケースは前者でした．
発生する問題
実は，まだIIJさんのDNSはDNSの問い合わせ自体には返答してくれます．ただし，一見Aレコードの問い合わせは正常に答えている様に見えて，実はおかしいです．
具体例を挙げてみます．試しにwww.google.comのAレコードを引いてみると，通常のDNSサーバ（Google Public DNS）では，
$ dig www.google.com @8.8.8.8 ; <<>> DiG 9.7.3 <<>> www.google.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3037 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 300 IN A 173.194.117.113 www.google.com. 300 IN A 173.194.117.114 www.google.com. 300 IN A 173.194.117.116 www.google.com. 300 IN A 173.194.117.115 www.google.com. 300 IN A 173.194.117.112 ;; Query time: 40 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Dec 3 23:45:12 2013 ;; MSG SIZE rcvd: 112
となりますが，12月3日現在のIIJ DNSサーバでは
$ dig www.google.com @210.130.0.1 ; <<>> DiG 9.7.3 <<>> www.google.com @210.130.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47505 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 60 IN A 203.180.220.123 ;; Query time: 77 msec ;; SERVER: 210.130.0.1#53(210.130.0.1) ;; WHEN: Tue Dec 3 23:42:58 2013 ;; MSG SIZE rcvd: 48
となります．DNSの問い合わせ自体は返ってくるけど結果が全然違う状態です．
ちなみにhttp://203.180.220.123/にアクセスすると，IIJの警告ページが表示されます．親切といえば親切ですね．
僕としては問い合わせ自体失敗してくれた方がDNSが原因だという点には気付き易い気もしますが，そうするとサーバダウンと見分けが付かないのでこうしているのだと思います．
このようにAレコードの問い合わせは，クエリ応答はありますが，常にIIJの注意喚起WebサーバのIPアドレスが返されるようです．
次に，MXレコードについては，正常だと
$ dig gmail.com MX @8.8.8.8 ; <<>> DiG 9.7.3 <<>> gmail.com MX @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38232 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;gmail.com. IN MX ;; ANSWER SECTION: gmail.com. 3282 IN MX 30 alt3.gmail-smtp-in.l.google.com. gmail.com. 3282 IN MX 40 alt4.gmail-smtp-in.l.google.com. gmail.com. 3282 IN MX 20 alt2.gmail-smtp-in.l.google.com. gmail.com. 3282 IN MX 5 gmail-smtp-in.l.google.com. gmail.com. 3282 IN MX 10 alt1.gmail-smtp-in.l.google.com. ;; Query time: 26 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Dec 3 23:47:28 2013 ;; MSG SIZE rcvd: 150
となりますが，現在は
$ dig gmail.com MX @210.130.0.1 ; <<>> DiG 9.7.3 <<>> gmail.com MX @210.130.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55915 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;gmail.com. IN MX ;; AUTHORITY SECTION: . 60 IN SOA localhost. nobody.localhost. 1 3600 1500 2592000 1200 ;; Query time: 93 msec ;; SERVER: 210.130.0.1#53(210.130.0.1) ;; WHEN: Tue Dec 3 23:47:37 2013 ;; MSG SIZE rcvd: 78
となり，MXレコードの問い合わせ結果が存在しない（そのメールサーバが見つからない）という結果になります．
そのため，メールサーバでIIJのDNSサーバを設定していた場合，外部へのメール配送に失敗するという問題が発生します．
対策
使っているサーバが繋がっているプロバイダのDNSサーバやGoogle Public DNSあたりを使えば良いと思います．
一般的なLinuxホストであれば，/etc/resolv.confに
nameserver 8.8.8.8 nameserver 8.8.4.4
と書けば良いです．一応設定変更後は各種サービスをrestartした方が無難です．また，DHCPでIPアドレスを取得している場合，resolv.confを修正してもdhclientなどに上書きされてしまうので，IP配布元のDHCPサーバの設定を修正する必要があります．
まとめ
この問題が厄介なのは，ただのWebサーバなどであればHTTPでの通信のやり取りにはDNSは関係ないので，メール配送のタイミングでエラーが発現するというところでしょうか．
※今回僕が対応した事例も，直接の障害は「メールが外部に配送されない」というトラブルでした
昔々，インターネットがもっと牧歌的だった時代はあちこちのプロバイダがDNSサーバを広くインターネットに公開してくれていたのは割合一般的だったのですが，オープンリゾルバを使ったDDoS攻撃をする輩が現れて始めてからは脆弱性の一つと言われるようになってしまいました．
この手のセキュリティ系の話題は，昔は問題視されなかった設定が次第にセキュリティホールだとか言われるようになるので，設定して年月の経ったサーバについてはたまに見てあげないといけないですね．
なにはともあれ，オープンリゾルバが問題になり始めてから今の今まで公開DNSサーバを設置してくれていたIIJさんには感謝したいと思います．これまでありがとうございました！
というわけで，教訓でした．