「RPKI」「DNSSEC」「DMARC」のガイドライン策定に込められた思い、内容のポイントとは 作成した有識者らが解説：「少しでもハードルを下げたい」 官民連携の取り組み（3/4 ページ）

[高橋睦美，＠IT]

印刷

鬯ｮ�ｫ驕ｨ繧托ｽｽ�ｹ隴趣ｽ｢�ｽ�ｽ�ｽ�ｽPost

Shareシェア

はてなブックマーク

SharePocket Button

意思決定者含め、多数のステークホルダーに向けた内容を含んだDNSSECガイドライン

インターネットイニシアティブ／DNSOPS.JP 其田 学氏

　続けて、インターネットイニシアティブ（IIJ）で長年DNSの運用に携わってきた経験を持ち、日本DNSオペレーターズグループ（DNSOPS.JP）で活動する其田 学氏が、DNSSECガイドラインを説明した。

　DNSSECは、DNSのゾーンデータに電子署名を行い、それを受け取ったキャッシュDNSサーバなどのリゾルバ側で署名を検証することで、DNSのデータが改ざんされていないかどうかを確認できるようにする仕組みだ。署名側と検証側、2つのプレイヤーがそれぞれで対応しなければならない上に、検証の際には上位ゾーンの「トラストアンカー」を設定する必要があり、関連するプレイヤーが多くなることが特徴だ。

　DNSSEC自体は以前から存在する技術だが、署名側の対応率は2022年ごろから急速に伸び始めた。特に対応が進んでいるのは、政府関連と金融といった分野で、日本の銀行では全体の20％を超えるドメインが署名されている。

DNSSECの署名普及率の推移（其田氏の講演資料より）

　一方、検証側の対応はまだまだだ。APNICの調査によると、2024年11月の時点での対応率は、端末ベースで13％を超える程度となっている。「銀行のように、多数の国民が利用しているサービスも署名に対応しているため、国民の多くがDNSSEC署名の恩恵に預かれる状態にあるはずです。しかし検証側がほとんど対応していないので、多くはまだDNSSECで守られていない状態が続いています」（其田氏）

DNSSECガイドライン案（PDF）より

　署名側が対応していないから、検証側は対応したくない、逆に検証側は署名側が対応していないから対応したくない……という、鶏が先か卵が先かのような状態がここ10年続いてきた。だが、2022年ごろからようやく変化の兆しが見え始めてきたという。

　こうした中で、DNSSEC対応をするための考え方をまとめたDNSSECガイドライン案の策定が進んでいる。まだ正式に発行されておらず、総務省のICTサイバーセキュリティ政策分科会第5回で案が提示されている段階だが、いずれは何らかの組織によって発行、管理される予定だ。

　其田氏は先に説明した通り、DNSSEC自体、多くのプレイヤーに関連する技術であることから、DNSSECのガイドライン案も5章構成、全68ページに上る、やや大部の資料となっている。

　全ての人を対象とした序章、第1章の他、フルリゾルバ、権威DNSサーバ、そしてドメイン名登録／登録管理関係者という具合に、想定読者ごとに章を分けて執筆されている。

ガイドラインの想定読者（其田氏の講演資料より）

　「特に全ての人に読んでほしいのが、序章と第1章だ」と其田氏は述べた。

　「第1章は、エグゼクティブサマリー的な内容です。DNSSECは、特に署名側に関しては多くの対応工数がかかるため、意思決定者の協力がなければ導入できないと思います。ぜひこの部分を意思決定者に共有していただきたいと思います」（其田氏）

　第1章では、「ドメイン名はもはや知的財産である」としてドメイン名の重要性を説くとともに、なぜDNSSECが必要なのかについても説明している。

　「ドメイン名は、インターネット上における組織のアイデンティティーのようなものとなっており、組織の価値とドメイン名の価値が密接にリンクするような状態になっています。DNSのデータが改ざんされて偽サイトに誘導されたりするといったドメイン名にまつわるインシデントが発生してしまうと、顧客からの信頼を失い、組織の価値の毀損（きそん）につながります」（其田氏）

　その意味で、レイヤーはちょっと異なるが、Fromアドレスを詐称した迷惑メールを防ぐ送信ドメイン名認証と同様に、「自組織のドメイン名を語った攻撃を防ぎ、ドメイン名の価値を守ることが、DNSSECの目的です」と同氏は述べた。

　こうした観点から、ガイドラインはドメイン名のライフサイクルマネジメントについても言及している。「そもそもドメイン名は『購入』できないものであり、再登録すれば他の人が使えてしまう仕組みです。登録時には、そもそもそのドメイン名が本当に必要なのかどうかを検討すべきですし、登録した場合は、その維持管理を考える必要があります」という。

　第3章では、権威DNSサーバのDNSSEC対応を解説している。其田氏は「全て押さえておかなければいけないポイントです」と述べた。中でも特に、DNSSECで利用する2つの鍵のうちKSK（Key Signing Key：鍵署名鍵）にロールオーバーで変更が発生する際には、DSレコードの登録情報も変更する必要があることに言及し、「どのタイミングでKSKロールオーバーが発生するのか、そして、誰がDSレコードの登録情報を更新するかを明確にしておかないと、事故が起こる可能性があります」とした。

　第4章では、ドメイン名登録者と登録管理関係者向けに、前述のDSレコードの扱いを解説している。「せっかくゾーンに署名していても、DSレコードが存在していないと署名検証がなされないことになります」（其田氏）。従って、子ゾーンの扱いや、権威DNSサーバを引っ越す際の手順を適切に行わなければ、「DSレコードはあるけれど未署名」という状況が発生し、署名検証エラーとなるため注意する必要があるとした。

　そして、同氏が執筆に協力した第2章では、フルリゾルバのDNSSEC対応を説明している。署名検証の流れを説明するとともに、フルリゾルバでDNSSEC対応を進めるためにどのような対応や確認が必要なのかを、3段階の対応レベルに分けて解説している。

　注目したいのは、署名検証に失敗したとき、特にユーザー影響が生じてしまったときにどうすべきか言及していることだ。「正直、フルリゾルバの設定自体は難しいものではありません。皆さんが心配されるのは、検証失敗時にどうするかです」（其田氏）

　特定のドメイン名についてのみ検証を無効化する「ネガティブトラストアンカー」という機能も用意されているが、其田氏は、一番まずいケースは、検証エラーによりユーザーがWebサイトにアクセスできなくなることではなく、DNSSEC検証を無効化した結果、ユーザーが偽の応答を受け取ってしまうことだろうと述べた。「守られているはずのものが守れていなければ、ユーザーの信頼を裏切る行為になってしまいます」（其田氏）。そして、確信が持てない限りはDNSSEC検証の無効化は避けるべきだとし、「一番大事なのは、『署名検証が返ることが正しい』という認識を組織内に浸透させることです」と呼び掛けた。

　こうしたケースも考慮し、DNSSECガイドラインには検証失敗時の対応がレベルごとに示されている。レベル1では「署名側で復旧を待つ」こととなるが、レベル2ではステークホルダーに説明できる状態にするためにDNSSECの検証状況をモニタリングすること、そしてレベル3では復旧に向けた適切な対応を取ることを求め、それぞれ設定方法を紹介している。

　こうした多岐にわたる内容がまとめられており、読み込むのもなかなか大変なDNSSECガイドラインだが、まずは「ぜひエグゼクティブサマリーを読み、意思決定層に展開してください」と其田氏は述べている。