本記事は DNS温泉 Advent Calendar 2019 第19日目の記事です。 もともと予定していた "DNSDNS Resolution X3 vs 2ndMIX (仮)" は明日の記事として投稿予定です。
また、IETF 106の非技術記事は公開を見送ります。
文中で触れている前回（IETF 105）の技術記事はこちらです。
これは何、背景
Application Behaviour Considering DNS(abcd) BoF*1は、前回開かれた Applications Doing DNS (ADD) BoFの続編にあたるBoFです。DNS over TLS, DNS over HTTPSのプロトコルを定めたはいいけれどそれの使われ方やデプロイメントに関する懸念事項や問題を議論する場所が必要である、ということで、前回はWorking Groupを形成することを目的としないオープンな議論の場、今回はWorking Groupの形成を目的とするBoF meetingが開かれました。
2014-2018にかけてDoHとDoTはそれぞれRFC 8484とRFC 7858として標準化が行われ、2018年以降は多くのクライアントがDoT・DoHを実装しました。このまとめとして、DoHのサーバー・クライアントの実装状況をまとめたcurlのGitHub wikiページがあります。
今回のBoFでは、Working Group形成のためのチャーターの議論に後半半分の時間が使われ、セッションとしてMozillaのCanary Domainの取り組みとdprive WG*2のドラフトであるAdaptive DNS Privacyの2つが紹介されました。
Canary Domain
DNS over HTTPSはペアレンタルコントロールなどのネットワーク管理者がそのネットワークのユーザーに課す制限を迂回してDNSの名前解決が行えてしまうことが問題とされ、イギリスのISPの団体からDoHを推進するMozillaが"Internet Villain"と名指しされる事態に発展しました。そこでMozillaはDNS-basedなペアレンタルコントロール（に限らずネットワークポリシー）が存在するかどうかを検知しそれが存在する場合にDoHを無効化する方法としてCanary Domainという仕組みを導入しました。
Canary Domainとは、実際にペアレンタルコントロールがフィルターするであろうドメインを引くことを試みてブロックされているかどうかを調べる代わりに、「DNS-basedなペアレンタルコントロールが導入されていれば必ずブロックされる」ドメインを定義し、そのドメインへのplatform DNS*3からの名前解決がブロックされるか加工されているかを以て該当のネットワーク内にペアレンタルコントロールが存在するかを調べます。
…この時点で嫌な予感しかしないというのはそのとおりで、このドメインをブロックするかどうかはエンドユーザーのネットワークよりも先のレベルでも制御できることなので、ある特定のISPでは全域的にcanaryがブロックあるいは加工されてDoHが無効化される、ということもありうるわけです。もちろんスライド中にはこの可能性についてテレメトリなどでモニターするとはしていますが、攻撃者が容易に悪用でき本当に想定されるDoHの脅威に対してDoHが使えなくなってしまう危険性があるといえます。
参加者の中にはそもそもDNSを用いてペアレンタルコントロールをするべきでない、間違った方法に誘導する仕組みである、という主張も見られました。
Adaptive DNS Privacy
現在のDNS over HTTPS/TLS vs DNS over Port53(Do53)のモデルは、DoHに移行することでローカルネットワークのリゾルバーを無視してパブリックなリゾルバーを全面的に利用するモデルを取ります。このモデルを取るにあたって、下記のような問題が浮上してきます:
- クライアントはどのようにして暗号化に対応したDNSリゾルバーを見つけるのか？
- ネットワークはどのようにしてローカルポリシーを告知できるのか？
- クライアントはどのようにして適切なリゾルバーを選択できるのか？
Adaptive DNS Privacyという提案はローカルのDNSリゾルバーの機能を一部借りながらパブリックDNSの機能も利用する、ということでこれらの問題に答えようとします。
まず最初のDoH対応のDNSリゾルバーの発見について、この提案ではService Binding records(SVCB/HTTPSSVC)というDNSレコードを使って特定の名前のオーナーはこのDoHサーバーを使ってほしいと告知し、ローカルのDNSリゾルバーを使って告知された情報を取得する、としています。
ローカルのDNSリゾルバーを併用するモデルを取ることで、ネットワークのローカルポリシーの告知もローカルのDNSリゾルバーが行うことができます。これは特定ネットワークにおけるフィルタリングポリシーの告知の他に、ネットワーク固有の最適化オプションの提示にも使えるとされています*4。
最後に、外にも中にも使ってほしいリゾルバーがいる場合どうやってそれを判定するのか？ということについて、リゾルバーの役割ごとに順位付けされたクライアント側のリゾルバー判定アルゴリズムを用意する、としています。まずVPNのリゾルバーを優先し、指定のあるローカルリゾルバー、指定のあるパブリックなリゾルバー、Oblivious DoH*5、直接の名前解決の順に利用できるものを利用します。
charteringの議論
注目度の高いネタに対して45分枠を設定しただけあってだいぶ議論がヒートアップしていました。WGの形成にはほぼ合意はしているものの、このWGで行う項目について、IETFの通常の決定プロセスである"Rough Consensus (and Running Code)"とは異なり"Full Consensus"を求めたい、とchairのスライドにあったことについて、特にこれだけ注目度の高いWGで完全な合意が可能なのか、ということが論争になっていました。
また、out of scopeとされているものに"privacy and surveillance"（プライバシーと監視の問題）があり、DoH/DoTはそもそもそれらと闘うためのものではなかったのか、という声も上がりました。
明日の記事では"DNSDNS Resolution"に軽くしか書かなかったanti-DNSSECの側面について書きます。分量次第では遅れて土曜日にもつれこむかもしれませんがご了承ください
