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

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

「HTTPSリソースレコード」がクエリの11％を占める

　DNS Update最初の報告は、WIDEプロジェクトの関谷勇司氏による「Root DNS Servers」である。大きな障害も攻撃も無く順調に運用できていること、昨年に比べ、Mルートサーバーの拠点数が増えたことなどが報告された（図1）。

図1：拠点増えました！

　続いて、株式会社日本レジストリサービス（JPRS）の池田和樹氏による「JP DNS Update」では、JP DNSに関する報告が行われた。JPドメイン名の登録数は増加傾向が続いており、JP DNSへのクエリ数も増加している（図2、図3）。2021年7月から9月にかけて開催された東京2020オリンピック・パラリンピック競技大会に向けた活動も報告され、攻撃とみられる通信は発生せず、大きな障害もなくパラリンピック閉会式を迎えることができたということである（図4、図5）。

図2：JPドメイン名登録数の推移

図3：JP DNSへのクエリ数の推移

図4：東京2020 オリンピック・パラリンピック競技大会に向けた活動

図5：東京2020 オリンピック・パラリンピック競技大会に向けた活動－結果

　一般社団法人日本ネットワークインフォメーションセンター（JPNIC）の小山祐司氏による逆引きDNSの報告からは、前回のInternet Week 2020でも話題となった[*1]、「.arpa」のルートサーバーからの分離に関する提案のその後を取り上げる（図6、図7）。この提案は、ルートゾーンやルートサーバーの運用に影響するとして、.arpaゾーンに関するさまざまな提案が却下されてしまう問題に対処するため、.arpaゾーンの運用をルートサーバーから分離しようというものである。その後、提案はIETFの活動方針を監督するIABによりまとめられ、2021年10月にRFC 9120[*2]として発行されている。

図6：.arpaゾーンのrootサーバーからの分離

図7：Informational RFCが発行

　NTTコミュニケーションズ株式会社の小坂良太氏による「DNS Update～フルサービスリゾルバ～」では、OCNのフルサービスリゾルバー（キャッシュDNSサーバー）に到達するクエリを分析した結果が報告された。クエリ（DNS問い合わせ）数は以前から増加傾向にあったが、最近では1日あたり1兆を超えるクエリがあり、2007年と比べると23倍、2019年から急増して2年で2倍以上に増加したそうである（図8）。

図8：ユーザーからのクエリ数

　注目すべき内容として、クエリに占めるHTTPSレコードの割合が大きくなっていることが挙げられる（図9）。A/AAAAレコードの割合が依然として多い（合計で86％）が、昨年から本格的に使われ始めたHTTPSレコードの割合がすでに11％もあるというのは驚きである。その他のレコードの中では、TXTレコードとSRVレコードの割合が比較的多いとのことであった。

図9：ユーザークエリにおけるクエリタイプの割合

　IPv6のトラフィックに関しては、平日のピーク時を見ると70％を大きく超えるようになった。ただし、ピーク時ではなく、1日全体を通して見ると60％（IPoEとPPPoE（IPv6）の合計）程度になるということである（図10）。IPv6の利用率が上がっていることが確認できるグラフである。

図10：OCN DNSのIPv4/IPv6のトラフィック割合

　JPRSの高松百合氏による「DNS Update～ドメイン名全般～」では、gTLDを含むドメイン名全般に関する話題が報告された。注目すべきは、TLD全体で見ると、ドメイン名の登録数がわずかに減っていることであろう（図11）。2020年6月に比して、2021年6月では280万ほどその数が減っている。これについて高松氏は、「従来からのgTLDは増えているが、ccTLDと新gTLDが減っている」とし、ccTLDでは「.tk」（トケラウ）と「.cn」（中国）、新gTLDでは「.icu」の登録数が大きく減ったのが主な原因ではないかとした（図12、図13、図14）。

図11：全TLDでのドメイン名数

図12：登録数の多いTLD

図13：登録数の多いTLD（2）

図14：「.icu」の登録状況

　.icuの登録数が大きく減った理由として、その大半が中国のレジストラ経由であり、中国における投機的なドメイン名登録が減ったことや、登録費用が安い（無料～100円程度）ことで登録されたドメイン名が、更新料が高い（1000円以上）ため更新されなかったことが考えられるということである。発表では、.icuの登録数が減少した結果、登録数の多いTLDの上位10位から新gTLDが消えてしまったことが示された。

　ICANNによるgTLDの次回募集に向けた動きについては、募集手続きに関する運用設計フェーズ（Operational Design Phase：ODP）開始に向け、課題の検討を進めている段階である旨が発表された（図15、図16）。今後の動きに興味のある方は、JPNICの「ICANN報告会」に参加するといいだろう。

図15：次回のgTLD募集に向けた動き（ODP）

図16：次回のgTLD募集に向けた動き（スケジュール）

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

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

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

図17：HTTPS リソースレコードの概要

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

図18：HTTPS RRのもたらすもの（効果）

　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が解決できるかについて考察したものである。

図19：CNAMEの課題

図20：HTTPS RRはCNAMEの課題を解決できるのか

　松本氏はこの点について、「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：DNSによるグローバル負荷分散（GSLB）

図22：DNS GSLBの課題

図23：HTTPS RR（ServiceMode）によるロードバランス

　大規模配信では多数のサーバーを広域に分散配置し、適切なサーバーにクライアントのアクセスを誘導することが重要である（図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が挙げられているが、具体的な情報が公式に出されているわけではなく、推定と書いてあるように不確定な面もあるため、参考情報として見ておくのがいいだろう。いずれにしても、現時点ではきちんと実装されているわけではなさそうである。

図24：クライアントのHTTPS RRサポート状況（11月上旬現在の推定）

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

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

図25：まとめ

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

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

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

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