「HTTPSリソースレコード」を使うと何がうれしいのか？ その効果への期待と現実を解説【Internet Week 2021】

　昨年に引き続き完全オンラインで行われた「Internet Week 2021」において11月19日、DNSに関する話題を集めたプログラム「DNS DAY」が開催された。本稿では、その盛り沢山の話題の中から、恒例となっているセッション「DNS Update」のほか、運用への影響の大きさから注目を集めているHTTPSレコードの話題を中心に取り上げる。

「HTTPSリソースレコード」に対する期待と現実

　アカマイ・テクノロジーズ合同会社の松本陽一氏による「HTTPSリソースレコードへの期待」は、CDNあるいは大規模配信を行う立場から見た話というかたちで、その効果や期待に関する話題を、会社から離れ、個人として解説するというものであった（以降、「リソースレコード」は「RR」と表記する）。

　HTTPS RRは、SVCB（Service Bindingに由来）RRのバリエーションとして、HTTPSおよびHTTPスキームに特化したかたちで定義される新しいDNSのリソースレコードである。本稿執筆時点ではIESGにおける最終レビュー中ということで正式なRFCとなってはいないが、前出のNTTコミュニケーションズ小坂氏の報告にもあるように、クエリ全体に占める割合が1割を超えるほど使われ始めている（図17）。

　その詳細については公開される資料を見ていただくとして、HTTPS RRを使うと何がうれしいのか、その効果が松本氏の言葉として示された（図18）。

　CNAME RRでは不可能であった、ゾーン頂点に別名を書けるようになるというのは、HTTPS RRを定義する際の大きな動機であっただろうし、アクセスの分散やフォールバックも重要なポイントであったはずだ。そうしたことを考えると、図18に書かれていることは「HTTPS RRでやりたかったこと」の一覧とも言えるだろう。

　基本的な考え方は、CDNサービスを利用・提供する際などに必要なさまざまな情報をDNSのRRとして設定できるようにし、クライアントであるウェブブラウザーがウェブサーバーに接続する際にHTTPS RRを検索することで、HTTPS接続に必要な情報を事前に得られるようにするというものである。対応しているHTTPのバージョンであるとか、ECH（Encrypted Client Hello）の公開鍵といった情報は、HTTPSで接続する際にウェブブラウザーが事前に知っておいた方が有利な情報である。HTTPS RRはまさに、その課題を解決するために開発されたプロトコルなのである。

　図19は、CNAME RRが持つ課題を整理したものである。そして、図20は、それらの課題をHTTPS RRが解決できるかについて考察したものである。

　松本氏はこの点について、「CNAMEの代替としてのHTTPS RRは、すぐに使えるようにはならないのではないか」とし、その理由として図20にある、ウェブブラウザーや専用アプリなどのクライアント側がHTTPS RRに対応しない限り新しい設定は参照されず、その状態で従来のA/AAAA RRを削除した場合、HTTPS RRに未対応のクライアントはウェブサービスを利用できなくなってしまうという点を挙げた。

　「残りの5％が未対応であったとき、その5％には（ウェブサイトが）見えないとなってはいけない」（松本氏）というのは、サービスを提供する側からすると悩ましい点であろう。極端に言ってしまうと、HTTPS RRに対応せず、これまで通りA/AAAA RRのみを使っていても問題は起きないと考え、対応を保留する可能性もあり得るからである。HTTPSに未対応のクライアントが多ければ、HTTPS RRには大きく舵を切りにくい。

　そのため松本氏は、「CNAMEの代替ではなく、他の目的でHTTPS RRを使うのが先になるかもしれない」とし、その例としてDNSによるグローバル負荷分散（Global Server Load Balancing：GSLB）での利用を挙げた（図21、図22、図23）。

　大規模配信では多数のサーバーを広域に分散配置し、適切なサーバーにクライアントのアクセスを誘導することが重要である（図21）。事業者によってはIP Anycastを使ったりもするようだが、アカマイではDNSで頑張っているとのことである。

　ただ、DNSによるGSLBでは、同じフルサービスリゾルバーを極めて多数のユーザーが使用している場合に細やかなコントロールができず、負荷分散が十分に動作しない場合がある。フルサービスリゾルバー側で複数のA/AAAA RRを応答する手段も考えられるが、その応答を有効に使ってくれるかどうかは受け取ったクライアント次第であり、かつ応答を変更してもTTLが満了するまでは反映されないという課題も存在するということである（図22）。

　そうした課題に対し、HTTPS RRを利用したロードバランスが有効であるということである（図23）。詳細はここでは述べないが、HTTPS RRを用いることで複数のアクセス先を指定でき、アクセス先ごとの優先度も指定できる。そのため「HTTPS RRをGSLBと組み合わせると、さらに柔軟な設定ができる」（松本氏）とのことである。

　では、HTTPS RRの普及の鍵を握るクライアント側の対応状況はどうであろうか。それを調査・整理したものが、図24である。主だったところで、iOS、macOS、Firefox、Chromeが挙げられているが、具体的な情報が公式に出されているわけではなく、推定と書いてあるように不確定な面もあるため、参考情報として見ておくのがいいだろう。いずれにしても、現時点ではきちんと実装されているわけではなさそうである。

　松本氏によるまとめは、HTTPS RRが持つ大きな可能性に期待しつつも、今後の普及はウェブブラウザーをはじめとするクライアント側の対応状況に大きく依存すること、DNSとHTTPのセキュリティやプライバシーの議論の1ピースとして、HTTPS RRの動向には今後も注目していくべき、というものであった（図25）。

　会場からは、CNAMEを置き換えることになるのかとか、多段参照の問題は起きるのかといった質問が投げ掛けられた。その回答としては、完全に置き換えることを期待していると思うが、どれくらい時間がかかるか分からない、CNAMEと同様、多段参照はありえるので、インターネットドラフト（I-D）には参照数に制限を設定しなければならない旨が書かれているということであった。個人的には、クライアント側が早急にHTTPS RRに対応していくことの重要性を感じている。

定着したオンライン開催だが、リアル会合にも期待をしたい

　DNS DAYは、DNSに関する定点観測情報を得る場としても、新しい話題を共有し議論する場としても有効である。今回も、内容的にとても興味深い話が多く、かつ、とても濃かったという印象を筆者は持っている。

　完全なオンライン形式は昨年に引き続き2度目となるが、登録料を払って登録すればほぼ全てのセッションを見ることができる。リアル会合の場合は、そのまま別の場に移って議論を続けたり、飲みに行って本音を聞いたりということもしやすいので捨てがたいが、回を重ねるに連れ、このようなオンライン開催も良いなと思い始めた。今後は、オンライン開催とリアル会合の両面からいいとこ取りができるような、ハイブリッド開催ができるようになってほしい。

　毎回感じることではあるが、さまざまな情報をその場その場で集めるためには大きな労力と理解のための知識が必要となる。Internet Weekのようなイベントは、情報を得るタイミングそのものは開催のタイミングで限定されてしまうが、識者による整理が行われた情報を得られることのメリットがとても大きい。読者の皆さまも、このようなイベントにはぜひ参加してほしい。