近年のDNSはプロトコル拡張が活発すぎる!?　現時点で意識しておくべきリソースレコードとは

6月に開催されたカンファレンス「DNS Summer Day 2022」。同カンファレンスのレポートは別記事『ドメイン名をドロップキャッチされた！ そのとき当事者は――長崎県立大学学生自治会が経緯と実情を語る』もぜひ参照してほしい

　近年のDNS（ドメインネームシステム）では、リソースレコード（RR）の追加を含むプロトコルの拡張が活発に行われており、その全貌を正しく知ることは容易ではない。そして、そのようなDNSの変化を知らずに企業・組織がドメイン名を使用し続けることにはリスクが伴うという。また、ドメイン名をめぐるリスクとしては、廃止したつもりのドメイン名が悪用される「ドロップキャッチ」「パーキング」といった問題もあり、ドメイン名のライフサイクルマネジメント（LCM）の重要性が指摘されるようになった。

　本稿では、日本DNSオペレーターズグループ（DNSOPS.JP）が6月に開催したカンファレンス「DNS Summer Day 2022」の中から、「ドメイン名のつかいかた」および「権威DNSサービス調査報告」という2つの講演で語られた内容をベースに、講演者および主催者関係者に追加取材。ドメイン名を使う企業・組織ならば知っておくべきDNSの最新事情を取りまとめた。

　なお、DNS Summer Dayは、2012年より始められたDNSに関する公開イベントである。主催するDNSOPS.JPは、DNSの運用を通して、社会基盤となったインターネットの安定運用に寄与することを目的とした任意団体として2006年に設立された。これまでのDNS Summer Dayは、DNS運用者向けの発表が目立っていたが、最近ではドメイン名のLCMの重要性のようにドメイン名そのものの管理・運用に焦点を当てた発表が目立つようになっている。この変化は、DNS関連の運用者を中心としたものから、ドメイン名を登録して使用する人々についてもそのターゲットに含めてきているからであろう。今回、その点も含めて、ドメイン名の管理・運用にまつわる発表に焦点を当てて取材を行った。

不安を抱えたままDNSを運用していませんか？問われているリスクマネジメント

　DNSOPS.JPの方々との話で特に興味深かったのは、「DNSの安定運用のために、取り組むべき対象を広げている」という点である。その背景には、インターネットサービスの多様化に伴って起きたDNSの変化があった。

　DNSは、ドメイン名に関する情報を提供するための汎用データベースとしての役割を持つ。よく知られているのは、IPアドレスやメールサーバーの検索であろう。しかしながら、近年のDNSではリソースレコード（RR）の追加を含むプロトコルの拡張が活発に行われており、その全貌を正しく知ることは容易ではない[*1]。

　そのような状況下において、ドメイン名を登録してサービスを提供している組織が、DNSについて安易な運用を行っていたとしよう。その場合には、世の中のニーズについていけなくなる可能性が高いばかりでなく、そのドメイン名の名前解決に支障が出る可能性すら出てくることになる。

　例えば、ドメイン名のDNSを任せている組織がこの先、CDNサービスを利用するときにHTTPS RR[*2]の設定が正しく行えるか、DNSを使ったドメイン名の認証が求められるときにACME dns-01認証[*3]を正しく扱えるか――といったことを考えてみていただきたい。できればいいが、できなければ、その部分については期待される結果が伴わないかもしれないのである。

　一般に、ドメイン名を使用して顧客にサービスを提供する仕組みを作る際、その責任を負う人々は、多くの場合で企画部門、または、それに類する部門の所属である。しかしながら、そのような人々の多くが持つDNSに対する要求は、「自分自身が使用するドメイン名の名前解決さえできればいい」という程度なのではないだろうか。現状では、サービスを行うサーバーのスペックを気にするようにDNSのスペックを気にする人々は希なのである。

　DNSは、現在のインターネットにおいて顧客を自分のサーバーに誘導するために必須の機能である。したがって、顧客が常に利用可能な状態になっているべきミッションクリティカルなドメイン名の運用において、DNSによる名前解決が途切れてしまうような事態は絶対に避けなければいけない。そのためには、DNSに対する正しい理解だけでなく、OSやDNSソフトウェアに対する適切なパッチの適用やネットワークの帯域確保、DDoS対策、サーバーの分散配置、定常的な監視とレポーティングといった運用は必須である。これらのことを“先人が残したマニュアル”をベースにDNSサーバーを運用しているだけの組織や、“一人情シス”であらゆることを行っている組織にできるとは思えないだろう。

　DNSを安定運用するための底上げとして、DNS関連技術者に対する情報提供は重要だが、それと同じくらい、ドメイン名を登録して使用する人々により良いDNS環境に関する情報を提供することを重要視するようになったということである。筆者が考えても、下手なDNS運用をするぐらいなら、専門の事業者が提供するマネージド権威DNSサービスを利用するほうが賢明だと思う。

　取材をしていて感じたことは、問われているのはリスクマネジメントであり、インターネットを利用してサービスを提供する側がそのことをどれだけ意識しているかという点である。誤解を恐れずに言えば、ミッションクリティカルなサービスを、何らかであっても不安を抱えたまま動かして大丈夫ですか、責任を持てますか――という問い掛けでもあると言えるだろう。

新たなドメイン名が本当に必要ですか？廃止後も見据えたライフサイクルマネジメントを

　次に、ドメイン名におけるLCMの重要性について、日本DNSオペレーターズグループ代表幹事の石田慶樹氏の話をまとめる。石田氏は、コンテンツ停止後のドメイン名の取り扱い（廃止や移転）について注視し、ドメイン名の当事者が意図しない利用がなされる（ドロップキャッチ、パーキング）リスクについて、実例をもとに啓発活動を6年ほど行ってきたそうである[*4]。

　まずは基本的な話として、ドメイン名そのものは登録した段階で、登録した組織（企業）における知的財産の一部となる。組織名であったり、ブランド名であったり、商品名やサービス、イベント名であったりした場合はなおさらであろう。そのようになるのは、その名前が誰かにとって価値があるからである。

　しかしながら現実を見ると、ドメイン名を登録するときにはあれこれ考えるのに、いざ使わないと決めたらあっさりと捨ててしまう、または、その維持に無頓着になり、ドメイン名の更新を忘れて失効してしまうというケースが散見される。ドメイン名に関する問題の多くが、このようなケースを起点に発生している。

　ここで考えなければいけないのは、そのサービス（コンテンツ）のために新たなドメイン名が本当に必要かという問いは十分に行われているであろうかという点である。本当に必要だという認識が薄いと、前述したような問題が起きやすい。だからこそ、本当に必要かという問い掛けが重要になるのである（図1～図3）。

図1：ドメイン名の登録

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

図3：ドメイン名のライフサイクルと発生するリスク

　また、近年ではシステム連携のためのAPIで利用することを目的としたドメイン名が使われていて、そのドメイン名が狙われるということが出てきているようである。ここでは詳細を説明しないが、例えば、あるドメイン名をCDNに振り向けるためにCDN事業者から発行されるCNAME先などはその1つの例である。石田氏はこの点について、「ドメイン名が人間にとって分かりやすいものである必要がなくなった」「その点が、悪性サイトの立ち上げを試みる人たちにも利用されている」とし、この方面にも注意が必要であることを述べている。

　悩ましいのは、「悪性サイトについて、特定のレジストラがあたかも加担しているとでも言えるような状況も目立ち始めている」という点だろう。加えて、「そのようなレジストラとホスティング事業者とCDNがお互いに責任をたらい回しにして、悪性サイトによる被害の拡大に手を貸すような事態が発生している」という状況があるという。そのような状態があるということになると、そのドメイン名を登録するにあたってどのレジストラと契約するのが適切かという検討も必要になるのではないだろうか。

　ドメイン名を利用することが当たり前になり、簡単にドメイン名の登録ができるようなシステムが整備された結果、ドメイン名の登録という重要な話をついついお手軽に考えてしまうようになっている。自分自身が痛い目に遭わないようにするためにも、あらためてドメイン名におけるLCMを考えてみてはいかがだろう。

意識すべきDNSリソースレコードの「MUST」と「MAY」～権威DNSサービスの選定ポイントに

　続いて、「ドメイン名のつかいかた」を発表した株式会社インターネットイニシアティブ（IIJ）の其田学氏、「権威DNSサービス調査報告」を発表した長崎県立大学の岡田雅之氏と日本DNSオペレーターズグループ幹事の米谷嘉朗氏の話をまとめる。

　「ドメイン名のつかいかた」は、ドメイン名登録者が意識し、知っておくべき基本的な知識を発表者目線で紹介したものだ[*5]。もう1つの「権威DNSサービス調査報告」は、組織が目的に沿って適切な権威DNS（自ゾーン）を運用可能とするために、国内外で提供されている代表的な権威DNSサービスの機能を一覧できるようにする活動の紹介である。

　最初に述べてしまうと、この2つの発表は別々のものとして行われたが、ドメイン名登録者の立場であれば、この2つの内容を関連させて見ていくのがいい。今後の展開を見ていく必要はあるが、「ドメイン名のつかいかた」でこれから必要になるDNSのRRを知り、そのRRをサポートする権威DNSサービスはどこが提供しているかを「権威DNSサービス仕様調査」[*6]で確認することで、今後の運用をある程度イメージすることができるようになることが期待できるからだ。

　例えば、図4を見ていただきたい。これは、公開されている「ドメイン名のつかいかた」の15ページ目であるが、どのようなRRを現時点で意識すべきかを「MUST」と「MAY」というかたちで記述している。MUSTは必須とされるRRであり、MAYとなっているTLSA、SVCB、HTTPSの各RR[*7]がこれから重要になってくると解釈すればよい。余談めくが、其田氏になぜ「MAY（してもよい）」[*8]にしたのかを尋ねたときの返答が「まだまだHTTPS RRとかSVCB RRを設定する機会は多くなく、SHOULDにすると強すぎるから」であった。

図4：権威DNSサービスを選ぶにおいて重要になる点

　次に、公開されている「権威DNSサービス仕様調査」の「（5）RR」の項目を確認すると、当該RRについては大手サービスであっても意外と利用不可（N/A：Not Available）が多いことが分かる。ここから言えることは、将来的にHTTPS RRを使いたいのであれば当該欄が「○」であるか、対応予定があるサービスを選ぶ必要があるということである。

　ドメイン名登録者としては、自分がそのドメイン名で行うサービスを念頭に置き、そのサービスが顧客に対して円滑に提供できるかが重要になる。そのときに、自組織が行っているDNS運用、もしくは現状で契約しているDNSサービスで対応できるのかということも含めて考えなくてはいけない。この部分は、人任せにすると失敗の芽が出る可能性が大きくなるからだ。

　今後の課題としては、あるサービスを実行したい場合にはどのRRが必要になるのか、そのRRはそのサービスにとってどのような意味を持つのかをDNSの初学者にも分かりやすく説明することであろう。DNSOPS.JPとしてもそのあたりは意識していて、検討中であるということである。

ますます重要性を増すDNSは仕様も複雑に。リスクマネジメントのためにも情報収集が不可欠

　冒頭で「近年のDNSではRRの追加を含むプロトコルの拡張が活発に行われており、その全貌を正しく知ることは容易ではない」と書いたが、筆者自身もそのことを強く実感している。

　例示しやすいのでここでも使うが、例えばHTTPS RRはCDNサービスを利用・提供する際に必須のRRになるはずである。しかしながら、そのためにはウェブブラウザーや専用アプリなどのクライアント側がHTTPS RRに対応しなければならない。クライアント側の対応が行われない状態で従来の設定、すなわちA/AAAA RRを削除した場合、HTTPS RRに未対応のクライアントはウェブサービスを利用できなくなってしまうという問題が起こってしまう[*9]。

　要は、そのRRが何をするものかだけではなく、どのような状況で有効になるのか、ネガティブは無いのか、あるとしたらどのようなものかまで含めて認識しなければいけないということである。表面的な仕様だけを見て何かをすることもリスクを伴ってしまう。

　先にリスクマネジメントの重要性を述べたが、それを確実に実行する際に重要なのは情報収集と理解であり、そのためには専門知識がある人材の確保か、優れたサービス事業者との連携が必要になる。そのためにも、DNS Summer Dayや、Internet Weekの「DNS DAY」や「日本DNSオペレーターズグループBoF」のようなイベント[*10]を活用したり、DNSOPS.JPが発信する情報を確認したりすることをお勧めしたい。

　インターネットが発展し、社会的にその重要性を増すことで、特にセキュリティ関連で積極的な対応を求められるようになった。DNSの仕様が複雑になるのは、相手との接続をより安全かつ確実に行うための起点となるからである。DNSは、これからますます重要になるであろう。