2013年12月2日の昼を境にメールが届かなくなったらDNS設定をチェック!

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の警告ページが表示されます.親切といえば親切ですね.

Screenshot 2013-12-04 00.06.58

僕としては問い合わせ自体失敗してくれた方が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さんには感謝したいと思います.これまでありがとうございました!

というわけで,教訓でした.

Ruby on RailsによるWEBシステム開発、Android/iPhoneアプリ開発、電子書籍配信のことならお任せください この記事を書いた人と働こう! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

morimorihoge

高校卒業後,学生をやりながらずっとWebアプリ開発に携わってきました.2010くらいまではPHP/Symfonyプログラマでしたが,それ以降のWeb開発はRailsほぼ一本に宗旨替えしました.開発とは別にサーバ構築・運用も10年以上やってきているので,要件定義から設計・実装・環境構築・運用まで一通り何でもこなせます.開発以外では季節により大学でWebサービス開発やプログラミング関連の非常勤講師もしており,技術の啓蒙・教育にも積極的に関わっています.最近はPM的な仕事が増えていますが,現役開発者としていつでも動ける程度にはコードもサーバも弄る日々を送っています.AWS 認定ソリューションアーキテクト – アソシエイトレベル取りました

morimorihogeの書いた記事

開発
RubyのArray(配列)の使い方

2017年03月15日

週刊Railsウォッチ

インフラ

Rubyスタイルガイドを読む

BigBinary記事より

ActiveSupport探訪シリーズ