20180223 DNSのトランスポート暗号化に関する調査2018

2018/02/23 ENOG49

2018年当時に DNS over HTTP/HTTPS/QUIC について調査した資料。
最新の情報とは異なる事にご注意ください。

Transcript

1. DNSのトランスポート暗号化 に関する調査2018 @r_takashima 1 ENOG49 2018-FEB-23 @ 嵐渓荘
2. 私とENOGとちょっとNISOC • ENOG4/OSC新潟2010 • ISP の中の運用とオープンソース【実践編】 (NetFlow,sFlow) • NISOC 2011/2 • 初めてのDNSSEC • ENOG19 • IETF TRILL 最新 update • ENOG27 • Network 装置の White box 化について • ENOG28 • OpenStack Juno で何が入るかみてみよう • ENOG34 • 君のキャッシュDNSサーバが出すクエリを君は本当に理解しているか？ あ、でもそのうちそうなっちゃうかも? QNAME minimisation の話 ♨️ ♨️ 2
3. ENOGとは(おさらい) 3
4. 温泉回重要！ 前回の嵐渓荘（ENOG19,2013) 4
5. 本日のお題 • 今回調査の経緯 • DNS Queries over HTTPS (ietf-doh) • Google Public DNS の DNS over HTTPS • DNS over TLS (RFC7858) • DNS over DTLS (RFC8094) • DNS over dedicated QUIC connections • まとめ 5
6. 今回調査の経緯 6
7. 2017年9月に IETF doh WG ができた https://datatracker.ietf.org/wg/doh/about/ 7
8. そう言えばGoogle Public DNS にも 何か書いてあった https://developers.google.com/speed/public-dns/docs/dns-over-https 8
9. けど、これなんだっけ、 調べてみるか、 というところから迷走が始まった 9
10. おさらい)DNS のプライバシー問題 ✓DNSSECは返答が 「正しいサーバが正しい応答を返したものであるか」 は検証できる ✓DNSSECはデータの暗号化を行わなず、 クエリ・応答の内容を 中間ノードは盗みみる事ができる 10
11. おさらい)DNS のプライバシー問題 cont. ✓DNS QNAME minimization (RFC7816) の様に、クエリの内容 を必要最低限にする提案はされている ✓DNS over TLS (RFC7858) や DNS over DTLS (RFC8094) の様 にトランスポートにTLSを使う仕様は標準化されているが、イ マイチ使われていない(と、思う) 参考：https://dnsprivacy.org/wiki/ 11
12. さて、どうカバーされるのか 12
13. DNS Over HTTPS (doh) 13
14. DNS Queries over HTTPS ✓draft-ietf-doh-dns-over-https-03 が出たばかり 14
15. dohの狙い ✓End-to-end の通信を暗号化する事により、DNS通信における プライバシー問題を解決すること ➢DNSの通信はしばしば end-to-end の接続性に問題が生じる が、HTTPS なら大概通る ➢ここらへんの記述に後述のDNSoTLSとか使われ辛いんだろ うなぁという悩みを感じる DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. 15
16. dohのユースケース ◼ユースケース1 ➢OSやアプリケーション等の DNS クライアントから doh が 有効になっているキャッシュDNSサーバへの接続を明示的に 設定する OS App キャッシュ DNSサーバ 中間ネットワーク 16
17. dohのユースケース ◼ユースケース2 ➢Web App にCORSを使ってDNS情報を参照させる。ブラウ ザ側はdohを利用しようとするWeb App以外にはその参照結 果は流用しない。 オリジン間リソース共有 (Cross-Origin Resource Sharing, CORS) は、追加 の HTTP ヘッダを使用して、ユーザーエージェントが現在のサイトとは別の オリジン（ドメイン）のサーバーから選択されたリソースにアクセスする権限 を得られるようにする仕組みです。ユーザーエージェントは、現在の文書のオ リジンとは異なるドメイン、プロトコル、ポート番号からリソースをリクエス トするとき、オリジン間 HTTP リクエストを発行します。 https://developer.mozilla.org/ja/docs/Web/HTTP/HTTP_access_control CORS 17
18. dohのユースケース ◼疑問点 ➢クライアント〜キャッシュDNSサーバ間の通信に関しては 言及されているが、キャッシュDNSサーバ〜権威DNSサーバ 間の通信については？（プロトコル上は問題なく見える） OS App キャッシュ DNSサーバ 中間ネットワーク インターネット NS of ”.” NS of ”jp.” NS of ”example.jp.” ココは? ？ ？ ？ 18
19. dohのプロトコル要求 ◼割と骨子はザックリ ✓HTTPのContent Negotiation を使う ✓HTTP/2のみサポート ◼スコープ外 ✓DNS64 ✓HTTP(not HTTPS) ✓HTTP/1.0, 1.1 19
20. dohの HTTP request ✓media-type は “application/dns-udpwireformat” ➢中身はRFC1035の on-the-wire format そのまま ✓GET と POST をサポート ➢GETは cache friendly だが後述する encode の関係でサイズ がでかい 20
21. dohの HTTP request ✓GET では path 内の “dns=“ 以下にクエリが書かれる (*) ➢“dns=“ 以下は base64url で encode ✓POST では body にクエリが書かれる ➢body は encode されない (*)02 時は “body=“だった 21
22. dohの HTTP request ✓GETの sample ( I-D 03 より抜粋 ) :method = GET :scheme = https :authority = dnsserver.example.net :path = /dns-query?ct& (no space or CR) dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB accept = application/dns-udpwireformat, application/simpledns+json 22
23. dohの HTTP request ✓POSTの sample ( I-D 03 より抜粋 ) :method = POST :scheme = https :authority = dnsserver.example.net :path = /dns-query accept = application/dns-udpwireformat,application/simpledns+json content-type = application/dns-udpwireformat content-length = 33 <33 bytes represented by the following hex encoding> 00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 23
24. dohの HTTP request ✓投げ先のURI ➢02まではこう書いてありましたが ➢03でこうなりました Configuration and discovery of the URI is done out of band from this protocol. A client can be configured with a DNS API URI, or it can discover the URI. This document defines a well-known URI path of "/.well-known/ dns-query" so that a discovery process that produces a domain name or domain name and port can be used to construct the DNS API URI. 24
25. dohの HTTP response ➢DNS response は HTTP responseの body に入る (当然といえば当然) ➢“the response types are works in progress” ✓“application/dns-udpwireformat” が使えることは確定 ✓json based のもあったほうがいいよね、とはあるが、未定 ➢サンプルにある”application/simpledns+json” も規定されて いるわけではなくただの yet another media-type の例 25
26. ➢同じ人が書いてるI-Dはこちら ✓draft-hoffman-dns-in-json-13 ✓draft-hoffman-simplednsjson-01 (これは 00 でポイされた) dohの HTTP response 26
27. dohの HTTP response ✓DNSとHTTPのCache話 ➢ひとつのAnswer Sectionには複数のRRsetsが入れられる ➢それぞれのRRは個別のTTLが入れられる ➢でも、HTTP response freshness lifetime はセッションで1つ なので、DNS RR の一番短い値をいれてあげる必要がある 27
28. dohの HTTP response ✓POSTの sample ( I-D 03 より抜粋 ) ✓www.example.comのAが192.0.2.1でTTLが128の場合 :status = 200 content-type = application/dns-udpwireformat content-length = 64 cache-control = max-age=128 <64 bytes represented by the following hex encoding> 00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 00 00 00 80 00 04 C0 00 02 01 28
29. dohの cache ✓DNSとHTTP双方のcacheの仕組みを考慮する必要がある ➢クライアント側では DNS response に含まれるTTL から、 RFC7234 の Age response header を用いた経過時間を差し引 いて実際のTTLを検証する ➢いろいろ、書いてあるが具体例に乏しいので省略。 要するに HTTP 側での Cache-Control max-age や revalidation ( Last-Modified: みて何かするとか) との関係がや やこしい。 29
30. doh server の discovery ✓まだ出来てない。ここの認証も考えないと意味ない気がする。 [[ From the WG charter: The working group may define mechanisms for discovery of DOH servers similar to existing mechanisms for discovering other DNS servers if the chairs determine that there is both sufficient interest and working group consensus. ]] 30
31. doh 途中のまとめ ✓HTTPSだと通信が大概できるので DNS over HTTPS ✓今のところフォーカスはクライアント〜キャッシュDNSサーバ間 ✓DNS と HTTP caching の相互作用についてはまだ十分に考慮が 進んでいない ✓クライアントが doh ready なキャッシュDNSサーバをどう見つけ てどう繋ぐかもまだ決めが足りない 31
32. Google Public DNS の DNS over HTTPS 32
33. https://developers.google.com/speed/pu blic-dns/docs/dns-over-https 33
34. 遊び方 ✓https://dns.google.com/resolveで API を叩く ✓https://dns.google.com/query でブラウザから叩く 34
35. xavier:~$ curl -s 'https://dns.google.com/resolve?name=www.hanya-n.org&type=A' | jq { "Status": 0, "TC": false, "RD": true, "RA": true, "AD": false, "CD": false, "Question": [ { "name": "www.hanya-n.org.", "type": 1 } ], "Answer": [ { "name": "www.hanya-n.org.", "type": 5, "TTL": 21599, "data": "urquell.hanya-n.org." }, { "name": "urquell.hanya-n.org.", "type": 1, "TTL": 21599, "data": "49.212.140.172" } ], "Comment": "Response from 49.212.140.172." } API ア ク セ ス の 例 35
36. ブラウザアクセスの例 36
37. ん？jsonで返ってくるけど、 ietf-doh だと まだ未定義じゃなかったっけ？ 37
38. そう、Google Public DNS の DNS-over-HTTPS と ietf-doh は別のもの！ 38
39. 途中でようやく気付いたぜ orz 39
40. DNS over TLS RFC7858 40
41. ✓TCP port 853 をTLSセッションに利用 ✓クライアント〜キャッシュDNSサーバ間での利用を想定 DNS over TLS概要 41
42. ✓やっぱり、クライアント〜キャッシュDNSサーバ間 ✓明示的にキャッシュDNSサーバ〜権威DNSサーバ間は out of scope と記述 ✓DPRIVE の scope がそうであれば doh も同じか・・・ DNS over TLSのスコープ The protocol described here works for queries and responses between stub clients and recursive servers. It might work equally between recursive clients and authoritative servers, but this application of the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter. 42
43. おまけ) DNS PRIVE WG のチャーター 43 The primary focus of this Working Group is to develop mechanisms that provide confidentiality between DNS Clients and Iterative Resolvers, but it may also later consider mechanisms that provide confidentiality between Iterative Resolvers and Authoritative Servers, or provide end-to-end confidentiality of DNS transactions. ✓DPRIVE の scope がそうであれば doh も DNSoTLS も同じか、 という感じ https://datatracker.ietf.org/wg/dprive/about/
44. ✓いかにTLSセッションを確立する際のコストを減らすかだがコレ。 ✓張ったセッションのライフサイクル管理を含むレゾルバライブラリ の実装を考慮しなくちゃいけない、よね。。 TLS のセッション確立コスト問題 For DNS clients that use library functions such as "getaddrinfo()" and "gethostbyname()", current implementations are known to open and close TCP connections for each DNS query. 44
45. ✓そういうの考えてる人もいるらしい。 ✓https://getdnsapi.net/ おまけ) getdns 45
46. ✓DNSoTLS enabled なキャッシュDNSサーバをクライアントはど の様に選定するか ➢予め Out-of-bound で Privacy Profile を持っておくやり方と、 DHCP 等で緩く渡すやり方がある ➢認証単体でもいろいろと議論があるようなので興味がある人は • https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls- profiles/ DNS over TLS の認証 46
47. ✓TLS確立時間を含むレイテンシ ✓TLS/TCPのセッション管理 ✓TLSの暗号処理コスト ✓同時接続数(クライアントの数) 等、考慮事項はあるが だそうです。 DNS over TLS の性能問題 A full performance evaluation is outside the scope of this specification. A more detailed analysis of the performance implications of DNS over TLS (and DNS over TCP) is discussed in [TDNS] and [RFC7766]. 47
48. Quad9 ( https://www.quad9.net/ , 9.9.9.9 ) は DNSoTLS もサポートしてるらしいよ！ 遊び方 https://labs.ripe.net/Members/stephane_bortzmeyer/quad9-a-public-dns-resolver-with-security 48
49. DNS over DTLS RFC8094 49
50. ✓TLSはTCP、DTLSはUDP ✓UDP port 853 を利用 ✓PMTUD問題がつきまとう ✓まじかー。。。 DNS over DTLS DNS over DTLS alone cannot provide privacy for DNS messages in all circumstances, specifically when the DTLS record size is larger than the path MTU. In such situations, the DNS server will respond with a truncated response (see Section 5). 50
51. DNS over dedicated QUIC connections draft-huitema-quic-dnsquic 51
52. ✓DNS over TLS の QUIC 版 ✓実験用にはUDP port 784を使うが、正式に IANA から assign さ れたわけではない ✓スコープはやっぱり、クライアント〜キャッシュDNSサーバ間 DNS over QUIC 52
53. ✓PMTUD問題はQUICのレイヤで克服してくれるので DNSoDTLS よりよさそう ✓大きい response も複数ストリームを用いて返せる ✓セッション再利用の問題はQUICにもあるが、QUICはconnection 上で複数のstreamを扱えるので、stream単位でDNSクエリの管理 をする事により、connectionをいちいち切ったりしない実装が可 能 DNS over QUIC 53
54. まとめ 54
55. IETF DPRIVE WG の範疇 クライアント 〜キャッシュDNSサーバ間がスコープ DNSoTLS （RFC7858） ✓ TCP853 ✓ TLSで保護 ✓ セッション利用の効率 化等の考慮が必要 ✓ proposed standard DNSoDTLS （RFC8094） ✓ UDP853 ✓ PMTUD、fragment の 問題がある ✓ experimental IETF DNSoHTTPS ✓ HTTPSだから通りやす い ✓ WG draft IETF DNSoQUIC ✓ QUICだから通りやすい ✓ connection/streamの階 層がDNSに良さげ ✓ Individual draft Google Public DNS DNS-over-HTTPS ✓ 名前は同じだが、IETF I-Dのと関係なし ✓ jsonで返答 UDP版 HTTPS版 QUIC版 無関係！ ❌ 55
56. 完 56