資料 3 DNS の世界的な運用変更に伴い必要となる対策について資料 3-1 DNS の世界的な運用変更に伴うキャッシュ DNS サーバーの設定更新の必要性について ( 総務省資料 ) 資料 3-2 同 (IT 総合戦略室 NISC 資料 )

Size: px

Start display at page:

Download "資料 3 DNS の世界的な運用変更に伴い必要となる対策について資料 3-1 DNS の世界的な運用変更に伴うキャッシュ DNS サーバーの設定更新の必要性について ( 総務省資料 ) 資料 3-2 同 (IT 総合戦略室 NISC 資料 )"

ひさともひろなが
5 years ago
Views:

1 資料 3 DNS の世界的な運用変更に伴い必要となる対策について資料 3-1 DNS の世界的な運用変更に伴うキャッシュ DNS サーバーの設定更新の必要性について ( 総務省資料 ) 資料 3-2 同 (IT 総合戦略室 NISC 資料 )

2 資料 3-1 総基デ第 4 9 号平成 29 年 7 月 14 日内閣官房内閣サイバーセキュリティセンター副センター長殿内閣官房情報通信技術 (IT) 総合戦略室副政府 CIO 殿総務省総合通信基盤局長 DNSの世界的な運用変更に伴うキャッシュDNSサーバーの設定更新の必要性についてこの度インターネットの重要資源の世界的な管理調整業務を行う団体 ICANN (Internet Corporation for Assigned Names and Numbers) が DNS( ドメインネームシステム ) において電子の正当性を検証するために使う暗号鍵の中で最上位となる鍵 ( ルートゾーンKSK) の更改を実施しますこれに伴いキャッシュDNSサーバーを運用する者 ( 契約者向けにサービス提供するインターネットサービスプロバイダ LAN 利用者向けにサービス提供する官庁独法学校企業等以下運用者という ) においては別紙のとおり速やかに事前公開されているルートゾーンKSKの公開鍵の情報を更新する等の措置を講じる必要がありますなお本年 9 月 19 日までに必要な措置が講じられない場合 web サイトへのアクセスやメールの送信ができない利用者が生じる可能性がありますつきましては貴センターから各府省等担当部局を通じ運用者に対して別紙の事項を周知いただきたくご協力をお願いしますなお本文書は ICANNから総務省に対する周知依頼文書 ( 総基デ受 50) に基づき発出するものです

3 DNS における電子鍵の更改について平成 29 年 7 月 14 日総務省総合通信基盤局データ通信課 1. 目的 DNS( ドメインネームシステム ) はなどのホスト名 ( 人が理解しやすいようにつけたサーバーの名前 ) をインターネット上の住所である IP アドレスに変換するために利用される検索の仕組みこの検索結果が第三者の成りすましにより改ざんされないよう電子を付加した DNSSEC という仕組みで運用されるのが一般的である本年 7 月 ~ 来年 3 月にかけて当該電子の正当性を検証するために使う鍵の中で最も中核をなすルートゾーン KSK についてその信頼性維持のため史上初めて更改することが発表された 2. 対応が必要となる者 DNS を用いた検索を実際に行うキャッシュ DNS サーバーの運用者全て例 : 契約者向けに提供するインターネットサービスプロバイダ LAN 利用者向けに提供する官庁独法学校企業など 3. 鍵の更改に伴い生じる可能性のあるトラブル (1) 鍵の更改に追従できず検索結果の正当性が確認できない( 結果として検索結果が信用できないものとして取り扱われる ) ため web サイトへのアクセスやメールの送信ができない利用者が生じる可能性がある (2) 鍵の移行期間において鍵の正当性を確認する情報や電子について旧来の鍵用と新しい鍵用の双方を送受信する必要があるため当該期間において検索結果として送受信されるデータ量が増大することから検索結果をインターネット経由で正常に送受信できなくなり web サイトへのアクセスやメールの送信ができない利用者が生じる可能性がある 4. トラブルを生じさせないために必要となる措置本年 9 月 19 日までに以下の措置が必要

4 (1) 鍵の更改に追従するために 1 キャッシュ DNS サーバーのソフトウェア ( 一般に BIND 又は Windows Server を利用 ) を最新版に更新する ( 今回の対策だけでなく脆弱性への対応のためにも最新版への更新は必須 ) 2 キャッシュ DNS サーバーにおいて DNSSEC のトラストアンカーの自動更新の設定を行う 3 念のためキャッシュ DNS サーバーにおいて DNSSEC が有効になっておりまた DNSSEC の検証が有効になっていることを確認する (2) 鍵の移行期間のデータ量増大に対応するために 1 キャッシュ DNS サーバーにおいて UDP 受信サイズを 4096 バイトの検索結果が受信できる設定 (RFC6891 による推奨設定 ) を行う 2 キャッシュ DNS サーバーにおいて dig コマンドなどを使い 4096 オクテットの検索結果が受信できるか確認する 3 不明点がある場合には運用委託先や上位 ISP に問い合わせを行う詳細はを参照連絡先総務省総合通信基盤局データ通信課

DNS 応答の仕組み 1 インターネット上の機器は IPアドレスと呼ばれる番号で管理されインターネット上の通信は IPアドレスを宛先として行われるホームページの閲覧やメールの送信をするためには相手方の機器 ( サーバー )

jp ) が利用されているドメイン名をインターネット上の宛先とするためには対応するIPアドレスに変換する仕組み (DNS: Domain Name System) を利用 DNSではドメイン名の各階層の管理者が管理情報 (

総務省のホームページを見る場合 > IP アドレスとドメイン名の変換 DNS の階層構造 ( 管理者 ) 1 www.soumu.go.jp ( ドメイン名 ) を入力 4 203.0.113.

jp ルート DNS サーバー jpドメインのdnsサーバー (JPRS) soumu.go.

5 DNS 応答の仕組み 1 インターネット上の機器は IPアドレスと呼ばれる番号で管理されインターネット上の通信は IPアドレスを宛先として行われるホームページの閲覧やメールの送信をするためには相手方の機器 ( サーバー ) の IPアドレスを知っていることが必要 IPアドレスは例えばなど人には記憶判別しにくいため IPアドレスに対応したドメイン名 ( 例 : 総務省のホームページの場合 ) が利用されているドメイン名をインターネット上の宛先とするためには対応するIPアドレスに変換する仕組み (DNS: Domain Name System) を利用 DNSではドメイン名の各階層の管理者が管理情報 ( ドメイン名とIPアドレスの対応関係等 ) を自身の権威 DNSサーバーに保持インターネットの利用者は ISPやLAN 内のキャッシュDNSサーバーを通じて上位階層の権威 DNSサーバーから順にIPアドレスを問い合わせる < 総務省のホームページを見る場合 > IP アドレスとドメイン名の変換 DNS の階層構造 ( 管理者 ) 1 ( ドメイン名 ) を入力を入力 ( したことになる ) 利用者のパソコンです DNS 応答 (IP アドレス ) 総務省のホームページを提供する機器 ( ドメイン名 ) ルート DNS サーバー jpドメインのdnsサーバー (JPRS) soumu.go.jp ドメインの DNS サーバー (ICANN) ( 総務省 ) 2 に対応する IP アドレスを教えてください詳細キャッシュ DNS サーバー (2) 上位の権威 DNS サーバーから順に IP アドレスを問い合わせる DNS (Domain Name System) (1) の IP アドレスは? (3) です利用者のパソコン

DNS の正当性を担保する電子 (DNSSEC) の仕組み (1/2) 2 各階層の管理者は自らのDNS 応答の正当性を証明するために秘密鍵と公開鍵を利用するまず各階層の管理者は問合せを受けたドメイン名に対応するIPアドレスとともに秘密鍵によるを併せて送付する回答を受けたキャッシュDNSサーバーの運用者は公開鍵によりを復号し IPアドレスの情報と一致することを確認することで

6 DNS の正当性を担保する電子 (DNSSEC) の仕組み (1/2) 2 各階層の管理者は自らのDNS 応答の正当性を証明するために秘密鍵と公開鍵を利用するまず各階層の管理者は問合せを受けたドメイン名に対応するIPアドレスとともに秘密鍵によるを併せて送付する回答を受けたキャッシュDNSサーバーの運用者は公開鍵によりを復号し IPアドレスの情報と一致することを確認することで回答が途中で改ざんされていないことを確認する以上に加えて各階層の管理者が上位の階層の管理者に公開鍵に関する情報を預け当該上位の階層の管理者が自らのを行いキャッシュDNSサーバーの運用者に提供することで公開鍵の正当性を検証することを可能としている JP ゾーン公開鍵の正当性を検証するための情報上位の階層の管理者に公開鍵に関する情報を預ける公開鍵の正当性を検証公開鍵総務省ゾーン IP アドレス秘密鍵公開鍵キャッシュ DNS サーバー IP アドレス : :ri0e8f 総務省 DNS サーバー ri0e8f ri0e8f 一致により DNS 応答の信頼性を確認ハッシュ値を計算秘密鍵で暗号化公開鍵で復号ハッシュ値 : ある値からハッシュ関数と呼ばれる計算方法で求められる値同じ値から得られるハッシュ値は常に同じ値となるが得られるハッシュ値から元の値を導くことはできない

DNS の正当性を担保する電子 (DNSSEC) の仕組み (2/2) 3 鍵の信頼性を確保するためには鍵長を長くすることで解読されるリスクを小さくすること鍵の定期的な更新を行うことが求められるしかし前者についてはのための時間がかかる後者については上位の階層の管理者が関与する仕組みからあまり頻繁な更新は難しいといった問題があるそこで DNSSECにおいては

7 DNS の正当性を担保する電子 (DNSSEC) の仕組み (2/2) 3 鍵の信頼性を確保するためには鍵長を長くすることで解読されるリスクを小さくすること鍵の定期的な更新を行うことが求められるしかし前者についてはのための時間がかかる後者については上位の階層の管理者が関与する仕組みからあまり頻繁な更新は難しいといった問題があるそこで DNSSECにおいては DNSデータにをするZSK(Zone Signing Key) とZSKにをする KSK(Key Signing Key) という性質の異なる2 種類の鍵を併用することで問題を解決している JP ゾーン一致により ZSK 公開鍵の信頼性を確認で復号 7840 zk37b ハッシュ値を計算一致によりの信頼性を確認 6 公開鍵の正当性を検証するための情報 3 4ZSK 公開鍵 5KSKによる :zk37b1 総務省ゾーン上位の階層の管理者に公開鍵に関する情報を預ける IP アドレス ZSK 秘密鍵ハッシュ値を計算 7840 KSK 秘密鍵 ZSK 公開鍵秘密鍵で暗号化 zk37b1 キャッシュ DNS サーバー 1IP アドレス : ZSK による :ri0e8f 総務省 DNS サーバーハッシュ値を計算 ri0e8f 3913 一致により DNS 応答の信頼性を確認ハッシュ値を計算 3913 秘密鍵で暗号化 ri0e8f 公開鍵で復号 ZSK(Zone Signing Key) ゾーンの DNS データにするための鍵鍵長は短くのための時間が少なくすむの安全性を高めるために鍵の更新を頻繁に行う必要がある KSK(Key Signing Key) ZSK 公開鍵等にをするための鍵鍵長が長くの安全性が高いため鍵の更新の頻度が少なくすむ

8 DNSSEC を利用した DNS 応答の流れ 4 各階層の管理者はあらかじめ自らのを上位の階層の管理者に預ける各階層の管理者はキャッシュDNSサーバーからの問合せに対し自らのZSK 秘密鍵による及び下位階層の管理者のIPアドレス及び当該下位階層の管理者のの情報を応答する加えて各階層の管理者は自らのKSK 秘密鍵による及びZSK 公開鍵及びを送付する応答を受け取ったISP 等はあらかじめ上位階層の管理者から受け取っていたの情報により問合せ先からの応答の正当性を確認したうえで次の問合せを行うキャッシュ DNS サーバー ( 最上位の管理者のため ) を事前公開ルート DNS サーバーのの情報を事前に保有の IP アドレスは? ZSK KSK 総務省の IP アドレス JP ZSK 公開鍵 6 総務省の公開鍵情報 JP ルートゾーンルート DNS サーバー JP ゾーン JP DNS サーバー IP アドレス公開鍵の情報 jp aaa uk bbb com ccc 総務省ゾーン IP アドレス公開鍵の情報 soumu.go.jp aaa xxx.jp bbb yyy.jp ccc 上位の階層の管理者にを預ける KSK 秘密鍵 ZSK 秘密鍵 ZSK 公開鍵上位の階層の管理者にを預ける KSK 秘密鍵 ZSK 秘密鍵 ZSK 公開鍵 KSK 秘密鍵インターネット利用者 IPアドレス総務省 DNS サーバー ZSK 秘密鍵 ZSK 公開鍵

9 ルート KSK の更改 ( ルート KSK ロールオーバー ) について年のルートKSKの導入以来初めての鍵の更改が本年 7 月 ~ 来年 3 月にかけて予定されているこれに伴いキャッシュDNSサーバーを保有するISP 等は事前公開されているルートKSKの公開鍵の情報を更新する必要があるまたルートKSKの円滑な更改のために一時的に新旧両方のを送信する期間がある当該期間は送信されるデータ量が増大し IPフラグメントが生じることがある ISP 等の事業者は自らのDNSの応答に係る経路上の機器の設定がIPフラグメントに対応可能か否かを事前に確認しておく必要があるなおルートDNSサーバーは応答相手のDNSSEC 対応非対応に関わらず公開鍵情報を送信してしまうため DNSSEC 非対応の機器についてもIPフラグメントによる問題が生じる可能性があるルートゾーン KSK 秘密鍵 1 ルート DNS サーバーの公開鍵を新しいものに更新しておく必要 ( 最上位の管理者のため ) を事前公開 IPアドレス公開鍵の情報 jp aaa uk bbb com ccc ルート DNS サーバー ZSK 秘密鍵 ZSK 公開鍵今回初めて更改 3 ヶ月ごとに更改ルート DNS サーバーの公開鍵の情報を事前に保有キャッシュ DNS サーバー 2 データ量増大に伴う IP フラグメントが生じないことを確認しておく必要 IP フラグメントとは通信のデータ量が通信機器の設定サイズを超過すると当該データは分割されて転送されるこれを IP フラグメントというさらにこの場合経路上の機器の設定によっては分割されたデータが破棄され通信が正常に行われなくなる可能性がある今回のルート KSK の更改においては定期的 (3 ヶ月ごと ) に行われるルート ZSK の更改とタイミングが重なる際に IP フラグメントが生じることになる < 通常時 > ヘッダー更改前ルート ZSK 公開鍵更改前ルート KSK 秘密鍵 KSK による IP フラグメント発生サイズ < 移行時 ( 最大時 )> インターネット利用者ヘッダー更改前ルート ZSK 公開鍵更改前ルート更改後ルート ZSK 公開鍵 = 更改後ルート KSK による

10 クイックガイド : ルート KSK ロールオーバーに向けたシステムの準備ルート KSK ロールオーバーとは? Internet Corporation for Assigned Names and Numbers(ICANN) はルートゾーン KSK と呼ばれるドメイン名システムのセキュリティ拡張 (DNSSEC) プロトコルで使用される暗号化鍵の最上位のペアを導入または変更することを予定しています KSK が 2010 年に最初に作成されてから初めての変更となります定期的なパスワードの変更はインターネットユーザーにとって重要なセキュリティ対策であるように ICANN にとっても今回の措置は重要なセキュリティ対策となります鍵を変更するには新しい暗号鍵ペアを生成し新しいパブリックコンポーネントを DNSSEC 検証リゾルバに配布する必要があります DNSSEC を使用するすべてのインターネットクエリがルートゾーン KSK を利用してその送信先を検証するためこれは重要な変更となります新しい鍵が生成されるとユーザーが Web サイトにアクセスするときに新しい KSK でその鍵を検証できるように ISP などの Web 関連の事業者は新しい鍵を使用してシステムを更新する必要があります準備が必要となる理由現在全世界のインターネットユーザーの 25%(7 億 5,000 万人 ) が DNSSEC 検証リゾルバを使用しており KSK ロールオーバーの影響を受けると考えられます新しい KSK が導入されるときにこれらの検証用のリゾルバに新しい鍵がない場合これらのリゾルバを利用しているエンドユーザー側でエラーが発生しインターネットにアクセスできなくなります DNSSEC を使用していない場合システムはロールオーバーの影響を受けませんしかし DNSSEC はドメイン名のハイジャックを防止する上で重要な役割を果たします DNSSEC の導入についての詳細はこちらをご覧ください DNSSEC の検証を有効にしている場合は新しい KSK を使用してシステムを更新しユーザーが引き続きインターネットにアクセスできるようにする必要があります ICANN は事業者や関係者がシステムで自動更新プロセスを正しく処理できることを確認するためのテストベッドを提供しています次のサイトにアクセスしてシステムの準備が整っていることを確認します go.icann.org/ksktest. Designed by ICANN Communications 2017 年 3 月クリエイティブコモンズ表示 - 非営利

11 必要な操作新しいルートゾーン KSK は 2017 年 2 月に公開されておりロールオーバーの実施前にいつでもシステムを更新できますまた一部のシステムではすでに自動更新が行われている場合があります以下の状況によって実施する必要がある操作は異なります DNSSECトラストアンカー (RFC 5011) の自動アップデートがソフトウェアでサポートされている場合 : KSKは適切なタイミングで自動的に更新されます特にユーザーによる操作は必要はありませんロールオーバー中にオフラインになっているデバイスについてはロールオーバーの完了後にオンラインになった場合手動で更新する必要があります ICANNは 2017 年 3 月 17 日からテストベッドの提供を開始していますテストベッドを使用すると事業者や関係者はシステムが自動更新プロセスを正しく処理できるかどうかを確認できます詳細については icann.org/kskrollをご覧くださいお使いのソフトウェアが DNSSECトラストアンカー (RFC 5011) の自動更新をサポートしていないかまたは使用するように設定されていない場合 : ソフトウェアのトラストアンカーファイルを手動で更新する必要があります新しいルートゾーンKSKは 2017 年 3 月以降ここから入手できます KSK ロールオーバーの実施時期 KSK のロールオーバーは一連のプロセスであり一度限りのイベントではありません以下の日付はこのプロセスの重要な工程でありエンドユーザーはインターネットサービスに一時アクセスできなくなる場合があります 2017 年 9 月 19 日 2017 年 10 月 11 日 2018 年 1 月 11 日 2018 年 3 月 22 日 2018 年 8 月ルートネームサーバーからの DNSKEY 応答のサイズが増大新しい KSK を初めてに使用古い KSK を失効古い KSK がルートゾーンに表示される最終日古い鍵を両方の ICANN の鍵管理システムの機器から削除今後の変更に対する準備を進める上で役立つリソースなどロールオーバーに関する詳細については icann.org/kskroll をご覧ください KSK Rollover という件名を付けて globalsupport@icann.org に電子メールを送信いただくこともできます #KeyRoll を使用して Twitter でのコミュニケーションに参加いただくこともできます Designed by ICANN Communications 2017 年 3 月 Creative Commons Attribution - NonCommercial

14 資料 3-2 事務連絡平成 29 年 7 月 18 日各府省庁情報セキュリティ担当課室長殿各府省庁情報システム担当課室長殿内閣官房内閣サイバーセキュリティセンター内閣参事官 ( 基本戦略担当 ) 内閣参事官 ( 重要インフラ担当 ) 内閣参事官 ( 政府機関総合対策担当 ) 内閣官房情報通信技術 (IT) 総合戦略室内閣参事官 DNS の世界的な運用変更に伴うキャッシュ DNS サーバーの設定更新の必要性についてこの度インターネットの重要資源の世界的な管理調整業務を行う団体 ICANN(Internet Corporation for Assigned Names and Numbers) から DNS( ドメインネームシステム ) において電子の正当性を検証するために使う暗号鍵の中で最上位となる鍵 ( ルートゾーン KSK) を更新することが発表されましたこれに伴いキャッシュ DNS サーバーを運用する者においては速やかに事前公開されているルートゾーン KSK の公開鍵の情報を更新する等の措置を講じる必要があります本年 9 月 19 日までに必要な措置が講じられない場合ウェブサイトへのアクセスやメールの送信ができない利用者が生じる可能性があります上記内容について総務省から内閣サイバーセキュリティセンター及び情報通信技術 (IT) 総合戦略室に対し周知依頼がありましたので別紙の内容をご確認のうえ対策を講じるようお願いいたしますまた独立行政法人その他の所管する法人に周知するとともに業界団体を通じて連絡する等により所管する産業界 ( 重要インフラ事業者を含む ) へも幅広く周知していただきますようお願いいたします問合せ先内閣官房内閣サイバーセキュリティセンター重要インフラグループ齊藤佐藤川上政府機関総合対策グループ石黒久保山内閣官房情報通信技術 (IT) 総合戦略室電子行政班大平川口

15 別紙インターネットの重要資源の世界的な管理調整業務を行う団体 ICANN(Internet Corporation for Assigned Names and Numbers) が DNS( ドメインネームシステム ) で利用されている DNSSEC に必要な電子鍵を初めて交換することが発表されました DNSSEC の電子正当性を確認するために使う鍵の中で最上位となる鍵ルートゾーン KSK について信頼性維持のため本年 7 月 ~ 来年 3 月に更改作業が行われ本年 9 月から新旧の鍵の併用が開始されますキャッシュ DNS サーバーを運用されている事業者等については別紙詳細を確認いただき鍵更改への追従鍵の移行期間中のデータ量 (UDP メッセージサイズ ) 増大への対応を確実に実施していただきますようお願いしますなお本年 9 月 19 日までに必要な処置が講じられない場合 Web アクセスやメール送信などができない利用者が生じる可能性があります対象者 DNS を用いた検索を実際に行うキャッシュ DNS サーバーの運用者全て例 : 契約者向けに提供するインターネットサービスプロバイダ LAN 利用者向けに提供する官庁独法学校企業など DNSSEC を無効にしている方も下記影響対応の 2 についてご確認ください影響 1 検索結果の正当性が確認できなくなり利用者のネット利用に不具合が生じる 2 検索結果の受信データ量 (UDP メッセージサイズ ) が増大することから利用者のネット利用に不具合が生じる可能性がある対応 1 鍵の更改に追従するキャッシュ DNS サーバーのソフトウェアを最新版に更新するキャッシュ DNS サーバーにおいて DNSSEC のトラストアンカーの自動更新の設定を行う 2 鍵の移行期間のデータ量 (UDP メッセージサイズ ) 増大に対応するキャッシュ DNS サーバーにおいて UDP 受信サイズを 4096 オクテットの検索結果が受信できる設定を行うキャッシュ DNS サーバーにおいて 4096 オクテットの検索結果が受信できるか確認する < 使用している DNS サーバーが 4096 オクテットの検索結果を受信できるか確認例 > WEB での確認例コマンドラインでの確認例 dig +bufsize=4096 +short rs.dns-oarc.net txt JPRS ルートゾーン KSK ロールオーバーによる影響とその確認方法について ICANN Root Zone KSK Rollover

(1) 鍵の更改に追従するために 1 のソフトウェア ( 一般に BIND 又は Windows Server を利用 ) を最新版に更新する ( 今回の対策だけでなく脆弱性への対応のためにも最新版への更新は必須 ) 2 において DNSSEC のトラストアンカーの自動更新の設定を行う 3

(1) 鍵の更改に追従するために 1 のソフトウェア ( 一般に BIND 又は Windows Server を利用 ) を最新版に更新する ( 今回の対策だけでなく脆弱性への対応のためにも最新版への更新は必須 ) 2 において DNSSEC のトラストアンカーの自動更新の設定を行う 3 別紙 2 DNS における電子鍵の更改について平成 29 年 7 月 14 日総務省総合通信基盤局データ通信課 1. 目的 DNS( ドメインネームシステム ) は www.soumu.go.jp などのホスト名 ( 人が理解しやすいようにつけたの名前 ) をインターネット上の住所であるに変換するために利用される検索の仕組みこの検索結果が第三者の成りすましにより改ざんされないよう電子を付加した

資料 3 DNS の世界的な運用変更に伴い必要となる対策について 資料 3-1 DNS の世界的な運用変更に伴うキャッシュ DNS サーバーの 設定更新の必要性について ( 総務省資料 ) 資料 3-2 同 (IT 総合戦略室 NISC 資料 )

資料 3 DNS の世界的な運用変更に伴い必要となる対策について資料 3-1 DNS の世界的な運用変更に伴うキャッシュ DNS サーバーの設定更新の必要性について ( 総務省資料 ) 資料 3-2 同 (IT 総合戦略室 NISC 資料 )