From 118fffc9777e4e23d9046de5cb8391b5733c2170 Mon Sep 17 00:00:00 2001 From: Ryo Kajiwara Date: Mon, 3 Feb 2025 22:49:22 +0900 Subject: [PATCH 1/4] initial memo --- .../2025-01-27-0065-TokyoRubyKaigi12Report.md | 52 +++++++++++++++++-- 1 file changed, 49 insertions(+), 3 deletions(-) diff --git a/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md b/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md index 6c5061cf..4c74c023 100644 --- a/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md +++ b/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md @@ -129,9 +129,55 @@ created_on: 2025-01-27 * 録画: https://example.com/ -レポート。レポート。レポート。レポート。レポート。 - -(your name) +- RubyKaigiのNOCチームを長く担当されている方 +- セッションの内容 + - Rubyとの生活という意味ではRubyKaigiが近づくと本番のネットワーク機材と同じセットアップで生活するらしい + - DNS + - ドメイン名にあらゆるデータを紐付けられるキーバリューストア、階層型分散データベース + - 今回はクライアントとリゾルバの間の通信をセキュアにする話 + - 何で？ + - Do53は平文。80年代に生まれてからずっと変わってない + - 公衆WiFiは盗聴が可能ということが知られている + - WPA2 Personalは事前共有鍵(PSK)が公知なら盗聴に対して脆弱 + - 転がしてあるケーブルはだれてもMITMできる + - でその上で平文DNSが流れている！ + - 平文DNSを暗号化する取り組み + - DoT + - DoH + - `GET /dns-query?dns={base64(query)}` + - H2あるいはH3、TLSで暗号化 + - DoQ + - QUICのストリーム + - DoH/3に比べてH3がないぶんマシ + - クライアントの自動構成をしたい + - 従来のDHCPやIPv6 RA(RDNSS)はリゾルバのIPアドレスのみ伝えるのでリゾルバがどんな暗号化に対応しているかを伝えない + - 日和見暗号化 + - Adaptive DNS Discovery + - DDR (RFC 9462): リゾルバとクライアントの間で暗号化プロトコルをネゴシエーション + - `resolver.arpa.` という特殊用途ドメイン名で自身の対応プロトコルを公開する + - `arpa.` の権威サーバーが返すわけではなく、リゾルバーがこれのqueryに答える + - macOS, iOS + - `resolver.arpa.` のSVCB(Service Binding)レコードを書く + - RubyKaigi 2023（以降）ではDoT, DoH, DDRを提供 + - だいたい半分くらいのDNSクエリが暗号化できた + - DNR (RFC 9463) + - Windows Insider + - 検証プログラムがほしい + - 野生のDNSのプロにミスを指摘された + - DNSは壊れててもそれっぽく動いちゃう + - プロトコルの組み合わせが多く検証が難しい + - Ruby界に足りてないのがQUIC + - ngtcp2（Cで書かれたQUIC実装）のRubyバインディングを書いた + - できるだけ薄いラッパー + - IOは呼び出し側で管理。並行プログラムのプリミティブに影響されたくない + - 一方メモリ安全性はほしい + - 通常のTCPクライアントは再送処理をカーネルがやるが、QUICではアプリケーションがやる + - (個人メモ) カーネルの面倒事をマッチョな実装者が引き受けることで代わりに高速化を得ているんですねえ + - (個人メモ) + - ngtcp2 - ruby (ruby上でUDPSocketを作る) - kernel という形で実装してる + - これはIOとconcurrencyをRuby側で面倒見たいので全部丸投げにできない + +(sylph01) ## 『Regional.rb and the Tokyo Metropolis』 From 11cd2ff1f06e33d908c594fca58d7098dd4c4ed2 Mon Sep 17 00:00:00 2001 From: Ryo Kajiwara Date: Tue, 11 Feb 2025 21:54:17 +0900 Subject: [PATCH 2/4] wrote --- .../2025-01-27-0065-TokyoRubyKaigi12Report.md | 58 ++++--------------- 1 file changed, 11 insertions(+), 47 deletions(-) diff --git a/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md b/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md index 4c74c023..f28ade24 100644 --- a/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md +++ b/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md @@ -129,53 +129,17 @@ created_on: 2025-01-27 * 録画: https://example.com/ -- RubyKaigiのNOCチームを長く担当されている方 -- セッションの内容 - - Rubyとの生活という意味ではRubyKaigiが近づくと本番のネットワーク機材と同じセットアップで生活するらしい - - DNS - - ドメイン名にあらゆるデータを紐付けられるキーバリューストア、階層型分散データベース - - 今回はクライアントとリゾルバの間の通信をセキュアにする話 - - 何で？ - - Do53は平文。80年代に生まれてからずっと変わってない - - 公衆WiFiは盗聴が可能ということが知られている - - WPA2 Personalは事前共有鍵(PSK)が公知なら盗聴に対して脆弱 - - 転がしてあるケーブルはだれてもMITMできる - - でその上で平文DNSが流れている！ - - 平文DNSを暗号化する取り組み - - DoT - - DoH - - `GET /dns-query?dns={base64(query)}` - - H2あるいはH3、TLSで暗号化 - - DoQ - - QUICのストリーム - - DoH/3に比べてH3がないぶんマシ - - クライアントの自動構成をしたい - - 従来のDHCPやIPv6 RA(RDNSS)はリゾルバのIPアドレスのみ伝えるのでリゾルバがどんな暗号化に対応しているかを伝えない - - 日和見暗号化 - - Adaptive DNS Discovery - - DDR (RFC 9462): リゾルバとクライアントの間で暗号化プロトコルをネゴシエーション - - `resolver.arpa.` という特殊用途ドメイン名で自身の対応プロトコルを公開する - - `arpa.` の権威サーバーが返すわけではなく、リゾルバーがこれのqueryに答える - - macOS, iOS - - `resolver.arpa.` のSVCB(Service Binding)レコードを書く - - RubyKaigi 2023（以降）ではDoT, DoH, DDRを提供 - - だいたい半分くらいのDNSクエリが暗号化できた - - DNR (RFC 9463) - - Windows Insider - - 検証プログラムがほしい - - 野生のDNSのプロにミスを指摘された - - DNSは壊れててもそれっぽく動いちゃう - - プロトコルの組み合わせが多く検証が難しい - - Ruby界に足りてないのがQUIC - - ngtcp2（Cで書かれたQUIC実装）のRubyバインディングを書いた - - できるだけ薄いラッパー - - IOは呼び出し側で管理。並行プログラムのプリミティブに影響されたくない - - 一方メモリ安全性はほしい - - 通常のTCPクライアントは再送処理をカーネルがやるが、QUICではアプリケーションがやる - - (個人メモ) カーネルの面倒事をマッチョな実装者が引き受けることで代わりに高速化を得ているんですねえ - - (個人メモ) - - ngtcp2 - ruby (ruby上でUDPSocketを作る) - kernel という形で実装してる - - これはIOとconcurrencyをRuby側で面倒見たいので全部丸投げにできない +RubyKaigiのNOCチームを長く担当されている花月かすみさんによる、DNSの暗号化の自動構成を行うためのプロトコルの紹介と、その検証のためにQUICライブラリのラッパーを実装した、という話です。 + +Domain Name System(DNS)は最も身近にはドメイン名からIPアドレスを得るための方法として用いられていますが、実際にはドメイン名にあらゆるデータを紐付けられるキーバリューストア、階層型分散データベースとしてインターネットに欠かせない存在となっています。しかしDNSは一般に使われている方式(UDPポート53でクエリを行う、通称「Do53」)では暗号化されておらず、カンファレンスのネットワークを含む公衆WiFiでは盗聴に対して脆弱であるということが知られています。カンファレンスにおいてはWiFiどころかそのへんを転がしているケーブルに対してMan-in-the-Middle攻撃することも容易です。そこで現代ではDNS over TLS(DoT), DNS over HTTPS(DoH; この中にはHTTP/2を使うものとHTTP/3を使うものがある), DNS over QUIC(DoQ)といった、クライアントとリゾルバ[^note-on-resolver]の間の通信を暗号化することで盗聴に対して保護する方式が提案されています。 + +[^note-on-resolver]: 正確にはRFC 9499 Section 6でいう"Recursive Resolver"のこと。「フルサービスリゾルバー」、「キャッシュDNSサーバー」と呼ばれることもある + +DNSの暗号化を行うにあたって、クライアントに対してこのサーバーはDNSクエリの暗号化に対応しています、という情報を伝えることで自動構成を行いたい、という要望があります。これを実現するためにAdaptive DNS Discovery(ADD)というワーキンググループがIETFで活動しており、標準として提案されたプロトコルとしてDiscovery of Designated Resolvers(DDR; RFC 9462)、DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR; RFC 9463)があります。前者はmacOSやiOS、後者は一部のWindowsで使われているそうです。RubyKaigi 2023以降ではDoT, DoH, DDRを提供しており、だいたい半分くらいのDNSクエリが暗号化されていたそうです。 + +DNSは動作するプロトコルの組み合わせが非常に多く、また「少し壊れててもそれっぽく動いちゃう」ので、検証プログラムを実装することにしたそうです。RubyでDNS over QUICを検証するにあたってRubyのQUIC実装がほとんどなかったことから、ngtcp2というCで書かれたQUIC実装にRubyバインディングを実装しました。この実装の工夫として、Ruby本体で進行中の並行処理の機能に影響されないようI/Oまですべてをngtcp2に任せるのではなくI/OはRubyで引き取るようにした、という点が挙げられていました。QUICは通常のTCPではカーネルが行う再送処理をアプリケーション側で巻き取ることで高速化を得ていますが、代わりにアプリケーションはその実装を頑張らなければいけないという性質があり、QUICの約束する効率化を実現するためには単にラッパーを書くだけでは足りず考えることが多い、ということを実感できました。 + +なかなかRubyの文脈でネットワークの裏側の話を聞くことがなかったのでとても新鮮でした。「動いて当たり前」と思われているネットワークの裏にこのような努力が埋まっているということを多くの人が感じていただければ、プロトコル実装仲間としてはとても嬉しいです。 (sylph01) From 068eeaffee0350315056b2d68a2b16e512fde633 Mon Sep 17 00:00:00 2001 From: Ryo Kajiwara Date: Thu, 13 Feb 2025 16:27:50 +0900 Subject: [PATCH 3/4] remove use of footnote notation --- .../0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md b/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md index f28ade24..cc3c9161 100644 --- a/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md +++ b/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md @@ -131,9 +131,9 @@ created_on: 2025-01-27 RubyKaigiのNOCチームを長く担当されている花月かすみさんによる、DNSの暗号化の自動構成を行うためのプロトコルの紹介と、その検証のためにQUICライブラリのラッパーを実装した、という話です。 -Domain Name System(DNS)は最も身近にはドメイン名からIPアドレスを得るための方法として用いられていますが、実際にはドメイン名にあらゆるデータを紐付けられるキーバリューストア、階層型分散データベースとしてインターネットに欠かせない存在となっています。しかしDNSは一般に使われている方式(UDPポート53でクエリを行う、通称「Do53」)では暗号化されておらず、カンファレンスのネットワークを含む公衆WiFiでは盗聴に対して脆弱であるということが知られています。カンファレンスにおいてはWiFiどころかそのへんを転がしているケーブルに対してMan-in-the-Middle攻撃することも容易です。そこで現代ではDNS over TLS(DoT), DNS over HTTPS(DoH; この中にはHTTP/2を使うものとHTTP/3を使うものがある), DNS over QUIC(DoQ)といった、クライアントとリゾルバ[^note-on-resolver]の間の通信を暗号化することで盗聴に対して保護する方式が提案されています。 +Domain Name System(DNS)は最も身近にはドメイン名からIPアドレスを得るための方法として用いられていますが、実際にはドメイン名にあらゆるデータを紐付けられるキーバリューストア、階層型分散データベースとしてインターネットに欠かせない存在となっています。しかしDNSは一般に使われている方式(UDPポート53でクエリを行う、通称「Do53」)では暗号化されておらず、カンファレンスのネットワークを含む公衆WiFiでは盗聴に対して脆弱であるということが知られています。カンファレンスにおいてはWiFiどころかそのへんを転がしているケーブルに対してMan-in-the-Middle攻撃することも容易です。そこで現代ではDNS over TLS(DoT), DNS over HTTPS(DoH; この中にはHTTP/2を使うものとHTTP/3を使うものがある), DNS over QUIC(DoQ)といった、クライアントとリゾルバ(※)の間の通信を暗号化することで盗聴に対して保護する方式が提案されています。 -[^note-on-resolver]: 正確にはRFC 9499 Section 6でいう"Recursive Resolver"のこと。「フルサービスリゾルバー」、「キャッシュDNSサーバー」と呼ばれることもある +(※: 正確にはRFC 9499 Section 6でいう"Recursive Resolver"のこと。「フルサービスリゾルバー」、「キャッシュDNSサーバー」と呼ばれることもある) DNSの暗号化を行うにあたって、クライアントに対してこのサーバーはDNSクエリの暗号化に対応しています、という情報を伝えることで自動構成を行いたい、という要望があります。これを実現するためにAdaptive DNS Discovery(ADD)というワーキンググループがIETFで活動しており、標準として提案されたプロトコルとしてDiscovery of Designated Resolvers(DDR; RFC 9462)、DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR; RFC 9463)があります。前者はmacOSやiOS、後者は一部のWindowsで使われているそうです。RubyKaigi 2023以降ではDoT, DoH, DDRを提供しており、だいたい半分くらいのDNSクエリが暗号化されていたそうです。 From 8230109701dd27df0f2796b228e54bca167d0767 Mon Sep 17 00:00:00 2001 From: Ryo Kajiwara Date: Thu, 13 Feb 2025 16:29:22 +0900 Subject: [PATCH 4/4] note on tcp fallback --- articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md b/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md index cc3c9161..5b44a316 100644 --- a/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md +++ b/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md @@ -131,7 +131,7 @@ created_on: 2025-01-27 RubyKaigiのNOCチームを長く担当されている花月かすみさんによる、DNSの暗号化の自動構成を行うためのプロトコルの紹介と、その検証のためにQUICライブラリのラッパーを実装した、という話です。 -Domain Name System(DNS)は最も身近にはドメイン名からIPアドレスを得るための方法として用いられていますが、実際にはドメイン名にあらゆるデータを紐付けられるキーバリューストア、階層型分散データベースとしてインターネットに欠かせない存在となっています。しかしDNSは一般に使われている方式(UDPポート53でクエリを行う、通称「Do53」)では暗号化されておらず、カンファレンスのネットワークを含む公衆WiFiでは盗聴に対して脆弱であるということが知られています。カンファレンスにおいてはWiFiどころかそのへんを転がしているケーブルに対してMan-in-the-Middle攻撃することも容易です。そこで現代ではDNS over TLS(DoT), DNS over HTTPS(DoH; この中にはHTTP/2を使うものとHTTP/3を使うものがある), DNS over QUIC(DoQ)といった、クライアントとリゾルバ(※)の間の通信を暗号化することで盗聴に対して保護する方式が提案されています。 +Domain Name System(DNS)は最も身近にはドメイン名からIPアドレスを得るための方法として用いられていますが、実際にはドメイン名にあらゆるデータを紐付けられるキーバリューストア、階層型分散データベースとしてインターネットに欠かせない存在となっています。しかしDNSは一般に使われている方式(UDPポート53(場合によってはTCPにフォールバック)でクエリを行う、通称「Do53」)では暗号化されておらず、カンファレンスのネットワークを含む公衆WiFiでは盗聴に対して脆弱であるということが知られています。カンファレンスにおいてはWiFiどころかそのへんを転がしているケーブルに対してMan-in-the-Middle攻撃することも容易です。そこで現代ではDNS over TLS(DoT), DNS over HTTPS(DoH; この中にはHTTP/2を使うものとHTTP/3を使うものがある), DNS over QUIC(DoQ)といった、クライアントとリゾルバ(※)の間の通信を暗号化することで盗聴に対して保護する方式が提案されています。 (※: 正確にはRFC 9499 Section 6でいう"Recursive Resolver"のこと。「フルサービスリゾルバー」、「キャッシュDNSサーバー」と呼ばれることもある)