イベントレポート
Internet Week 2024
DNSにおける委任の構造が大きく変わる!? IETFの「deleg WG」が最近熱いらしい。再設計を目指し、慎重な議論
DNS界隈の2024年を振り返る――毎年恒例「DNS DAY」の話題から
2024年12月24日 07:00
「Internet Week 2024」において11月26日、DNSに関する話題を集めたプログラム「DNS DAY」が開催された。本稿では、その盛り沢山の話題の中から、恒例となっているセッション「DNS Update」のほか、筆者が気になった話題を取り上げる。
大きな盛り上がりを見せる「deleg（DNS Delegation）WG」
「DNS Update」は、DNSに関する前回のInternet Week以降の状況を、関係者がそれぞれの立場から報告するセッションである。昨年までの本記事ではプログラムの報告順に話題を取り上げていたが、今回は、株式会社日本レジストリサービス（JPRS）の藤原和典氏が「DNS Update: IETF/RFC動向」の中で述べた、とても興味深い話題を取り上げることから始めたい。
その話題とは、DNSにおける委任を再設計するために創設された、IETFのdeleg（DNS Delegation）WGがとても盛り上がっているという話である。実際、藤原氏が「最近熱い」と述べていたことから、委任の再設計は多くのDNS関係者が待ち望んでいたものなのかもしれない。重要なのはとにかく熱量があるという点で、関係者を長年悩ませていた設計上の懸案を解決できるのではないかという期待が高まっている。
この話題を理解するための鍵となるのが、DELEGリソースレコード（RR）である。これは、通信の暗号化やマネージドDNSサービスなどの普及に伴い、それらの利用に必要な項目を委任元にまとめて記述可能なRRがあると良いというアイデアに基づき、2023年11月のIETF 118 Hackathonで誕生したものである。分かりやすく言えば、委任先の権威DNSサーバーがサポートしている拡張機能（通信の暗号化やそのために必要なサービスパラメータなど）やIPアドレスの情報などを、委任元に1つのRRで記述できるようにするということである。
DELEG RRについては以前の記事で2回ほど取り上げている[*1] [*2]が、HTTPS/SVCB RRのフォーマットを利用するというアイデアは関係者の大きな反響を呼び、2024年3月のIETF 119においてWG結成に向けたBoFが開催され、2024年6月に「deleg WG」として正式に発足、という流れとなっている。WG初のミーティングが発足直後の2024年7月に開催されたIETF 120においてであるから、かなり速いペースで進んでいると言えるだろう。
この提案がRFCとして標準化された場合、DELEG RRが、NS RRで定義されていたDNSの階層構造を置き換えていくことになる（互換性維持のため、従来のNS RR、DS RR、グルーレコードは残される予定である）。つまり、DNSにおける委任の構造が大きく変わることになるのである。例えば、提供する機能が異なる権威DNSサーバーの共存、複数のマネージドDNSサービスの円滑な利用、フルサービスリゾルバー（キャッシュDNSサーバー）が利用する権威DNSサーバーの効率的な選択など、WGでは現在、再設計におけるさまざまな可能性が探られている。標準化に成功した場合、DNSにとって、とても大きな影響があるプロトコルが誕生することになる。
そのような背景を持つdeleg WGとDELEG RRであるが、現在では「DNSの委任を改良するプロトコルを作る」（藤原氏）ことを目的として、そのために「既出のDELEG RR案にとらわれず、DNSの委任を再設計することを目指して慎重に議論が進められている」ということである。新しい委任の仕組みに特に厳密に要求される事項として、スライド（図1）にあるような項目が挙がっているとのことなので、ぜひご覧いただきたい。
筆者は、具体的なプロトコルのフォーマットではなく、この「既出のDELEG RR案にとらわれず、DNSの委任を再設計することを目指して慎重に議論が進められている」という点に、本気度の高さを感じている。個人的には、親ゾーンに登録されるNS RRは「委任情報」であり、子ゾーンに設定されるNS RRは「権威情報」であるというように、本来異なる情報であるのに同じリソースレコードタイプを使って指定しているという点が昔から気になっていた。それが改善されるのは歓迎である。
そして、DELEG RRが持つ影響力の大きさを示すような話題も提供された。IETFには、dprive（DNS Private Exchange）WGという、DNSの通信を暗号化することでDNSトランザクションにおける機密性を提供し、利用者のプライバシーを保護することを目的としたWGがある（図2）。そちらでは、フルサービスリゾルバーと権威DNSサーバーの間でDoT/DoQ[*3]を使うためのRFC 9539[*4]が2024年2月28日に実験的プロトコル（Experimental）として発行され、使えるようになった。
しかしながら、関係者の関心はdprive WGからすでに離れているようである。これについて藤原氏は、「皆の関心はRFC 9539のモデルから離れてDELEG RRに移ったようで、1年間、dprive WGの進展はありません。DELEG RRにDoT/DoQ対応と証明書の情報を載せられれば全ての問題が解決すると、皆が考えています。今後、このあたりについてはまだこれからいろいろ変わっていくと思います」と述べている（図3）。これは、DELEG RRのインパクトがいかに大きかったかを感じさせる、典型的な動きの1つと言えるであろう。
藤原氏の報告にはほかにも、DNSプロトコルにおける上限値の設定に関する話題や、DNSSECで推奨するアルゴリズムの管理方法を改良する話題などが含まれていた。
[*1]……DNS屋さん目線で2023年を振り返る――「HTTPS RR」クエリ数が48％も増加、「ランダムサブドメイン攻撃」からの教訓など、今年の「DNS DAY」の話題から
「HTTPS/SVCB RR」は特別対応を受けRFC 9460として発行、普及にはずみがつくか
https://internet.watch.impress.co.jp/docs/event/1556600.html
[*2]……「ChromeはHTTPS RRをまともに実装できているとは言い難い」各ブラウザーの対応状況を調べた結果が報告される
DNSの“TCPクエリ”問題が以前よりも悪化している可能性も指摘
https://internet.watch.impress.co.jp/docs/event/1617586.html
[*3]……DoT/DoQ：DoTはDNS over TLSのことで、DNSのTCPワイヤーフォーマットをそのままTLSセッションに載せるかたちで、暗号通信を実現する。DoQはDNS over QUICのことで、DNSのTCPワイヤーフォーマットをUDP port 853のQUICに載せるかたちで、暗号通信を実現する。
[*4]……RFC 9539「Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS」
https://datatracker.ietf.org/doc/rfc9539/
2025年1月、新しいKSKがルートゾーンに出現
さて、「DNS Update」最初の報告は、慶應義塾大学／WIDEプロジェクトの加藤朗氏による「Root DNS Update」である。
加藤氏からは、Mルートサーバーの運用について、2005年12月から開始したWIDEプロジェクトとJPRSとの共同運用が順調であること、APNIC Foundationからの資金をベースにWIDEプロジェクト、JPRS、APNICの三者で2020年8月にMoUを締結し、これに基づいてアジア太平洋地域内外でのMルートサーバーの展開を進めていることなどが伝えられた（図4～図6）。
図6には、現在運用中の21サイトが示されている。漢字・カタカナで書かれているのがサービス範囲をインターネット全体としたラージサイトで、ローマ字で書かれているのがサービス範囲を主に拠点設置国あるいはその周辺国に限定したスモールサイトであるとのことである。
また、次回のルートゾーンKSKロールオーバーの実施に伴い、新しいKSK（KSK-2024）が2025年1月にルートゾーンに出現することが予定されている（図7）。DNS関係者は、自分が管理しているフルサービスリゾルバーの状態やサーバーソフトウェアがRFC 5011[*5]によるトラストアンカーの自動更新をサポートしているかといったことなどを再度確認しておくのが良いだろう（図8）。
加藤氏は、KSK更新の際にハマるケースとして、1年以上落としていた計算機を立ち上げた場合、古いインストールメディアでインストールした場合を挙げた。その場合には、IANAのウェブページから手動で新しい鍵を入手してインストールするなどの対策をするようにしてほしいと述べている。
[*5]……RFC 5011「DNSセキュリティ拡張（DNSSEC）におけるトラストアンカーの自動更新」（JPRSによる日本語翻訳）
https://jprs.jp/tech/material/rfc/RFC5011-ja.txt
続いて、JPRSの池田和樹氏による「JP DNS Update」では、jpゾーンを管理するJP DNSの状況に関する報告が行われた。
JPドメイン名の登録数は増加傾向が続いており、JP DNSへのクエリ数の伸び率も増加していること（図9、図10）、総クエリ数に対するIPv6で到達したクエリ数の比率は、ここ数年30％をキープするかどうかというところであることなどが伝えられた。
また、昨年のJP DNS Updateで予告した「JP DNSのさらなる安定運用に向けたDNSソフトウェアダイバーシティの確保」について、NSDとKnot DNSの導入が完了し、複数ソフトウェアによるダイバーシティを確保できた旨も報告された（図11、図12）。
一般社団法人日本ネットワークインフォメーションセンター（JPNIC）の塩沢啓氏による「逆引きDNS Update」では、逆引きDNSにおけるlame delegationの改善に関する報告が行われた。
lame delegationは、DNSにおいて委任先の権威DNSサーバーが委任されたゾーンの情報を適切に返さない状態を示す用語である。塩沢氏からは、「たまにピークも出ているが、皆さまのご協力のおかげでlame delegationの割合は0.2％から0.3％の範囲にとどまっている」ことなどが報告された（図13～図15）。
NTTコミュニケーションズ株式会社の小坂良太氏による「フルサービスリゾルバー利用状況」では、OCNのフルサービスリゾルバーに到達するクエリとレスポンスを分析した結果が報告された。
長期的傾向における注目点は、直近の2年間でクエリ数が大きく増加したことである。図16では、一昨年から去年にかけてクエリ数が11％増加し、去年から今年にかけてさらに15％増加したことが示されている。原因について小坂氏は、「送信元のIPアドレス数については1％程度の増加にとどまっており、お客様が増えたというよりも、お客様ひとりひとりのクエリ数が増えたと考えられる」と述べている。
ユーザークエリにおけるクエリタイプの割合については、去年まで増加傾向であったHTTPS RRの割合は、今年はほぼ変化していない。また、AAAA RRについてはやや減っているように見える（図17）ということで、図16と図17をあわせたかたちで作成したものが図18であるが、そちらではA/AAAA/HTTPSともに増加していることが見える。A RRは21％増加、AAAA RR/HTTPS RRは共に9％の増加となっている。
また、今年はこれまで「その他」としていたクエリの内訳を調べてみたということで、その結果についても報告された（図19）。特に注目したいのが、その他のクエリにはSVCB RR（TYPE64）が多く含まれていることで、この原因として、DoTやDoHといった暗号化に対応したリゾルバーを利用しようとするクライアントがそれなりにいるのではないかと考えているとのことであった。この件に関しては、会場から「暗号化リゾルバーを自動検出するためのdns.resolver.arpaへのSVCBクエリなのではないか」といったコメントがあり、引き続き調べてみるということであった。
JPRSの高松百合氏による「DNS Update～ドメイン名全般～」では、gTLDを含むドメイン名全般に関する報告が行われた。gTLDの登録数については少々数が減っており、.comが前年の約1億6130万件から1億5760万件に減少した影響であろうということである（図20～図22）。図22を見ても分かるとおり、多少の順位変動はあっても、これといった大きな動きはなかったようだ。新gTLDについては、その総登録数が増加傾向にあることが示されている（図23）。
新gTLDの次回募集については、前回の報告からステップ上は変わらず5番目の位置にあること、少し具体的な話が出てきたことなどが伝えられた（図24～図26）。個人的に注目したいのが、gTLDの申請料が「審査料（evaluation fee）」と呼ばれている点である。高松氏によれば、ブランドに関わる場合のように何か問題が発生しそうなケースでは追加の審査が必要になり、その費用請求が別途発生するかもしれないとのことで、申請を考えている方々は注意してほしいとのことである。いずれにしても、申請を行う際には十分な検討が必要なことは変わらないはずなので、2025年5月に完成予定の申請者ガイドブックが公開されるのを待つのがいいだろう。
その他トピックスとして紹介された「gTLDのレジストリ・レジストラにおけるDNS Abuse対応義務の明文化」は興味深く、今後の動向を見守りたい。もう1つの「gTLDレジストリの提供料金に関する動向」については、実感している方々も多いのではないだろうか。レジストラ提供料金を値上げするgTLDレジストリが増加しているのは既知であるが、.comと.netに関して「2011年の料金と比較して.comは約1.4倍、.netは2倍以上になり、.comと.netの料金が逆転する状況となっています」と言われると、大きな値上げが行われているのだなと実感する。
ドメイン名は「取得」するものに非ず？ 認識の違いが不幸を招く
その他のプログラムからは、ドメイン名のライフサイクルマネージメントに関する話題を取り上げる。
ちなみに、今回のDNS DAYはこれまでと比べ、ドメイン名の取り扱いに関する発表が特に多かったと言える。一般社団法人JPCERTコーディネーションセンター（JPCERT/CC）の中井尚子氏による「調整機関から見るドメイン空間で起きていることと対処について考える」、日本DNSオペレーターズグループ（DNSOPS.jp）の石田慶樹氏と長崎県立大学／DNSOPS.jpの岡田雅之氏による「ドメイン名のライフサイクルマネジメント～最近の事例とともに～」、JPNICの是枝祐氏による「ドメイン名の登録と維持管理のあり方について」、NTTコミュニケーションズの森山美保氏、平木康介氏、冨樫良介氏による「使後の世界～利用終了した独自ドメインのその後～」と、4本ものプログラムが並んでいる[*6]。
その背景にあるものは、ドメイン名を無責任に取り扱い、結果として悪用されてしまう事例があとを絶たないという現実であろう。またか、という事例が繰り返されることに、関係者が悩んでいることは想像に難くない。
[*6]……石田氏と岡田氏は同じタイトルで個別に資料を用意しているため、実質的には5本である。
さて、プログラム「ドメイン名のライフサイクルマネジメント～最近の事例とともに～」と「ドメイン名の登録と維持管理のあり方について」は、実質的に1本のセッションである。最初に石田氏がドメイン名のライフサイクルマネジメントに関する基本的な話と現状を説明し、続いて岡田氏が放棄されたドメイン名がどのような状態になっているのかの調査結果を報告、最後に是枝氏がドメイン名の活用やドメイン名を扱う際の考え方について説明する、という流れであった。
石田氏は冒頭で「ドメイン名の話ばかりで恐縮するが、ドメイン名の取り扱いがしっかりしないと、DNSをまともに運用しようとしても根幹が成り立たない」と述べ、説明を開始した。強く同意したいのは、ドメイン名は「取得」するものではなく「登録」するものであるという部分である（図31）。その説明の中で「そのあたりの認識の違いが不幸を招いている」とも述べているが、その通りであろう。
ここは個人的な意見だが、業界にいるとドメイン名に対して「取得」とか「移譲」といった言葉を使う人をよく見かける。そのことが、誤解や間違いを生み出す大きな原因の1つになっていると感じるのは筆者だけではないはずだ。取得とは「自分の所有とする」ことであり、移譲とは「権限や権利、財産などを他に人や組織に譲り移す」ことである。どちらも所有権の移動を連想させるため、そのモノに対する全面的な支配ができるように錯覚してしまう。使うも捨てるも、利益の源泉とするのも自分の自由であり、廃止すればこの世から消えてしまうという錯覚である。したがって、このような「間違った言葉を使った説明」を撲滅していくことも重要であると思う。
石田氏は、ほかにも「ドメイン名は、登録時に定められた一定期間、当該ドメイン名の管理権限を渡されているだけ」「管理権限を手放したあと、そのドメイン名は海の藻屑と消えるとか宇宙の果てに消えると思っている方もいらっしゃるが、実際にはデータベースにそのドメイン名は残っている」「ドメイン名は所有するものではなく、実際にはリースの方がイメージとして正しい」「レジストリのデータベースは、そのドメイン名の登録者を正しく紐付けするもの」とも述べている。
また、ドメイン名を使うことで向き合わなければいけないリスクもある。図32にあるドメイン名のライフサイクルとリスクは、そのことを示したものである。黒地に白抜き文字で書いてあるものは犯罪に近いもの、グレーのものは違法ではないが日常的に行われているものとのことだが、実に多くのリスクがあることが分かる。そのための対策（費用や工数などを含めて）を考えると、ドメイン名を1つ使うだけでも大変なのに、数多くのドメイン名を使うとその数分の管理が必要になるため、管理工数が鰻上りに増えていくことになる。本来、新しいドメイン名を使うことを考える人は、その後の管理コストまで含めて考えるべきなのである（図33）。
続く岡田氏からは、昨年のInternet Weekからの調査の続きということで説明が行われたが、個人的に引き寄せられたのは、図34で示された質問に対する答えである。送信数100に対して回答が5ということでサンプル数としては少ないが、良く聞く話が可視化されているという点で興味深い。やはりというか、社会に対する啓発が十分ではないということなのだが、問題は、「では、そのような人々にどのようにリーチすれば良いのか」という点であろう。なかなかに難しい話である。
是枝氏の発表からは、企画関係者やドメイン名に関わることがある普通の人々に向けた、図35と図36の2枚を取り上げたい。よくある好ましくない例に心当たりはないかとか、ドメイン名を失ったあとでできることはほとんどないといったことを、ご理解いただければと思う。
最後に、今後への期待を込めて、NTTコミュニケーションズの森山美保氏、平木康介氏、冨樫良介氏による「使後の世界～利用終了した独自ドメインのその後～」を簡単に紹介しておきたい。
この発表は、利用を終了した（使ったあとの＝使後の）ドメイン名はどのように廃止するのが最適かを検討するために、保有した状態のドメイン名に対するDNSクエリおよびウェブアクセスを観測・調査した結果を整理し、報告したものである（図37）。発表者が何を考え、どのように環境を構築し、集まったデータを分析していく話は、真面目で興味深かった。
それらのドメイン名には前提があるとはいえ、MX RRがそんなに引かれるのかとか、最近の傾向からするとAAAA RRの割合がものすごく低いとか、分かった気になっていた筆者にとって、今回の発表内容は新鮮であった。現状で集めたデータだけでは最終的な結論に至らなかったということであるが、今後も試行錯誤を重ねながら、調査・分析を継続してほしいと思う。
最後に
今回のInternet Week 2024も昨年同様、会期後半の「カンファレンスWeek」はリアル会場のみで同時配信は行われなかったため、DNS DAYについても会場参加者のみが、その内容にリアルタイムで触れられたことになる。
記事では触れていないが、株式会社インターネットイニシアティブ（IIJ）の山口崇徳氏とNTTコミュニケーションズの末松慶文氏による「フルサービスリゾルバにおけるDNSブロッキング・フィルタリングの法的解釈と実施状況」は情報が良く整理されていて参考になったし、JPCERT/CCの中井尚子氏による「調整機関から見るドメイン空間で起きていることと対処について考える」も、DNS Abuse対応における実例として参考になった。
毎回書いていることではあるが、まとまった情報収集ができるという点でDNS DAYの存在はありがたい。この情報が欲しいと分かっていれば、インターネット上から探して拾ってくることはできる。ただ、それはあくまで対象が明確になっている場合にのみ有効な方法なのである。優秀なエンジニアの方々が整理してくれた情報が持つ価値は、とても大きいと思う。皆さまには、ぜひ参加をご検討いただきたい。