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

■1Eスポ このエントリーをはてなブックマークに追加

クルマに乗ってFMラジオを聴いていたら、雑音が混じったり混信する感じだったので、「もしかして」と思ってスキャンしてみたら、バンド中がにぎやかだった。
ちょうどローカル番組をやっている局があって、東海地方だったので、77.8MHzにチューンしてみると、 ZIP-FM[https://zip-fm.co.jp/index.html] が、SINPO=55555でした。
夏の日の電離層のイタズラであるところの スポラディックE層[http://www2.crl.go.jp/kk/e412/CRL_News/back_number/110/110.htm] によるもので、受信障害を起こしたりして嫌われることもあるんですが、少しの間だけでも普段聴けない局が聴けるというのは、なかなか感動的な体験だと思います。
日本国内の電離層観測データ[http://wdc.nict.go.jp/ISDJ/index.html] 見てみると、 真っ赤[http://wdc.nict.go.jp/ISDJ/fxEs-alert.html] ですね。

■ 関連記事

詳細はこの日の詳細から

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

■1SYA!nikki[SYA!nikki] このエントリーをはてなブックマークに追加

1800 棚の製作:

部屋の模様替えに合わせて棚を製作。
棚の製作

■ 関連記事

詳細はこの日の詳細から

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

■1 nstx - Tunnel IP over DNS[http://nstx.dereference.de/nstx/][セキュリティ] このエントリーをはてなブックマークに追加

otsuneさんとこ[http://www.otsune.com/diary/2004/05/29.html#200405291] から。
TCP over DNS[http://www.nantoka.com/~kei/diary/?200311a&to=200311041#T200311041] とかいうネタを以前書いたのですが、実装がある様ですね。
できない[http://61.203.92.65/~fkz/daiary/200406.html#d011952] っていう指摘を頂いていまして( RinRin王国[http://www.pluto.dti.ne.jp/~rinou/saji/200405.html] 経由)、説明不足だなと思ったりもしたんですが、この場合TTLを気にする必要はありません *1 し、あるドメイン名のAを引いてそいつが実はCNAMEだった場合は、当然そのCNAMEレコードの正規名が得られる *2 訳で、この点でも問題無いように思いますが、いかがでしょうか。
もちろん、
DNSというのは半固定の広域分散データベースであり、任意のデータグラムの通信を行うための枠組ではない
のはもっともな指摘です。
モデル[http://61.203.92.65/~fkz/daiary/200406.html#d032320] を元にした伝送効率の考察もあります。素晴らしい。
DNS管理者ならRFCとまではいかなくてもバッタ本位は読みましょう。CNAME返すものがないとかちゃんと書いてありますよ。
ですね。バッタ本位は手元に必要です。第4版まで出てる様です。第4版はbind9に対応してずいぶん厚くなりました。16.1.6あたりの、ある正規名の別名を得る方法がないという話だと思うのですが、別名から正規名(と称する何か)が得られれば良いわけですから問題にはならない訳です。
この話、DNSの枠組みのabuseですから、
使ったらDoSになる可能性がかなり高いです。少なくとも途中に普通のDNSサーバが入るような状態では絶対に使うべきではないです。帯域埋め尽くしたり途中に入るDNSサーバのリソースを喰い潰したりといくつかの障害の元になります。
なので、よい子は 本当に使ったりしちゃダメ[http://amrita.s14.xrea.com/d/?date=20040602#p04] です。迷惑ですし優秀な管理者がいたらきっとバレます。 しかし、アプリケーションゲートウェイで通信を遮断しているのにDNSが引ける構成で運用しているトコの管理者が優秀かどうかというとあやしいです。
まぁ「外部に情報を漏らさずに外部の情報を得るのは非常に難しい」という例の一つとしてのお話だと思って下さい。 情報を取得することは、情報が漏洩することと表裏一体[http://d.hatena.ne.jp/hyperash/20040601#1086087669] ですし、 某ちゃんねるを見たりなんかするのに使ったら、さすがに派手なトラフィックを発生してばれるでしょうけど、細くても秘密の通信経路が作れる可能性があるということは、セキュリティを考える上では考慮しなきゃいけない問題です。 おおっぴらに使わなければ[http://senzai07.poly.kit.jp/~iwata/ChangeLogs/2004-06-01.html#ChangeLog-2004-06-01-4] 管理者も気づかない可能性があります。

ちなみに:

これを止めたかったら、 社内DNSキャッシュサーバは社内のリソースしか解決しない[http://www.mimori.org/~h/tdiary/20040603.html#p02] のが正しいわけです。
ただ実際のところ、外部へのアクセスをアプリケーションゲートウェイ経由にしているような組織では外部のドメインの解決ができても殆ど役に立たないハズなのに、引ける組織は多いようです。
*1: 一度引いたドメイン名は使い捨てにすれば良いから。
*2: 返すのはネームサーバのフリはしてるけどあくまでトンネルの相手方だから何でも好きなように返せる。

■ 関連記事

詳細はこの日の詳細から

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

■1SYA!nikki[SYA!nikki] このエントリーをはてなブックマークに追加

1532 マルチモニター:

パソコン新調に合わせてマルチモニター環境に。
マルチモニター

■ 関連記事

詳細はこの日の詳細から

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

■1 JIS素案「高齢者・障害者等配慮設計指針− 情報通信における機器・ソフトウェア・サービス −第三部:ウェブコンテンツ」の公開レビュー[http://www.jsa.or.jp/domestic/instac/review2003/Web/itbf_web.html][バリアフリー] このエントリーをはてなブックマークに追加

6月20日にWebコンテンツJIS(JIS X 8341-3:2004 高齢者・障害者等配慮設計指針 −情報通信における機器・ソフトウェア・サービス − 第3部 ウェブコンテンツ)として公開されたものの素案。

■ 関連記事

詳細はこの日の詳細から

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

■1 夜間金庫前に偽金庫設置、投入した133万円盗まれる[http://www.sankei.co.jp/news/040628/sha128.htm][セキュリティ] このエントリーをはてなブックマークに追加

昭和48年2月に大阪で起きた事件のリバイバル的犯行。 “ニセ夜間金庫”問題[http://www.imasy.or.jp/~ume/copyright-ml/inetmag/internet-magazine-1998-03.html#section4] という問題に登場するらしい。
とある銀行がやっているインターネットバンキングは、システムを全面的にヨソに委託している様で、サイトで使用しているSSL鍵もその委託先の会社のモノという困った状態になっている。
銀行のホームページにはそのページへのリンクがあるが、こちらはSSLのページではないため、結局のところ、なりすましに対してはSSLを使用している意味がほとんど無くなっていると言えよう。
しかも、郵送されてきた操作説明には、
○○銀行のホームページ(http://www.XXXXbank.co.jp/)にアクセスし、「○○バンキング(仮称)」の「ログオン」画面に進んで下さい。
としか記述がない。
これまた悪い癖で、サンプル画面は全てアドレスバーが消してあるので、果たしてこのドメインが本当に銀行が業務委託している先なのかどうかを見分ける方法が全くない。 ベニヤで作ったニセ夜間金庫に騙される人がいる一方、取得した画像などを加工して作ったニセサイトは、ベニヤ製の夜間金庫よりも遙かに本物らしいものがお手軽にできてしまう現実がある。
ドメイン名やサーバ証明書は、偽物と本物を見分けるための唯一と言って良い手段なのだから、もう少し重視すべきだと思うのです。

■ 関連記事

詳細はこの日の詳細から

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

■1 続・夜間金庫前に偽金庫設置、投入した133万円盗まれる[http://www.nantoka.com/~kei/diary/board.cgi?act=read&msgid=112][セキュリティ]次の記事 >> このエントリーをはてなブックマークに追加

コメントを頂きました。
自社ドメインじゃなくて外注ドメインを使っていたときに「自分でやらないなんて無責任な会社だ」と思ってしまう消費者意識を変えるところから始めないとまずそうですね。 コストや技術力を考えた場合、外注するほうが合理的で安全な場合が多いと思うのですが。

自社でやるか外注でやるかについては、この問題に関してはニュートラルな積もりだったのですが、読み返して見ますと、確かに外注することがネガティブに見える書き方になっていました。
以前、 トラコスにユーザーサポートを外注している企業は珍しくない[http://www.nantoka.com/~kei/diary/?200307c&to=200307292#T200307292] の項でアウトソースについて書いたのですが、上手に使えばアウトソースは会社側にとってもユーザー側にとっても、よりよいサービス提供を行える可能性があります。
しかし、otsuneさんご指摘の様に、「自分でやらないなんて無責任な会社だ」の様な私的があることも事実でしょう。
ただ、私はサービス提供側にも問題があって、これは顧客側の意識と鶏と卵かも知れませんが、ヨソにアウトソースしていることを隠したがる傾向にも問題が潜んでいるのではないかと思います。
特に今回取り上げたSSLの話に関しては、アウトソースしているならアウトソースしているなりに、アウトソースしている事を顧客に告げないと、信頼性において問題が生じる構造になっています。
今回取り上げた銀行はまだ良いほうなのですが、以前にはアウトソースした上に、アドレスバーでアウトソースしたことが分かるのが嫌だったらしく、わざわざJavaScriptを使ってアドレスバーが出ないウインドウを開いていた事例もありました。
アウトソースにおけるルール作りを整備していく必要があると思います。

■ 関連記事

■2RSS対応[hns]<< 前の記事 このエントリーをはてなブックマークに追加

■ 関連記事

詳細はこの日の詳細から

以上、7 日分です。

指定日の日記を表示

前月 2004年06月 翌月
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

最近の日記

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
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

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