「ChromeはHTTPS RRをまともに実装できているとは言い難い」各ブラウザーの対応状況を調べた結果が報告される

　日本DNSオペレーターズグループ（DNSOPS.JP）の主催によるカンファレンス「DNS Summer Day 2024」が6月21日に開催された。今回は、その発表の中から、HTTPSリソースレコード（以降、「リソースレコード」は「RR」と表記する）とDNSのゾーン管理に関する話題を中心に取り上げる。

各ウェブブラウザーのHTTPS RRへの対応は不十分である

　HTTPS RRは、SVCB（Service Bindingに由来）RRのバリエーションとして、HTTPSおよびHTTPスキームに特化したかたちで定義されるDNSのRRである。2023年11月にIETFでの特別対応[*1]を受けて、RFC 9460[*2]として発行された。

　HTTPS RRがウェブ関係者の注目を集めるのは、HTTPSサービスの利用・提供に関するさまざまな要求を一度に実現できるからであろう。CNAME RRでは不可能であったゾーン頂点に別名が付けられるようになること、ウェブサーバーに優先度を設定できること、HTTPS接続情報や対応しているHTTPのバージョンといった情報を事前にクライアントに提供できることなど、採用のメリットが数多く存在する。

　ただし、そのようなメリットを実際に手にするためには、ウェブブラウザーや専用アプリなどのクライアント側がHTTPS RRに対応する必要がある。DNSのクエリ全体に占めるHTTPS RRの割合は年々大きくなってきているが、ウェブブラウザーの対応状況はどうなのだろうか。

　株式会社インターネットイニシアティブ（IIJ）の山口崇徳氏による発表「HTTPS RRの現状と今後」は、HTTPS RRの現状と、HTTPS RRで発明されたサービスパラメータという概念をDNSにも取り入れようとする動きについて解説したものである。その中で、ウェブブラウザーのHTTPS RRへの対応状況を調べた結果が提示されていることから、まずはその話題から始めたいと思う。

　分かりやすさを優先して結論を先に述べてしまうと、現状ではウェブブラウザー側の対応状況に大きな差があること、特に「ChromeはHTTPS RRをまともに実装できているとは言い難い」という点がポイントであろう（図1）。筆者にはとても興味深かったので、以降、発表内容を順に追っていくことにする。

図1　Best Current Practice

　今回、調査対象としたのは、Chrome 125（Windows 11）、Safari 17.4（macOS Sonoma）、Firefox 126（Windows 11）の3つ。いずれもデスクトップ版で、まずは、それらがHTTPS RRのクエリを出しているかを調べるところから始めたということである（図2、図3）。

図2　HTTPS RRのクエリを出しているか（1）

図3　HTTPS RRのクエリを出しているか（2）

　図2にあるように、Safariは、2020年ごろからデフォルトで有効になっている。Chromeは、Chromeの内蔵リゾルバ（AsyncDNS）でHTTPS RRに対応するかたちになっており、Mac/Androidはかなり以前からAsyncDNSに切り替え済みということである。

　ただし、Windowsのケースでは問題がある。以前の記事[*3]で取り上げたとおり、2022年11月ごろから条件によってTCPによるクエリ（以降、「TCPクエリ」と略す）が出されるようになり、TCPクエリを扱えないホームルーターを使っていた場合に名前解決できないという状況が発生した。

　この問題は、ホームルーターを“TCPクエリを扱える機種”に交換すれば解決するが、現在までWindows側またはChrome側で何かしらの対応があったという話は聞いていない。山口氏によれば、「TCPクエリが増加している問題は全く解消していない」「Chrome起動直後の一発目でTCPクエリが出たりしているので、TCPになる条件が実は増えているような気がする」ということであった。つまり、以前より悪くなっている可能性がある。

　もし、WindowsとChromeの組み合わせを使っており、インターネットにはつながっているように見えるのにウェブサイトにつながらないという症状が出たら、この問題を疑ってみる必要があるのかもしれない。DNSの名前解決が失敗すると、はた目には、つなごうとして失敗する接続障害のように見えることが多いはずである（ホームルーターの動作についての解説記事[*4]も書いているので、ご興味がある方は参照していただきたい）。

　図3は、Firefoxについて述べたものである。日本ではHTTPS RRの使用についてデフォルトで無効になっているが、なぜかDoH（DNS over HTTPS）を使うよう設定変更すると有効になるようだ。山口氏も「DoHとHTTPS RRは本来、無関係のはずなのだが」と述べつつ、首をかしげていた。

　続いて、エイリアスモードへの対応である（図4）。エイリアスモードとは、HTTPS RRのサービスプライオリティ（SvcPriority）にゼロ（0）を指定することで、シンプルなエイリアス（別名）を実現できるというものである。よく「HTTP（S）限定で、ゾーン頂点でも使えるCNAME」という説明がされるが、それをこの設定で実現する。多段エイリアスが可能であるが、その際にはCNAME→エイリアスモード、エイリアスモード→CNAMEという構成も可能である（多段エイリアスについては、実装側の裁量とされる）。

図4　エイリアスモードへの対応

　Safariは、エイリアスに対応はしているが、多段にはできない。一方、ChromeとFirefoxは、エイリアス非対応（RFC違反）だということである。山口氏は、この件について「これでは、HTTPS RRの目玉機能の1つが使えない。ゾーン頂点でCNAMEが使えない問題があるからウェブブラウザー業界の人々はHTTPS RRを作ったはずなのに」「気合を入れてエイリアスを10段まで作ってテストに臨んだのに、いずれも最初の1段で終わってしまいました」と述べている。

　さて、HTTPS RRのサービスプライオリティにゼロ以外を指定するとサービスモードとなる。これによりウェブサーバーに優先度を設定できるが、さらにサービスパラメータ（SvcParams）を使用してサーバーの付加情報も記述できるようになる。

　図5を見ていただくと分かるが、Chromeはターゲット指定を無視する（RFC違反）ということである。山口氏は、「SafariとFirefoxはまともだが、Chromeがこの惨状では検証を進める意味が見出せなかった」と述べ、サービスプライオリティで設定された優先度に従うかどうかの検証は行わないことにしたそうだ。

図5　サービスモードへの対応

　では、サービスパラメータの解釈について（図6）は、どうであったのだろうか。その点について、alpn[*5]と、ipv4hint、ipv6hintについて調べてみたところ、alpnはChrome、Safari、Firefoxともに見ているようだが、ipv4hint、ipv6hintについてChromeは無視しているとのことであった。

図6　サービスパラメータの解釈

　alpnは、HTTP/2やHTTP/3が使えるかをクライアントに通知するためのパラメータである。Chromeは、このalpnだけしか見ていない。ipv4hintやipv6hintはあくまでヒントであり、「内部名のSVCB/HTTPS/A/AAAAの各RRをadditional sectionに含める」実装が普及するまでのつなぎのパラメータである。したがって、従わなくても問題はない。

　HTTPS RRへの対応・未対応のクライアントが混在している過渡期においては、どちらのクライアントであってもアクセスできるようにする配慮は必要だろう。それを考えると、HTTPS RRのエイリアスモードの使用は避け、サービスパラメータの通知のみに用途を絞るのは間違いではない。ただし、本格的な普及のためには、ウェブブラウザーや専用アプリなどのクライアント側がHTTPS RRにきちんと対応していく必要があるということも忘れてはならない。

　ここで、図1で示した「Best Current Practice」を再掲するが、ここまでの結果を見ていると、山口氏の言うように「ChromeはHTTPS RRをまともに実装できているとは言い難い」と感じる方は多いのではないのでなないだろうか。

図1の再掲

　権威DNSサーバーとフルサービスリゾルバー（キャッシュDNSサーバー）については、オープンソースの主要な実装はどれもHTTPS RRに対応済み（図7、図8）。大手権威DNSサービスの場合、対応済みと未対応があるが、Cloudflareのように積極的に推進しているところもあるとのことであった。もし、自分でHTTPS RRを使いたいのであれば、使用するDNSサービスは選んだ方がいいだろう。

図7　権威DNSサーバーの対応状況

図8　パブリックDNSサービスの対応状況

　ここまで見てきたように、各ウェブブラウザーのHTTPS RRへの対応状況はまだまだと言わざるを得ない。山口氏の言うように「現時点では、それほどメリットを生かせる状況ではない」というのは、その通りであろう（図9）。

図9　対応状況まとめ

サービスパラメータを用いてプロトコルを拡張する

　山口氏からのもう1つの話題は、HTTPS RRで発明されたサービスパラメータという概念をDNSにも取り入れようとする動き（プロトコルの拡張）についての解説である。

　HTTPは、クライアントとサーバー間において1往復のやりとりだけで終わるプロトコルである。原則としてステートレス（stateless：状態を保持しない）であり、ウェブブラウザーなどのクライアントがサーバーに対してリクエストを送ると、それに応じた結果がサーバーから送られてくるという仕組みで成り立っている。そのため、サーバーからの応答によってクライアントがその後の動作を変えることはできない。

　一方、メールで使われるSMTPでは、ESMTPの機能拡張を使うことにより、クライアントが挙動を変えることができるようになっている（図10）。ウェブブラウザー業界の人々は、接続しようとするウェブサーバーがどのような拡張機能に対応しているかをクライアントが事前に知ることができるようにするために、HTTPS RRを作ったのである（図11）。

　HTTPS RRのサービスパラメータは、サーバーの付加的情報を記述するためのものである。「SvcParamKey=SvcParamValue」という形式で列挙していくため、高い拡張性を持っている（新しい機能には新しいSvcParamKeyを定義すればよい）。

図10　プロトコルの拡張

図11　HTTPの拡張

　そして、DNSも同じように、1往復のやりとりだけで終わるプロトコルである。DNSの拡張という意味ではすでにEDNSがあるが、HTTP同様、1往復で終わるプロトコルであるためサーバーからのEDNS情報に応じてクライアントが動作を変えることはできない。

　あえてやるのなら2回目のクエリからであろうが、でもやはり、初回からやりたいとすると、どこかにそのDNSサーバーの拡張機能に関する情報を持たせなければいけない（図12）。

図12　DNSの拡張

　メールサーバーの拡張機能は、メールサーバーに聞けばよい。ウェブサーバーの拡張機能は、DNSサーバーに聞けばよい。権威DNSサーバーの拡張機能は親の権威DNSサーバーに聞けばよいとなるのだが、問題は「そのような情報を登録するRRは存在しない」ということである。そこで登場するのが、DELEG RRである（図13～図17）。

図13　拡張機能の情報はどこに？

図14　権威DNSサーバーの機能拡張

図15　DELEG RR

　DELEG RRは、NS RRで定義されていたDNSの階層構造を置き換えていくものになる。個人的に注目したい点は、サービスパラメータが記述できることだけでなく、親のゾーンにしか存在しないという点である。

　現在のDNSでは、NS RRは親のゾーンと子のゾーンの両方に存在し、子のNSの方が権威を持つことになっている（親のNSよりも優先度が高い）。このようなかたちになっているのは、「昔にそうしたから」という経緯の面が大きく、必ずしもこのかたちが良いからというわけではない。

　問題なのは、親ゾーンに登録されるNS RRは「委任情報」であり、子ゾーンに登録されているNS RRは「権威情報」であるというように、本来異なる情報であるのに同じリソースレコードタイプを使って指定しているという点である。これは、人間の理解のしやすさという点からは好ましい姿ではない。

　筆者としては、この機会に、委任情報は親ゾーンへDELEG RRで記述し、権威あるNSは子ゾーンへNS RRで記述するというかたちになってもらえると説明が少し楽になる。今後、DELEG RRがどのようになるかは予測がつかないが、NSの委任と権威が明確に分離されるのは良いことではないかと感じている。

図16　DNSの拡張機能って具体的には？

図17　DELEG RRの例

　DELEG RRの具体的な話はIETFで提案され議論されている最中[*6]なので省くが、もしこのDELEG RRが普及していくとDNSにとって非常に大きなインパクトがあるものになる可能性がある。図18に書かれているとおり、HTTPS RRやSVCB RRは、他のプロトコルが使うための入れ物を提供するだけである。しかし、DELEG RRは、DNS自身が使うためのものである。DNS関係者にとっては、要注目案件であろう。

図18　DELEG RRのインパクト

自分が扱う一次情報としてのゾーンデータは手元に持っておくべき

　さくらインターネット株式会社の滝澤隆史氏による発表「DNS as Code―CI/CDを利用したゾーン運用―」は、マネージドDNSサービスを利用する際のゾーン管理方法を提案するものである。今回、所属会社とは関係なく、趣味であるDNSの話題を提供する意図でこのイベントに応募したそうだ。

　ここでの発表のポイントは、2つある。1つ目が、自分が扱う一次情報としてのゾーンデータは手元に持っておくべきであるという点。2つ目が、一次情報としてのゾーンデータをGitのようなバージョン管理システムを利用して管理し、その運用をマネージドDNSサービスに依存しないツールで行う（問題があれば切り替える）という点である。これにより、マネージドDNSサービスに過度に依存することなく、利用者が主導権を持ってDNSの管理・運用を行えるようになる。

　1つ目の点に異論がある人は少ないであろう。多くの人は、やりたくても「でも、どうやって管理すればいいの？」となっているはずである。2つ目の点は、まさに、その悩みへの回答である。紹介されるツールは、DNSControlとoctoDNSという2つであるが、記事ではその解説は行わない。詳細を知りたい方は、公開されている滝澤氏の発表資料を読んでほしい。以降では、発表に従ったかたちで要点をまとめていく。

　さて、クラウドサービスを利用する場合、提供されるマネージドDNSサービスを使うのが一般的である。しかしながら、そこで提供されるSDKやツールは便利な反面、DNSゾーンの運用に利用するには煩雑である。そのため、扱いやすいWebUI（コントロールパネル）を使う人が多いという（図19）。

図19　クラウド時代におけるDNSゾーン運用

　ただし、WebUIを使用した場合には変更管理ができなかったり、問題発生時に切り戻しができなかったりするという課題がある（図20）。「自分では設定を変更した記憶はないのに、設定が変わっていた（誰かが変えた）」「設定を変えたけれども、なぜそうしたのか記録がない」といった経験をお持ちの方も多いと思う。そもそも、WebUIの役割は設定を容易に行えるようにすることであるから、それ以外の変更履歴を残すとか、コメントを残すといった機能は持ち合わせないのが一般的である。

図20　WebUI（コントロールパネル）起因による課題

　問題が発生しなければ、図20で示されたような課題を意識することはほとんどないであろう。しかし、自分が提供し、管理しているサービスを止めないということを考え出すと、ここに書かれている課題の解決はとても重要になる。

　滝澤氏が提案するそのための対策は、WebUIを使わず、ゾーンデータを手元でテキストファイルとして運用し、提供されるAPIを利用してDNSサービスに反映させるというものである（図21）。

図21　WebUI（コントロールパネル）起因による課題の対策

　滝澤氏は、そのことをマネージドDNSサービスで大規模障害が起こった場合を例にして説明した。大規模障害が起こった場合には、ゾーンデータを取り出せない状態であろうから（障害時に取り出せるとは思えない）、ゾーンデータを手元に持っていることが重要になる。

　図22は、大規模障害が発生すると何が起きるか、何ができるかの説明である。図23と図24は、事前の準備と提案する方法で他のマネージドDNSサービスに切り替えを行うことの説明である。

図22　マネージドDNSサービスの大規模障害による課題

図23　マネージドDNSサービスの大規模障害による課題の対策、その1

図24　マネージドDNSサービスの大規模障害による課題の対策、その2

　手元にゾーンデータがあれば、あとはマネージドDNSサービスが提供するAPIを使用してゾーンデータを反映させるだけでよい。DNSControlとoctoDNSは、いずれも複数のマネージドDNSサービスに対応しており、実際に登録されているゾーンデータから更新した内容を確認できるなど、必要と思われる機能を持っているということである。

　ゾーンデータをコード（テキストファイル）として扱い、Gitのようなバージョン管理システムを利用することで変更履歴や変更理由を残せたり、変更内容（差分）を確認できたり、問題発生時に切り戻しができるといったメリットを得ることができるのは、確かに嬉しいことではないだろうか。図25から図27までは、今回の提案が持つメリットを整理して説明したものである。

図25　コード（テキストファイル）であることの利点

図26　Gitのようなバージョン管理システムを利用できる

図27　GitHubやGitLabのようなバージョン管理システムのプラットフォームを利用できる

　発表が終わると、会場からは、多くの質問が投げ掛けられた。DNS RRの構文チェックの話や、ゾーン管理者とは別の人がオーナーとなるレコードの編集はどうすればいいかといった話など、その内容は多岐に渡る。

　個人的には「オーナーがGitHubを使いこなせないのでは」というコメントが気になったが、要は慣れの問題でもあるので、必要に迫られれば大丈夫なのではとも思える。顧客側の環境整備は分かる人がセットアップすればいいので、手順書なり操作手引書なりが整備されれば利用してみようという人は増えるかもしれない。

digのコマンドラインオプション一覧がPDFで公開

　今回、筆者はIIJ山口氏の発表を聞きながら、新しいプロトコル、それも大きな影響を持つプロトコルが普及するためには何が必要なのかを深く考えさせられた。対応・未対応の環境が混在する中で、そのどちらにも対応しようとするとどうしても制約が生まれてしまう。

　全くの新サービスで思い切った舵を切るにしても、全体の90％以上が新しいプロトコルに対応したとしても、未対応のユーザーを切り捨てるという判断は容易には行えない。本当に難しいと痛感させられた。

　最後に、今回のプログラム（スポンサーセッション）の中で、アカマイ・テクノロジーズ合同会社の松本陽一氏より、前回（DNS Summer Day 2023）の発表「新しいdig」で分類したdigのコマンドラインオプションを1枚の表に整理したものをPDFにして公開した旨の説明が行われた。脚注で示したURL[*7]でアクセスできるので、ご興味のある方は訪問してみてほしい。

　いつもながら、濃く、参考になる情報が多く、とても有用なイベントであったと思う。会場の雰囲気も良いので、ご興味のある方は次回以降での参加を検討してほしい。