DNS屋さん目線で2023年を振り返る――「HTTPS RR」クエリ数が48％も増加、「ランダムサブドメイン攻撃」からの教訓など、今年の「DNS DAY」の話題から

　「Internet Week 2023」において11月21日、DNSに関する話題を集めたプログラム「DNS DAY」が開催された。本稿では、その盛り沢山の話題の中から、恒例となっているセッション「DNS Update」のほか、筆者が気になった話題をいくつか取り上げる。

「HTTPS RR」のクエリ数が前年に比べ48％も増加

　「DNS Update」最初の報告は、慶應義塾大学／WIDEプロジェクトの加藤朗氏による「Root DNS Update」である。加藤氏からは、Mルートサーバーの運用は順調であること、ほぼ全拠点がIPv6 Readyとなったことなどが報告された（図1）。ここではその中で、Mルートサーバーの統計情報において到着する問い合わせ（クエリ）のEDNS率が全体の84.7％（IPv4：83.4％、IPv6：91.0％）に達している点に注目したい。DNSのIPv6対応においてEDNSへの対応は必須であるが、IPv4においてもEDNSを使用したクエリが増えていることから、フルサービスリゾルバー（キャッシュDNSサーバー）においてEDNSへの対応が進み、いわゆる「DNS応答（レスポンス）における512バイトの壁」が事実上なくなってきている、ということが読み取れる[*1]。

図1　MルートサーバーにおけるEDNS率が書かれたスライド

　続いて、株式会社日本レジストリサービス（JPRS）の阿部信平氏による「JP DNS Update」では、jpゾーンを管理するJP DNSの状況に関する報告が行われた。JPドメイン名の登録数は増加傾向が続いており、JP DNSへのクエリ数の伸び率も増加している（図2、図3）一方で、総クエリ数に対するIPv6で到達したクエリ数の比率は減少したこと（図4）などが報告された。なお、JP DNSのクエリ数において2023年3月近辺に大きなスパイクがあるが、これは「Google Public DNSからの大量のクエリによるものである」とのことであった。

　また、阿部氏からは、JP DNSにおいて現在進めているDNSソフトウェアの多様性（ダイバーシティ）確保に向けた活動が紹介された。導入を予定しているのはBIND 9、NSD、Knot DNS の3種類[*2]で、来年中にはこれらのDNSソフトウェアで運用を開始し、次回のDNS DAYで報告したいとのことであった（図5、図6）。

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

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

図4　IPv6でトランスポートされたクエリの比率

図5　DNSソフトウェアダイバーシティの確保

図6　DNSソフトウェアダイバーシティの確保（2）

　一般社団法人日本ネットワークインフォメーションセンター（JPNIC）の小山祐司氏による「逆引きDNS Update」では、小山氏に代わり、JPNICの木村泰司氏から逆引きDNSにおけるlame delegationの改善に関する報告が行われた。

　lame delegationは、DNSにおいて委任先の権威DNSサーバーが委任されたゾーンの情報を適切に返さない状態を示す用語である。送信元IPアドレスの逆引きゾーンが名前解決できなくなると、メールサーバーに受け取りを拒否されたり、アクセス時の認証に支障が生じたりする可能性があるため、注意が必要である。ほぼ恒例となりつつあるが、図7に逆引きゾーンに占めるlame delegationの割合を、図8にJPNICでlame delegationであると判断する条件と対策を掲載しておく。

図7　逆引きゾーンに占めるlame delegationの割合

図8　JPNICでlame delegationであると判断する条件と対策

　NTTコミュニケーションズ株式会社の小坂良太氏による「フルサービスリゾルバー利用状況」では、OCNのフルサービスリゾルバーに到達するクエリとレスポンスを分析した結果が報告された。今回の注目点は、一昨年から去年にかけては1％程度の増加であったクエリ数が、今年1年は11％程度の増加を見たという点であろう（図9）。その増加は、主としてHTTPSリソースレコード（RR）によるものであり、ユーザークエリにおけるクエリタイプの割合（図10）でも、全体の20％に達している。

図9　ユーザーからのクエリ数

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

　こうした変化は、クエリタイプごとに集計された図11を見ると分かりやすい。A/AAAA RRのクエリは微増だが、HTTPS RRは前年に比べて48％も増えている。小坂氏からは、HTTPS RRを問い合わせる端末が増えたのではないかという見立てが示されたが、その通りであろう。

図11　ユーザーからのクエリ数（クエリタイプごとに集計）

　一方、HTTPS RRに対するクエリ数とANSWERセクションにHTTPS RRを含む、つまり権威DNSサーバー側でHTTPS RRが設定されていることを示すレスポンス数の調査結果では、クエリ数・レスポンス数はともにこの1年で大きく増加したものの、クエリ数に対するレスポンス数の比率は約5％程度にとどまっており、権威DNSサーバー側におけるHTTPS RRの設定率はまだ高くないことが見て取れる（図12、図13）。HTTPS RRの本格的な普及にはコンテンツ配信プロバイダーなど、サービス提供側におけるHTTPS RRへの対応が重要になりそうである。

図12　HTTPS RRのクエリ数およびレスポンス数

図13　HTTPS RRが設定されているドメイン名数（FQDN数） ※なお、スライドには「alpn =“h3,h3-29,h2”が多い印象」とあるが、この部分は別途公開される資料で修正されるとのことである。2022年はQUIC対応に合わせて付与したと考えられること、2023年はQUIC対応していなくても付与しているケースが増えていると考えられること、という点を反映させるということであろう。最終的な資料が必要な場合には、後日公開される資料をご覧いただきたい

　JPRSの高松百合氏による「DNS Update～ドメイン名全般～」では、gTLDを含むドメイン名全般に関する報告が行われた。gTLDの登録数については少し増えたが、特に目立った動きは見られなかったこと（図14～図16）、トップ10については10位に変動があり、「.xyz」に代わり、昨年の3月からセカンドレベルへの登録が始まったことで登録数が増えている「.au」（オーストラリア）が入ったことが説明された。

図14　全TLDでのドメイン名数

図15　登録数の多いTLD（グラフ）

図16　登録数の多いTLD（表）

　高松氏からは新gTLDの登録数について、相変わらず動きが読めないことが報告された。しかし、トップ10から落ちたとはいえ、「.xyz」は2012年の募集で登録された新gTLDにおける登録数では依然としてトップであり、トップ10のTLDが登録数の過半数を占めている点は変わらないことから、特筆すべき傾向の違いはなさそうである（図17、図18）。

図17　新gTLDの総登録数の推移

図18　新gTLD登録数の内訳

　現在進められている新gTLDの次回募集については、ICANN事務局は申請受付の開始までに、あと3年かかると見込んでいるとのことであった（図19）。

図19　新gTLD募集開始の見通し

　また、高松氏からはその他トピックスとして、レジストリやレジストラが登録情報を公開するプロトコルとして2015年に開発された「RDAP（Registration Data Access Protocol）」[*3]が紹介された。

　インターネットではドメイン名の登録情報を調べるための仕組みとして、WHOISが長年使われている。しかしながら、WHOISは1980年代に開発された古い仕組みであり、いくつかの問題点があることが指摘されてきた。それらの問題点を解決し、WHOISを置き換えるべく標準化されたのが、RDAPである。

　高松氏からはgTLDにおけるRDAPの取り扱いに関して、2023年8月7日にgTLDのレジストリ契約（RA）とレジストラ認定契約（RAA）が改訂[*4]され、RDAPの提供にも現在のWHOISと同等のSLAが定められるとともに、2025年1月28日以降はWHOISの提供が契約上の義務でなくなることが報告された（図20～図22）。

　RDAPはWHOISと同等以上のサービスを提供・利用可能であるため、今後も一般ユーザーが登録情報をウェブブラウザーで調べる際の違いはほとんどないと考えられる。しかし、登録情報をプログラムで調べる際のAPIをRDAPに対応させる必要があるため、関連するプログラマーや開発担当者は、RDAPに今から慣れておくのが良いだろう。

図20　WHOISの問題点とRDAPの標準化

図21　RDAPとは

図22　RDAPに関する動き

「HTTPS/SVCB RR」が特別対応を受け「RFC 9460」として発行

　JPRSの藤原和典氏による「IETF/RFC動向」では、IETFにおけるDNS関連WGの動向や話題に関する報告が行われた。今回は、その中から気になる話題をいくつか取り上げる。

　最初は、HTTPS/SVCB RRが特別対応を受け、2023年11月6日にRFC 9460[*5]として発行されたという話題である。HTTPS/SVCB RRがなかなかRFCにならなかったのは、しばらくRFCになる見込みのなかったドキュメント（draft-ietf-tls-esni[*6]）を参照していたからである。参照先がRFCにならないため、RFC Editorによる編集プロセス[*7]で「MISSREF（参照先欠落）」状態となっていた。

　しかし、8カ月も放置され、さすがにまずいと思ったのか、dnsop WGを担当するエリアディレクターが「提案をRFC EditorからWGに差し戻し、当該参照を外して標準化プロセスをやり直す」という特別対応を提案し、ドキュメントへの参照を削除したものを再提出するかたちで承認を受けるという、異例の措置が取られた。HTTPS RRはすでに利用が広がっていることもあり、ようやくといったところであろう。

　とはいえ、RFC 9460の中には「hintがあっても、TargetNameのA/AAAA RRは名前解決しろ（SHOULD）」と書かれている点はとても気になる。それでは、HTTPS RRが普及したとしてもA/AAAA RRのクエリは減らないことになるからだ（図23、図24）。会場からもその点に関する質問が出されたが、すでにRFCになってしまっているため、「そこを書き換えるためにはRFCをUpdateするなりしなければならないだろう」（藤原氏）ということであった。

図23　HTTPS/SVCB RRに対するIETFでの特別対応

図24　「hintがあっても、TargetNameのA/AAAA RRは名前解決しろ（SHOULD）」という記述のあるスライド（右下の赤字）

　次に、dprive（DNS Private Exchange）WGの現状で説明された、DNS通信をTLSで暗号化するという話題である。これまで、プライバシー保護の観点からスタブリゾルバーからフルサービスリゾルバー間のDNS通信の暗号化が進められてきたが、次のステップとして、フルサービスリゾルバーと権威DNSサーバー間のDNS通信の暗号化の必要性も挙げられていた。

　その概要については図25と図26を見ていただきたいが、現在の提案ではまずDoT/DoQ[*8]による暗号通信を試し、接続できなければ通常のDNSクエリを送るかたちになっている。そのため、権威DNSサーバーの管理者は今後、そのようなクエリが来ることを想定しておく必要がある。もちろん、「そのようなクエリには応答しないという自由もある」（藤原氏）ということでもあるが、DoTやDoQは将来的によく使われるプロトコルとなりそうなことから、正直悩ましいところであろう。

図25　DNSの通信をTLSで暗号化――dprive（DNS Private Exchange）WG

図26　dprive WG の現状（2023/11）

　DNSのIPv6トランスポートに関する運用ガイドラインの改訂（draft-momoka-dnsop-3901bis[*9]）の話題も重要である。東京大学の山本桃歌氏によるこの提案は、DNSサーバーはIPv4をサポートすべしとしていた、RFC 3901を改訂するための提案である。

　概要は図27を見ていただきたいが、IPv6の普及を進めるにあたっての制約となっているRFCを改訂するという点で、概ね好意的に受け入れられているということであった。会場からは、フルサービスリゾルバーの実体がdual stackでなければいけないのかといった質問が寄せられたが、この提案が言っているのはフルサービスリゾルバーと権威DNSサーバーの通信がdual stackであることを求めているのではということであった。結果的にDNSのサービスとして、IPv6とIPv4の双方をサポートすれば良いようである。

図27　RFC 3901を改訂するためのdraft-momoka-dnsop-3901bis

　また、今後どのような進展があるか不明ではあるが、IETF 118 Hackathon発の提案として、委任情報をまとめて記述する「DELEG RR」に関する議論があったという話題には興味をそそられた。現在のDNSではNS RRとグルーレコードを使って委任情報を記述し、DS RRを使ってDNSSECの信頼情報を記述しているが、それらを一本化し、かつ新機能の追加や複数のDNSプロバイダーの利用も容易にするための新しいRRを導入することが提案されたという話である（図28）。

図28　IETF 118 HackathonにおけるDELEG RR提案

　委任情報の取り扱いについては、このDNS DAYの直前に行われたJPRSのランチセミナー「グルーレコードについて改めて考える ～ランチのおともにDNS～」において、DNSにおける委任／グルーレコードの運用のあり方に関する話題が提供されている。今回の提案が今後どのようになるのか、藤原氏によれば「おそらく実装までは行かないだろう」ということだが、議論は継続されているとのことであるから注目しておきたい話題の1つである。

一部の「ランダムサブドメイン攻撃」は攻撃目的ではない可能性も

　興味深かったということで、NTTコミュニケーションズ株式会社の神田敦氏、坪井祐一氏、飛岡良明氏、畑田充弘氏の4名による「ランダムサブドメイン攻撃において事業者として行なった対策と解析について」も簡単に取り上げたいと思う。

　この発表は、今年話題になったランダムサブドメインによる大量アクセスについて、研究やサービス提供などさまざまな観点から調査した結果であるという。方法としては、他者に迷惑をかけないよう一定の対策を施したうえでオープンリゾルバーとなるハニーポットを仕掛け、そこに来るクエリを観測するというものだ（図29～図32）。

図29　本セッションの目的・狙い

図30　日本×ランダムサブドメイン攻撃

図31　観測された大量アクセスの特徴

図32　まとめ：ハニーポット観測から見えたもの

　詳細については一定期間後に一般公開される資料を見ていただくしかないのだが、この調査の結果、大量のクエリを使った攻撃（DoS）に見えたものは「実は攻撃目的ではないのかもしれない」という知見が得られたというのは新しいかもしれない（図33、図34）。

図33　大量アクセスを観測した経験から

図34　今回のまとめ

　とはいえ、現実的に見ればクエリを出した側に攻撃の意図は無くとも、実際に大量のクエリが届いた側からすれば攻撃と等価である。数字的には驚きの値が出ているが、本質的な問題は、権威DNSサーバーの処理能力を設計する際に予想アクセス数の数倍を最大と想定するのではなく、100倍とか桁を変えて見積もらないといけないということであろう。小規模なDNSサービス事業者やDNS運用者にはきつい話のように感じるが、それが現実ではないだろうか。

「使い終わったドメイン名」のトラブル事例が減らない理由

　最後に、日本DNSオペレーターズグループの石田慶樹氏と岡田雅之氏による「基礎から考えるドメイン名ライフサイクルマネジメント」を取り上げる。

　近年、ドメイン名ライフサイクルマネジメントの話題が続くのは、実際にそれを考えずにドメイン名を使った結果、トラブルとなるケースが後を絶たないからだ。石田氏と岡田氏も、これまで10年近くドメイン名を扱う際の注意事項としてドメイン名ライフサイクルマネジメントを啓発してきたのに、なかなかトラブルが減らないことに落胆しているという。最近ではNHKのニュースでドメイン名の利用に関する特集が放映されたり[*10]、関係者の間で大きな話題になっていたりもしているのだが、筆者の感覚的にも、目に見える事例はむしろ増えているように感じる。

　かく言う筆者もことあるごとに記事化している[*11]わけだが、結局の所、本当にそれが“必要な人々”に届いていないということなのだろう。今後の課題は、まさにそこにあるということである。

　発表の中で出てきた話だが、問題が起きた先の担当者にレクチャーをしたところ、その担当者から「ドメイン名は契約を切れば使えなくなるから大丈夫ですよ」と言われたというのは、その典型である。つまり、「使い終わったドメイン名は使えなくなるのではなく、実は誰でも使えるようになる」ということを理解できていないのである。その点で、図35にあるスライドの絵そのものではないだろうか。ドメイン名の管理をきちんと行わないと、図36に描かれているようなリスクがあるということを多くの方に理解してほしい。

図35　廃止した（つもりの）ドメイン名の行方

図36　ドメイン名のライフサイクルとリスク

　今回使われた資料は一定期間が経過した後に公開されるのでそちらを読んでもらえるよう、関係しそうな人々への周知に読者の皆さまのご協力をいただきたいと考えるが、いかがだろうか。

最後に

　DNS DAYのプログラム終了後、「DNSOPS.JP BoF」が同じ会場を使って開催された。内容的に濃いものが多かった印象だが、筆者個人としては楽しめた。使われた資料はすでに公開されているので、参照してみてはいかがだろうか[*12]。

　今回のInternet Week 2023は、前半3日間はオンライン開催、後半3日間はオンサイト開催のみで生のオンライン配信は行われないという構成のため、DNS DAYには現地参加者のみがその内容に触れることができたことになる。その点には賛否両論があるだろうが、さまざまな事情というのもあるのであろう。

　余談めくが、NTTコミュニケーションズの坪井氏が「ランダムサブドメイン攻撃において事業者として行なった対策と解析について」の続編として「サブドメイン列挙とはどういうものなのか調べてみた」というものを自社ブログに書いたそうである[*13]。ご興味のある方はご覧いただきたい。

　毎回同じようなことを言うが、情報収集先としてInternet Weekは優れていると感じる。整理された情報がまとめて手に入るのはありがたいし、会場にいれば担当者に質問を投げ掛けることも容易である。皆さまにはぜひ次回の参加をご検討いただきたい。