トップ «前の日記(2011-11-14) 最新 次の日記(2012-06-14)» 編集

インターノット崩壊論者の独り言


EPIC2014
Google Public DNS (8.8.8.8, 8.8.4.4) 経由では本サイトにアクセスできないよう措置させて頂いております。

2012-03-09 iOSアップデートの罠

iOSのアップデートで8.8.8.8を使うのは回避策であって解決策ではない

追記: 3/14 お昼の観測では、応答自体は解決したように見えます。少なくともOCNでは応答が512byteを下回りました。

8.8.8.8にすれば良いというふうにしか読み取られない残念な状況が生じているようなのでタイトルを変更しました。ショートカット症候群が蔓延していますね。8.8.8.8 など自分の ISP の外にある DNSキャッシュサーバを用いていると広域負荷分散サービスで最適なサーバを割り当てることができず著名なサイトとの通信が遅くなる可能性があります。

twitterで「iOS アップデート 8.8.8.8」で検索すると阿鼻叫喚が観測できます。iOSのアップデートできない人が 8.8.8.8 (Google Public DNS) を使うとアップデートできるらしい。何かがおかしいと調べてみると、、、

まず、8.8.8.8 で検索してみましょう。

~% dig @8.8.8.8 appldnld.apple.com
 
; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 appldnld.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52591
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
 
;; QUESTION SECTION:
;appldnld.apple.com.	IN A
 
;; ANSWER SECTION:
appldnld.apple.com.	3482 IN	CNAME appldnld.apple.com.akadns.net.
appldnld.apple.com.akadns.net. 182 IN CNAME appldnld.apple.com.c.footprint.net.
appldnld.apple.com.c.footprint.net. 112	IN A 199.93.55.126
appldnld.apple.com.c.footprint.net. 112	IN A 204.160.103.126
appldnld.apple.com.c.footprint.net. 112	IN A 206.33.55.126
 
;; Query time: 17 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Mar  9 14:45:18 2012
;; MSG SIZE  rcvd: 172
引けました。(追記: 本ブログは 8.8.8.8,8.8.4.4 を使うと見られないようにしてあります! 常用は避けましょう!)

次に、OCNのオープンリゾルバ ns-kg021.ocn.ad.jp で引いてみました。

~% dig @211.129.14.166 appldnld.apple.com
;; Truncated, retrying in TCP mode.
 
; <<>> DiG 9.8.1-P1 <<>> @211.129.14.166 appldnld.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44912
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 10, ADDITIONAL: 10
 
;; QUESTION SECTION:
;appldnld.apple.com.	IN A
 
;; ANSWER SECTION:
appldnld.apple.com.	2565 IN	CNAME appldnld.apple.com.akadns.net.
appldnld.apple.com.akadns.net. 158 IN CNAME appldnld2.apple.com.edgesuite.net.
appldnld2.apple.com.edgesuite.net. 7616	IN CNAME appldnld2.apple.com.edgesuite.net.globalredir.akadns.net.
appldnld2.apple.com.edgesuite.net.globalredir.akadns.net. 158 IN CNAME a2047.gi3.akamai.net.
a2047.gi3.akamai.net.	20 IN A	124.40.51.64
a2047.gi3.akamai.net.	20 IN A	124.40.51.65
a2047.gi3.akamai.net.	20 IN A	124.40.51.81
a2047.gi3.akamai.net.	20 IN A	124.40.51.8
a2047.gi3.akamai.net.	20 IN A	124.40.51.17
a2047.gi3.akamai.net.	20 IN A	124.40.51.18
a2047.gi3.akamai.net.	20 IN A	124.40.51.33
a2047.gi3.akamai.net.	20 IN A	124.40.51.40
a2047.gi3.akamai.net.	20 IN A	124.40.51.51
 
;; AUTHORITY SECTION:
gi3.akamai.net.		1207 IN	NS n5gi3.akamai.net.
gi3.akamai.net.		1207 IN	NS n6gi3.akamai.net.
gi3.akamai.net.		1207 IN	NS n7gi3.akamai.net.
gi3.akamai.net.		1207 IN	NS n8gi3.akamai.net.
gi3.akamai.net.		1207 IN	NS a0gi3.akamai.net.
gi3.akamai.net.		1207 IN	NS n0gi3.akamai.net.
gi3.akamai.net.		1207 IN	NS n1gi3.akamai.net.
gi3.akamai.net.		1207 IN	NS n2gi3.akamai.net.
gi3.akamai.net.		1207 IN	NS n3gi3.akamai.net.
gi3.akamai.net.		1207 IN	NS n4gi3.akamai.net.
 
;; ADDITIONAL SECTION:
a0gi3.akamai.net.	37552 IN AAAA 2001:218:2007:ffff:9206:8c00:5f81:82a6
n0gi3.akamai.net.	2942 IN	A 193.108.88.194
n1gi3.akamai.net.	2920 IN	A 61.213.146.6
n2gi3.akamai.net.	1943 IN	A 193.108.88.193
n3gi3.akamai.net.	12791 IN A 193.108.88.195
n4gi3.akamai.net.	1943 IN	A 125.252.227.150
n5gi3.akamai.net.	20476 IN A 121.119.254.174
n6gi3.akamai.net.	2942 IN	A 121.119.254.188
n7gi3.akamai.net.	10652 IN A 125.252.227.157
n8gi3.akamai.net.	23847 IN A 125.252.227.156
 
;; Query time: 19 msec
;; SERVER: 211.129.14.166#53(211.129.14.166)
;; WHEN: Fri Mar  9 15:19:07 2012
;; MSG SIZE  rcvd: 730

730byteありますね。512byteを越えています。他の原因もあるでしょうけれど、大半はこれが原因でしょう。"Truncated, retrying in TCP mode." というのは、応答が512byteを越えていてUDPで応答を受けられないので、TCPで問い合わせし直したということです。私の環境ではリゾルバはTCPにフォールバックして、ちゃんと応答を得ることができています。(あるいはEDNS0というDNSにおけるUDPの拡張仕様に対応していればそれが用いられることもあります)

8.8.8.8 じゃないと iOS アップデートができない人は、多分ブロードバンドルータに 512byteを越える応答が扱えない障害を抱えています。あるいは ISP の DNSキャッシュサーバが TCP や EDNS0 に対応していない可能性も排除できません。途中のネットワークに TCP 53 をフィルターするファイアウォールが入っている可能性もあります。

8.8.8.8 だと引けるのは、8.8.8.8 が Answer Section しか応答しないので、512byteを越えないからです。

Google なんかに依存するんじゃなくて、ちゃんと原因を探って対策しましょう(してもらいましょうかも)。

(CNAMEの連鎖を用いるCDN屋も滅びろ)

p.s.

ところでこれは何ですか w dns01.hs.kddi.ne.jp で引いてみた結果です。 おかしいでしょ、これ。

~% dig @211.134.181.104 appldnld.apple.com
;; Truncated, retrying in TCP mode.
 
; <<>> DiG 9.8.1-P1 <<>> @211.134.181.104 appldnld.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45936
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 13, ADDITIONAL: 15
 
;; QUESTION SECTION:
;appldnld.apple.com.    IN A
 
;; ANSWER SECTION:
appldnld.apple.com.     3086 IN CNAME appldnld.apple.com.akadns.net.
appldnld.apple.com.akadns.net. 164 IN CNAME appldnld2.apple.com.edgesuite.net.
appldnld2.apple.com.edgesuite.net. 1840 IN CNAME appldnld2.apple.com.edgesuite.net.globalredir.akadns.net.
appldnld2.apple.com.edgesuite.net.globalredir.akadns.net. 165 IN CNAME a2047.gi3.akamai.net.
a2047.gi3.akamai.net.   18 IN A 118.155.230.32
a2047.gi3.akamai.net.   18 IN A 118.155.230.33
a2047.gi3.akamai.net.   18 IN A 118.155.230.49
a2047.gi3.akamai.net.   18 IN A 118.155.230.65
a2047.gi3.akamai.net.   18 IN A 118.155.230.66
a2047.gi3.akamai.net.   18 IN A 118.155.230.67
a2047.gi3.akamai.net.   18 IN A 118.155.230.81
a2047.gi3.akamai.net.   18 IN A 118.155.230.16
a2047.gi3.akamai.net.   18 IN A 118.155.230.26
 
;; AUTHORITY SECTION:
net.                    169979 IN NS j.gtld-servers.net.
net.                    169979 IN NS h.gtld-servers.net.
net.                    169979 IN NS b.gtld-servers.net.
net.                    169979 IN NS i.gtld-servers.net.
net.                    169979 IN NS e.gtld-servers.net.
net.                    169979 IN NS l.gtld-servers.net.
net.                    169979 IN NS d.gtld-servers.net.
net.                    169979 IN NS k.gtld-servers.net.
net.                    169979 IN NS g.gtld-servers.net.
net.                    169979 IN NS a.gtld-servers.net.
net.                    169979 IN NS f.gtld-servers.net.
net.                    169979 IN NS c.gtld-servers.net.
net.                    169979 IN NS m.gtld-servers.net.
 
;; ADDITIONAL SECTION:
a.gtld-servers.net.     24303 IN A 192.5.6.30
a.gtld-servers.net.     25704 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net.     10571 IN A 192.33.14.30
b.gtld-servers.net.     23303 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net.     4792 IN A 192.26.92.30
d.gtld-servers.net.     30717 IN A 192.31.80.30
e.gtld-servers.net.     110935 IN A 192.12.94.30
f.gtld-servers.net.     23074 IN A 192.35.51.30
g.gtld-servers.net.     61608 IN A 192.42.93.30
h.gtld-servers.net.     17996 IN A 192.54.112.30
i.gtld-servers.net.     22280 IN A 192.43.172.30
j.gtld-servers.net.     22369 IN A 192.48.79.30
k.gtld-servers.net.     64118 IN A 192.52.178.30
l.gtld-servers.net.     22121 IN A 192.41.162.30
m.gtld-servers.net.     21995 IN A 192.55.83.30
 
;; Query time: 17 msec
;; SERVER: 211.134.181.104#53(211.134.181.104)
;; WHEN: Fri Mar  9 15:14:26 2012
;; MSG SIZE  rcvd: 843

本日のツッコミ(全27件) [ツッコミを入れる]
ひろくん (2012-03-09 20:04)

ドンピシャだったようです。<br>私の使っているルータではこんな結果が返ります (T_T)<br><br>$ dig @ルータ appldnld.apple.com<br>;; Truncated, retrying in TCP mode.<br>;; ERROR: ID mismatch: expected ID 52981, got 8896<br><br>今思えば、そういう感じのメッセージが出ていました。<br>合併して消えた大阪近鉄バファローズのように<br>B社も消えた方がよいのかもしれません :-(<br><br>なお、iOS 5.1 へのアップデートは unbound を用いて自前で<br>resolve させているコンピュータ上で iTunes を動かし、<br>そのコンピュータに iPad2 をつないで行ないました。<br><br>iOS で動くデバイスで自前で resolve させる方法募集中。

takuya_1st (2012-03-09 20:44)

うちのBuffalo機器は次の結果でしたね。<br>takuya@hostr:~$ dig @192.168.11.1 appldnld.apple.com<br>;; Truncated, retrying in TCP mode.<br>;; ERROR: ID mismatch: expected ID 61684, got 822<br><br>ビンゴです。

ひろくん (2012-03-09 20:45)

なお、イーモバイルの Pocket Wi-Fi D25HW の場合は<br>$ dig @192.168.1.1 appldnld.apple.com<br>;; Truncated, retrying in TCP mode.<br><br>; <<>> DiG 9.7.1 <<>> @192.168.1.1 appldnld.apple.com<br>; (1 server found)<br>;; global options: +cmd<br>;; connection timed out; no servers could be reached<br><br>となります。道理でダメだったわけですね :-(

tss (2012-03-09 20:47)

dig +bufsize=1024 とかするとどうでしょうね。

ひろくん (2012-03-09 20:58)

ただ私が使っている WZR-HP-G300NH の場合は<br>work around があります。<br>DHCPで配るDNSサーバを設定できるので、<br>512byteを越えた応答を処理できるDNSサーバを<br>DHCPで教えてやるようにすればいいわけです。<br>幸い、JCOMのDNSサーバは<br>512byteを越えた応答を処理できるらしいので<br>iPad2ではそうやって凌ぐことにいたします。

ひろくん (2012-03-09 21:07)

dig +bufsize=1024 の場合、WZR-HP-G300NH は Timeout し、<br>Pocket Wi-Fi D25HW でが resolve できましたね。

tm (2012-03-09 21:59)

[TCPで問い合わせしなおしてね] ではない。ところで、A レコードがひどい。<br>こんなサービスは使いたくないな。<br>いまアップデートできても、将来またなにかおきるでしょう。<br>----<br>Google の返事もなにかおかしい。

tss (2012-03-09 22:49)

はい。正しくなかったです。dig の表示は TC みてfallbackした(しようとした)結果ですね。

jps (2012-03-10 00:15)

何故そこでgTLDのNSレコードがAUTHORITYに出てくるかがよくわかりませんでした。こんなところで出てきて良いんでしたっけ?

tss (2012-03-10 09:18)

ね、変でしょ?

tss (2012-03-10 12:29)

dig では問題ないという報告がありますが、dig とアップデータが使うOS X のリゾルバ(mDNS?)は異なる動作をする可能性があるので、dig が TCP に fallback したからといって、自分の環境に問題がないとはいえないでしょう。Mac OS X に詳しくなくてすみません。

tss (2012-03-10 13:22)

8.8.8.8 を設定して問題解決を図るのではなく、自分のISPのDNSキャッシュサーバのIPアドレスを直接設定してみましょう。

tss (2012-03-10 17:19)

中身を読まず、8.8.8.8 を使えば解決と思っている人が多そうなので、タイトルを変更しました。

tm (2012-03-11 20:02)

[8.8.8.8 を使えば解決と思っている人]はここを読んだから発生したとは限らない。<br>多分、違うでしょう。

tss (2012-03-11 23:10)

発生していたから、わざわざ調べたのですよ。そうしたら、ショートカット症候群が増幅してしまった。悲しい。

tm (2012-03-12 10:12)

「発生したとはかぎらない」というのは「発生していた」とは矛盾しない。<br>ーーーー<br>「増幅した」とはかぎらない。まあ、増えたのだろうが、別のサイトの影響の方が<br>大きいだろう。<br>ーーーー<br>反省は必要だが、悪い方向にだけ考えることもない。ショートカット症候群だけが<br>問題なわけでもない。

tm (2012-03-12 10:42)

[ショートカット症候群]の人を表に見せただけのような気がする。顕在化させたことは<br>増幅させたこととは違う。後者の可能性もないとは言えないけど、元々いたのだろう。<br>ーーーーせっかくのチャンスだったから、退治できるとよかったけど、それは高望みだろう。

tm (2012-03-12 12:04)

ルータが悪いとか言っているのも問題だ。ルータを売りたいのかも。<br><br>もう、なんでもありの売り込み合戦になっているような気もする。<br>ひどい。

tss (2012-03-14 12:12)

OCN他で、512byteを下回りました。

hoge (2012-03-15 00:42)

"ショートカット症候群" の話も含めて参考になりました。<br><br>ルータが悪いとしても、ファームウェアの改善要求ぐらいはできるのではないでしょうか。<br>B社製ルータのベースである OpenWrt あたりに問題があるのであれば、治してくれないかもしれませんけど。

strnh (2012-03-17 00:10)

やっぱりルータは多少ごつくて消費電力が嵩むようでも、*BSDに限ります。一時期気の迷いでarm-Linuxが乗っかってるFoneraとか使ってみたけど、名前解決でもたもたしてい感が否めなかった。おまけに、クロス開発環境を持ってないので、柔軟な対応が出来そうにないと、結局舞い戻ってますが djbdns を使っていれば なんの不自由もない事を改めて知るなど。

tm (2012-03-17 19:23)

ルータのキャッシュに問題があったとしても、第一の責任はiPhone側にあります。<br>そのことを放置してルータを責めているように見える。読み違いであればいいが。

hoge (2012-03-20 02:43)

iPhone のどこに責任があるのでしょうか。<br>そもそも、 iOS 自体はあまり関係ないように見えます。<br><br>理想的であるかは別にして、512を超える場合には、 EDNS0 あるいは TCP フォールバックによって、<br>正しく機能することが求められており、機能しないルータ等はアウトと認識しておりますが、誤りでしょうか。

tss (2012-03-21 08:57)

tmさんの主旨はわかりませんが、iPhoneっていうより Apple いや Akamai が 多段の CNAME を用いている時点で誤りだと思います。あと未確認ですが、iOS 自体は (EDNS0 などで) 512byte越の応答を扱えるのでしょうかね。

tm (2012-03-21 18:46)

akamaiのDNS設定が問題を引き起こした。<br> そういうakamaiを使っているのがiPhoneの更新なわけです。<br><br>ルータには最新の規格どおりに動作して欲しいというのは結構ですが、<br>古いルータだけがアウトという認識は誤りです。<br><br>akamai側はすでに対策しているらしいので、議論する必要はもうありませんが。

hoge (2012-03-21 23:00)

確かに多段 CNAME は問題ありですね。<br>今、確認しても多段 CNAME は治してないようで。<br><br>iOS の 512 bytes を超える応答については、 5.1 へのアップデートで全員がアップデート<br>できなかったという訳ではないことから、扱えるのではないかと考えています。<br><br>調べ直しましたところ、EDNS0 はともかくとして、 TCP での問い合わせについては、<br>RFC 1035 にも記述があり、 RFC 1123 において "SHOULD support" となっておりますので、<br>古さは理由になりません。<br>一方、あくまでも "SHOULD" なのでアウトともいえませんね。<br><br>ちなみに、 RFC 5966 で "MUST" になったようです。

tm (2012-03-22 15:22)

RFCは法律ではないので、守らないからアウトというようなものではない。<br>AppleやAkamai がどういう人を相手に商売をしているか、という姿勢の問題だと<br>考えるのがいいでしょう。あとはネット上の関係ない人に悪影響がないかとかを<br>配慮しているかどうか。


最近の日記

2008|04|05|06|07|08|10|11|
2009|02|03|04|06|07|09|10|11|
2010|01|03|06|09|10|11|12|
2011|01|02|03|05|06|07|10|11|
2012|03|06|07|10|11|12|
2013|02|03|04|05|06|08|09|10|11|
2014|01|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|07|08|09|10|11|12|
2016|01|06|08|12|
2017|03|07|08|09|12|
2018|04|08|10|11|
2019|01|02|07|11|12|
2020|01|02|03|05|06|07|08|
2021|02|03|09|12|
2022|02|03|05|06|
2024|02|

リンク

Copyright by T.Suzuki