APNICのDNSサーバ障害で一部のDNS逆引きが使えなくなる 71
ストーリー by yoosee
私は困りましたよ、えぇ 部門より
私は困りましたよ、えぇ 部門より
S0R5曰く、"まだ掲載されていないのでタレコまれてないのでしょうか。昨日10月23日に、JPNICが割り振りをおこない、APNICが逆引きDNSを提供しているIPアドレスで、DNS逆引きができないという障害がありました(JPNICによる報告)。
結構長時間で色々なシステムに不具合が出てそうな気がするのですが、その割に障害中にニュースサイトで取り上げられていなかったように見えるのは、NICの発表がなかったからですかね。"
ニュースになっても良いと思う。 (スコア:5, 興味深い)
僕の所では、午後三時前後辺りから、普段開いているasahi.com、/.J、NHK(の番組表)等につながらなくなりました。ping打ってみると、ぽちぽち行くのですが、実際のWebページを転送するところまでは安定しませんでした。news.bbc.co.ukなんかはちゃんとつながりました。ヨーロッパ系は様々でした。akamaiとかの負荷分散サービスを利用しているところは軒並みやられてましたね。
上記の状態だったんで、DNS絡みだとは思ったのですが、ちょうどプロバイダを変えたところで、合わせてモデムもそこのものに変えたところだったので、モデムの電源切断、冷却、再起動、NISの不安定化等々疑って試行錯誤してました。
それにしても、たれこみにも触れられている通り、こういうのは一般のニュースサイト(asahi.comとかNHKのテレビでのニュースとか)でもニュースになっても良いと思うのですが。現在では、DNS障害は、電車の遅延、停止、停電、断水などと同じくらい重要だと思います。皆さんどう思いますか。
Re:ニュースになっても良いと思う。 (スコア:5, 参考になる)
この結果からDNSの異常を疑うのはおかしいです.単にネットワークの通信障害では?
ping が一度でも成功した時点で,DNSによる正引きは出来ています.また,今回のタレコミの発表はDNSの逆引きにおける障害です.
DNSを疑うのであれば,digとかnslookupを使って調べましょう.
Re:ニュースになっても良いと思う。 (スコア:4, おもしろおかしい)
BBQ やっている会場から連れ戻されてました。
# 肉ぅ!と叫んでいたかどうかは不明。
深刻だったのは mail サービスかな。
逆引きの障害はわかりにくい (スコア:3, 参考になる)
障害がおきててもなかなかわからないですよねえ。
アクセス数の多いWEBサーバなんかだと、ログ取りが遅くなって
負荷が上がって「逆引き?」って感じで気がつく時があるんですが、
普通にネットを使っている場合はなかなかわかりません。
Re:逆引きの障害はわかりにくい (スコア:1)
逆引きが嘘つきなホストからのアクセスがあっても検証できなくなりますので、
私はアクセスログには逆引きさせず、素のIPアドレスを記録してます。
で、後で確認するときも、whois で調べて裏を取ったり。
最近、逆引きを過信しないようにしてます。
Re:ニュースになっても良いと思う。 (スコア:1, 参考になる)
ん? これらのサービスって逆引きできないホストからのアクセスを制限してるの?
どっかでルーティングの障害が発生してそういう現象が起きたのならわかるが、
DNS の、しかも逆引きの障害ではそういうことは起きないと思うんだけど。
まったく別の現象と勘違いしてない?
普段は... (スコア:1)
Re:IRC (スコア:0)
負荷分散のために逆引きで.jpからでないと繋げられない
まぁ、国内の逆引きできないIPの為の手段も提供されているようですが。
#IRCは私にとっては生活の一部
メールいっぱいはじかれたんだろうなぁ (スコア:1, 興味深い)
正常なメールもspam扱いにされてはじかれたサーバが多いんじゃないんかなぁ。うちは導入直前だった…
こんな長時間障害が続くってことは逆引き対策やるのも結構怖いもんなんかなぁ。 効果的なんだけど。
Re:メールいっぱいはじかれたんだろうなぁ (スコア:1, すばらしい洞察)
これが、.jpゾーンの提供障害が発生、だったときに、DNSが引けなくなってメールが配送できなかったから、DNSのMXやAレコードに依存せずに全てスタティックに配送するように設定しないと恐いねぇ、ということになるでしょうか。
Re:メールいっぱいはじかれたんだろうなぁ (スコア:1, 興味深い)
楽天のメールサーバ群 [senderbase.org]がごっそりと含まれてます。
受注確認のメールがいっぱい spam 扱いされたことでしょう。
正引きの場合では (スコア:1)
障害などの場合は,4xx(Temporary Error) でエラーを返すと思います.これ
なら,まともなメールサーバなら再送を繰り返します.postfix のデフォルト
では,たしか 5 日間は再送をくりかえすので,逆引きのフィルタも似たような
感じであれば,今回の程度の障害では,Sender にエラーメールが返るケースは
ほとんどないでしょうね.
まぁ,自分のところでは「ssh でログインできなくなったんだけど…」という
報告がきたくらいです.その報告を見たときにはすでに問題は解消されていた
わけですが.ちょうど,hosts.allow の設定を見直した後だったので,こちらの
原因かと疑ってしまいました.
Re:正引きの場合では (スコア:1, 参考になる)
SERVFAIL なら再試行のように、エラーの種類によって適切に取り扱うべし、とあります。
must じゃないし、for example だし、配送先を調べるときの話であって
逆引きじゃないし、RFC974 は 2821 により obsolete になってるけど、
まあ参考までに。
# RFC2821 には問い合わせに失敗したときの扱いが書かれてないようだ。
>postfix のデフォルトでは
450 ですが、unknown_client_reject_code = 550 で応答を変えられます。
spam対策で (スコア:1, 参考になる)
Re:spam対策で (スコア:1)
#ちょこちょこ漏れはありますけど。
続報 (スコア:1, 参考になる)
だそうな。
うちのブラウザでは見れない orz (スコア:0)
JPNICがスタイルシートを準備してますが、それでもブラウザ標準のスタイルシートでも該当ページは見えません。
Wikipediaでもたまに見かけるんだけど、スタイルシートを切らないと読めないページってのは泣けてきます。
Re:うちのブラウザでは見れない orz (スコア:2, 参考になる)
Re:うちのブラウザでは見れない orz (スコア:1, 参考になる)
//ならないかもしれないけど、よくある事なので。
Re:うちのブラウザでは見れない orz (スコア:1)
単にCtrl+Rだけで十分ですよ。。。
Re:うちのブラウザでは見れない orz (スコア:4, 参考になる)
ネットワーク先から再ダウンロードしようとする
スーパーリロード [google.co.jp]のことでは?
FirefoxのみならずIEでも実装されていて、
IEではCtrl+更新ボタンで可能です。
すでにベーシックな機能の感があるので、
Opera他でも実装されてるんじゃないでしょうか。
使ってないので知りませんが。
Re:うちのブラウザでは見れない orz (スコア:1)
Re:うちのブラウザでは見れない orz (スコア:0)
Hotmail等、IE以外のブラウザに不親切なサイトでほぼ必須のコマンドだったりします。Ctrl+Rでは利かないページも多いので。
Re:うちのブラウザでは見れない orz (スコア:0)
Re:うちのブラウザでは見れない orz (スコア:0)
Re:うちのブラウザでは見れない orz (スコア:3, 参考になる)
Re:うちのブラウザでは見れない orz (スコア:0)
そしてスーパーリロードは普通に使います。知りませんでしたか? ひとつ言葉を知りましたね。あなたは感謝を知らなければなりません。
スーパーをつけるのはかっこいいからという理由じゃありません。あなたには想像もつかないでしょうが。
Re:うちのブラウザでは見れない orz (スコア:0)
# 他力本願なのでAC
否定形禁止!(オフトピ) (スコア:0, 参考になる)
真っ白なページなのか文字がぐちゃぐちゃで読めないのかなぜかブラウザが落ちるのかとかいろいろ考えられる。
ついでに「動かない」も禁止! 「1分観察したが画面に変化が無かった」などと報告すべし!
Re:否定形禁止!(オフトピ) (スコア:0)
こんな事言う若いのが居たら
「問題の切り分け位ちゃんとしろ、原理分かってんのかボケ」
と怒鳴っちゃうよ
Re:否定形禁止!(オフトピ) (スコア:0)
Re:うちのブラウザでは見れない orz (スコア:0)
> スタイルシートを切らないと読めないページってのは泣けてきます
w3m なら安心
Re:うちのブラウザでは見れない orz(オフトピ (スコア:1)
いや、現にら抜き言葉なのですが、いわゆる「若者語」じゃないんですよね。。。
困るなぁ (スコア:0)
例えば名古屋大とかだけど、
あの設定は問題あると思うんで止めて欲しいものだ。
逆引きできないと困る理由とは? (スコア:1)
今回のような障害時にメールが届かなくなるという理由以外では、まともなホストでも逆引きを設定してない場合があるからですか?
個人的には、まともなメールサーバーなら逆引きを設定すべし、と思います。UUCP 接続以外で逆引きができない状況ってあるんでしょうか?
# 動的 IP 割り当ての自宅サーバーでメールサーバー動かしているから、というのは理由になりませんね:-)
Re:逆引きできないと困る理由とは? (スコア:1, すばらしい洞察)
IP1アドレスに複数ドメイン割り当てたりって事を許さない(逆引きで複数引ける時とか)とか
インターネットやメールのやり取りに関する仕様にはない
独自の解釈でサーバ全体をフィルタするのは問題あるのでは?
私は管理者としてこのようなフィルタはしてはならないと
常に感じています、ユーザ個々が設定できるSPAMフィルタを導入すべきです、
理由はサーバ管理者や運営者が迷惑と感じるメールであっても
必ずしも全てのユーザにとって迷惑メールであるとは限らない
それを一括切り捨てるのは如何にも管理者のマスターベーション的エゴであると
># 動的 IP 割り当ての自宅サーバーでメールサーバー動かしているから、というのは理由に…
これは意味が違うとは思いますが、上記理由からすれば
当然メールを受け入れるべきだと私は思いますよ
よく考えてみてください誰の為のサーバなのですか?
管理者の為ですか?
利用者のサーバではないのですか?
利用者が判断する以前にサーバで弾いてよいのですか?
Re:逆引きできないと困る理由とは? (スコア:0)
元コメントを勝手に受け取り手の管理者の話にしているのはあなたです。推敲する時は相手の言い分もよく吟味しましょう。
--
ついでに他の頓珍漢なコメントにもツッコミ
(#819954)> 逆引きを設定してあるからまとも、あるいは逆引きがないからまともでない
targzさんは(#819922)ではそんな事は言ってません。
(#819984)> DNSに依存しているインターネット上のサービスの一部が、DNSの障害で不調になっているだけなのに、DNSに依存した設定をすると恐いなぁ、という感覚が良く分かりません。
DNSの逆引き機能に依存する
Re:逆引きできないと困る理由とは? (スコア:0, すばらしい洞察)
逆引きを設定してあるからまとも、あるいは逆引きがないからまともでない、
といえる正当な根拠があれば「べし」と言ってしまっていいと思います。
しかし、逆引きがないホストを自分なりの主観でまともでないと
みなしている例(ここ [hart.co.jp]とか)はよく見ますが、
客観的に納得できる「正当な根拠」は残念ながら見かけたことがありません。
「おれはまともでないと見なす」というは勝手ですが、
「おまえも従え」というのは少々乱暴な飛躍ではないかと。
ちなみにメールサーバの例ではないですが、www.google.com を
正引きして得られる IP アドレスには逆引きがありません。
Re:逆引きできないと困る理由とは? (スコア:1, すばらしい洞察)
Re:逆引きできないと困る理由とは? (スコア:1)
メールサーバではなくとも,ログ採り・アクセス制限・ロードバランス云々で,逆引きすることもないこともないですね。
"Patriotism is the last refuge of a scoundrel." - Samuel Johnson
逆引きできる≠逆引きが一致する (スコア:1)
ひょっとして皆さんは後者の様なきつい制限をしてらっしゃるんでしょうか?自宅鯖や学生時代にいた研究室ではきわめてゆるい受信制限をしているわりには特に SPAM にも悩まされていないので、あんまり気にとめてませんでした。ちなみに自宅鯖のポリシーは
1)誰からでも受け取る
2)localhost 発ならどこへでも発信する
3)中継はしない
屍体メモ [windy.cx]
Re:逆引きできる≠逆引きが一致する (スコア:0)
今回の障害は
「ゾーンの SOA が 確認できなかった (委譲されていなかった)」
という問題でしょう。
「IPv4 アドレスの逆引きに 対応する FQDN がある/ない」 という話に短絡させるべきではないと思います。
ましてや SMTP HELO のような オプショナルな話にまで発展させるのは オフ・トピックではないでしょうか。
Re:困るなぁ (スコア:0)
どこが問題なのか、詳しく教えて!!
逆引きできないホストでメールを出すのってSPAMじゃなくても、まともな管理してないサーバーだけじゃないの?
もしかして、個人で立ててるから困るってこと?
だったら素直にプロバイダーに中継させたら。
Re:困るなぁ (スコア:1, すばらしい洞察)
まともな管理をしているからといっても、必ず逆引きできるわけでもない。
逆引きが出来るようにするということは絶対にやらなくちゃいけないという決まりもない。
ついでにいえば正引きができなくちゃいけないというわけでもない。
逆引きできないホストからは拒否などという設定の根拠は、単純にspam業者の使用するホストのほとんどが逆引きできないからというだけの理由である。
しかし、spam業者にも逆引きできるホストを使うやつもいるし、まっとうな会社でも逆引きできないホストを使っているところもある。
spam業者のホストが逆引きできないものが多いというのは、将来的にわたって同じなのかはわからない。
spam業者だって逆引きが出来れば受信されると気づけば、逆引き設定するのは確実。
自分の管理下のメールサーバで、逆引きできないホストからのメールを拒否する設定にするのは勝手だろう。
しかし、それがまともで当然であるなどという嘘を広めるのはやめよう。
Re:困るなぁ (スコア:0)
管理者はもういないでしょうね、そりゃ。
Re:困るなぁ (スコア:0)
> そういう管理者もほとんど化石みたいなものですね。(ワラ
確かに逆引き設定されたサーバからなら届くとか、届かなければ
ならないはずのメールが届かなくなる場合があるなど、業務用には
使えない手法ではあるが、BLと組み合わせればイニシャルコスト・
ランニングコスト共に安価に実現可能な対策としての効果はいまだ
絶大なものがある手法だというのもまた事実。
「化石化した手段」と否定するなら、安価に、よりローリスクで、
同程度以上の効果が得られるエレガントな代案を具体的に提示して
いただきたい。
できない&する気がないなら返事不要です。
Re:困るなぁ (スコア:0)
今回の DNS の障害でリスクがあることを改めて認識したばかりなのに、
まるで逆引きがローリスクな手段であるかのような書き方ですね。
よしきた、おいきた (スコア:0)
# ご希望のコメント付与サービス中
Re:困るなぁ (スコア:0)
そうでないという事は、今はSPAMは絶対に逆引き可能な所から送られてくるんですか?
Re:困るなぁ (スコア:1, 参考になる)
IPアドレスから連想されるようなホスト名で、サブドメインに「ap」の文字を含むものばかりです。
逆引きできないところからは、慢性的に送られてきていて、問題視するつもりも起きなくなってますが。
# ap = access point なんだろーかやっぱ