トップ 追記

インターノット崩壊論者の独り言

過去の日記
EPIC2014
Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。

2018-04-08 ささやかな抵抗 2

- 8.8.8.8 に加え 1.1.1.1 を用いたアクセスも拒否させて頂きます。

国が著作権侵害を行っているサーバを DNS ブロッキングで遮断する措置を 電気通信事業者へ要請しようとしているというニュースが入って来ました。これは検閲の禁止や通信の秘密と公共の福祉が真っ向からぶつかる話になるでしょう。慎重な議論が必要です。

児童ポルノのブロッキングの際には長い議論があって、児童の人権と生命のほうが大切ということから、ISP たちは「自主的に」ブラックリストを共有してブロッキングを行いました。今回の著作権問題が人命が危険に晒されていた問題と同様に扱って良い話だとは思えません。いきなり政府から電気通信事業者への要請という危険な方向へ走る前にできることがあるのではないでしょうか。

問題とされている著作権侵害のサイトに配信サーバを提供し幇助しているのは Cloudflare だとのことです。彼らは米国の裁判所から著作権侵害の幇助が成立するという判決を受けています。わが国もまずは配信サーバのテークダウンの要請あるいは裁判を彼らに対して起こすべきでしょう。

そして国から要請を受ける前に我々もできることはあるでしょう。とりあえず私は Cloudflare が運営しているパブリック DNS キャッシュサーバ 1.1.1.1/1.0.0.1 を利用した私のサイトへの接続を拒否し、ささやかな抵抗としたいと思います。

これは別途論じたいと思っていますが、電気通信事業法も見直されるべき時に来ているのではないでしょうか。私はインフラとしての電話とあくまで実験でしかないインターノットを同列に扱うのがおかしいと思っています。自律ネットワークには自律的に何を流すのかを決める権利と、協調のための自律の努力義務があると思います。そのうえで検閲やまっとうな定義での盗聴(機械的にヘッダを見るのも違法だが正当業務行為だという現状の法解釈と運用は詭弁でしょう)を禁ずることは可能でしょう。さもなくば私の AppleTalk を流してくれないのは通信の秘密に抵触することになりますよ。IPv6 しかり。ネット中立論なんて絵に描いた餅にすぎません。

本日のツッコミ(全3件) [ツッコミを入れる]

_ ものぐさクソ野郎 [もしよろしければ上のヘッダー(Google Public DNS 云々)も CloudFlare の件について書き加..]

_ tss [入れました。ありがとうございます。]

_ 14.192.44.4 www.e-ontap.com [14.192.44.4 www.e-ontap.com]


2017-12-13 インターネットの子供たちへ

- 子供たちに知っておいて欲しい話がある。

昔インターネットと呼ばれたネットワークがあったんだ。

インターネットよりも昔の時代には一握りの巨大な電話会社たちが提供する通信サービスしか人々は利用できなかったんだ。何が出来るかは彼らが決めていたんだ。決められたこと以外はやっちゃいけなかった。罰せられたんだ。

昔はパソコンというものもなくて、コンピュータはお金のある組織の一部の特権的な技術者だけが扱うことを許されていたんだ。

だけど45年ほど前にイヴァン・イリイチという人が道具は誰もが自由に使えてお互いを助け合えるもの (コンヴィヴィアリティのための道具) でなくてはいけないと人々に説き、同様に考えた人たちがパーソナルコンピュータ(パソコン)を生み出したんだ。アラン・ケイの書いた論文 "あらゆる年齢の「子供たち」のためのパーソナルコンピュータ" とか読んでみて欲しい。

そしてパーソナルなコンピュータを使って誰とでも自由にいろんなデータをやり取りしたい、自由なコミュニケーションがしたいという人たちが集まって新しいネットワークを生み出したんだ。それがインターネットだったんだ。

彼らはまず自分の会社や大学で自分たちのネットワークをつくった。そしてそれらを寛容な合意形成をしながらお互いにつなぎ合ってどんどん大きなネットワークにして行ったんだ。手を繋いでみんなで輪をつくるように。そのネットワークには中心はなかった。それぞれの人たちが自分で作ったネットワークを互いに繋いだだけだったからね。

そのつながりあったネットワークはインターネットと呼ばれるようになり、そこでは他人に迷惑をかけない自律と、話し合い譲り合い困った人を助ける協調と、そして全体を支配する人のいない分散した管理が尊ばれたんだ。通信ソフトウェアもそのような「自律分散協調」の動作をするように作られていたんだ。

誰かがこんな通信をしたいと思いつくと、彼はソフトウェアを書き、それを皆に分け与えた。それを気に入った人はそれをまた周りの人に配り、使い方を教え、使える人が増えて行った。ほとんどのソフトウェアは自由に改良できるようになっていて、人々は好みにあったソフトウェアを自由に作り出し選択できたんだ。

でも結局そういうインターネットは理想的な世界を作り出す前にうまく行かなくなったんだ。インターネットってのは幻想だったのかも知れないね。

通信の秘密とやらのおかげで自律と協調ができない人たちもお金を払えば合意の輪に入れるようになってきて、どんどん全体の協調が崩れていったんだ。

そしてそれに対抗しようとする頭の良い人たちのおかげで仕組みが複雑になりすぎたんだ。技術は大きく複雑になると管理できなくなって人々の手を離れるんだ。頭の良い人たちに管理してもらわなくちゃいけなくなる。頭の良い人たちがそうやってどんどん主導権を握るようになるんだ。主導権とりたい人たちは頭良いよね。

最初自分で自由にやるのが楽しかった人たちも、協調できない人たちや複雑になりすぎた技術が手に負えなくなってくると、誰かに任せた方が楽だと思い出すようになる。

そのうち対価をもらって自由な人たちを手助けしていた人たちにも手に負えなくなってくる。手が掛かりすぎて商売にならなくなるんだ。もともと技術がないのに適当にごまかして引き受けていたりした人たちも多かった。残念なことだね。

そして失敗が重なると安全・安心じゃないといわれて、技術力のない人たちの居場所がなくなっていった。国もインターネットはインフラだ、安全・安心が大切と言っていろんな規制を始めようとしている。

安全・安心な仕事を引き受ける人がいなくなってくると仕事の対価はどんどん高くなる。高いのに十分な技術を持った人は見当たらないという状況が生まれてきちゃった。

インターネットをインフラにしたいなんていう無理な相談しているのだから当たり前だよね。インターネットを構成している君の学校、会社のネットワークがインフラだと言っているに等しいんだから。そんなの担えきれないよね。

そこへ大勢まとめて面倒みるから安く出来ますよ、我々のやり方に従ってもらいますけどね、というところが出てくると皆はそこに頼まざるを得なくなってきちゃった。

こんな風にして気がついたときにはもう大勢まとめて面倒みているところにしか優秀な技術者の居場所はないという世界になってしまっていたんだ。絶滅寸前の古い技術者も巷にちょっとだけ生き残ってはいるけどね。大事にしてあげてね。

そして世界は情報の消費者ばかりになり、中央のコンピュータに日々の行動を自ら監視してもらうようになり、コンピュータの提案に無意識に従うようになりつつあるんだ。(星新一の『声の網』って読んだことあるかな。あんな風になってきてるの気づいているかな。そしてその方向は加速してる。皆が見えない塀の中に閉じ込められ管理されつつあることに気づいて欲しいな。

人々は与えられるもので満足してしまうから、自由のなさをなかなか不自由に感じられなくなってしまう。塀の中ではそれなりに幸せなんだろうね。むしろ皆と同じものを使わないでいると息苦しくなるんだ。管理された技術は社会を技術に合うように変えちゃうからね。

自律分散協調を尊び自由を求めたインターネットはもう存在しないんだよ。今あるネットはなんと呼べば良いんだろう。インターノットかな。

それでも塀の外には自由はあるんだと信じている人たちはまだ残っていて、新しい世界をつくろうとがんばっている。貴重な存在なので応援したいね。そもそも新しいものを生み出す道具を手にする人たちが絶滅しかけているのだし。

自由な人たちに絶滅して欲しくないんだ。自由な世界が崩壊して欲しくない。そんなに管理されたい? インターネットが何だったかをぜひ学んで欲しいな。このリンク先とか参考にしてね。そして戦おうよ。自律分散協調の旗を再び掲げ、自由のための道具を手にして。それこそがネットリテラシー、情報リテラシーだ。

p.s.

『インターネットの子供たち』を書かれた故三宅なほみ先生に本エッセイを捧げます。また、「子供/保護者/学校」×「情報リテラシー」 Advent Calendar 2017 の13日目のための記事でもあります。

過去の記事


2017-09-18 台風迫る中

- DNS 温泉 4 無事終了

台風迫る 10/16 - 10/17、無事に DNS 温泉 4 が終了しました。参加した皆さん、お楽しみいただけましたでしょうか。

資料はこちらです。後藤さんがツダってくださったログがこちら(Day1, Day2)。

参加者の皆さんのレポートもありがたいですね。


なお、台風で予定の旅程で帰れないかもと判断した私ともう一人が延泊し、楽しく補講を行いました。


2017-08-07 総務省の注意喚起は FUD

- DNSSEC に関する一連の注意喚起で混乱中の皆様へ

総務省をはじめとする一連 (NISC,JPRS,JPNIC,JPCERT/CCあるいはそれらを元にした報道) の DNSSEC KSK ロールオーバーに関する注意喚起を鵜呑みにしてはいけません。総務省データ通信課の高村信企画官は注意喚起文書の文面が嘘も方便あるいは FUD であることを認め、さらには注意を喚起するためには「Terrible Story (恐ろしい話) が必要だった」とまで発言されています。(先日の記事参照)
彼らの説明や対策は DNSSEC 推進のための余計な方策が組み込まれているために、非常に複雑なものになっている一方で説明すべきことを説明していないために専門家が読んでも理解不能な文書になっています。DNSSEC推進やフラグメントの問題などネットワーク健全化の話は今回の問題とは分けたほうがすっきりしてわかりやすくなると進言もしたのですが、高村氏は「政府は DNSSEC 推進の立場にあり、それを盛り込まないわけにはいかない」と発言し、それを拒否しました。(いつ政府が DNSSEC 推進だと決まったのでしょう? 今のところ go.jp では 4 ドメインくらいしか DNSSEC 署名がなされていないように見えます。NISC.GO.JP や NPA.GO.JP, IPA.GO.JP, KANTEI.GO.JP ですら無署名です。)

彼らとは別な立場からは彼らの説明とはもっと異なるシンプルな問題回避策がありますので、混乱している方々のためにここに記したいと思います。

まず第一に DNSSEC はほとんど安全に寄与しないどころか害ですらあります。DNSSEC推進、そして今回の対策はその害を拡大するものです。(参考: 「DNSSEC はなぜダメなのか」)

一連の注意喚起(特に総務省)は、

  1. DNSSEC を有効にせよ (総務省)
  2. ルートの鍵更新に追従せよ
  3. UDP のサイズ制限を拡大せよ
  4. 9/19 に増大する KSK 応答を受け取れなくなり、名前解決に障害が発生する可能性があるので、サーバのみならずネットワーク機器などを洗いざらい調査せよ

などというものです。これらがどうおかしく、どう対処するのが本当は適切なのか説明します。

第一の適切な対処: DNSSEC 署名の検証は無効にしましょう

総務省の言い分はDNSSEC を有効にせよというものです。これは現在有効にしていなくてもこの機会に有効にして鍵を更新しておかないと、将来本格利用してもらうときに再度困ったことになるからというのが総務省の説明でした。いらぬお節介が過ぎるでしょう。DNSSEC の害は 「DNSSEC はなぜダメなのか」に書いたとおりです。DNSSEC 署名の検証は無効にし、さらに DNSSEC も無効 (これが詳しくない人には意味不明だと思いますが専門的には DO bit off) にするとよいでしょうがクライアントが必要としていたり、実装上無効にできない実装もあったりするようです。でも検証しなければ問題はないと ICANN の文書にもあります。(問題あるかのように書かれている文書は書き方が悪いかミスリードの意図がある)

第二の適切な対処: DNSSEC の署名を検証したい方は鍵更新について専門の文書に従いましょう (よく勉強して)

早い時期から DNSSEC に手を出しておかしな設定をしたような経緯がない組織では問題になるようなことはないでしょう。最近の実装は普通にインストールして普通にアップデートしていれば問題はないはずです。そもそも DNSSEC の仕組みがわかっていない組織が DNSSEC に手を出すべきではありません。障害対応が出来なくなるでしょう。

第三の適切な対処: UDP サイズ制限は小さくしましょう

DNSSEC を推進する方々はなぜか UDP を使わせたがります。そして 大きな応答も UDP で扱えるよう、キャッシュ DNS サーバで UDP のサイズ制限 (Unbound だと edns-buffer-size:) を大きくしましょうというのが注意喚起が要求していることなのですが、これこそがマッチポンプで問題を生じさせる話なのです。UDP サイズを大きくすると IP フラグメントが発生しやすくなり、もし通信経路上にフラグメントを適切に扱えない機器があったら障害が発生するかもしれないわけです。(ただ今回は Ethernet の 1500 バイトやフレッツの 1438-1454 バイトを越えるわけでもなく、心配すべきは例えば IPv6 や VPN を使っている人くらいなのではないでしょうか。騒ぎすぎです。)
今回はむしろ UDP サイズ制限は小さくするべきです。今回注意喚起にある MTU 1280 バイトに収まるサイズにすると IP フラグメントの発生する可能性はずっと小さくなり、通信経路を全部心配する必要もなくなります。例えば 512 バイトにしてしまえば、DNSSEC 登場以前の DNS のように 512 バイトを越える応答は DNS の仕組み (truncate) に従って UDP よりずっと安全な TCP に切り替わってくれるはずです。(ただしこの場合、ファイアウォール等で TCP 53 が止められていないことを確認することが重要です。TCP のサポートは RFC でも必須となっています。TCP に未対応のドメインが少数あるかもしれませんが、そういうところは DNSSEC にも未対応でしょうし、もし大きな応答を返すようなら自業自得で責められるべきでしょう。)
なぜ、これを一連の注意喚起を出した人たちは説明しないのでしょう。TCP だとルートサーバの負荷が増えるとか ANYCAST で問題がでるかもしれないとか理由がないわけではありませんが大した問題には思えません。ルートサーバの負荷が問題なら DNSSEC やらなきゃいいのに。本音は TCP だと DNSSEC の必要性が薄れるからなのではないでしょうか。

第四の適切な対処: ネットワークの調査・対策は急ぎません

第三の対処で総務省等の注意喚起とは逆に UDP のサイズ制限を小さくしておけば、経路全体を心配する必要がなくなります。今回の注意喚起を機会に調べるのは大変結構なことではありますが、杞憂でいらぬ騒動をさせられる現場の人たちがかわいそうです。慌てず予算と他の仕事に余裕のあるときに調べれば良いのではないでしょうか。なお、フラグメントはセキュリティポリシーで止められているかもしれません。第一フラグメント便乗攻撃などといった攻撃も心配されますし、甘いチェックでセキュリティ機構をすり抜ける IP フラグメントは他のリスクを招き寄せるからです。

以上は、DNSSEC 推進をもとにした注意喚起に反対の立場から書かせてもらいました。推進の立場の文書とあわせて、自分の頭で考えてみることが一番大切なことです。もちろんご相談には応じますけれど。


追記(8/24):この件でセミナーを企画しました。

追記(9/11): セミナーの資料 「DNSSECの仕組みとKSKロールオーバへの対応」 を公開しました。

追記(9/2): Unbound の edns-buffer-size の推奨値が間違っていたことがわかりました。おかしいと思った。(Unbound-Users ML より)

参考リンク

本日のツッコミ(全4件) [ツッコミを入れる]

Before...

_ tss [本文中、MTU と UDPサイズを混同してしまっている部分がありますが、細かく書きなおしませんのでご自分で換算してく..]

_ tm [「DNS 署名検証チェック」はおかしいので、 「DNSSEC署名検証の有無判定」あたりにしたら。w (リンク先は..]

_ tss [採用させて頂き TYPO も直しました。ありがとうございます。]


2017-07-31 嘘も方便

- こういう DNSSEC 推進おかしくないですか?

ブログを書こうと思っていたけれど、IGCJ members ML に投稿したのでそれを転載します。意見のある方はぜひ IGCJ members ML へ。ただし IGCJ を本当にインターノットガバナンスの場と考えて良いかは疑問に思っていますけれど。

総務省高村様からこちらで議論するのがよかろうと伺って投稿させて頂きます。
 
DNSの世界的な運用変更に伴うキャッシュDNSサーバーの設定更新の必要性
http://www.soumu.go.jp/menu_news/s-news/02kiban04_04000212.html
 
という総務省の注意喚起文書に色々疑問があって総務省へ電話したところ、高村様と
以下のようなやりとりをさせて頂くことができました。
 
Q. 別紙2 に「本年9月19日までに、以下の措置が必要」として、
 二枚目の (1)_ の 3 に "念のため、「キャッシュ DNS サーバー」において、
 「DNSSEC」が有効になっており、また「DNSSEC の検証」が有効になっている
  ことを確認する。"
 とあるが、DNSSEC の検証が MUST であるかのように読めるのはおかしいのでは
 ないか? 検証しない機器まで巻き込む必要ないでしょう?
A. 総務省は政府として DNSSEC を推進する立場であるので、この文書でもその立場
 で記述している。検証は「推奨」という立場で書いている。
Q. 「推奨」とは読み取れない。読者を誤解させないで欲しい。
A. (立場を繰り返すのみ)
 
Q. 添付図表の 5枚目 (PDF 7枚目) に
 "ルートDNSサーバーは、応答相手のDNSSEC対応・非対応に関わらず公開鍵情報を
 送信してしまう" は間違いではないか?
A. ICANN がルートサーバの運用をどう変えるかわからない。将来そうするかもしれ
 ないという話がある。将来にも問題が生じないようにそう書かせてもらった。
 
具体的なポイントのやりとりは上記の2点ですが、全体として誰に読んでもらいたい
文書か分からない(誰が読んでもわからない)文書ですし、技術的におかしなことば
かり書かれていて、騒動を起こすための文書にしかみえません。
 
注意喚起をするのは結構なことですけれども、混乱を引き起こすのはやめて頂きた
い旨を高村さんにお伝えしたところ、
 「広く注意喚起をするのが目的なので Terrible Story としてこのような文書に
  してある。どこの組織でも問題が発生する可能性があるので、SIer など分かる
  ところへ投げるアクションをとってもらえたらそれでよい」
ということでした。
 
教育者としては間違った知識を広めてもらうのは困るとお伝えしましたが、あなた
はあなたの立場、我々は我々の立場で行動する。鈴木さんが注意喚起を抑えること
で何か障害が発生したらあなたは責任を取れるのかということでした。
 
このような FUD のような手法で注意喚起を行って、社会を混乱させるのが果たして
正しいインターノットガバナンスなのでしょうか。問題提起としてここに振らせて
頂きましたので御議論頂ければと思います。

とりあえず2通目も追加。あとは ML 見てください。

> 注意喚起をするのは結構なことですけれども、混乱を引き起こすのはやめて頂きた
> い旨を高村さんにお伝えしたところ、
>  「広く注意喚起をするのが目的なので Terrible Story としてこのような文書に
>   してある。どこの組織でも問題が発生する可能性があるので、SIer など分かる
>   ところへ投げるアクションをとってもらえたらそれでよい」
> ということでした。
 
不安になった組織のお偉いさんの指示で呼び出された SIer が問題を理解していれば
まだ良いのですが、巷の SIer でこの話がわかる技術者が出てきてくれるケースはほ
とんどないと言ってよいでしょう。そこが DNSSEC の問題点なのです。
 
ちゃんとサポートできる技術者がいればよいのですが、いないと結局皆が Google な
どに逃げ出すことなり、日本の技術力は負のスパイラルで落ち込んで行くでしょう。
もちろん自律分散協調だったインターネットも崩壊し、他律集中非協調のインター
ノットになっていく (それもたぶん持たないので崩壊) という私のインターネット
崩壊論がどんどん裏付けられているのは皮肉にもありがたいところではあります。
 
それを政府をあげて応援するのが私には不思議ですね。

追記: 「DNSSEC はなぜダメなのか」

本日のツッコミ(全3件) [ツッコミを入れる]

_ tss [関連して「DNSSEC はなぜダメなのか」まとめてみました。]

_ tm [G社からの風が吹いているのかも。あるいはDNSSEC推進のI社からも。 ここに書いてある通りだとすると、国会で..]

_ tm [DNS, DNSSECが分かる技術者を育てようとしないで、普及だけさせたいというのは間違っています。その結果としてG..]


2017-03-11 追いかけるの辛い

- とりあえず学ぶべき IPv6 関連 RFC をリストアップしてみた

IPv6 の技術者がとりあえず知っておくべき (学ぶべき?) であろうものを独断で選びました。このほかにルーティング関連なども色々あるしこれで全てじゃありません。改廃もよくあるし学ぶの辛いですね。

  • 1995.12 RFC 1883 Internet Protocol, Version 6 (IPv6) Specification (改廃して RFC 2460)
  • 1995.12 RFC 1886 DNS Extensions to support IP version 6 (改廃して RFC 3596)
  • 1996.08 RFC 1970 Neighbor Discovery for IP Version 6 (IPv6) (改廃して RFC 2461)
  • 1996.08 RFC 1981 Path MTU Discovery for IP version 6 (改廃して RFC 8201)
  • 1998.07 RFC 2373 IP Version 6 Addressing Architecture (改廃して RFC 3513)
  • 1998.12 RFC 2460 Internet Protocol, Version 6 (IPv6) Specification (改廃して RFC 8200)
  • 1998.12 RFC 2461 Neighbor Discovery for IP Version 6 (IPv6) (改廃して RFC 4861)
  • 1998.12 RFC 2462 IPv6 Stateless Address Autoconfiguration (改廃して RFC 4862)
  • 1998.12 RFC 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (改廃して RFC 4443)
  • 1998.12 RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
  • 2001.01 RFC 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (改廃して RFC 4941)
  • 2001.08 RFC 3152 Delegation of IP6.ARPA (改廃して RFC 3596)
  • 2003.02 RFC 3484 Default Address Selection for Internet Protocol Version 6 (IPv6) (改廃して RFC 6724)
  • 2003.04 RFC 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture (改廃して RFC 4291)
  • 2003.07 RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
  • 2003.10 RFC 3596 DNS Extensions to Support IP Version 6
  • 2003.12 RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
  • 2004.05 RFC 3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats
  • 2004.07 RFC 3849 IPv6 Address Prefix Reserved for Documentation
  • 2004.09 RFC 3879 Deprecating Site Local Addresses (サイトローカルの廃止)
  • 2004.09 RFC 3901 DNS IPv6 Transport Operational Guidelines (BCP 91)
  • 2005.10 RFC 4193 Unique Local IP v6 Unicast Addresses
  • 2006.02 RFC 4291 IP Version 6 Addressing Architecture (一部 RFC 5942 で改)
  • 2006.04 RFC 4294 IPv6 Node Requirements (改廃して RFC 6434)
  • 2006.03 RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
  • 2006.04 RFC 4472 Operational Considerations and Issues with IPv6 DNS
  • 2007.09 RFC 4861 Neighbor Discovery for IP version 6 (IPv6)
  • 2007.09 RFC 4862 IPv6 Stateless Address Autoconfiguration (一部 RFC 7527 で改)
  • 2007.09 RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
  • 2007.09 RFC 5006 IPv6 Router Advertisement Options for DNS Configuration (改廃して RFC 6106)
  • 2007.12 RFC 5095 Deprecation of Type 0 Routing Headers in IPv6 (RFC 2460,4294 改)
  • 2010.08 RFC 5952 A Recommendation for IPv6 Address Text Representation (RFC 4291 改)
  • 2010.11 RFC 6106 IPv6 Router Advertisement Options for DNS Configuration (改廃して RFC 8106)
  • 2011.04 RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
  • 2011.04 RFC 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
  • 2011.12 RFC 6434 IPv6 Node Requirements
  • 2012.09 RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6)

これが抜けているのはまずいだろ、ってのがあれば教えてください。

NAT64/DNS64 は入れましたが他の IPv4/IPv6 共存技術は混沌過ぎて紹介する気にならないのでご容赦ください。

3/21追記:やはり追いかけるの辛い

  • 2017.03 RFC 8106 IPv6 Router Advertisement Options for DNS Configuration (RFC 6106 改)

7/15追記:これで終わりならよいけれど

  • 2017.07 RFC 8200 This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. (RFC 2460 改)
  • 2017.07 RFC 8201 Path MTU Discovery for IP version 6 (RFC 1981 改)

'18/4/20追記:見落とし。7217 は OpenBSD 6.3 に実装されたとか。

  • 2014.04 RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)
  • 2015.04 RFC 7527 Enhanced Duplicate Address Detection (4429, 4861, 4862 改)
  • 2017.02 RFC 8064 Recommendation on Stable IPv6 Interface Identifiers
本日のツッコミ(全1件) [ツッコミを入れる]

_ tm [ありがとうございます。]


2016-12-21 「子供/保護者」×「オンラインコミュニケーション」Advent Calendar 2016

- EXFORMATION

この記事は「子供/保護者」×「オンラインコミュニケーション」Advent Calendar 2016 - Adventarの21日目を担当したものです。

私が大学で受け持っている科目の一つに「情報と通信の理論」があります。クロード・シャノンの情報理論にトラフィック理論を少々加えた内容が中心なのですが、それだけで情報と通信を語ることはできないので雑談を多く混ぜ込んでいます。その一部をもとに今回の記事を書いてみます。子供とか保護者とかに特化した話じゃないのはご勘弁ください。

世界一短い手紙と呼ばれる逸話があります。『レ・ミゼラブル』の出版時に亡命していたヴィクトル・ユーゴーが出版社に "?" と手紙を送り、出版社は "!" と返信したというものです。これによって大変な売れ行きだということがユーゴーに伝わったわけです。しかしこれをシャノン流の情報の定義で測ると片道 5 ビット程度の情報量にすぎません。(符号をアルファベットと基本的な記号から選ぶとする)

現代の情報化社会の基盤になっている情報理論は 1948 年当時電話会社の研究所に在籍していたシャノンが考案したものです。そして通信回線の中にどれだけの情報を流せるかを定量化したものなわけであり、人間のコミュニケーションで交わされる情報量をそれだけで測るのは無理があるでしょう。

情報は英語で INFORMATION と書きますね。IN-FORMATION つまり形 (文字とか音声とか) にしたものです。シャノンの情報理論とそれに基づく情報通信が扱っているのはこれなわけです。それに対して人間は形にならない情報、つまり EX-FORMATION (外情報) の交換を行っていると考えられます。

人間のコミュニケーションにおいて、脳内の EXFORMATION を削ぎ落とし不可逆圧縮を行ったものが INFORMATION であるとも言えるでしょう。それが対面ではない帯域幅の限られた通信路を介すほどに削ぎ落とされるものは大きくならざるを得ません。そして受け取った相手はその圧縮された INFORMATION を脳内に再展開するのです。その際に想像力によって EXFORMATION が加わります。この EXFORMATION がうまく以心伝心されれば良いのですが、うまくいかないと「誤解」が発生するわけです。哲学者のフッサールの「会話の木」という概念がこのことを示しています。(表象と認識のギャップについてはフッサールや青田青嗣あたりお薦めです)

conversation-tree

別な言い方をすれば人間同士のコミュニケーションでは、TEXT だけ見ていてもダメで CONTEXT が重要なのです。CON は CONVIVIALITY にも使われている「共に」という接頭語です。人と人が共にあって文脈を共有し合うことが大切なわけです。オンライン・コミュニケーションではこのあたりが希薄になりがちなので気をつけたいですね。

p.s.

ミームのこととか講義の雑談ネタをもっとたくさん書きたかったのですが、長く書いても読まれないのでこれくらいにしておきます。興味ある人は私の講義に潜り込んでください。

参考: 『ユーザ・イリュージョン』

2016-08-04 浸透させよう

- 温泉と酒とDNS

DNS温泉3 を企画しました。開催地は熊本の玉名温泉です。参加申し込み受付中です。https://atnd.org/events/80244

DNS温泉2 とほぼ同じ内容ですが伊豆が遠くて参加できなかった西日本方面の方々、特に震災で観光客の足が遠のいている熊本の方々に配慮して開催地を決定しました。また、今回は JPRS や AFNIC が解説、注意喚起を出そうとしない "ENT was here !!!" の話題についても (DNSSECは苦手ながら) 解説をしたいと思います。お楽しみに。

本日のツッコミ(全2件) [ツッコミを入れる]

_ tm [タイトルでDNSが最後にあるのは多少の正直さの現れだと思うが、 「酒と温泉とDNS」の方がより近いのではないかとおも..]

_ tm [「DNSを浸透させよう」と言っているようにも読める。]


2016-06-15 座布団持ってって

- ENT was here !!!

dns-operations ML でトボけた漫才のような謎のやりとりがありました。適当に訳してみましょう。(https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/thread.html#15011より)

私) これ、なんすかね? dig -t txt gouv.fr +dnssec +short
  ステファン) こっちに訊けばいいでしょ。 dig -t txt co.jp +dnssec +short
    私) 知ってる。2年待ってるけど公式な説明はされてない。
  ニコ) ステファンが答えてくれると思うよ :)
    ステファン) gouv.fr はフランス政府だよ。 フランシスとマニュエルに投げとく。
  ビンセント) はい。それ今進行中のやつ。この件についてはそのうちちゃんとした説明をしに戻ってくるから待っててね。注目しててね :-) p.s. いや、ENT って名前の h4ck3r (ハッカー) にハイジャックされたわけじゃないからね... :-)
    私) 楽しみに待ってる
  ワレン) たぶん https://iepg.org/2014-07-20-ietf90/201407-poisoning.pdfhttps://conference.apnic.net/data/40/jp-actions-apnic_1441335387.pdf に関係してる。数年前に注目を得たけど、その後はまったく話をきかないな、、、
    私) だって、彼らは一般の技術者向けに公式な注意喚起を出していないし、APNIC 等での専門家向けのプレゼンでも全てを語ろうとはしないから。彼らは「(この件は)よく知られている」って言うんだ。

何か隠していたものが見つかって、うろたえて誤魔化そうとしているようにみえます。Warren 以外、答えているのは .FR を管理する AFNIC の関係者ですね。 JPRS も AFNIC も態度は大差ありませんね。

ちなみに ENT とは Empty Non Terminal の略に間違いないでしょう。"ENT was here" は「ここに Empty Non Terminal がありました」(だけど訳あって無くしました) ということです。

dig の結果は以下のようになっています。

% dig -t txt gouv.fr +dnssec +short
"ENT was here !!!"
TXT 8 2 172800 20160731080733 20160601080733 34516 fr. dwklNc0MFBgpbHhxeJIJIakFByU7gDfX204tQBrchu4KPjYPg6UiaGXm Lo3GDeN/3QwBvRwXp7EASP4he4a05ljwEmMerk4K78nN13ONzULko0Al B9EhEFEITOsABJnaWmz/k/Aq58gDle4em5o99g/fKGhZxej0V6mNcYNB 7Rs=

これは2年前の毒入れ話を AFNIC がようやく理解して対策に乗り出したことを示しているように見えるものです。

JPRS は内輪の集まりともいえる JANOG34 でこの資料のように説明しましたが、これじゃわかりませんね。一連の問題について一般の技術者たちに向けて広く解説と注意喚起を出してもらいたいものです。2年待ち続けてます。


追記:2年前の Bortzmeyer at nic.fr とのメールのやりとりを載せておきます。

From: Stephane Bortzmeyer
To: "T.Suzuki"
Subject: Re: Opened Pandora's box of Cache Poisoning
Date: Tue, 6 May 2014 12:21:18 +0200
Organization: NIC France

On Tue, May 06, 2014 at 01:37:43AM +0900,
T.Suzuki wrote
a message of 32 lines which said:

> Why don't you put a record in gouv.fr?

Because there is no reason to.

私) なんで (co.jp みたいに) gouv.fr にレコード入れないの?

ステファン) だって、そんな理由ないから

From: Stephane Bortzmeyer
To: "T.Suzuki"
Cc: Stephane Bortzmeyer
Subject: Re: Opened Pandora's box of Cache Poisoning
Date: Tue, 6 May 2014 17:14:04 +0200
Organization: NIC France

On Wed, May 07, 2014 at 12:07:45AM +0900,
T.Suzuki wrote
a message of 16 lines which said:

> I think that DNSSEC signed zones under gouv.fr can be poisoned if
> the gouv.fr zone is poisoned.

It has nothing to do with the fact that gouv.fr is an ENT. It is a general property of the DNS (being hierarchical).

私) gouv.fr ゾーンに毒入れされると gouv.fr 配下の DNSSEC 署名されているゾーンも毒入れできるかもしれませんよ。(注: この訊き方は間違いだったと今は思っているがステファンの回答もトンチンカン)

ステファン) それは gouv.fr が ENT であることとは全く関係ない。それは (階層的になるという) DNS の一般的特性ですよ。

追記: "ENT was here!!!" (DNS-OARC 25, Dallas, 10/2016)
本日のツッコミ(全24件) [ツッコミを入れる]

Before...

_ tss [重要な指摘 https://lists.dns-oarc.net/pipermail/dns-operations/..]

_ tss [NSD の ldns-signzone ではなく BIND の dnssec-signzone に問題がある htt..]

_ tss [そういえば NSD 4.1.10rc2 以前の ldns-signzone を試していないな。(ldns は別パッケ..]


2016-06-01 新gTLD は焼け野原?

- game は 50,000円?

インターリンク、「.game」の登録料を10倍に訂正というニュースを目にしました。ドメイン登録料を5,400円から54,000円 (税込) に訂正したそうです。人為的なミスだと言っていますが本当でしょうか。申し込んで利用を始めた人たちが法的に訴えそうな気もしますが大丈夫なのですかね。

.game は NSEC を採用しているので NSEC walk してみたところ 1716 のドメイン名が集まりました。5/25 に一般登録受付が始まって一週間ですが、それにしても少ないですね。当初の登録数の目論見が外れて慌てたのではと邪推してしまいます。(レジストリじゃないのでそれはなさそう。ちなみにレジストリの Uniregistry ってケイマン諸島にあるのですね。)

さて、計算してみると、5,000円 × 1,716 = 8,580,000円/年 となります。ICANN への申請費用 185,000ドル = 20,350,000円, 年間手数料 75,000ドル = 8,250,000円/年 25,000ドル = 2,750,000円/年 に運用コストを加えたらとてもビジネスになりませんね。これを50,000円/年にしてどれだけ利用者が残りますかね。

ちなみに2年経つ .moe は 6/1 現在で 5325 ドメインです。1,800円/年らしいので、1,800円 × 5,325 = 9,585,000円/年、ICANN に手数料払った残りで運用コスト出るのでしょうか。苦しいですね。

原野商法は結局焼け野原になるのでしょう。ICANN だけ焼け太りですかね。新gTLD には近寄らないほうがよいですね。いつ使えなくなるか心配です。

オマケ: games のドメイン名リスト, moe のドメイン名リスト

参考: .moe を DNSSEC walk してみた

本日のツッコミ(全1件) [ツッコミを入れる]

_ tm [gameはあてはずれかもしれないが、新gTLD一般は焼け野原というよりは草も生えない荒地の方が適切かも。他人に使わせ..]


最近の日記

リンク

Copyright by T.Suzuki