Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

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

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

2018/02/23 ENOG49

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

Ryuichi Takashima

May 25, 2022
Tweet

More Decks by Ryuichi Takashima

Other Decks in Technology

Transcript

  1. 私と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
  2. 本日のお題 • 今回調査の経緯 • 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
  3. おさらい)DNS のプライバシー問題 cont. ✓DNS QNAME minimization (RFC7816) の様に、クエリの内容 を必要最低限にする提案はされている ✓DNS

    over TLS (RFC7858) や DNS over DTLS (RFC8094) の様 にトランスポートにTLSを使う仕様は標準化されているが、イ マイチ使われていない(と、思う) 参考:https://dnsprivacy.org/wiki/ 11
  4. 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
  5. dohの HTTP request ✓media-type は “application/dns-udpwireformat” ➢中身はRFC1035の on-the-wire format そのまま

    ✓GET と POST をサポート ➢GETは cache friendly だが後述する encode の関係でサイズ がでかい 20
  6. dohの HTTP request ✓GET では path 内の “dns=“ 以下にクエリが書かれる (*)

    ➢“dns=“ 以下は base64url で encode ✓POST では body にクエリが書かれる ➢body は encode されない (*)02 時は “body=“だった 21
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. dohの cache ✓DNSとHTTP双方のcacheの仕組みを考慮する必要がある ➢クライアント側では DNS response に含まれるTTL から、 RFC7234 の

    Age response header を用いた経過時間を差し引 いて実際のTTLを検証する ➢いろいろ、書いてあるが具体例に乏しいので省略。 要するに HTTP 側での Cache-Control max-age や revalidation ( Last-Modified: みて何かするとか) との関係がや やこしい。 29
  13. 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
  14. doh 途中のまとめ ✓HTTPSだと通信が大概できるので DNS over HTTPS ✓今のところフォーカスはクライアント〜キャッシュDNSサーバ間 ✓DNS と HTTP

    caching の相互作用についてはまだ十分に考慮が 進んでいない ✓クライアントが doh ready なキャッシュDNSサーバをどう見つけ てどう繋ぐかもまだ決めが足りない 31
  15. 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
  16. ✓やっぱり、クライアント〜キャッシュ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
  17. おまけ) 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/
  18. ✓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
  19. ✓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
  20. 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
  21. ✓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
  22. ✓DNS over TLS の QUIC 版 ✓実験用にはUDP port 784を使うが、正式に IANA

    から assign さ れたわけではない ✓スコープはやっぱり、クライアント〜キャッシュDNSサーバ間 DNS over QUIC 52
  23. 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