総務省実証実験：DNSSECに参加してみた
こんにちは、エンジニア2号です。
コラム第2回です。
今回は2022年末から2023年初めと、2023年7月から現在も引き続き行われている総務省実証実験に「実証者」という立場で参加したときのことを書いていこうと思います。参加レポートです。
正しい内容を事実に基づいて書くつもりですが、あくまでコラムなので難しいことや細かいところまでは追求せず、実証実験に参加したことで経験したことや、得たこと、感想をメインにするつもりです。
また、あまり細かく書くと「厳密には違う」が発生するので 技術者でない方の読みやすさを考慮して、大まかな書き方をする部分もあるかと思います。
率直に言います。何卒お手柔らかにお願い申し上げます。
はじめに
実証実験の正式名称は
「ISP におけるネットワークセキュリティ技術の導入に関する調査の請負」
です。ググると総務省のページなどがヒットするかと思います。
要するに、インターネットをより安全に使えるようになるために、ISPのみなさんにはまだあまり普及していない認証技術を実際にさわってもらって、導入の手助けにしてください、というイメージで大丈夫だと思います。自分がそうです。
今回はRPKI、DNSSEC、DMARCという3つの技術を実際に検証環境や自社環境へ導入して構築・運用をしてみよう、という事業でした。
その中で、自分は二つ目のDNSSECを担当しました。
DNSSECにおいては自社環境だけでなく、DNSSECを検証するための環境も借りることができ、主にはそちらで一緒に渡された手順（マテリアル）に沿って導入や管理を実際にやってみました。
自分はここ数年ちょっとずつエンジニアになりかけ始めたタイプの生き物で、DNSは基礎を勉強している途中でした。
その先の技術にはまだ手が届いていなかったため、今回本案件に参加できたことは、自分の知識・技術の向上という意味でとても良い機会となりました。
実証実験について
本実証実験は、以下の流れで行われました。
今回の実証実験についての説明
実証実験実作業
実作業のハンズオン
実証実験結果をレポートにまとめ、提出
立案者と有識者、参加者による情報交換会
そもそもDNSSECとは？
略さずに書くと
DNSSEC = DNS SECurity Extensions
DNSにセキュリティ系の拡張子をつける、という意味だそうです。
DNSSECがない状態だと、問い合わせへの返答がどこから来ていて、情報に問題がないかどうかを確かめるすべがありません。
DNSはドメインの情報を持っている大元のサーバだけでなく、一度問い合わせをした情報を一時的に保存するサーバ（キャッシュサーバ）が代わりに返答を返すことで問い合わせの時間や不可を抑える仕組みがあるのですが、本来の情報とは異なる行先をそのサーバに不正に登録されてしまうと、URLは正しいのに、異なるサイトにつながってしまう、といったリスクがあります。
DNSの情報に電子署名をつけることで、
署名をした人が作成したDNS情報であること
情報に改ざんや欠落がないこと
を検証できるようにした、DNSの仕組みに則りつつそこに新たな機能を追加した「拡張仕様」なのだそうです。
情報に署名が付けられれば、署名がない情報と差別化ができ、怪しい情報を検知できるようになります。情報そのものが暗号化されるわけではなく、情報に署名がついていることでクライアント側、つまり応答を受け取る側が情報を精査でき、不正な情報を弾くことができます。
不正な情報を弾くことができると、偽サイトにつながるのを阻止できます。
実証実験の話に戻ります。
DNSSEC実証実験 実作業
実証実験では実際にDNSSECを取り入れてみて、それを運用していくためのノウハウを実際に試してみました。
簡単なDNSSEC導入手順
DNSSECは、おおむね以下の手順で導入します。
DNS情報につける鍵を公開鍵・秘密鍵というペアの形で作成
1で作成した鍵と、外からの問い合わせ用の鍵を公開鍵・秘密鍵というペアの形で作成
1と2の鍵の情報をDNS情報に署名という形で紐づけ
DNS情報の中に、1の鍵と2の鍵を使うことを追記
ドメインと2の公開鍵が正しいことを保証するためのデータを作成、それを上位組織（iprio.jpであればjpを管理している組織）に登録を依頼
DNS情報を置いているDNSサーバをリロードし情報を反映
サーバ外から名前解決ができることを確認でき、かつDNSSECが入っていることが分かる返答が確認できれば導入完了です。
1.で作成した鍵のことをZSK（Zone Signing Key）
2. で作成した鍵のことをKSK（Key Signing Key）
5. で作成したデータのことをDSリソースレコード（Delegation Signer Resource Record）
と言います。
覚えたくなければ「1の鍵」「2の鍵」「5の鍵」でいいです。
これで、DNSデータに署名鍵をつけることができました。
ですが、SSL証明書なんかもそうであるように、同じものをずっと使い続けるのはセキュリティ的な意味で安全ではないです。セキュアではない、とか言いますね。
ですので、定期的に交換します。
一般的に、それぞれの鍵は同じタイミングで交換するのではなく、1の鍵は短い周期で、2の鍵は比較的長い周期で交換します。。
2の鍵を交換したら、5の鍵も交換する必要があるので、別途作成し上位にも登録してもらいます。
実証実験にて用意していただいた検証環境用の作業手順では、
1の鍵：3ヶ月毎
2と5の鍵：1年毎
の交換を推奨していました。
表にするとこうなります。
（以降も同じペースで更新する）
概要はつかみやすいかもしれませんが、手順が多く、かつ鍵ファイルは似たような名前で生成されるため、実際にDNSSECの鍵の更新・管理を手動で管理するのはとても大変です。
よほどマメな方でもないといつか事故ります。ググってみると「絶対に事故るから手作業で管理してはいけない」と断言されていたりもします。
しかも、署名に失敗するとDNSSECが無効になるだけでなく、ドメインそのものが外から見えなくなります。そのドメインを利用しているメール、webサイト等が全て使えなくなるということです。ヤバイですね。
DNSSECを実際に運用する上でどんな点が大変かというと
用意するファイルが多い
鍵ファイルの名前を指定できず、別で表を作るなどしないと管理が難しい。
コマンドを入力する際、指定する必要のある項目が多く、オプションとしてつけられるものも含めるとさらに長くなる。
ドメインとドメインのファイル名や、公開する日付と非公開にする日付など、コマンドで指定する項目に同じような文字列が多く、間違えやすい。
というように、全くテクニカルではないことをたくさん管理する必要があり、無駄に大変です。
では、DNSSECを導入する現実的なやり方はどうしたらいいでしょうか？
そこが本実証実験において各事業者が考えるポイントであり、かつこれまで多くのエンジニアが試行錯誤してきた部分でもあると思います。そちらは最後にまた触れていきます。
実作業後に考えたこと
実際にDNSSECの導入や運用を行い、また意見を交換する場に参加したことで、DNSSECについて知り、検討する良い機会になりました。
また、本実証実験の狙いについてお話を聞く機会もありました。
本実証実験は、最後に取り組んだ結果をまとめたレポートを提出して完了となります。
レポートに書いたこと
レポートで聞かれたことは主に
導入検討のきっかけ
行った検証とその環境
得られたこと
ガイドラインや手順書に載せるべきだと思うこと
です。
マテリアルを検証が可能な環境内で一通り行ったことや、DNSSECを手動で構築・運用することはとても手間がかかり、かつ間違えやすいのだということを実感した旨を、丹精込めて書き残しました。
また、実際に導入することを考えると、ガイドラインや手順書には手動管理による方法ではなく、すでにある自動的に管理するサービスや仕組みとその構築方法を紹介した方がいい、ということも書きました。
有識者検討会と情報交換会
本実証実験では、定期的にオンラインでのミーティングが行われました。
DNSの技術を専門的に取り扱っている技術者の方や大学の先生方による知見と、実際にサービスを提供、もしくはそのサポートを行っている事業者目線での所感や意見をもとに、DNSSECを広く導入してもらうためのガイドラインを作成するためにはどうすべきかが定期的に検討されていました。
DNSSECの導入を進めるのが困難である点は、作業の煩雑さだけではありません。
DNSSECを導入することで得られる成果は
「経路が汚染されたとき、不正サイトへのアクセスを防いでくれる」
だけで、
「正しいサイトに誘導してくれる」
ということではないため、成果が見えにくく、かつかかる手間やリスクのことを考慮すると、事業者目線では魅力的に映らないことが懸念されていました。
サーバを管理する側としては、避けられるセキュリティリスクは避けるべきですが、予算や規模の大小に関係なく「割に合わない仕組み」を導入を断るのは、事業者としては当然のことです。
実際、DNSSECによって対策できる攻撃「キャッシュ・ポイズニング」はいわゆる古典的な攻撃手法で、昨今では様々な対策がクライアント環境など、DNS以外の範囲において標準的に搭載されており、実際に行われた大規模な事件として挙がるものは20年以上前になってしまいます。
悪質なサイトへのリダイレクトは今でも報告がありますが、主に別の要因であるか、原因を特定できないことがほとんどです。
ただ、古くから知られている攻撃である以上、対策を全く行わなくていいわけではありません。
導入するのであれば、仕組みを正しく理解した上で、リスクを回避した上で最小限の工数で導入したいところです。
そのためには有識者だけではなく、事業者目線の意見も大いに有用で、また様々な視点からの意見や要望を聞くことができたので、個人的にもためになりました。
同時に、自分だったらお客さんにどう提案するか、どう取り入れてもらえるかを考える機会にもなりました。
本実証実証実験における目的と、立案者のねらい
レポートを提出し終わった頃、立案者側の方とお話する機会がありました。
お話を伺っていると、どうやら今回の実証実験において一番の目的は「いかに国内の各事業者においてDNSSECを導入してもらえるか」とは少し異なるようでした。
あくまで狙いは
「国内のインターネット環境のセキュリティレベルの向上」
であり、その上でDNSSECは有用であるかどうかを、有識者だけでなく国内の多くのネットワーク事業者がDNSSECを
「導入・運用検証をしてみる。運用の仕方を検討し、導入可能かどうかを現実的に考える」
ということを行ったという事実・実績が目的だったそうです。
総務省と専門家だけで知見を集め、DNSSECの有用性を検討して終わるところだった実証実験が、一般事業者を広く集め、経営者目線で導入の可否を検討し、その結論をレポートとして収集できたことで、最終的に納める資料や作成されるガイドライン・導入手順書に説得力があり、事業者の認識レベルやセキュリティ意識の向上にもアプローチできた、ということが大事なのだそうです。
で、結局DNSSECはどうしたらいいのか？
個人的な一意見としては「便利なツールを使って導入する」のが良いと思っています。
DNSSECをより安全に、手間なく導入する方法は長年検証され続けていて、knotDNSというOSSでは、最初に運用ポリシーなどを設定するだけで、鍵の作成、署名、更新を自動で行ってくれるため、管理者は定期的に上位に登録する5の鍵を更新するだけでよくなります。
2の鍵の有効期限を無期限にすると、その必要もなくなりますし、ドメインによっては5の鍵情報を自動更新してくれる仕組みもあるようです。
もちろん、DNSSECがどんな仕組みで、使用するツールの中ではそれがどんなやり方で管理されているのかを把握する必要はあると思います。
その観点からすると、OSSを使用するのはややリスクがあります。
完全に管理をツールに任せてしまうと、不具合があったとき手動で修正することが困難になる可能性があります。
そういったリスクを回避した構築例もあるようですので、それは引き続き調べてみたいと思っています。
自分がDNSSECを知ったのはここ1，2年のことであり、それより以前から様々な議論が行われ、いくつものソリューションが生まれていることと思います。
ゆくゆくはDNSSECが導入されていることを前提とした新たな仕組みが今後のスタンダードになることも検討会で予測されていましたが、現段階としては、
手動管理：非現実的
ツール管理：中でどう動いているかが不透明で、不具合が起こると手動管理以上の手間がかかる可能性がある。
導入による効果：不正サイトへのアクセスを「遮断」するだけ
実際に大きな被害が出た事件：ここ20年以上起こっていない
という、なかなか組織の経営層を納得させるのに時間がかかりそうな側面もあります。
導入するべきか否か
どのような形での導入が最適か
どう提案したらクライアントは導入を承諾してくれるか
実はすでにより良いソリューションがある。
などなど、こちらの記事を読んでいただいた皆様からの知見・意見を拝見できたらと思っています。
最後までお読みいただき、ありがとうございました。
株式会社イプリオのエンジニアズです！ ネットワークやサーバに関わること。お客さまのインターネットでのビジネスを支えるコラムを連載していきます！