月: 2005年4月

ぎっくり腰…

実は今週月曜日に人生2回目のぎっくり腰になってしまいました…
前回はちょうど10年前になりました。2度と繰り返したくないことですが、なってしまいました。前回より強力でかなり大変です… 今は何とか寝ながら入力しています…

ぎっくり腰になった時はまずひどくしない為に恥じも外聞もなく動かない事が重要と思います。次に横になれたら炎症を抑えるために冷やすことが必要だそうです。氷水をビニール袋に入れて20分冷やし、30分休むを3~4回は繰り返すと良いそうです。

義理の父に半強制的に針につれていかれたのですが、これがかなりの効果です。私の場合、筋肉だけでなく椎間板(脊椎の間の軟骨)が動いた(?)ことが原因だったようで痛みは完全には取れませんでしたがまったく動けなかったのですがなんとか動けるようになりました。人間の体もデジタルにできているようで動けないスイッチが入っていると動けなくなる、と鍼灸院の先生が言っていました。

動けるようにはなったのですが自由が利くというには程遠い状態です。椅子に座るのは腰に良くないらしく10分も座るとかなり痛くなってしまいます。来週には仕事復帰できないとまずいのですが、これで復帰できるのか不安です。

ICANN、新ドメイン「.JOBS」「.TRAVEL」を正式認定

IT Premium 本日のニュース 2005/04/09

●ICANN、新ドメイン「.JOBS」「.TRAVEL」を正式認定
 インターネット管理団体ICANNは4月8日、新しいトップレベルドメインとし「.JOBS」「.TRAVEL」の2種類を正式認定したと発表した。アルゼンチンで開催の第22回ICANN国際会議で理事会に承認された。Employ MediaとTralliance Corporationがレジストリとして運営に当たる。

全ての実世界のドメインをドメイン化することになるのかな…
前にも書きましたが利益があるのはドメイン名販売業者だけと思われます…

空港ラウンジサービス

最近羽田でかなり長い時間、搭乗までの時間を待っていることが連続してありました。結構辛いのでJALかANAのカードを契約してラウンジサービスを使うと言う手を考えたのですが契約してもマイレージカードとしてのみ使うのは確実なのでもったいないです。

そう言えば三井住友VISAカードもゴールドカードならラウンジサービスをしていたはずなので検索してみるとありました。これでANA、JALのどちらを使っても問題無しです。無線LANも使えればなお良いですね。確か知人が使える、と言っていたと思うのですがJALのラウンジだったのか三井住友VISAカードのラウンジだったのか失念… 使ってみれば判るのでラウンジを使ったらblogに書くことにします。

国際線のラウンジサービスは何度か使った事がありますが、国内線は初めてです。なんとなく楽しみですね。

DELLの20′ UXGAモニタ

送料込み5万5千円弱の特売DELLの20インチのUXGAモニタを1台買いました。非常に満足しています。EIZOのL565のデュアルヘッドだったのですが、このDELLのLCDの画質はL565より良いです。これを2台かっておけばよかったと後悔しています… また安くなるまで待つか…

追記:DELLはUXGA(1600×1200)とEIZOはSXGA(1280×1024)なので同列で画質を比較するのは多少問題ですね。

カードの暗証番号入力を拒否できるか?

これのつづきです。

世の中は防犯カメラが100%設置されている銀行のATMでさえ暗証番号入力は危ないので生体認証を採り入れようか、という時にも関わらず加盟店のレジでクレジットカードの暗証番号を入力させるという時代錯誤の加盟店が急増中に思えます。

レジで清算する際には真後ろや真横に他人が待っていて暗証番号を見るのは非常に簡単です。レジには防犯カメラが付いている事も多いと思いますが、その映像の管理は銀行等のATMに比べて十分安全に管理されているか?には大きな疑問符が付くと思います。
# 通上、利用規約上は暗証番号の入力を伴う取り引きの全て責任は
# 利用者にある、と書かれているはずです。ただし、判例などでは
# 明らかに不正利用と思われるケースでは暗証番号の入力があって
# も被害が保証される場合もあるようです。

そこで三井住友VISAカード、セゾンMASTERカード、ニコス郵貯VISAカードで暗証番号を拒否しサインで利用することは可能か聞いてみました。3社ともカードの暗証番号入力を拒否してサインで利用できます、と回答がありました。

セゾンにはより詳しく調べて頂き、判っている限りではJRのみどりの窓口以外は暗証番号を入力せずに利用できる、と詳しい回答を頂きました。答えて頂いた方の説明によるとJRのシステムが暗証番号無しで取り引きが出来ないように作られてしまった事が原因のようです。
# これは許される間違い(?)なのかな…

クレジットカード利用時に無意味かつ不必要な電話番号の記入を強要する加盟店でも電話番号を書いたことはほとんどないのですが、こんどは暗証番号入力を拒否する手間が増えるとは…

多分他のカード会社も同じ様に取り引き時の暗証番号入力は拒否できると思われます。クレジットカードの暗証番号記入に不安を覚える方はどんどん暗証番号入力を拒否しましょう。

英国では建築家が不幸?

建築家が不幸(幸福ではない)とは意外でした。

英国の雇用確保のための教育・訓練・資格取得の推進団体である「City & Guilds」の実施した2005年の「幸福度」調査で、建築家は最も幸福でない職能という結果が出た。

IT関係の職能はどうだったか気になりますね。この記事の出どころはここだったので見てみると、

IT Specialistsは満足度5%で堂々の下から4位… よく見ると同じ5%でも僅差で6位のようですね。弁護士よりましなようです ;)

「非常に満足している」人の割合なので感覚的には日本でアンケートしてみても同じかも知れませんね。

このサイトに載っていたTipsが気に入りました。

How to be happy in the workplace

    * Start off by being positive
    * Remember that every problem can be solved
    * Enrich your working environment with photos 
      and flowers
    * Have a laugh
    * Start the day with a natter or gossip
仕事場で幸せになるには
  *楽観的にはじめよう
  *どんな問題も解決可能な事を覚えておこう
  *写真と花で仕事場を飾ろう
  *笑いましょう
  *無駄話か噂話からその日をはじめよう

カード暗証番号入力の問題

クレジットカード利用時に不必要な電話番号の記入を強要するカード加盟店は昨年の記入された電話番号を悪用した事例のおかげでやっと無くなりました。カード規約には書名でサービスを利用できると明記されているので私はいつも電話番号記入は拒否していました。電話番号の記入を求める加盟店はまずカードの署名と伝票の署名が一致しているか確認していませでした。海外では署名を確認しない、ということはあり得ないのですが日本では確認しない加盟店の方が今でも多いくらいです。署名を確認されないと私は非常に不満なのですが、署名を確認されると不満に感じる利用者も多い(?)ということかも知れません。

もっと読む

@Wiki

とりすがりに@WikiというWikiを見付けました。
IEだけでなくMozillaでもしっかりWYSIWYG出来ているところが素晴らしいです。

http://www1.atwiki.jp/test/?cmd=edit&page=NEW

このWikiは無料サービスですが、よく調べるとダウンロードできるようになっているのかも知れませんが、オープンソースでは無い(?)ようです。

グーグルで検索するとJavaScriptのWYSIWYGエディタは結構オープンソースであるようですね。GPLの物もあるのでPukiWikiに付けるのはよいかも知れませんね。

http://www.bris.ac.uk/is/projects/cms/ttw/ttw.html

@WikiはソースコードみるとGPLのEpozを利用しているようです。Epozのデモサイトも用意されています。こんど使ってみよう :)

# @Wikiは学生さんが作られたサイトの様ですがWikiのベースはPukiWikiの様に
# 思えます。GPLの場合、完全なソースコードの公開義務があることを認識した
# 上で作られているか多少不安…

# epoz自体がi18nを意識した作りになっているのですが、日本語のメッセージ
# ファイルはEpoz 0.9.0には無いですね。是非コントリビュートして欲しいで
# すね :)

リファラスパム

このブログはそれほど人気がある訳でもないのでトラフィックは月あたり数百MBくらいでした。しかし先月から度重なるリファラスパムにあっています… その結果、トラフィックが1.5GBくらいになってしまいました。

私が受信するスパムメールは毎日数百通(webmaster等の管理用のメールアドレスからの転送、MLからのメール含む)です。しかも最近はHTMLメールにイメージファイルを埋め込んで送って来るスパムがかなり増えました。スパムメール、リファラスパムで相当なネットワークトラフィックが無駄に消費されていると思います。P2Pは使った事が無いのでどの程度トラフィックが発生するかは知りませんが、スパムだけでも膨大な無駄になります。

このブログのリファラ表示機能も無効化することにします。

はじめてのPHP言語プログラミング

まだいつ発売になるか私も知りませんが「はじめてのPHP言語プログラミング」(技術評論社)というタイトルでPHP入門書を書きました。4月末から5月に書店に並ぶと思います。

Webサイト構築の為の入門書ではなくプログラミング言語の入門書、読み終わった後もリファレンスとして使える本になるように書いたつもりです。どちらかと言うと既にプログラミング言語を習得されてPHPもマスターしたい方向けかもしれません。320ページで全て説明するのは難しく、ばっさり説明を省略している部分もありますが、言語仕様の解説部分では出来るかぎり妥協しないようにしています。どんな本を書く場合も同じと思いますが「自分が欲しい」と思える書き方、内容になったと思っています。

宣伝にはまだ早すぎですが、書店で見掛けたら買ってください :)

DNSキャッシュ汚染

BINDのバグの多さに辟易して2000年にdjbdnsに乗り換えてからBINDを使っていないのですがDNSキャッシュ汚染問題はまだまだ続いているようです。

DNS ‘pharming’ attacks target .com domain で広範囲なDNSキャッシュ汚染攻撃があったとニュースになっています。

SANSのブログによると

1,304 domains poisoned (pulled from the referer entries in the HTTPD logs)

と、1,300以上のDNSキャッシュ汚染(DNS cache poisoning)エントリが見つかったと書いています。

セキュリティに詳しい方には古い問題ですがなかなか改善されていません。私自身も昨年、日本のあるISPにDNS設定の問題を連絡したのですが、知合いのシステム管理者からISPから変更の連絡あったと聞いていないのできっとまだ改善されていないと思います。ISPでさえもこのレベルなので日曜DNS管理者(私もDNS管理を専門としていないので日曜DNS管理者ですが)が設定したDNSサーバに問題があっても当然かもしれません。

これから書く事を理解するためにはDNSサーバとDNSキャッシュを明確に区別する必要があります。example.comドメインを例に説明します。example.comのDNSサーバはexample.comドメインに権限を持ち、www.example.com, ftp,example.com等、example.comのサブドメインにホストを登録できます。一方、DNSキャッシュはDNS問い合わせをクライアントに代わって行うサーバです。DNSキャッシュサーバはトップレベルドメインから目的のホストのIPアドレスを取得するまで再帰的にDNS問い合わせを行い、結果をキャッシュします。ISP等が”DNSサーバ”と呼んでいるのは通上はDNSキャッシュサーバです。BINDでは再帰問い合わせに答えるサーバがDNSキャッシュサーバになります。

DNSサーバを構築する場合、DNSサーバとDNSキャッシュは別サーバとしなければならない、のですがBINDの悪いデザインのためDNSサーバとDNSキャッシュが同じサーバに設定できるようになっています。しかも、古いBINDではデフォルトで全てのクライアントから再帰問い合わせを受け付けるように設定されていました。このため、間違ったDNSサーバ設定方法ドキュメントが大量に再生産/再利用され現在でも間違った設定のDNSサーバが大量に存在します。

example.comドメインでDNSサーバとDNSキャッシュが同じDNSプログラム(BINDなど)で実行されていると、DNSキャッシュが汚染されるとexample.com以下のwww.example.com,ftp.example.comヘのアクセスを別のIPアドレスのサーバに誘導する事が可能です。SSLのサイト証明を使用していないと http://www.example.com/ へアクセスしたユーザは意図しているサイトにアクセスしているか、偽サイトにアクセスしているか全く区別がつきません。
# HTTP Response Splitting Attackでも同じ効果をHTTPキャッシュを汚染し
# 偽サイトを表示させることも出来ますが、DNSキャッシュ汚染に比べると
# DNSキャッシュ汚染の方が強力な攻撃方法です。

DNSが安全でないことはqmaildjbdnsの作者として有名なDan J. Bernstein氏が詳しく説明しています。

DNSを安全に利用する為には

  • DNSサーバとDNSキャッシュは必ず別サーバにする
  • DNSキャッシュサーバは必要なクライアント(社内クライアントなど)のみ問い合わせを受け付ける
  • ISPが提供するDNSキャッシュ(DNSサーバ)は利用しない
  • DNSキャッシュサーバは権限のあるDNSサーバ(Authoritative DNS)からの応答のみをキャッシュするサーバ(djbdnsのdnscacheなど)を使用する

などの対策が必要です。これらの対策を行ってもDNSサーバとDNSキャッシュを同じサーバプログラムで実行しているサイトでDNSキャッシュ汚染があると偽ホストにアクセスしていても普通は気が付かないでしょう。

The importance of separating DNS caches from DNS serversの中で指摘されているようにBINDのマニュアルでもDNSサーバとDNSキャッシュを必ず別するよう書いてあます。DNSキャッシュとDNSサーバを同じサーバに設定しても構わない場合は、分離されているネットワークシステムの実験環境などでDNSを使えるするようにする、など非常に限定された状況しかありません。本来、DNSサーバプログラムはDNSサーバとDNSキャッシュは別プログラムとして提供されるべき物です。djbdnsではDNSサーバ(tinydns)とDNSキャッシュ(dnscache)プログラムは別プログラムになっており、DNSサーバとDNSキャッシュは別サーバとして動作します。当然ですが最近作られたDNSサーバプログラムはDNSキャッシュとDNSサーバは別サーバととして動作します。

個人的にはsendmailの様に捨てられるサーバプログラムになっても構わないのですが、ISCはいつになったら壊れたBINDのデザインを修正するつもりなのでしょうね?

追記:念のために書いておきますがDNSキャッシュ汚染はdnscacheを使っていても可能です。dnscacheの場合汚染がより難しいだけです。DNSキャッシュ汚染は仕組の問題であるためプログラムでは修正できません。通常、ISP以外の組織がDNSキャッシュを公開する必要はなく、また公開DNSキャッシュを運用するべきではありません。

名前のローマ字表記

たまたま私の名字(おおがき)をローマ字表記で初めてグーグルで検索してみると、「ohgaki」と表記されている方も結構いる事が判りました。

「おおがき」をパスポート等で強制的に使用されるヘボン式で書くと「ogaki」になります。ほぼ100%「おがき」と発音されます。「oogaki」と書くと「うーがき」と読まれる可能性がかなり高くなります。そこで自分でローマ字表記が指定できる場合は「ohgaki」と書いています。多分、他の「おおがき」さんも同じ理由で「ohgaki」と表記されていると思います。

別のローマ字表記でも記述できる氏名の場合困った事になることもあります。例えばJALマイレージグラブです。カードのローマ時表記とJALに登録されているローマ字表記が異なるので自分名義のクレジットカードであるにも関わらず登録できません。(しかも、記憶が正しければ、JALはローマ字表記はヘボン式を使う規則と思いますが「oogaki」と登録されています)

最近カード利用での問題が多くなって来ているのでカード番号をウェブサイトで覚えさせることは少なくなっていく方向性かもしれませんが、このブログを読まれている方で、もしローマ字表記の氏名を取り扱うサイトを構築される場合、氏名のローマ字表記には複数の方法があり場合によっては個人の自由にならない事があることに留意してください。

追記:ヘボン式の表記を調べてみると2000年4月から正式にパスポートでも”OH”が利用できるようになったようです。JALのマイレージバンクでも電話をかけて簡単に修正できました。