_ 去年事故ったとき(わしゃ悪くないやい、ぶつけられただけだい)、現場検証したおまわりさんにはあとで出頭してもらうからそのつもりでとか言われたけど、何の音沙汰もなくけっきょく青切符なしだったので、違反点数ゼロで無事ゴールド免許。
_ 役所だから平日だけかと思ったらゴールド免許のみ日曜日も更新受付をやってるらしい。どこもそうなのか、千葉だけなのかは知らんが。前回更新は青免許だったので平日だったけど、そんなわけで、今日運転免許の更新にいってきた。
_ が、日曜は混むわ。前回の青免許のときは講習1時間込みで1時間半もかからずに新しい免許証をもらえたけど、今回は優良ドライバーで講習時間が短くなったにもかかわらず2時間。次は平日に来よう。5年後だが。
_ そんなわけで、青免許がゴールド免許に、普通免許が中型免許に、さらに IC チップ入り免許証に、といろいろグレードアップした。つーか中型免許に変わるって知らんかった。もしかして常識でしたか。最近の道交法改正で普通車と大型車の間に中型車という区分ができて、改正前に普通免許で運転できた 4t トラックが中型車に分類されるようになったので、これまで運転できてたものができなくなるのはよろしくないっつーことで、限定条件つきの中型免許に区分が変わるということらしい。名前が変わっただけで実質的にはなんも変わってないわけだが。
_ あと、IC カード免許。非接触型なのな。Suica と干渉したりせんのかな、とか、リモートからスキミングされんかな、とかデメリットばっかり思いつくんだが、さすがに杞憂だと思う。杞憂だと信ずる。知らんけど。あと、次の更新まで暗証番号をふたつも覚えてられる自信がありませぬ。これは杞憂ではなく確実。なんにせよ、非接触型にするメリットというのはまったく思いつかん。本籍地は印字されず IC チップ内にのみ記録されますプライバシー守ります、って自分にとっては大した情報じゃないし、偽造防止ってのは警察さんからしたらメリットかもしれんが、わし自身にはまったく関係ないし。
_ 運転免許が新しくなって以降、駅の改札でひっかかりまくり。免許証の IC チップが Suica の読み取りを阻害してるとしか思えん。これまでとカード入れの中身で違うのは免許証だけだし、実際カード入れからどっちか抜くと問題なく改札を通れるんだから。なにこれ。なんでこういうアホ仕様にしたの？
_ いいかげんウザいので、とりあえずアルミホイルで免許証を覆って簡易シールドしてみた。検問とかで免許の提示を求められたときにめんどくさいが、そうしょっちゅう機会があるわけでもないので気にしない。
_ DNS で複数の IP アドレスをラウンドロビンで応答しても、毎回同じアドレスしか使ってくれないクライアントが相当数存在することは一部では知られた事実なんだけど、これ、腐った実装だなー、と思ってたらそうじゃなくて RFC にも定められていたことが判明。えー???
_ DNS Round Robin and Destination IP address selection。しかるべきルールによりソートした結果の先頭のアドレスを使うよう RFC3484で要求していて、そのルールの中にラウンドロビンと矛盾するものが含まれる。具体的には、DNS から返ってきたそれぞれの IP アドレスを自分の IP アドレスと比較して、一致する部分の長さが最長になるものを選ぶ。上のページで挙げられてる例をそのまま丸写しすると、
ということで、最長マッチの 192.168.0.{10,11,15} の3つのうち DNS の応答に最初に含まれていたもの(この例では 192.168.0.10)が使われる。192.168.0.1 のクライアントは 192.168.0.100 を使うことはないけれど、クライアントが 192.168.0.120 だったとすると同じ応答でも今度は 192.168.0.100 しか使われないことになる。11000000 10101000 00000000 00000001 = 192.168.0.1 = Client IP to match. 11000000 10101000 00000000 01100100 = 192.168.0.100 = (24 + 1 = 25 bits matching the client IP) 11000000 10101000 00000000 00001010 = 192.168.0.10 = (24 + 4 = 28 bits matching the client IP) 11000000 10101000 00000000 00001011 = 192.168.0.11 = (24 + 4 = 28 bits matching the client IP) 11000000 10101000 00000000 00001101 = 192.168.0.15 = (24 + 4 = 28 bits matching the client IP) 11000000 10101000 00000000 00010100 = 192.168.0.20 = (24 + 3 = 27 bits matching the client IP)_ じゃあラウンドロビンを無視するクライアントというのはみんな RFC3484 に従っているのかといえば、どうもそうではない。従ってたら IP アドレスの若いホストにアクセスが集中するなんて現象は起きない。
_ たとえば、DNS のラウンドロビン応答を無視するクライアントの代表格である Windows Vista。 MS で KB948505 として公開されていた情報(なぜか今は MS から消えてるのでリンク先は別のところ)によると、ソート順は RFC3484 のルールではなく numeric order になると書いてある。つまり、上の例ではクライアントが 192.168.0.1 だろうと 192.168.0.120 だろうと関係なく常に 192.168.0.10 のサーバだけが選択されることになる。これは現実の観測と一致する。
_ Solaris 10 でもデフォルトではラウンドロビン応答をソートして常に同じアドレスを使うようだ。ソートアルゴリズムは不明だが RFC3484 ではなくこれもたぶん numeric order だろう。ただし、この挙動は 設定で変更できるらしい。
_ あと、たしか Java の SMTP クライアントライブラリも numeric order でソートしてたはず。しかも、こいつはデフォルトではいちど名前解決に成功すると無期限にキャッシュしてしまって、障害が起きたから該当アドレスを DNS から除いた、とかやっても延々とキャッシュされた古いアドレスにアクセスし続けるという泣ける実装だったりする。
_ 不評とはいえ数としては vista がけっこうな割合を占めるはずだが、しかし IP アドレスが若いホストに集中するという現象は vista 発売以前から観測されていたので、ここに挙げた以外でも numeric order でソートする実装がいくつも存在すると思われる。
_ もっとも、DNS の応答リストの最初のものを使わなきゃいけない、なんてルールはどこにも存在せず、「ほとんどの実装がたまたまそうなってた」という事実を利用してただけのことなので、ソートしたからといってそれをルール違反だと責めることはできない。でも numeric order でソートすべき特段の理由ってのも存在しないはずだから、これまで幸せに使えてたやりかたをぶっこわす実装ってのはやめてほしいもんだ。RFC3484 のやりかたもラウンドロビンは成立しないけど、それでも numeric order よりはアクセスの偏りは小さいはずなんでまだマシ。
_ まあ、NSD や Unbound といった固定順でしか答を返せない DNS サーバが普及すると、どっちにしろ関係ない話になってしまうんだけどな。やっぱり DNS ラウンドロビンは廃れていく運命にあるってことか。