私たちがインターネットにアクセスして様々なサービスやデータをやり取りする際に使う、
「DNS：ドメインネームサービス」には改竄（キャッシュポイズニング）や盗聴（スニフィッング）などの様々な脆弱性を孕んでいる。
今回は、改竄（キャッシュポイズニング）の対策に焦点を当てた技術企画「DNSSEC」
について分かりやすく解説します。
キャッシュポイズニングとは
DNS（Domain Name System）は、インターネット上のドメイン名をIPアドレスに変換するシステムです。例えば、”tech-life-media.com”というドメイン名を入力すると、DNSがそのドメイン名を対応するIPアドレス（例: 183.90.181.10X）に変換し、ウェブサイトにアクセスできるようにします。
この変換がなければ、ユーザーはウェブサイトにアクセスする際にIPアドレスを直接入力しなければならず、非常に不便です。
しかし、常にこの回答を保管する権威DNS（コンテンツ）サーバーに問い合わせるを
行うのは非効率でパフォーマンス低下させます。
そこであらかじめDNSリゾルバと呼ばれるキャッシングサーバーを用意しクライアントは
DNSリゾルバに問い合わせを行うことで権威DNSの回答をキャッシングしておき瞬時に回答を出すことで通信を快適にしています。（解決おおよそ１秒前後）
DNS自体に回答を検証する術がなかった
キャッシングポイズニングはこのキャッシュDNSサーバーの回答を偽の情報に差し替えることでクライアントが意図しないホストへの接続を誘導する攻撃手段です。
分かりやすく例えるとキャッシュ（事前に持つ情報に）ポイズニング（毒入れ）をする。
これはDNSキャッシュとコンテンツDNSの記録「レコード」を検証する術がなかったためにです。
DNSのセキュリティ拡張”DNSSEC”
「無いのであれば用意しようがテクノロジーの定石」
そんなこんなで、1990年代後半に実装されたのがDNS「ドメインネームシステム」
SEC「セキュアエクステンション」＝DNSSECです。
SEC「Scure Extension」とはセキュリティ拡張の意でセキュリティ機能の無いDNS
「ドメインネーム」にセキュリティ機能を拡張すことが目的の技術です。
具体的な仕組み
DNSSECの具体的な仕組みは、コンテンツDNSのゾーン全体を公開鍵認証方式で暗号化することで、レコードデータを暗号化し、そのハッシュ値の違いを比較することでキャッシュの相違（毒入れの有無）を検証することができます。
信頼の連鎖
この仕組みだと「鍵」と「署名」の組み合わせのみが合っているだけで、正しい応答であると判断してしまうため、「鍵」と「署名」のセットで偽装すれば、その応答を正しいものとして扱ってしまう可能性があります。それを防ぐために用意されているものが「信頼の連鎖」です。
DNSは、ドメイン名の巨大な分散データベースです。いくつもの権威DNSサーバーがそれぞれのデータを管理し、キャッシュDNSサーバーが順々に辿って目的のドメインの名前解決を行います。通常、www.tech-life-media.comの名前解決をする場合は、以下の順番で上位のDNSから問い合わせていきます。
- STEP1「.」(ルート)の権威DNSに「.com」の権威DNSを教えてもらう
- STEP2「.jp」の権威DNSに「.tech-life-media.com」の権威DNSを教えてもらう
- STEP3「tech-life-media.com」の権威DNSに「www.tech-life-media.com」のIPアドレスを教えてもらう
DNSSECではこの性質を利用して、次の権威DNSサーバーを教える際に、その権威DNSサーバーが管理している対象ゾーンの「鍵」にハッシュ関数をかけた「DS」 (Delegation Signer)をセットで応答します。
「.」に「.com」のDNSを問合せた際に、「.com」の「DS」も合わせて受け取ります。
続いて「.com」に「tech-life-media.com」のDNSを問合せた際に、正しいものであることの証明となるDNSSECの「鍵」と「署名」を受け取ります。その後、「.」からもらった「.com」の「DS」と、「.com」の「鍵」と「署名」を利用して以下のように正しいかを検証します。
「DS」と「鍵」を比較して、「鍵」が正しいことを確認する。
正しい「鍵」と「署名」が正しいセットであるかを確認する。
全てOKであれば正しい応答であると判断できる。
まとめると『上位のDNSが、次のDNSが正しいことを証明している』ということになります。
その証明が連鎖していくことで最終的に「www.tech-life-media.com」の応答が正しいことが分かるのです。 先ほどの、「www.tech-life-media.com」の名前解決の例に、この「信頼の連鎖」の動きを加えると以下のようになります。
- 「.」(ルート)の権威DNSに「.com」の権威DNSとその「DS」を教えてもらう
- 「.com」の権威DNSに「tech-life-media.com」の権威DNSとその「DS」を教えてもらう
- 「.」の権威DNSからもらった「DS」と「.com」の「鍵」と「署名」から、「.com」の応答が正しいことを判断する
- 「.com」の権威DNSに「tech-life-media.com」の権威DNSとその「DS」を教えてもらう
- 「tech-life-media.com」の権威DNSに「www.tech-life-media.com」のIPアドレスを教えてもらう
- 「.com」の権威DNSからもらった「DS」と「tech-life-media.com」の「鍵」と「署名」から、「tech-life-media.com」の応答が正しいことを判断する
イメージはよくある公開鍵認証を用いたセキュア通信である
署名の有効性を検証する方法
DNSSECが正しく実装されているか検証する方法は以下の３通り
- https://dnsviz.net/を使う
- DNSSEC Debuggerを使う
- dig +dnssecを使う
dnsviz.netは、イメージ画像のようにDNSの動作を視覚できるように図に表してくれるウェブサービスでDNSSECの有効性も検証し図に表してくれます。
dnssec-debuggerは、.（ルートゾーン）や.comゾーンを管理するレジストリであるベリサインが開発提供するDNSSECデバッカーで使用するとDNSSECの有効性をリスト形式で表示してくれます。
DNSSECを実装する方法
ここまでで、DNSSECがどのような仕組みなのかは理解できたのではないだろうか？
実際に実装する手順を見ていこう。
- DNSリゾルバ（キャッシュDNSの実装方法）
- コンテンツDNS（権威DNSの実装方法）
- CDN（コンテンツデリバリーネットワークのDNSを使う場合）
DNSリゾルバ（キャッシュDNSの実装方法）
一番実装が簡単なのがDNSリゾルバ（キャッシュDNS）であるなぜならば、仕組みで説明しているようにキャッシュDNSサーバーには、信頼の起点（トラストアンカー）になるルートゾーン(.)が生成するDS（Delegation Signer)レコードさえ存在すれば良いためです。
信頼の起点となるルート証明と中間があればすべての証明書が
認証できるようにDNSSECもルートゾーンの公開鍵（DS）があれば
すべてのゾーンの署名を検証することができます。
コンテンツDNS（権威DNSの実装方法）
コンテンツDNS（権威DNS)の実装はクライアントサイドのキャッシュDNSのように簡単には実装できません。
コンテンツDNSでDNSSECを有効化するにはレジストラ（登録事業者）を通じてレジストリ
が運用する上位の権威DNS上にコンテンツDNSのゾーン署名によって生成される公開鍵である（DS）レコードの登録を取り次いでもらう必要があります。
お名前.comのようなレジストラをから直接取得しているドメインはレジストラの管理パネル上で対応している場合DNSSECの有効化設定を行うことでゾーンの署名とDSレコードの設定を取り次ぐことができます。
しかし、バリュードメインのようにレジストラと再販契約を行い登録申請を代行する
再販業者（リセラー）の場合は、このような対応を行っていないことが多く直接レジストラ
に問い合わせる必要がある場合があります。
また、レジストラによってはDSレコードの設定はメール等の問い合わせが必要なケースも
あります。
CDN（コンテンツデリバリーネットワークのDNSを使う場合）
CloudflareなどのCDN（コンテンツデリバリネットワーク）では、コンテンツの配信を円滑に行うためにDNSゾーンの管理を直接事業者に委任する必要性が出る場合が多いです。
この場合、CDNのゾーンが生成するDSレコードをレジストラが運用する自身のコンテンツ
DNS内に登録を行う必要あります。
例えば、このサイトtech-life-media.comでCloudflare DNSを使ってDNSSECを有効化する場合は以下の画像のDSレコードをレジストラに記録する必要があります。
- Inetdホスティングサービス
- IP Mirrorグローバルドメイン管理サービス
- IIJ インターネット
- WIXI
- NTTPC
- KDDIインターネット
- スマートバリュー
- Thomson Brandyドメイン名登録サービス
- JPDirect
- ドメインネーム・フォー・ユー
- SANNETインターネットサービス
取次をおこなっているリセラーやレジストラは上記の事業者と海外企業だけなので対応してない場合はあきらめて移管してください。
DNSSECの普及率
フルリゾルバにおけるDNSSECの世界普及率は30％中でもオセアニアが46％と高い普及率を占めており我が国にの所属するアジアは30％とゆっくりな普及率である。
アジア圏内で見るとサウジアラビアが90％以上と非常に高く、我が国日本は１０％前後とかなり芳しい数値である。
権威DNSの普及率
DSレコードの登録とゾーンの署名の割合は年々増加傾向にあり、権威DNSにおいても順調に普及していると言える。TLD（トップレベルドメイン）で見ると・・・
| TLD | Number working | DS records | Percent working |
|---|---|---|---|
| makeup | 3154 | 3155 | 99.97 |
| skin | 5158 | 5161 | 99.94 |
| br | 1051836 | 1052584 | 99.93 |
登録数の少ないmakeupやskinが全体の99％近くの普及率でドメイン取得率の高い3種のTLDは下図のように推移している。
| TLD | Number working | DS records | Percent working |
|---|---|---|---|
| com | 6193408 | 6344370 | 97.62 |
| net | 585806 | 598788 | 97.83 |
| jp | 12773 | 13029 | 98.04 |
国内インターネット事業者のレポート
日本国内のインターネットインフラ事業者の数値を見るとKDDIやASAHIネット、ケーブルテレビなどが２桁％と好調な普及率だがOCNなど大手で個人の契約者が多い事業者は1桁％とかなり少ないこれはISP側のリゾルバがDNSSECに対応していないためである。
私の契約しているahamo光を提供するOCNインターネットですら、検証率3.52%とかなり
低い実際digで検証してみたが対応していないかHGWのDNSプロキシ機能によってDNSSECの検証が無効化されたのか正常に機能しなかった。
DNSSEC導入における課題
DNSSECはインターネットの安全性を高めるための重要な技術ですが、導入にはいくつかの課題があります。
鍵管理の重圧
DNSSECでは、暗号鍵の適切な管理と定期的な交換が必須です。鍵の漏洩や推測はセキュリティ上の重大な問題を引き起こすため、厳重な管理体制が求められます。
キャッシュとTTL
DNSSECの鍵や署名もキャッシュされるため、鍵交換のタイミングはTTL（Time To Live）を考慮する必要があります。TTLが大きい場合、鍵交換作業は数日間に及ぶ可能性があります。
名前解決の失敗
鍵交換のタイミングが適切でないと、キャッシュDNSサーバーで鍵と署名の不整合が発生し、名前解決に失敗する可能性があります。これは、Webサイトへのアクセス不能など、重大なサービス停止につながります。
ネットワーク的なハードル
DNSSECを有効にすると、DNS応答パケットが大きくなります。UDPパケットの最大値を超えると、TCPにフォールバックするか、EDNS0でパケットを分割する必要があります。
ルーターやファイアウォール
TCPの53番ポートをブロックするルーターやファイアウォール、分割されたUDPパケットを認識できない古いルーターやDNSサーバーは、DNSSECの導入を妨げる可能性があります。
ISP事業者の責務
ISP事業者は、DNSSEC導入における様々な課題を克服し、顧客に安全なインターネット環境を提供する必要があります。
まとめ
DNSSECはインターネットの安全性を高めるための重要な技術ですが、導入には様々な課題があります。これらの課題を解決し、安全なインターネット環境を提供することが、ISP事業者の重要な責務で
「広告収入で安定収入を得たい！」「自分のブログやサイトで稼ぎたい！」
そんな夢を叶えるためのヒントが、このブログには詰まっています。
広告掲載の基礎知識から、収益を上げる方法、さらには読者やユーザーとの共感を呼ぶコンテンツ作成まで。実践的なノウハウを元に、あなたのブログやサイトを収益化に導きます。
