トップ 追記

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

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

2018-11-04 DNSSEC は危ない (その2)

- Unbound を安全にしよう

現代的な DNS キャッシュサーバは RFC 4035 の要請により、DNSSEC 署名の検証を必要としないポリシーのもとにおいても無駄な DNSSEC 応答を要求する DO bit フラグが立ってしまっており、第一フラグメント便乗攻撃に脆弱になっています。

またデフォルト設定の Unbound は否定応答に付随する NS や A をキャッシュに取り込んでしまうため非常に危険な状態で動作してしまいます。

12/5 追記:
Unbound 1.8.2 releasedに "The nameserver records in large returned negative responses are scrubbed out of the packet to avoid fragmentation based DNS cache poisoning, from a report from T.Suzuki." とあるようにこの否定応答における深刻な脆弱性は 1.8.2 で解消されました。すぐにバージョンアップしましょう。(各種バリエーションのある第一フラグメント便乗攻撃すべてが解消したわけではありません)

追記その2: rec: Skip NS records in authority/additional sections of NXD / NODATA #7258のようにPowerDNS Recursor も対応してくれました。

第一フラグメント便乗攻撃に対して耐性を強くするためには、DO bit を 0 にして、Unbound では harden-referral-path: yes を設定するとよいでしょう。(10/31の記事参照)

そのような Unbound の動かし方を以下に示します。FreeBSD の ports を利用の場合です。DO=0 にする設定はないのでパッチ (以下の sed の部分) が必要です。自分の環境に合わせて作業してください。

# portsnap fetch
# portsnap update
# cd /usr/ports/dns/unbound
# make clean
# make extract
# sed -i '' -e 's/EDNS_DO 0x8000 \/\* Dnssec Ok \*\//EDNS_DO 0x0000 \/\* Dnssec NO \*\//' work/unbound-1.?.?/util/net_help.h
# grep Dnssec work/unbound-1.?.?/util/net_help.h
# make
# make deinstall
# make reinstall
# echo 'unbound_enable="YES"' >> /etc/rc.conf
# echo 'unbound_anchorflags="-l"' >> /etc/rc.conf (注: 起動スクリプトが trust anchor を取り寄せようとするのを抑止するため)
# echo 'module-config: "iterator"' >> /usr/local/etc/unbound/unbound.conf
# echo 'harden-referral-path: yes' >> /usr/local/etc/unbound/unbound.conf
# service unbound restart

これだけで安全になるわけではありませんが、第一フラグメント便乗攻撃のリスクはかなり低減できるはずです。なお当然ながらこの記事により生じた問題、あるいは私を信用しなかった場合に生じた問題等に私は一切の責任を持ちません。自分の頭脳で考えて行動しましょう。

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

Before...

_ tss [どちら側でも有効ですね。]

_ tm [DNSSECでなくとも危ない。というのが正しそう。]

_ tm [Unboundだけではなさそうなので、もっと広く警告したい。]


2018-10-31 DNSSEC は危ない

- これを NSEC/NSEC3 Replacement Attack と呼ぶのはどうだろう?

二週間ほど前に恐ろしい毒入れ手法が成立しうることに気づいて、どうやって公表したらよいか悩やんだのだけれど、何と Herzberg と Shulman の論文を読み返したところアバウトながらしっかり書いてあったので躊躇することなく解説することにした。なぜ私はこれを読み流してしまっていたのか。どうしてこれを誰も騒ぎにしていないのだろうか。

DO bit を常に on にしろという RFC 4035 の傲慢な要請は修正されるべきだと思う。そして RFC 2308 という酷い RFC (私なら査読通さない) も SOA に付随する NS を許さないよう書き直されるべきだと思う。(私に IETF に行けというのは無し)

以下、第一フラグメント便乗攻撃の原論文 Fragmentation Considered Poisonous の II 章の C. Circumventing the Cache が示唆していると思われる攻撃手法の解説 (11/4 追記: こっちの論文のほうが詳しい。同じ内容かと思ってちゃんと読んでいなかった。迂闊。https://arxiv.org/pdf/1205.4011.pdf 4.1.1 Injecting NS RR to NSEC3 Response)

  1. 第一フラグメント便乗攻撃は成立しうる
  2. だが Answer 応答の差し替えはバッファとキャッシュに阻まれて連続的な攻撃が困難 (うちの学生が卒研で検証中)
  3. 否定応答であれば連続的な攻撃が可能となる
  4. RFC 2308 は否定応答の SOA レコードに NS や A が付随することを許している
  5. 否定応答の SOA レコードに付随する NS や A をキャッシュする実装が存在する
    検証用のゾーンを作成したのでご利用ください。
    dig hoge.sub.mufj.jp txt ; dig fuga.sub.mufj.jp txt
    などと二度 (負荷分散されている環境では多数回) 繰り返して
    "Your_cache_server_is_vulnerable."
    と出たら使用中のキャッシュサーバは第一フラグメント便乗攻撃への耐性が低いと考えられます。ただし EDNS0 への対応等は別途検査が必要です。
    (Unbound で検証済/harden-referral-path:yes にしないと危険)
  6. NSEC/NSEC3 とその署名 (RRSIG) のついた否定応答の応答は大きい
  7. 第二フラグメントに追い出された NSEC/NSEC3 や RRSIG の一部を NS や A に差し替えることが可能である
    (NSCOUNT,ARCOUNTの数合わせとパディング等によってチェックサムを合わせることは難しくない)
  8. つまり否定応答を用いた第一フラグメント便乗攻撃により、移転インジェクションが可能となる (たぶん委任インジェクションも)
  9. RFC 4035 の要請により現代的なキャッシュサーバは DO bit が常に on になっており、署名検証をしない場合この攻撃が成立する
    (検証しても DoS になる / 鈴木が示したように条件によっては検証していても成立しうる )
  10. 応答内容が分かっていて変化しない場合、IP ID が完全にランダムであってもエントロピーは高々 16 bit だ (ポートランダマイズは役に立たない)

要するに DNSSSEC 署名しているドメインは、どうぞ未検証のキャッシュに毒入れしてくださいと言っているようなものである。そして検証もしないのに DO bit を常に立てているキャッシュサーバはマヌケである。(パッチが提供されるべきであろう)
(「DNSSEC はなぜダメなのか」もどうぞ)

11/5 追記: シャルマンらの論文 5 Conclusions and Defenses の以下の指摘はとても重大な指摘だと思う。大きな議論になっていないのが不思議だ。

We want to caution against drawing the conclusion that DNSSEC should not be used. In fact, the best defense is to apply DNSSEC correctly in all resolvers and domains (without using NSEC3 opt-out); this will certainly prevent many of our poisoning attacks, and even defend against more powerful Man-in-the-Middle adversaries. However, incremental DNSSEC deployment is vulnerable to our cache poisoning attacks, and complete adoption of DNSSEC may take considerable time, since it depends on adoption by both name server and resolver.

p.s.
この件でも思うのだが脆弱性はぼやかさずはっきりと解説されるべきだろう。悪いやつらだけが高いモティベーションで攻撃方法にたどり着き、守備側は何が危ないかも理解できないまま放置されることになる。

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

Before...

_ tm [delegation返答中のadditional sectionのすり替えも可能であることが分かりました。卒研の邪魔..]

_ tm [Unboundなどの実装の不良だと考えています。(RFCを書かないと修正されないだろうから、面倒なのでやらない。)]

_ tm [additional sectionのすり替えが可能だと書きましたが、 それがキャッシュを上書きして、毒となる..]


2018-08-27 5年目を迎えて地元愛知で

- DNS 温泉 5 無事終了

台風一過の 8/25 - 8/26、無事に DNS 温泉 5 が終了しました。参加した皆さん、お楽しみいただけましたでしょうか。前回は台風迫る山代温泉でしたが、今回は 5 周年記念に第 1 回を行なった猿投温泉&中京大学へ戻りました。やはり地元はやりやすい。

開催地も最初と同じ場所へ戻ったこともあり、内容も今回は初心に戻って超初心者向けに基礎から解説をさせて頂きました。1日目は基礎のお勉強がてら台風一過で晴天の中京大学で自慢のアイスアリーナ (スケートリンク) もみなさんに見ていただくことができました。オリンピック強化選手たちの滑りを見て頂き、有名な Y コーチとも遭遇したりとか。夜の部では猿投温泉も満喫頂けたかと思います。呑兵衛グループが就寝したのは午前3時半くらいでした。アイルランドへ転職されて今回参加できなかった常連 O さんからのアイリッシュウィスキーなど皆様からの差し入れの数々を美味しく頂きました。

2日目はゾーン作成からネームサーバ移転まで全員参加でハンズアウトに取り組んで頂いて終了。さらにリニモに乗って名古屋へ出てオプショナルな懇親会で夜遅くまで意見を交わさせて頂きました。皆様ありがとうございました。

交通の便は悪かったかもしれませんね。普段東京へ情報収集に出かけている身からすると、ざまあお気持ちはわかりますがご勘弁を。

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

参加した皆さんの振り返りレポートに期待したいと思います。


アイスアリーナ AURORA RINK 前にて 2018.8.25

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 しかり。ネット中立論なんて絵に描いた餅にすぎません。

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

Before...

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

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

_ tss [現在は解除しています。]


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

p.s.

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

過去の記事


2017-09-18 台風迫る中

- DNS 温泉 4 無事終了

台風迫る 9/16 - 9/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.

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

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

最近の日記

リンク

Copyright by T.Suzuki