2009年12月06日()<< 前の日記 | 次の日記 >>
この日の詳細

■1Google Public DNSで無力化される米国特許6108703 このエントリーをはてなブックマークに追加

話題になっている Google Public DNS[http://code.google.com/intl/ja/speed/public-dns/] ですが、結局のところ、速度向上のメリットがあるのは、自分が現在利用しているISP等の DNS サーバが遅い場合ということになると思われます。
ウチでは手元にネームサーバを立ち上げていますが、ISPのネームサーバを使った場合、
kei@home[120] dig www.google.co.jp @xxx.xxx.xxx.xxx

; <<>> DiG 9.4.3-P3 <<>> www.google.co.jp @xxx.xxx.xxx.xxx
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32789
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.co.jp.              IN      A

;; ANSWER SECTION:
www.google.co.jp.       71292   IN      CNAME   www.google.com.
www.google.com.         75334   IN      CNAME   www.l.google.com.
www.l.google.com.       271     IN      A       66.249.89.103
www.l.google.com.       271     IN      A       66.249.89.147
www.l.google.com.       271     IN      A       66.249.89.99
www.l.google.com.       271     IN      A       66.249.89.104

;; Query time: 17 msec
;; SERVER: xxx.xxx.xxx.xxx#53(xxx.xxx.xxx.xxx)
;; WHEN: Sun Dec  6 11:09:01 2009
;; MSG SIZE  rcvd: 146
で、「Query time: 17 msec」という測定結果が出ました。
一方、 Google Public DNS[http://code.google.com/intl/ja/speed/public-dns/] の場合、
kei@home[121] dig www.google.co.jp @8.8.8.8

; <<>> DiG 9.4.3-P3 <<>> www.google.co.jp @8.8.8.8
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27943
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.co.jp.              IN      A

;; ANSWER SECTION:
www.google.co.jp.       259200  IN      CNAME   www.google.com.
www.google.com.         259200  IN      CNAME   www.l.google.com.
www.l.google.com.       300     IN      A       66.249.89.103
www.l.google.com.       300     IN      A       66.249.89.147
www.l.google.com.       300     IN      A       66.249.89.99
www.l.google.com.       300     IN      A       66.249.89.104

;; Query time: 51 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Dec  6 11:11:31 2009
;; MSG SIZE  rcvd: 146
と、51 msecを要しています。その差、Tg(=51ms) - Ti(=17ms) = 34(ms)ですから、差は歴然としています。「Google Public DNSに変更したら早くなった」という人は、これまで相当に遅いDNSサーバで我慢してきた人と言うことになるでしょう。
こう書くと、「RTTが短いのは分かるけど、Google Public DNSには圧倒的なキャッシュ能力があるから、結局早いんじゃないの?」という反論がありそうです。 もちろん、GPDNSは投機的なキャッシュ更新をはじめとした、様々な高速化対策が施されているので、安定して早いと言うのは事実だと思います。
ですが、ISPのネームサーバのキャッシュに載っていないアドレスを引く確率はどの程度のものでしょうか。1%もあったら、相当特殊なブラウジングをしているのでは無いでしょうか。
ということで、日常的な体感速度には、結局、現在使っているネームサーバとGPDNSとの応答時間の差が支配的になると考えます。まず、計測してみましょう。

前段が長くなりましたが…:

みんながGPDNSを使うようになると、 Akamai[http://www.akamai.co.jp/] が保有している、 米国特許6108703[http://www.google.com/patents?id=-HsEAAAAEBAJ&dq=6,108,703] が無力化してしまう可能性に気づきました。
DNSクエリの問い合わせ元IPアドレスを見て、ネットワーク的に近くのサーバのIPアドレスを返すと言う仕組みなのですが、GPDNSを使われてしまうと、DNSクエリはGPDNSから来ることになって、この仕組みが使えなくなりそうです。
実際、 Akamai[http://ja.wikipedia.org/wiki/Akamai] *1 のシステムを使っている、いくつかのサイトに対する問い合わせを、ISPのネームサーバ経由とGPDNS経由で出してみたところ、違った答えを返してくるケースがありました *2 。GPDNSがAkamaiの様に、クエリ元IPを意識してIPアドレスを返し別けていれば良いですが、そうでなかったらCDNを使っているサイトはむしろ遅くなる可能性があります。
今は、利用者が少ないので大きい影響は無いと思いますが、今後、利用が拡大していけば、Akamaiに限らず、DNSを使った負荷分散や地理的分散処理を行っているシステムに影響を与えることになるかも知れません。
*1: AkamaiもGoogleと同じ1998年設立。
*2: 負荷分散のために、ラウンドロビンしている可能性もあるので、必ずしもGPDNSが原因とは言えませんが。

■ 関連記事

詳細はこの日の詳細から

2005年12月06日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1 「設定変更は禁止、ダウンロードファイルは再起動で削除」:マイクロソフトの無償ツール[http://japan.zdnet.com/news/itm/story/0,2000052525,20092160,00.htm][セキュリティ]次の記事 >> このエントリーをはてなブックマークに追加

Stressful Angel[http://stressfulangel.cocolog-nifty.com/stressful_angel/2005/12/_126_08f3.html] より。
これは使えそうだ。日本語版の提供開始は、12月15日の予定。

■ 関連記事

■2モバイル機器とパスワード[セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ノートパソコンのメーラのパスワードを記憶させるようにするべきか、その都度入力するようにするか、ずいぶん迷ったのだけど、記憶させる運用で使っている。
パスワードをその都度入力するのは、面倒という側面もあるけれども、モバイル機器の場合は、人前でパスワードを入力しないといけない局面が出てくるという問題がある。
隣でノートパソコンを覗き込んでいる人がいるときに入力はできないし、周りに知っている人はいないように見えても、遠くから監視カメラで覗き込んでいる人がいるかも知れない。大事なパスワードをそういう危険にさらすことはできない。
ということで、暗号化ファイルシステムを活用して、ワンタイムログオンに近い運用をするようにしている。sshのパスフレーズも電源を入れるたびに一度だけ入力することになる。
蓋を閉じるとWindowsパスワードを聞かれるから、これだけは危殆化する前に変更する必要がある。
もちろん、レジューム状態でノートパソコンを盗まれたら、鍵やパスワードが盗み出される心配があるから、この時は全てのパスワードと秘密鍵を変更する必要があるだろう。
こういう「人前での認証」という用途を考えると、生体認証は便利だなと思う。

■ 関連記事

■3静脈認証に対する疑問[セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

最近、静脈認証が流行している様だけれども、いくつかの疑問が。
静脈認証で用いられる認証パターンだけれども、これは世の中の個人を特定するに十分な情報量を持っているのだろうか。直感的にだけれども、指紋や虹彩ほどの情報量を持っている画像には見えない。あるいは、その辺りにある画像は説明用のもので、本来はもっと解像度の高い画像を用いているのだろうか。
もう一つは、「身体内部にある情報だから安全」という主張と「非接触で認証できる」というメリットが相反するのではないかという懸念。身体内部にある情報だけれども、知らない間に非接触で盗み出されるという心配は無いのだろうか。

■ 関連記事

詳細はこの日の詳細から

2004年12月06日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1 [和書]前田建設ファンタジー営業部[http://www.amazon.co.jp/exec/obidos/ASIN/4344007069/keisdiary-22?dev-t=DDHPHE04VROHE%26camp=2025%26link_code=sp1][book] このエントリーをはてなブックマークに追加

■ 関連記事

詳細はこの日の詳細から

2001年12月06日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1IPv6だと動くのが[おしごと][IPv6]次の記事 >> このエントリーをはてなブックマークに追加

業界標準の様なので、 会社のロゴ[http://www.nanet.co.jp/] を差換えておいた。IPv6な環境だと動くはず。
残念ながら、この日記を置いているホストはIPv6化されていない。

■ 関連記事

■2逆引きの設定[IPv6]<< 前の記事 このエントリーをはてなブックマークに追加

0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   IN PTR hogehoge.nanet.co.jp.
はちょっと長いので、将来ネットワークをポリシー分割することも考えて、 途中で自分に移譲して書くことにした。
49a.218.2001.rev
----
0.0.0.0         IN      NS      ens.nanet.co.jp.
                IN      NS      ns.nanet.co.jp.
しておいて、
0.49a.218.2001.rev
----
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN      PTR     hoge1.nanet.co.jp.
0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN      PTR     hoge2.nanet.co.jp.
って感じ。これでも長いのは長いけど、これ以上は分割しちゃいけないような気がするし、 将来分割することも無いはず。 本当はrfcなりなんなり調べれば良いのだけれど、野生のカンがトラブルの元になりそうだといってる気がする。
ところで、v4の時は逆引きのAレコードにネットマスク書く習慣があったのだけれど、 v6では何か決まっているんですかね。

DNS-deskからメール:

がきて、
0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   IN PTR hogehoge.nanet.co.jp.
に修正して欲しいと言われた。やっちゃダメなのかなぁ。

■ 関連記事

詳細はこの日の詳細から

以上、12 日分です。

指定日の日記を表示

前月 2021年12月 翌月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

予定

    ToDo

      link

      keikuma on Twitter

      keikuma Name:前田勝之
      Location:長崎市
      Web:http://www.nantok...
      Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

      サイト内検索

      Google AdSense

      Powered by hns-2.19.9, HyperNikkiSystem Project