iOS 5.1 に更新できなかった理由を Buffalo 社に伝えてみたら
先日、Buffalo社製ルーターの不具合が理由と思われる現象により、iPad2 にて iOS 5.1 への更新ができずにはまった話を書きましたが、待てど暮らせど肝心のBuffalo社が対応を始めたという情報が入ってきません。そこで問い合わせを行なったところ、回答を得たので報告いたします。
まず、問い合わせの内容は次の通りです。
カスタマ Web フォーム - 2012年03月13日 09:02 PM
御社製品のWZR-HP-G300NHを使用し、
JCOMに接続して使用しております。
その環境で私の使用している iPad2 の iOS を 5.1 に
更新使用したのですが、サーバに接続できず、
何度実行しても途中で止まってしまいます。
そんな状況で困っていたところ、下記の情報を得ました。
http://www.e-ontap.com/blog/20120309.htmlつまり、ルーターの不具合で iOS 5.1 更新のための
接続先である appldnld.apple.com を名前解決できないと
言うのです。
データが512バイトを超えるために TCP で接続しなおすのですが、
そこからの処理に失敗するようです。この情報に基づいて調べたところ、
次の結果が出ました。
なお、192.168.85.1 というのは私の環境での
WZR-HP-G300NHのIPv4アドレスです。$ dig @192.168.85.1 appldnld.apple.com
;; Truncated, retrying in TCP mode.
;; ERROR: ID mismatch: expected ID 33236, got 110確かに名前解決ができません。
なお、JCOMが用意しているDNSキャッシュサーバ
220.152.38.201 および 220.152.38.233 は
きちんと名前解決ができます。
というわけで名前解決にWZR-HP-G300NHを使うのを
やめたところ、きちんと iOS 5.1 に更新することができました。そこで質問です。
(1) 私はiPad2がiOS 5.1に更新できなかったのは
WZR-HP-G300NHの不具合であると考えておりますが、
それに間違いはないでしょうか。
(2) WZR-HP-G300NHの不具合である場合、
対応する予定はあるのか。
(3) 対応する場合、いつ頃までに対処可能か。
(4) 対応する予定がない場合、
御社の他のルーターで上記の不具合は出ないのか。
(5) 各DNSサーバでDNSSECが導入されれば
512バイトを超えるデータが頻繁にやり取りされることが
考えられると思われるが、
問題はないと言い切れるのか?お手数ですが、回答をお願いします。
対応予定がない場合、別の会社のルーターに
買い替えるつもりですのであしからず。
ところが、その翌々日(3/15)、appldnld.apple.com を運用している akamai.net が対策を打ち、Aレコードの数を減らすなどしたため、appldnld.apple.com についての応答データが 512 バイト未満になってしまいました。これを確認した時、私は「もしかしたら、再現しないという理由で対処されないかもしれないなあ」と思ってしまいました。そんな時に次の回答が Buffalo 社から返ってきました。
回答 メール(バッファローサポート) - 2012年03月16日 05:39 PM
弊社製品のご利用にあたり、ご不便をお掛けして申し訳ございません。■iOSアップデートができない現象について、弊社で発生条件を
確認したところ、上位回線に依存することを確認いたしました。回避方法について、お手数ですが、下記サイトをご参照ください。
アンサー タイトル： iOSのアップデートができません
アンサー リンク: http://buffalo.custhelp.com/app/answers/detail/a_id/14023
■ご質問1〜3についてiPad2 iOS 5.1の更新に失敗した現象について、
弊社ルータの不具合であるかどうかは現在確認中です。
上位回線側のDNSとの組み合わせに依存して発生します。
恐れ入りますが、弊社契約プロバイダでは発生しておらず、
調査は難航しております。■ご質問4〜5について
おっしゃったとおり512バイトを超えない限りは、Truncatedにならないために、
TCPでのクエリを必要としないため、現象は発生しません。
例えば、ATHORITYセクション以降を省略するGoogleDNSを
使うことで現象は発生しなくなります。大変ご迷惑をお掛けして申し訳ございませんが、
今後ともどうぞよろしくお願い申し上げます。
あーあ。予想通りの答えが返ってきました。しかも、想定していた中で一番最低のものが返ってきました。なお、「アンサー タイトル： iOSのアップデートができません
アンサー リンク: http://buffalo.custhelp.com/app/answers/detail/a_id/14023」に書かれている方法、実は私が tss_ontap さんのブログで報告しているものとほぼ同じものです。ただ余計な内容が付け加わっています。それは「Google Public DNSを使う」というものです。一応、「ルーターが取得しているDNSサーバアドレス（ISP指定のアドレス）」を一番目に書いていますが、例として載っている設定例はGoogle Public DNSだけを設定するというものです。さらに「Google Public DNSを使う設定」は図解付きなのに対し、「ルーターが取得しているDNSサーバアドレス（ISP指定のアドレス）」を確認する方法については文章が載っているのみで図が載っていません。これでは「Google Public DNSを使う設定」だけが普及してしまうでしょう。
さらに、このアンサーには大きな欠陥があります。それは現象が起きた理由に関する説明が一言もないことです。要するに「動けばいいだろう」という姿勢なのでしょう。理由がわかっていないのなら「現在調査中です」とでも書けばよいと思います。Buffalo社が「動けばよい」と考えているのか、それとも「利用者に説明しても理解してもらえないさ」という考えなのか。いずれにしろ、誠意ある対応とは言えないのではないかと思いました。
このまま問い合わせを続ける意義があるのかどうか、はなはだ疑問です。実は、ある会社のルーターではこの問題は起きなかったという話も聞いています。なので、できるだけ早くルーターを買い替え、Buffalo社製品は使わない方がよいのではないかと思いました。そうでもしないと、この会社は目を覚まさないのではないかと思います。
と同時に、こんな会社をのさばらせている我々消費者にも問題があるのではないかと思います。ダメなものはダメだと言わないと、いつまで経ってもよくはなりません。あと、ダメと言えるようになるためには自分たちも勉強しなくてはなりません。メーカー任せにしたつけがこうして出てきてしまったのではないかと反省もしました。
ついでに書きましょう。512バイト超データについては次の報告もあります。http://www.janog.gr.jp/meeting/janog15/program.html#date1 の http://www.janog.gr.jp/meeting/janog15/data/12-dns-yoshimura.pdf 問い合わせをした時は気がつきませんでしたが、意外と 512 バイト超のデータが返ってくる場合が多いようです。ということは、このような現象はまた起こる可能性が高いと思います。今回の不具合が見過ごされて再度同じ事象が発生した場合、Buffalo社はどう説明するのでしょうかねえ。
(追記)上記の問い合わせで「データが512バイトを超えるために TCP で接続しなおす」と書いてありますが、これは私の間違いです。正しくは「データが512バイトを超えるために TCP で接続しなおすか、ENDS0でUDPでの通信をする」です。ただ、「retrying in TCP mode.」とあるので TCP で接続しなおして失敗しているのではないかと思っています。また、問い合わせの内容は上記の通りなので、修正は致しません。
