Domain Name Hacks
2008年07月28日
今更ながら追加
全ページではない。
大半のページにソーシャルブックマークのリンクを追加。
チョロチョロブックマークしてくれてる人がいる事に初めて気付いた。
2008/07/28(月)現在、はてブ数14。
2008年07月27日
実はいい加減なフォーマット
幾つか位置情報を確認してみると
マッピングに失敗している事が多い事に気付いた。
期待していたフォーマットとは違ったからだ。
期待していたフォーマット
下記の通り
- 都道府県 市区
- 町村
- ビル名
正常系サンプル:livedoor.jp
- 東京都新宿区
- 歌舞伎町2-16-9
- 新宿TKビル4F
つまり、上2つを取得してやれば良い
そう思っていた。
しかし、現実は甘くない。
何だよこれ…
異常系サンプル: kin29.jp
- 茨城県牛久市中央5-12-14
- [汎用JPドメイン指定事業者]
- 有限会社ネットグルーヴワークス
説明文が混入している。
Google Maps APIの特徴
実際に使ってみて分かった事。
- 正常な住所である事は大前提
- 正常な住所であるはずなのに位置情報取得…
- ビル名が入っていると位置情報取得失敗
現在の住所取得ロジック
- 3行のうち、文字列「ビル」が入っていたら除外
これで大分救えるデータが増えた。
先述のkin29.jpのような特殊データは無視しておく。
Google Maps Hacks 第2版 ―地図検索サービスをもっと活用するテクニック
posted with amazlet at 08.07.27
Rich Gibson Schuyler Erle
オライリー・ジャパン
売り上げランキング: 46266
オライリー・ジャパン
売り上げランキング: 46266
2008年07月19日
公開窓口の住所を地図で見たい
きっかけはいつも通り、自分の興味本位。
その住所がどこなのかを地図で見たかった。
例: livedoor.jp
処理内容は下記の通り。
- パース済みの公開連絡窓口の住所を利用
- Google Maps APIのジオコーディングで位置情報を取得
- 正常取得時は該当位置情報
- 異常取得時は株式会社あくしゅの位置情報
- 取得した位置情報をGoogle Mpasにマッピング
今後は他のccTLDも対応可能であれば対応して行きたい。
Google Maps Hacks 第2版 ―地図検索サービスをもっと活用するテクニック
posted with amazlet at 08.07.19
Rich Gibson Schuyler Erle
オライリー・ジャパン
売り上げランキング: 84589
オライリー・ジャパン
売り上げランキング: 84589
2008年07月18日
前から位置情報を表示させたかった
今回、位置情報表示を実装してみた。
処理内容は下記の通り。
- FQDNの場合はIPアドレスを参照
- IPアドレスを元にGeoIP City Geolocationから位置情報を取得
- 位置情報をGoogle Maps APIで地図表示
何故実装したのか。
それは…
そのIPアドレスがどこにあるのか
そのFQDNはどこにあるか
これらを知りたかったから。
具体例
- FQDN:
- blog.hansode.org
- IPアドレス:
- 203.131.198.205
問題点
幾つか試してみると分かるのは、位置情報の精度が低い事。
前述の様に今回位置情報データベースとしてGeoIP City Geolocationを使用した。
有料版と無料版があり、無料版を使用。
有料と無料の違いは位置情報の制度。
今後の位置情報改案
- 位置情報精度向上
- whois情報から住所を取得出来るドメイン名は位置情報を表示させたい
- 複数情報をマッピングさせたみたい(具体的ネタはまだ思いついてない)
Google Maps Hacks 第2版 ―地図検索サービスをもっと活用するテクニック
posted with amazlet at 08.07.18
Rich Gibson Schuyler Erle
オライリー・ジャパン
売り上げランキング: 55884
オライリー・ジャパン
売り上げランキング: 55884
2008年07月17日
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情報を確認してみると、
空行までを比較対照としてやれば良い事が分かった。
空行までを比較対照とするようにパーサーを修正して解決。
少ないとは言え、無駄な過去データが入り込んでしまった。
2008年06月20日
何もしないまま一ヵ月半経過
新機能が追加される訳でもなく、
サーバがトラブルに見舞われた訳でもない。
無事に動き続けていたwhoisシステム。
チューニングしよう
実践ハイパフォーマンスMySQL
posted with amazlet at 08.06.20
ジェレミ・D. ザウドニ デレク・J. ベリング
オライリージャパン
売り上げランキング: 11576
オライリージャパン
売り上げランキング: 11576
この読んでみた影響で調査してみようと思い始めた。
- クエリの見直し
- スロークエリーの確認と調査
- EXPLAINで使用するインデックスの確認
- MySQLのチューニング
- サーバの統計情報確認(munin)
- mytopコマンドで確認
- vmstatコマンドで確認
- my.cnfの確認
調査結果
- クエリとインデックスに関しては劇的変化を期待出来ない状態
- key_bufferが少な過ぎ…?
そして今回はkey_bufferを増やして見ることにした。
現在様子を見ているところ。
速くなった気がする。
数日様子を見てmuninがどんなグラフを描くか楽しみだ。
2008年05月05日
文字種類の切替
文字種類変更時のボタン押下が抜け落ちている事を指摘された。
例えば、確かに判定には無かった。
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
さて、どうなるのかな。
2008年04月29日
それは試行錯誤の繰り返し
- 第1世代
- 思いつく有名所を調べる
- すぐに限界が訪れる…
- 第2世代
- 3文字、4文字を調べる
- 無意味な文字列も含まれてて、あまり有用情報ではない
- 第3世代
- ネームサーバからドメイン名を取得していく
- そこそこ意味のあるドメイン名を取得出来る
- しかし、やがて限界が訪れる
- 第4世代(今ココ。巡回中。)
- IPアドレスの逆引きホスト名からドメイン名を取得していく
- ホスティング用のIPアドレスレンジの場合、逆引きにサービス中のホスト名が設定されている
- かなり価値のあるドメイン名を取得出来る
第5世代はどうするか
こんな事をやりたい。
- 価値あるドメイン名を取得したい
- アクティブなウェブサイトは価値があるはず
- 知らぬ間に検索してる
- ネットサーフィンしてるだけで検索されてる
これを満たすには…
- Firefoxのアドオン(orツールバー)を作る
- 表示中ページのホスト名を取得
- whois.hansode.orgへリクエスト送信
ホスティング業者向けマーケティングツールとして使えそうな気がするな。
2008年04月24日
気になるページのHost名情報を一発検索!!
Host検索用ブックマークレットを用意した。
- Host名情報を検索
- blogパーツにより、間接的にWhois情報を検索
営業さんから「欲しい」と言われていた機能。
ターミナルからコマンドを実行する事なく、
全てがブラウザだけで解決する。
結果的に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コマンドを使い慣れない人が
調べたい事を最小の時間で最大の情報を取得出来る事。
例えば営業さんにターミナルを使って作業をさせたくない。
教える時間が勿体無い。知ってる必要性は限りなく少ない。
物凄く非効率だ。
効率良く情報を収集して貰えれば言う事無い。
フィードバック大歓迎
- ここ、こうして欲しい。
- この情報も欲しいな。
- もっと使い易く…どうにかならない?
2008年04月23日
2008年04月20日
調査対象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は一意に決まると思っていた。
こんなの…アリ?
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。
もう、何度テーブルを作り直したんだろうか。
そろそろ仕様が固まりそう。
2008年04月15日
今の所、これが最短距離
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を指定して検索出来る事を期待していた。
マニュアルを読み直しても見当たらない。
どうも納得行かないな。
やはり妥協するしかないのか。
2008年04月12日
どうやらwhois情報を調べたい訳ではない
営業さんと話していると、こんな事を調べたいと言う。
- このサイトはどの管轄なんだろう?
- このサイトはどのレンタルサーバなんだろう?
それを調べるには
- URIからA RRを抜き出す
- A RRからIPアドレスを取得
- whois情報からIPアドレスがどの組織団体が管理しているか割り出す
これだけだと面白くない。
もう一歩。
IPアドレスにマッピングされているA RRのリストを整理出来ると、
どのサービスが同居しているのかを把握可能。
「あのサービス」と「あのサービス」、同居してたのか。そんな事が分かる面白い気がする。

つまり
運営しているサービス名を一撃で取得出来れば解決する。
もう一歩進んだマーケティング補助ツール化。
さあ、追加開発開始だ。
一覧表
調べごとがあったのでまとめてみた。
まだ、始まったばかり。
2008年04月02日
携帯電話向きドメイン名の定義
- アルファベットの1文字目である事
つまり、「a」「d」「g」「j」「m」「p」「t」「w」 - 連続して同じ文字は来ない
それは、入力する回数が増えるから。 - 上記条件を満たすTLD
実は「.jp」が該当する。
JPの登録状況
上記条件を満たす文字列を調査。
今回は「3文字.jp」「4文字.jp」を調査した。
| 文字数 | 組合せ | 登録数 | 未登録数 |
|---|---|---|---|
| 3文字 | 392 | 392 | 0 |
| 4文字 | 2744 | 1957 | 787 |
これを見て驚いた事。
それは、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 |
これにより気付く傾向。
- 「w」が空き傾向
- 「a」が人気傾向
そして導かれるNo.1
こんな統計出すヤツ
自分以外に居るのだろうか…
変更履歴
- 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)
携帯のキーを使った表示方法で見える化すると、
もっと面白く見えて来るのかも知れない。
アイデア大募集!!
こんなこと良いな。
出来たら良いな。
そう言ったアイデア、
ガンガン貰えると助かります!
2008年03月25日
2008年03月18日
例えばこんな障害
- 指定事業者変更だけをすればよかった
- ネームサーバを変更してしまった
- 変更先にはzone情報が無い
そして
- 作業ミスに気付く
- 変更前のネームサーバが何だったか分からない
- 八方ふさがり…
さぁ、どうする?
1つの答えは、whois.hansode.orgを使う。
それは何故か。
- whois情報の変更履歴があるから
- ただし、クロール済みである事
クロール済みであれば、
変更前のネームサーバを確認可能。
とは言え、ツールは「補助」なので、
作業前後の差分確認は必ずやるべき事。
初心忘れるべからず
時には振り返ろう。
そして、一歩先行くドメイン名管理サービスへの提案
ネームサーバ関連の障害事例を考えていたら、
以前、こんなエントリを書いた事を思い出した。
ネームサーバには2種類ある「内部名」と「外部名」。そしてサービス提案。
・ドメイン名のネームサーバに外部名があるかどうか
・外部名がある場合、ネームサーバのドメイン名の有効期限も積極的に確認
・レジストラは有効期限通知の際、ネームサーバの有効期限も一緒に通知
ネームサーバの部分は内部名と外部名を
もっと分かりやすく表示してやれば良いのかも知れない。
機能改善ヒント、振り返り
自分の過去のエントリにヒントが隠れている事もある。
自分のエントリを少し振り返ってみよう。



