半袖野郎 blog.hansode.org

今更ながら追加

全ページではない。
大半のページにソーシャルブックマークのリンクを追加。

• はてなブックマーク
• livedoor Clip
• Yahoo!ブックマーク
• Buzzurl

チョロチョロブックマークしてくれてる人がいる事に初めて気付いた。
2008/07/28(月)現在、はてブ数14。

実はいい加減なフォーマット

幾つか位置情報を確認してみると
マッピングに失敗している事が多い事に気付いた。

期待していたフォーマットとは違ったからだ。

期待していたフォーマット

下記の通り

• 都道府県 市区
• 町村
• ビル名

JPドメイン名では住所を上限3行。
正常系サンプル:livedoor.jp

• 東京都新宿区
• 歌舞伎町2-16-9
• 新宿TKビル4F

つまり、上2つを取得してやれば良い

そう思っていた。
しかし、現実は甘くない。

何だよこれ…

異常系サンプル: kin29.jp

• 茨城県牛久市中央5-12-14
• [汎用JPドメイン指定事業者]
• 有限会社ネットグルーヴワークス

これは正常な住所と言えるのだろうか…
説明文が混入している。

Google Maps APIの特徴

実際に使ってみて分かった事。

• 正常な住所である事は大前提
• 正常な住所であるはずなのに位置情報取得…
  • ビル名が入っていると位置情報取得失敗

現在の住所取得ロジック

• 3行のうち、文字列「ビル」が入っていたら除外

これで大分救えるデータが増えた。
先述のkin29.jpのような特殊データは無視しておく。

公開窓口の住所を地図で見たい

きっかけはいつも通り、自分の興味本位。
その住所がどこなのかを地図で見たかった。

例: livedoor.jp

処理内容は下記の通り。

1. パース済みの公開連絡窓口の住所を利用
2. Google Maps APIのジオコーディングで位置情報を取得
   1. 正常取得時は該当位置情報
   2. 異常取得時は株式会社あくしゅの位置情報
3. 取得した位置情報をGoogle Mpasにマッピング

今後は他のccTLDも対応可能であれば対応して行きたい。

前から位置情報を表示させたかった

今回、位置情報表示を実装してみた。
処理内容は下記の通り。

1. FQDNの場合はIPアドレスを参照
2. IPアドレスを元にGeoIP City Geolocationから位置情報を取得
3. 位置情報をGoogle Maps APIで地図表示

何故実装したのか。
それは…

そのIPアドレスがどこにあるのか
そのFQDNはどこにあるか

これらを知りたかったから。

具体例

FQDN:

blog.hansode.org

IPアドレス:

203.131.198.205

百聞は一見にしかず。

問題点

幾つか試してみると分かるのは、位置情報の精度が低い事。

前述の様に今回位置情報データベースとしてGeoIP City Geolocationを使用した。
有料版と無料版があり、無料版を使用。
有料と無料の違いは位置情報の制度。

今後の位置情報改案

• 位置情報精度向上
• whois情報から住所を取得出来るドメイン名は位置情報を表示させたい
• 複数情報をマッピングさせたみたい(具体的ネタはまだ思いついてない)

WHOISデータベースが更新される度に変更アリ判定

例看護.biz

before	after
<<<< Whois database was last updated on: Tue Jul 15 19:25:50 GMT 2008 >>>>	<<<< Whois database was last updated on: Wed Jul 16 15:30:53 GMT 2008 >>>>

変更されたとみなされている部分。

このデータは重要ではない。
レジストリ側のタイムスタンプなのだから。

WHOIS情報を確認してみると、
空行までを比較対照としてやれば良い事が分かった。

空行までを比較対照とするようにパーサーを修正して解決。
少ないとは言え、無駄な過去データが入り込んでしまった。

何もしないまま一ヵ月半経過

新機能が追加される訳でもなく、
サーバがトラブルに見舞われた訳でもない。
無事に動き続けていたwhoisシステム。

チューニングしよう

この読んでみた影響で調査してみようと思い始めた。

• クエリの見直し
  • スロークエリーの確認と調査
  • EXPLAINで使用するインデックスの確認
• MySQLのチューニング
  • サーバの統計情報確認(munin)
  • mytopコマンドで確認
  • vmstatコマンドで確認
  • my.cnfの確認

調査結果

• クエリとインデックスに関しては劇的変化を期待出来ない状態
• key_bufferが少な過ぎ…？

そして今回はkey_bufferを増やして見ることにした。
現在様子を見ているところ。
速くなった気がする。

数日様子を見てmuninがどんなグラフを描くか楽しみだ。

文字種類の切替

文字種類変更時のボタン押下が抜け落ちている事を指摘された。

例えば、
a0だった場合と、
acだった場合。

前者よりも後者がキーを押す回数多いよ。

確かに判定には無かった。

whois.hansode.org(35/n) - ドメイン名を数値化する1つの手段。携帯電話で打ちやすい文字列のスコアリング。の採点方法を更新。

新採点方法

• 減点方式
  • 1文字目は-1
  • 2文字目は-2
  • 3文字目は-3
  • 4文字目は-4
• 次の文字が、同じキーにある場合 　
  • aaa だったら、 a(-1) + a(-2) + a(-2)
  • abc だったら、 a(-1) + b(-3) + c(-4)
  　
• 次の文字種類が違う場合 　
  • a0 だったら、 a(-1) + 0(-2)
  • 0a だったら、 0(-1) + a(-2)
  　

SEOを意識

SEOは余り意識してなかったけど、
SEOに関する質問を立て続けに受けた。

SEOの勉強がてら、whois.hansode.orgを使って効果測定。
whois.hansode.orgは、 Googleのキャッシュが7万程度あるので
効果測定値を得るには丁度良さそう。

変更内容

• サイト名が先になっていたので、サイト名を後ろへ回した
• カテゴリが抜け落ちていたので追加

前: whois.hansode.org - キーワード
後: キーワード < カテゴリ | whois.hansode.org

さて、どうなるのかな。

僕とあくしゅ！

これを追加した。

Powered by axsh co., LTD.

追加したこと以外、何も変わらない。
今後もドメイン名に関するハックは続く。

それは試行錯誤の繰り返し

• 第1世代
  • 思いつく有名所を調べる
  • すぐに限界が訪れる…
• 第2世代
  • 3文字、4文字を調べる
  • 無意味な文字列も含まれてて、あまり有用情報ではない
• 第3世代
  • ネームサーバからドメイン名を取得していく
  • そこそこ意味のあるドメイン名を取得出来る
  • しかし、やがて限界が訪れる
• 第4世代(今ココ。巡回中。)
  • IPアドレスの逆引きホスト名からドメイン名を取得していく
  • ホスティング用のIPアドレスレンジの場合、逆引きにサービス中のホスト名が設定されている
  • かなり価値のあるドメイン名を取得出来る

やがて第4世代も限界が訪れる。

第5世代はどうするか

こんな事をやりたい。

• 価値あるドメイン名を取得したい
  • アクティブなウェブサイトは価値があるはず
• 知らぬ間に検索してる
  • ネットサーフィンしてるだけで検索されてる

これを満たすには…

• Firefoxのアドオン(orツールバー)を作る
  1. 表示中ページのホスト名を取得
  2. whois.hansode.orgへリクエスト送信

ツールバーを作れれば、
ホスティング業者向けマーケティングツールとして使えそうな気がするな。

気になるページのHost名情報を一発検索!!

Host検索用ブックマークレットを用意した。

• Host名情報を検索
• blogパーツにより、間接的にWhois情報を検索

この機能はnslookupコマンドを慣れてない人向け。
営業さんから「欲しい」と言われていた機能。

ターミナルからコマンドを実行する事なく、
全てがブラウザだけで解決する。

結果的にGeoIPと似た機能

GeoIPを目指していた訳ではない。
気付いてみると、IPアドレスから国名を取得出来る機能が備わっていた。

例えば203.131.198.205。
リンク先へアクセスすると分かる。

国: JP

この様に、
203.131.198.205は日本である事が分かる。

逆引きだけでは国名を知る事は出来ない。
IPアドレスレンジを知っているからこそ、国名を知る事が出来る。

時は来た

納得の行く状態になったので本番環境へ反映させた。

例えば『blog.hansode.org』
下記情報を取得出来る。

Aレコード	blog.hansode.org
IPアドレス	203.131.198.205
逆引き	blog-01.t.livedoor.com
IPアドレス範囲	203.131.192.0-203.131.207.255
IPアドレスの管理組織	datahotel

内容はnslookupにヒゲが生えたようなもの。
最近何度も登場してるイメージ図。

目指していた事

whoisコマンドやnslookupコマンドを使い慣れない人が
調べたい事を最小の時間で最大の情報を取得出来る事。

例えば営業さんにターミナルを使って作業をさせたくない。
教える時間が勿体無い。知ってる必要性は限りなく少ない。
物凄く非効率だ。

効率良く情報を収集して貰えれば言う事無い。

フィードバック大歓迎

• ここ、こうして欲しい。
• この情報も欲しいな。
• もっと使い易く…どうにかならない？

ご意見・ご感想・苦情・告白など…お待ちしてます。

完成予想図画あると横道へそれない

以前、完成予想図を描いた。
自分自身に助けられた様な物。

迷ったら予想図を見る

当たり前の事なのだろうけど、
行き詰った時に見ると先へ進める。

ホスト名を検索するだけで良い

1. ホスト名(FQDN)を検索
2. ホスト名からDNSよりIPアドレスを取得
   1. DNSよりPTR(逆引き)を取得
3. WHOIS情報からIPアドレスレンジを取得

この一連の作業を行えるようになった。
それぞれデータベースへ登録されて行く。

残りは表示ページ。
レイアウトと表示すべき内容をどうするか考え中。

何が表示されれば良いのか営業さんに聞いてみるかな。

調査対象IPアドレスは決まった

ようやく納得行くデータ構造になった。
さて、次はIPアドレスの逆引きレコードの調査。

ここまで来たらクローラー作りは簡単。
早速実行し、様子を見ていた。

PTR RRが2つ…?

クローラーがコケタ。
59.106.1.204がどうも上手く行かない。

デバッグと調査の為、digコマンド。

$ dig -t ptr 206.1.106.59.in-addr.arpa

; <<>> DiG 9.4.2 <<>> -t ptr 206.1.106.59.in-addr.arpa
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36527
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;206.1.106.59.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
206.1.106.59.in-addr.arpa. 2578 IN      PTR     tkdw-207.sakura.ad.jp.
206.1.106.59.in-addr.arpa. 2578 IN      PTR     tkdw-206.sakura.ad.jp.

;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 20 20:10:20 2008
;; MSG SIZE  rcvd: 101

え、2つ返って来た…

1つしか返って来ない事を前提に作っていた。
コケル理由は分かった。

PTR RRは一意に決まると思っていた。
こんなの…アリ？

アドレスレンジ数が多量過ぎる

試しにAPNICが管理しているアドレスレンジを使い、
任意IPアドレスが含まれるアドレスレンジを割り出す方法を考えていた。

データが多過ぎる事とサーバスペックの問題もあり、結果が出るまで数秒かかる。
ある時、ふと思った。

自力で頑張るのではなく、
WHOISサーバをそのまま使ってしまえば良いんじゃないか?

whoisサーバに問合せすると、一瞬でアドレスレンジが返ってくる。
パーサーを書いてあるので、アドレスレンジを取得しやすい。

この方向性で開発中。

CIDR表記出来ないものがある…?

APNICがアサインしているアドレスレンジを調査。
気付いたのは、そのまま一撃でCIDR表記出来ないレンジがある事。

例えば「150.26.0.0 - 150.100.255.255」
これは分解してやるとCIDR表記が可能。

150.26.0.0 - 150.100.255.255
↓
150.26.0.0/15 + 150.28.0.0/14 + 150.32.0.0/11 + 150.64.0.0/11 + 150.96.0.0/14 + 150.100.0.0/16

クローラーを書いて実験中

先ずはJPに割り当てられているアドレスレンジの調査。

次から次へと予期せぬ事が起き、その度にdrop table。
もう、何度テーブルを作り直したんだろうか。

そろそろ仕様が固まりそう。

今の所、これが最短距離

whoisのhelpを一通り見てみた。
しかし、納得行く検索を出来なかった。

妥協した結果はこのコマンド。

$ whois -h whois.apnic.net SAKURA | grep inetnum:
inetnum:      202.181.96.0 - 202.181.111.255
inetnum:      59.106.0.0 - 59.106.255.255
inetnum:      219.94.128.0 - 219.94.255.255
inetnum:      61.194.86.88 - 61.194.86.95
inetnum:      210.167.252.0 - 210.167.252.15
inetnum:      221.186.213.48 - 221.186.213.63

netnameを指定して検索出来る事を期待していた。
マニュアルを読み直しても見当たらない。

どうも納得行かないな。
やはり妥協するしかないのか。

どうやらwhois情報を調べたい訳ではない

営業さんと話していると、こんな事を調べたいと言う。

• このサイトはどの管轄なんだろう?
• このサイトはどのレンタルサーバなんだろう?

それを調べるには

1. URIからA RRを抜き出す
2. A RRからIPアドレスを取得
3. whois情報からIPアドレスがどの組織団体が管理しているか割り出す

これだけだと面白くない。
もう一歩。

IPアドレスにマッピングされているA RRのリストを整理出来ると、
どのサービスが同居しているのかを把握可能。

「あのサービス」と「あのサービス」、同居してたのか。

そんな事が分かる面白い気がする。

つまり

運営しているサービス名を一撃で取得出来れば解決する。
もう一歩進んだマーケティング補助ツール化。

さあ、追加開発開始だ。

一覧表

調べごとがあったのでまとめてみた。
まだ、始まったばかり。

nic	URI
iana:	http://ftp.apnic.net/stats/iana/delegated-iana-latest
apnic	http://ftp.apnic.net/stats/apnic/delegated-apnic-latest
arin	ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest
ripencc	ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-latest
lacnic	ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest
afrinic	ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest

携帯電話向きドメイン名の定義

1. アルファベットの1文字目である事
   つまり、「a」「d」「g」「j」「m」「p」「t」「w」
2. 連続して同じ文字は来ない
   それは、入力する回数が増えるから。
3. 上記条件を満たすTLD
   実は「.jp」が該当する。

JPの登録状況

上記条件を満たす文字列を調査。
今回は「3文字.jp」「4文字.jp」を調査した。

文字数	組合せ	登録数	未登録数
3文字	392	392	0
4文字	2744	1957	787

※2008/04/02 23:00現在(hansode.org調べ)

これを見て驚いた事。
それは、3文字ドメイン名が全て登録されていた事。

4文字JPをもう少し分類してみる

空き状況の傾向は？

文字	?文字目				合計
	1	2	3	4
a	186	184	198	189	757
d	262	258	265	264	1049
g	257	283	258	262	1060
j	230	260	245	284	1019
m	220	206	204	217	847
p	264	230	247	225	966
t	273	246	259	238	1016
w	265	290	281	278	1114

※2008/04/02 23:00現在(hansode.org調べ)

これにより気付く傾向。

• 「w」が空き傾向
• 「a」が人気傾向

そして導かれるNo.1

• 人気No.1は「amam.jp」
• 不人気No.1は「twdj.jp」

こんな統計出すヤツ

自分以外に居るのだろうか…

変更履歴

2008/04/03 11:10頃

不人気No.1を変更。
「twtj.jp」 → 「twdj.jp」
thx けいごーん

アイデアは雑談から

携帯電話で使いやすい文字列がどれなのか、分かると面白いね。

なるほど。
そう言う視点もあるのか。

そして試作

hansode.org = -24点

h(-2) + a(-1) + n(-2) + s(-4) + o(-3) + d(-1) + e(-3)
+ .(-1)
+ o(-3) + r(-3) + g(-1)

採点方法

• 減点方式
  • 1文字目は-1
  • 2文字目は-2
  • 3文字目は-3
  • 4文字目は-4
• 次の文字が、同じキーにある場合 　
  • aaa だったら、 a(-1) + a(-2) + a(-2)
  • abc だったら、 a(-1) + b(-3) + c(-4)
  　

携帯のキーを使った表示方法で見える化すると、
もっと面白く見えて来るのかも知れない。

アイデア大募集!!

こんなこと良いな。
出来たら良いな。

そう言ったアイデア、
ガンガン貰えると助かります！

punycode変換されたドメイン名だった

新着feedを見ていた。
punycode変換された文字だった事に気付いた。

iCalもpunycode逆変換表示。
これで分かりやすくなったはず。

そして気になった、日本語ドメイン名数

2008/03/25 01:40現在

tld	count(*)
com	4449
net	1539
jp	121
biz	40
合計	6149

流行るんだろうか…？

例えばこんな障害

• 指定事業者変更だけをすればよかった
• ネームサーバを変更してしまった
• 変更先にはzone情報が無い

そして

• 作業ミスに気付く
• 変更前のネームサーバが何だったか分からない
• 八方ふさがり…

さぁ、どうする？

1つの答えは、whois.hansode.orgを使う。
それは何故か。

• whois情報の変更履歴があるから
• ただし、クロール済みである事

クロール済みであれば、
変更前のネームサーバを確認可能。


とは言え、ツールは「補助」なので、
作業前後の差分確認は必ずやるべき事。

初心忘れるべからず

時には振り返ろう。

そして、一歩先行くドメイン名管理サービスへの提案

ネームサーバ関連の障害事例を考えていたら、
以前、こんなエントリを書いた事を思い出した。

ネームサーバには2種類ある「内部名」と「外部名」。そしてサービス提案。

・ドメイン名のネームサーバに外部名があるかどうか
・外部名がある場合、ネームサーバのドメイン名の有効期限も積極的に確認
・レジストラは有効期限通知の際、ネームサーバの有効期限も一緒に通知

ネームサーバの部分は内部名と外部名を
もっと分かりやすく表示してやれば良いのかも知れない。

機能改善ヒント、振り返り

自分の過去のエントリにヒントが隠れている事もある。
自分のエントリを少し振り返ってみよう。

whois情報数があるなら、ネームサーバ数があってもイイ

トップページにネームサーバ数を表示させてみた。

• whois情報とのレイアウトを考慮した事が関係する
• レイアウトのズレが改善された