書籍『DNSがよくわかる教科書』が「よくわかる」のはなぜ？ あれから7年。DNSの来し方行く末を思う

　「Internet Week 2025」において11月26日、恒例のランチセミナー「ランチのおともにDNS」が行われ、「DNSにおける最近の変化―『DNSがよくわかる教科書 第2版』発行に寄せて」と題して、株式会社日本レジストリサービス（JPRS）の森下泰宏氏と熊谷維魅（くまがい いみ）氏が講演した。

　今回の内容は「DNSの変化」をテーマとし、『DNSがよくわかる教科書』[*1]が発売された2018年から現在までの間にドメイン名とDNSに起こった主な変化と、それを踏まえたDNSと『DNSがよくわかる教科書』のこれからが、話の中心になっている。講演の後半は書籍に関する話題が多かったことから、本レポートでは前半の「ドメイン名とDNSにおける最近の変化」に重点を置いて解説する。

図1　『DNSがよくわかる教科書』

図2　今年のテーマは「DNSの変化」

DNSは枯れた技術ではなく、現在も変化し続けている

　「ドメイン名とDNSにおける最近の変化」では、2018年以降に起こった7つの項目が熊谷氏から紹介された（図3）。以降、当日は説明されなかった内容・背景を随時補足しながら、順を追って解説していく。

図3　「ドメイン名とDNSにおける最近の変化」のパートの内容

図4　CAAリソースレコード（RR）の義務化と対応

　図4は、CA/Browserフォーラム（The Certification Authority/Browser Forum）が、認証局（CA）におけるCAAリソースレコード（RR）のチェックを義務化したこと、それにより実装・サービスにおける対応が広まったことを伝えるものである。

　SSL/TLSサーバー証明書（以降、単に「サーバー証明書」とする）は、インターネットの安全な利用に欠かすことができない、重要な要素の1つである。しかし、サーバー証明書には誤発行や不正発行によるセキュリティインシデントというリスクも、同時に存在する。CAA RRは、サーバー証明書の誤発行・不正発行を事前に防止・検知するために使われる。「CAA」が「Certification Authority Authorization（認証局の許可）」に由来すると言えば、ピンとくるのではないだろうか。

　ドメイン名の管理者は、CAA RRによって、サーバー証明書の発行を許可するCAの一覧や、不正な発行要求があった際の連絡先などを指定できる。発行依頼を受け取ったCAが管理者の設定したCAA RRを名前解決し、設定内容をチェックすることで、以下の2点を実現できることになる。

• 許可しないCAから、自身の証明書が発行されるのを防ぐ
• 許可しないCAに、証明書の発行要求があったことを知る

　CAによるCAA RRのチェックが義務化されたことで、DNSプロバイダーにおけるCAA RRのサポートが進んでいる。こうした背景から利用者側から見た場合、CAA RRのサポートの有無が、DNSプロバイダーの選択における要素の1つになっているとも言える。

図5　HTTPSレコードの先行対応と標準化

　図5は、WebブラウザーやサービスプロバイダーがRFCの発行を待たずに、HTTPS RRに先行対応したことで、フルサービスリゾルバー（キャッシュDNSサーバー）に到達するクエリ数が急増したことを説明したものである。

　いまや、DNSクライアントがフルサービスリゾルバーに問い合わせるDNSクエリの5分の1近くを占めるようになったHTTPS RRだが、その普及の過程を過去のInternet Weekの「DNS DAY」のレポートから追ってみた。それらを見ると、2021年[*2]には「昨年から本格的に使われ始めたHTTPSレコードの割合がすでに11％もある」と書いており、2022年[*3]には「全体の15％」、2023年[*4]には「全体の20％」と、RFCの発行前であったにもかかわらず、クエリ数が急速に増え続けたことが分かる。RFC発行後の2024年は「前年に比べて9％の増加」となっているが、A RRやAAAA RRに混じっての数字であり、対応がさらに進んだ結果であると言えるだろう。

　HTTPS/SVCB RRがIETFの標準化において特別対応を受け、2023年11月6日にRFC 9460として発行された経緯については、2023年の記事[*4]で記述している。ご興味がある方は、そちらも参照していただきたい。

図6　QNAME minimisationの普及

　「QNAME minimisation」は、フルサービスリゾルバーが権威DNSサーバー群に問い合わせる際の問い合わせ名を最小化し、利用者のプライバシーを保護する仕様である。図6はQNAME minimisationの普及状況について説明したものだが、.com/.netの権威DNSサーバーに到達する問い合わせの65％以上がQNAME minimisationによるものだというのは、かなり高い比率である。

　従来の仕様では、フルサービスリゾルバーはスタブリゾルバーから受け取った問い合わせ名と型（例えば、www.example.jpのAレコード）をそのまま、権威DNSサーバー群への非再帰問い合わせで使用する。しかし、この仕様ではルートサーバーやTLDの権威DNSサーバーの管理者が、そのフルサービスリゾルバーの利用者がいつ、どのような名前を問い合わせたか、ひいてはどのようなサイトやサービスを利用しているのかを、ある程度知り得る状況にあることになる。

　利用者のプライバシー保護の観点からは、そのような状況は好ましくない。そのため、フルサービスリゾルバーが非再帰問い合わせを実行する際のアルゴリズムを変更し、権威DNSサーバー群に送信する情報を必要最小限のものにするために誕生したのが、QNAME minimisationである。QNAME minimisationを使用すると、名前解決すべき名前が「private.example.jp」である場合、ルートサーバーにはjpの委任先を問い合わせ、続いてjpの委任先であるJP DNSサーバーにはexample.jpの委任先を問い合わせるようになるため、ルートサーバーやTLDの権威DNSサーバーの管理者は、利用者が問い合わせた「private.example.jp」という名前を知ることができなくなる。このようにすることで、利用者のプライバシーを保護するわけである。

図7　サブドメインテイクオーバーの流行

　「サブドメインテイクオーバー」とは、外部サービスの利用開始時に設定したCNAME RRやA/AAAA RRが利用終了後も削除されずに残っていることに付け込み、その設定を利用してそのサブドメインの利用を引き継いで（テイクオーバーして）しまおうというものである。図7は、サブドメインテイクオーバーの流行と、2025年1月に報告された複数のgo.jpドメイン名の被害事例により、デジタル庁のガイドラインが改定されるに至ったことを伝えている。

　DNSデータは公開情報であるため、サブドメインテイクオーバーが行える状態にあるドメイン名は外部からのDNS検索で見つけることができるし、攻撃可能な設定を効率良く発見するためのツールもインターネット上で公開されている。トラブルに巻き込まれないためにも、外部サービスの利用終了時には不要となるDNS設定の削除・変更を、確実に実行してほしい。

　サブドメインテイクオーバーについて興味のある方は、2020年のランチセミナー「マネージドサービス時代のDNSの運用管理について考える ～DNSテイクオーバーを題材に～」[*5]の内容をレポートしている[*6]ので、そちらを参照していただきたい。

図8　レジストリサービスプロバイダーの出現・成長

　図8は、2012年のgTLD追加募集で多数のgTLDが創設されたことから、レジストリの運用実務を請け負う「レジストリサービスプロバイダー（RSP：Registry Service Provider）」が出現し、成長していることを説明したものである。

　創設されたgTLDの中には、特定のコミュニティやグループでの利用を前提としたコミュニティgTLD、企業名や組織名、商標などの文字列を使ったブランドTLDのように、狭い範囲での利用を前提にしているものも多い。しかし、そうした狭い範囲での利用であっても、ICANNとの契約や各種手続き、レジストリデータベースの管理、DNSの運用、RDAPの運用など、レジストリの運用には高い専門性が必要になる[*7]。そうしたことを自前で賄っていくことはコストや人材面などの点から難しく、レジストリの運用をどこか信頼のできるところに任せてしまいたいと考えることは、自然なことであろう。

　レジストリサービスプロバイダーは、そのようなニーズに応えるものである。実際に2012年の募集で創設されたgTLDでは、レジストリの運用をレジストリサービスプロバイダーに委託する形が一般的なものとなっている。

　こうした背景から、gTLDのレジストリになりたい組織の立場に立った場合、どのレジストリサービスプロバイダーに運用を任せればよいかを判断する、判断基準の重要性が高まることとなった。ICANNはこれを受け、2026年に予定されているgTLD次回募集において、レジストリプロバイダーの技術力を総合的に評価し、結果を公開する「レジストリサービスプロバイダー評価プログラム」[*8]を開始することになった。

図9　gTLDにおけるWHOISの非義務化

　図9は、2025年1月28日以降、gTLDレジストリ／レジストラにおけるWHOISの提供が契約上の義務でなくなり（非義務化）、RDAP（Registration Data Access Protocol）への移行が図られていることを説明したものだ。

　ドメイン名レジストリ／レジストラの基本的な役割の1つに、ドメイン名の登録情報の公開がある。そのためのサービスはRDDS（Registration Data Directory Service）と呼ばれ、その方法として長い間、WHOISが使われていた。

　しかし、WHOISは1980年代に開発された古いプロトコルであり、応答の形式が規格上定められていない、検索対象と問い合わせ先の対応を取得する方法が定められていない、アクセス制御・認証・許可の仕組みが定められていないなど、さまざまな問題が指摘されていた。そのため、WHOISを置き換えるためのRDAPが、2015年にRFC 7480～RFC 7485として標準化されている[*9]。

　RDAPへの移行を図るため、ICANNは2023年8月にgTLDのレジストリ契約（RA）とレジストラ認定契約（RAA）を改訂した。改訂に伴うタイムラインは以下の通りである。

• 2023年8月7日から2024年2月3日までを「RDAP強化期間」とし、gTLDレジストリ／レジストラに自身が提供するRDAPシステムの強化を呼び掛ける
• RDAP強化期間の終了後、RDAPにもWHOISと同じサービスレベル要件（SLA）を、契約で義務付ける
• 360日の移行期間を経て、2025年1月28日にWHOISの提供を非義務化する

　RDAPはWeb（HTTPS）ベースでの提供および利用が前提となっており、RDAPに対応することでWHOISと同等以上のRDDSを提供、または利用できる。また、どの応答も統一されたJSON形式でデータを返すため、機械的な処理が容易になっている。

図10　委任の再設計（1/3）

図11　委任の再設計（2/3）

図12　委任の再設計（3/3）

　図10から図12は、DELEG RRの始まり（アイデアの提案）から、標準化作業の進め方が決まるまでの流れを説明するものである。まず、従来のNS RRとグルーレコードによる委任の置き換え・併存を実現する基本部分の標準化作業を進め、DELEGならではの機能の追加はその後で進めることが合意されたことが示されている。

　DELEG RRは、DNS通信の暗号化やマネージドDNSサービスの普及といった、新たなプロトコルやサービスの出現に伴い、それらの円滑な導入・利用に必要な項目を委任元にまとめて記述可能なRRがあると良いというアイデアに基づくものである。つまり、委任先の権威DNSサーバーがサポートしている拡張機能（通信の暗号化やそのために必要なサービスパラメーターなど）やIPアドレスの情報など、委任先に関する情報を委任元に1つのRRで記述できるようにし、必要な情報を一気に伝達してしまおうという野心的なリソースレコードであると言える。

　しかし、DELEGの標準化作業は全てが順調というわけではなく、2025年8月に著名なインターネットエンジニアの1人であり、APNICのチーフサイエンティストを務めるGeoff Huston氏[*10]が自身のブログで、作業状況に関する憂慮[*11]を表明している。端的に言うと、現在のdeleg WGの活動は「委員会による設計（Design by committee）」[*12]に進んでいる可能性があり、問題を解決する方向に進んでいないのではないかという懸念を指摘したのである。

　委任という仕組みはDNSの根幹を担う基本部分の1つであり、ドメイン名を登録する際の登録情報の取り扱いやレジストリ／レジストラモデルは、委任の仕組みを前提として設計されたものである。そのため、インターネットの安定運用の観点から、その変更には慎重な検討と適切な導入計画が必要になり、ある程度の時間を要することはやむを得ない。Huston氏の指摘は、現在のdeleg WG、ひいてはIETFの活動そのものがプロトコルの「作成」「改良」という手段に終始し、現実の課題を解決するという本来の目的がおろそかになっているのではないかという問題提起であり、広く普及したプロトコルの改良と標準化作業は難しいものなのだと痛感せざるを得ない。

『DNSがよくわかる教科書』が「よくわかる」理由とは？

　次のパートである「『DNSがよくわかる教科書 第2版』の概要」では、森下氏から、現在の『DNSがよくわかる教科書』を振り返り、前のパートで説明したDNSの変化を踏まえ、現在制作を進めている『DNSがよくわかる教科書 第2版』がどうなる予定であるかの概要が紹介された。書籍を作っていく過程の話はとても興味深いが、レポートとしては簡潔に、筆者が頷いた部分と第2版の概要について紹介する（図13、図14）。

図13　専門用語の取り扱い

図14　説明の進め方

　書籍に関する編集方針で筆者が一番感心したのが、専門用語をいきなり使うのではなく、最初に役割や動作を示し、その役割や動作を行うものを何々と呼ぶ――というかたちで説明するようにした点と、重要な部分の説明はあえて冗長にしたという点である（図13と図14）。この点はとても大事で、初めてDNSを学ぶ人にどれだけ正確なイメージを持ってもらうかを優先したということになる。

　一般的に、解説書の多くは最初に用語を示してその役割や動作を示すかたちを取ることが多い。その方が、説明が楽で、内容を簡潔に記述できるからである。用語を中心にすることで、技術書であるという雰囲気も出しやすい。『DNSがよくわかる教科書』でも「階層化」「委任」といった、DNSの本質を説明するために必要な基本用語は、そのかたちになっている。

　しかし、DNSには一見とっつきにくかったり誤解されやすかったりする、独特の用語・表現が存在する。そうした用語――例えば、特に誤解されやすい「再帰的問い合わせ」「非再帰的問い合わせ」は「私の代わりに名前解決をして、」が付いているかいないかの違いとして説明され、後で専門用語に置き換えるというかたちになっており、誤解を防ぐための工夫がされていると感じる。

　思うに、読者に対して、役割や動作を示しながらDNSの動きがイメージできるまで解説を繰り返すというのは、根気のいる作業だったのではないだろうか。ある説明では理解が及ばなくても、異なる観点から説明を重ねることで理解の解像度が上がるというのはよくあることである。しかしながら、そのような積み重ねをしていく作業は、技術屋が持つ「合理性」とかけ離れている。「もっと簡潔に書きたい」と思う気持ちは常に湧くであろうし、知識が豊富なゆえに「こんなことも書きたい」という欲も出てくるであろう。

　余談めくが、講演後に会場から「執筆には時間がかかったと思いますが、どのようにしてモチベーションを保ったのでしょうか？」という質問があったが、それに対する答えは「読者の気持ちを考え続けた」であった。それを聞くと、やはり苦労はあったのだと思うが、そのような積み重ねが技術書としては異例の販売部数につながっている源泉なのではないだろうか。

　筆者は古い人間なのでよく覚えているが、昔は、権威DNSサーバー[*13]とフルサービスリゾルバーが明確に区別されておらず、BINDのnamedが両方の機能を持っていたこともあり、いずれも「DNSサーバー」と呼ばれることが多かった。そうした状況もあり、権威DNSサーバーを指すときに「DNSサーバー」や「ネームサーバー」「コンテンツサーバー」「ゾーンサーバー」といった、さまざまな呼び方が使われるケースが多々見られたものだ。フルサービスリゾルバーにしても、「キャッシュDNSサーバー」や「ネームサーバー」「DNSサーバー」「参照サーバー」という具合に他の呼び方が使われるケースもあったことを考えると、DNSの分かりにくさ（理解の難しさ）の原因の1つとして、使われる用語が統一されていなかったことが挙げられるのではないだろうか。

　『DNSがよくわかる教科書』を手にする読者には、DNSについて何も知らないか、どこかで勉強することを断念した経験がある方も一定数いると思われる。仮に後者であった場合、用語の混乱でつまずいているであろうと考えると、誤解されやすい用語を具体的な役割から説明することにした方針は、賢明であったと言える。

　実際、「ネームサーバー」や「DNSサーバー」という用語は文脈に依存するため、書かれている内容に関する正しい知識がないと、正確な理解ができない。また、「コンテンツサーバー」や「ゾーンサーバー」「参照サーバー」という用語は、DNSをより分かりやすく説明したい説明者が自分なりに考えて（過去に）作られた用語であった。DNSの用語を定義するRFC 7719が2015年に発行され（2019年にRFC 8499、2024年にRFC 9499に改版）、さすがにそうした用語は少しずつ使われなくなってきたが、古い資料には今でも残っていたりするので注意が必要である（実際、JPRSの資料の中にもそのような用語が残っているものがある）。

　筆者の手元にもこの本の初版があるが、最初の「基礎編」では用語を適切なタイミングで紹介し、以降は正確な使い方をして、それがブレていないという点も好感が持てる。地味ではあるが、こうしたことも理解の助けになっていると思う。今後の改定でも、この編集方針は継続してほしい。

　そして、現在進行中とされる第2版がどうなるかという話題である。図15から図17を見ていただきたいが、基本的には以下の3点が重要であろう。最初の2点は、現状に合わせたアップデート的な意味合いを持ち、3つ目の点は不確定な未来も含めて記述されるというかたちになる。

• 初版で記述しなかった項目の一部を追加
• 全般的な更新と修正
• 第15章「DNSにおける最近の動き」を新設し、今後のDNSに影響を及ぼす項目をまとめて紹介

図15　『DNSがよくわかる教科書 第2版』の概要

図16　第2版における追加・変更点

図17　今後のDNSに影響を及ぼす項目

　最初の2点については改訂のレベルに見えるのでここでは言及しないが、3つ目の点については興味津々である。そこで、筆者の想像を含めてその意味を考えてみたい。

　スライドの中で、一番気になるのが「委任の再設計」である。後述する最後のパートでもDELEG RRに言及されていたことから、この話題が持つ意味の大きさを考えざるをえない。

　今年のDNS DAYのレポート（関連記事『SSL/TLSサーバー証明書の有効期間が398日→47日に短縮へ。サイト管理者はどうすればいい？ 「耐量子計算機暗号」移行によるDNSSECへの影響は？ 毎年恒例「DNS DAY」の話題から』参照）やこのレポート内でも書いたように、DELEG RRの標準化には長い時間がかかりそうな流れになってきている。かつ、DELEG RRは委任の仕組みを変えることになるため、『DNSがよくわかる教科書』の内容にも影響を及ぼすことになる。つまり、DELEG RRの進み具合が、第3版以降の改訂のタイミングに影響するわけだ。この話は最後のパートの解説で改めて行うので、ここでは他の項目に対して感じたことを述べることにする。

　まず、「新しいリソースレコードの追加」については、例えばHTTPS RRがその代表格であろう。昔のDNSにおける標準化では、新しいデータが追加されてもリソースレコードの種類をあまり増やさない方向にあった。しかし、2009年に発行されたRFC 5507「Design Choices When Expanding the DNS」で「新しいデータをDNSに追加する場合、リソースレコードの追加が好ましい」とされて以降、新たなリソースレコードを追加する方向で標準化が進められるようになっている。個人的には、なんでもTXT RRに入れてしまうという運用には辟易しているので好ましく感じるのであるが、DNSの動向を追う立場としては大変である。第2版でまとめていただけるのであれば、ありがたい。

　次の「DNSを用いたサイトブロッキングに関する動き」については、これまでの経緯をまとめたものとなるであろう。将来は予測不能であるし、考え方や実効性など、整理しておくことに価値があると考える。

　最後の「ルートゾーンのアルゴリズムロールオーバーに向けた検討」については、なかなか難しそうだ。最近では、DNSSECにおけるKSKとZSKの運用トレンドが変わってきているし、DNS DAYのレポートで書いたとおり、「暗号の2030年問題」に伴う、耐量子計算機暗号（PQC）への移行という話もある。このあたりの話について興味のある方はDNS DAYのレポートを読んでいただきたいが、実用的な量子計算機の登場により、現在の公開鍵暗号方式で使われているアルゴリズムの安全性が脅かされる可能性が高くなっている状況で将来を予測するのは困難であろう。どのようにまとめるのか、興味が湧く。

　とはいえ、そうしたことも、第2版が出れば結果が分かる。買い物が本当に楽しいのは、買うものについて考えているときであるという意見もある。当分は、この話題で楽しめそうである。

DNSと『DNSがよくわかる教科書』のこれから

　最後のパートである「DNSと『DNSがよくわかる教科書』のこれから」は、森下氏と熊谷氏の掛け合いというスタイルで進められた。ここまで掲載するスライドが多くなりすぎたのと、最初の数枚はこれまで述べてきたことと被るため掲載せず、具体的な詳細を知りたい方は、公開済みの資料[*14]を見ていただきたい。

　ここでの核心は、図19にある「DELEGの基本仕様はいつ、標準化されると思いますか？」と「DELEGはいつ、本格的に使われ始めると思いますか？」という、森下氏から問い掛けられた質問であろう。

図18　DNSと『DNSがよくわかる教科書』の今後

図19　ここでみなさまに質問です

　森下氏は冒頭のあいさつで、「JPRSを定年退職し、JPRSに入社しました」と述べており、定年後の再雇用であれば、雇用期間は5年程度と考えるのが妥当であろう。図19での質問に対する会場からの反応の多くは、基本仕様の標準化は2番の6～9年後、DELEGが本格的に使われ始めるのは3番の10年以上先というものであった。

　筆者は、基本仕様の標準化についてはもっと早いのではと感じるが、普及には相応の時間がかかりそうである。インターネットの関係者が協力して「こうしよう」と強力に推進しなければ、レガシーとしてのNS RRとグルーレコードを使った現在のシステムが残るのは避けられないからである。

　『DNSがよくわかる教科書』は名著だと思うが、監修者としての森下氏が今後どのようにかかわっていくのか、かかわれるのかがとても気になってしまった。無責任かもしれないが、契約社員や外部委託という手もあると思うので、健康に気を付けながらできるだけ頑張っていただきたいと切に願う。

図20　おわりに