Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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. DNSのトランスポート暗号化
    に関する調査2018
    @r_takashima
    1
    ENOG49 2018-FEB-23 @ 嵐渓荘

    View Slide

  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

    View Slide

  3. ENOGとは(おさらい)
    3

    View Slide

  4. 温泉回重要!
    前回の嵐渓荘(ENOG19,2013)
    4

    View Slide

  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

    View Slide

  6. 今回調査の経緯
    6

    View Slide

  7. 2017年9月に IETF doh WG ができた
    https://datatracker.ietf.org/wg/doh/about/
    7

    View Slide

  8. そう言えばGoogle Public DNS にも
    何か書いてあった
    https://developers.google.com/speed/public-dns/docs/dns-over-https
    8

    View Slide

  9. けど、これなんだっけ、
    調べてみるか、
    というところから迷走が始まった
    9

    View Slide

  10. おさらい)DNS のプライバシー問題
    ✓DNSSECは返答が
    「正しいサーバが正しい応答を返したものであるか」
    は検証できる
    ✓DNSSECはデータの暗号化を行わなず、 クエリ・応答の内容を
    中間ノードは盗みみる事ができる
    10

    View Slide

  11. おさらい)DNS のプライバシー問題 cont.
    ✓DNS QNAME minimization (RFC7816) の様に、クエリの内容
    を必要最低限にする提案はされている
    ✓DNS over TLS (RFC7858) や DNS over DTLS (RFC8094) の様
    にトランスポートにTLSを使う仕様は標準化されているが、イ
    マイチ使われていない(と、思う)
    参考:https://dnsprivacy.org/wiki/
    11

    View Slide

  12. さて、どうカバーされるのか
    12

    View Slide

  13. DNS Over HTTPS (doh)
    13

    View Slide

  14. DNS Queries over HTTPS
    ✓draft-ietf-doh-dns-over-https-03 が出たばかり
    14

    View Slide

  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

    View Slide

  16. dohのユースケース
    ◼ユースケース1
    ➢OSやアプリケーション等の DNS クライアントから doh が
    有効になっているキャッシュDNSサーバへの接続を明示的に
    設定する
    OS
    App
    キャッシュ
    DNSサーバ
    中間ネットワーク
    16

    View Slide

  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

    View Slide

  18. dohのユースケース
    ◼疑問点
    ➢クライアント〜キャッシュDNSサーバ間の通信に関しては
    言及されているが、キャッシュDNSサーバ〜権威DNSサーバ
    間の通信については?(プロトコル上は問題なく見える)
    OS
    App
    キャッシュ
    DNSサーバ
    中間ネットワーク
    インターネット
    NS of ”.”
    NS of ”jp.”
    NS of ”example.jp.”
    ココは?



    18

    View Slide

  19. dohのプロトコル要求
    ◼割と骨子はザックリ
    ✓HTTPのContent Negotiation を使う
    ✓HTTP/2のみサポート
    ◼スコープ外
    ✓DNS64
    ✓HTTP(not HTTPS)
    ✓HTTP/1.0, 1.1
    19

    View Slide

  20. dohの HTTP request
    ✓media-type は “application/dns-udpwireformat”
    ➢中身はRFC1035の on-the-wire format そのまま
    ✓GET と POST をサポート
    ➢GETは cache friendly だが後述する encode の関係でサイズ
    がでかい
    20

    View Slide

  21. dohの HTTP request
    ✓GET では path 内の “dns=“ 以下にクエリが書かれる (*)
    ➢“dns=“ 以下は base64url で encode
    ✓POST では body にクエリが書かれる
    ➢body は encode されない
    (*)02 時は “body=“だった
    21

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  26. ➢同じ人が書いてるI-Dはこちら
    ✓draft-hoffman-dns-in-json-13
    ✓draft-hoffman-simplednsjson-01
    (これは 00 でポイされた)
    dohの HTTP response
    26

    View Slide

  27. dohの HTTP response
    ✓DNSとHTTPのCache話
    ➢ひとつのAnswer Sectionには複数のRRsetsが入れられる
    ➢それぞれのRRは個別のTTLが入れられる
    ➢でも、HTTP response freshness lifetime はセッションで1つ
    なので、DNS RR の一番短い値をいれてあげる必要がある
    27

    View Slide

  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

    View Slide

  29. dohの cache
    ✓DNSとHTTP双方のcacheの仕組みを考慮する必要がある
    ➢クライアント側では DNS response に含まれるTTL から、
    RFC7234 の Age response header を用いた経過時間を差し引
    いて実際のTTLを検証する
    ➢いろいろ、書いてあるが具体例に乏しいので省略。
    要するに HTTP 側での Cache-Control max-age や
    revalidation ( Last-Modified: みて何かするとか) との関係がや
    やこしい。
    29

    View Slide

  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

    View Slide

  31. doh 途中のまとめ
    ✓HTTPSだと通信が大概できるので DNS over HTTPS
    ✓今のところフォーカスはクライアント〜キャッシュDNSサーバ間
    ✓DNS と HTTP caching の相互作用についてはまだ十分に考慮が
    進んでいない
    ✓クライアントが doh ready なキャッシュDNSサーバをどう見つけ
    てどう繋ぐかもまだ決めが足りない
    31

    View Slide

  32. Google Public DNS の
    DNS over HTTPS
    32

    View Slide

  33. https://developers.google.com/speed/pu
    blic-dns/docs/dns-over-https
    33

    View Slide

  34. 遊び方
    ✓https://dns.google.com/resolveで API を叩く
    ✓https://dns.google.com/query でブラウザから叩く
    34

    View Slide

  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

    View Slide

  36. ブラウザアクセスの例
    36

    View Slide

  37. ん?jsonで返ってくるけど、
    ietf-doh だと
    まだ未定義じゃなかったっけ?
    37

    View Slide

  38. そう、Google Public DNS の
    DNS-over-HTTPS と
    ietf-doh は別のもの!
    38

    View Slide

  39. 途中でようやく気付いたぜ
    orz
    39

    View Slide

  40. DNS over TLS
    RFC7858
    40

    View Slide

  41. ✓TCP port 853 をTLSセッションに利用
    ✓クライアント〜キャッシュDNSサーバ間での利用を想定
    DNS over TLS概要
    41

    View Slide

  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

    View Slide

  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/

    View Slide

  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

    View Slide

  45. ✓そういうの考えてる人もいるらしい。
    ✓https://getdnsapi.net/
    おまけ) getdns
    45

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  49. DNS over DTLS
    RFC8094
    49

    View Slide

  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

    View Slide

  51. DNS over dedicated QUIC connections
    draft-huitema-quic-dnsquic
    51

    View Slide

  52. ✓DNS over TLS の QUIC 版
    ✓実験用にはUDP port 784を使うが、正式に IANA から assign さ
    れたわけではない
    ✓スコープはやっぱり、クライアント〜キャッシュDNSサーバ間
    DNS over QUIC
    52

    View Slide

  53. ✓PMTUD問題はQUICのレイヤで克服してくれるので DNSoDTLS
    よりよさそう
    ✓大きい response も複数ストリームを用いて返せる
    ✓セッション再利用の問題はQUICにもあるが、QUICはconnection
    上で複数のstreamを扱えるので、stream単位でDNSクエリの管理
    をする事により、connectionをいちいち切ったりしない実装が可

    DNS over QUIC
    53

    View Slide

  54. まとめ
    54

    View Slide

  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

    View Slide


  56. 56

    View Slide