事務連
絡
平成 29 年 7 月 18 日

各府省庁情報セキュリティ担当課室長 殿
各府省庁情報システム担当課室長 殿内閣官房 内閣サイバーセキュリティセンター
内閣参事官（基本戦略担当）
内閣参事官（重要インフラ担当）
内閣参事官（政府機関総合対策担当）
内閣官房 情報通信技術(IT)総合戦略室
内閣参事官
ＤＮＳの世界的な運用変更に伴うキャッシュＤＮＳサーバーの設定更新の必要性について

この度、インターネットの重要資源の世界的な管理・調整業務を行う団体ＩＣＡＮＮ（InternetCorporation for Assigned Names and Numbers）から、ＤＮＳ（ドメインネームシステム）において電子署名の正当性を検証するために使う暗号鍵の中で最上位となる鍵（ルートゾーンＫＳＫ）を更新することが発表されました。
これに伴い、キャッシュＤＮＳサーバーを運用する者においては、速やかに事前公開されているルートゾーンＫＳＫの公開鍵の情報を更新する等の措置を講じる必要があります。本年９月１９日までに必要な措置が講じられない場合、ウェブサイトへのアクセスやメールの送信ができない利用者が生じる可能性があります。
上記内容について総務省から内閣サイバーセキュリティセンター及び情報通信技術(IT)総合戦略室に対し周知依頼がありましたので、別紙の内容をご確認のうえ対策を講じるようお願いいたします。また、独立行政法人その他の所管する法人に周知するとともに、業界団体を通じて連絡する等により所管する産業界（重要インフラ事業者を含む。
）へも幅広く周知していただきますようお願いいたします。

問合せ先内閣官房内閣サイバーセキュリティセンター
重要インフラグループ 齊藤、佐藤、川上
03-3581-8903
政府機関総合対策グループ

石黒、久保山03-3581-3959
内閣官房情報通信技術（IT）総合戦略室
電子行政班 大平、川口
03-3581-3467

別紙

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

② 「鍵の移行期間」のデータ量(UDPメッセージサイズ)増大に対応する。
・キャッシュDNSサーバーにおいてUDP受信サイズを4096オクテットの検索結果が受信できる設定を行う。
・キャッシュDNSサーバーにおいて4096オクテットの検索結果が受信できるか確認する。
<使用しているDNSサーバーが4096オクテットの検索結果を受信できるか確認例＞
・WEBでの確認例 http://keysizetest.verisignlabs.com/
・コマンドラインでの確認例 dig +bufsize=4096 +short rs.dns-oarc.net txt【JPRS】ルートゾーンKSKロールオーバーによる影響とその確認方法について
・https://jprs.jp/tech/notice/2017-07-10-root-zone-ksk-rollover.html【ICANN】Root Zone KSK Rollover・https://www.icann.org/resources/pages/ksk-rollover総 基 デ 第 ４ ９ 号
平成２９年７月１４日
内閣官房内閣サイバーセキュリティセンター
副センター長 殿内閣官房情報通信技術（ＩＴ）総合戦略室
副政府ＣＩＯ 殿
総務省

総合通信基盤局長

ＤＮＳの世界的な運用変更に伴うキャッシュＤＮＳサーバーの設定更新の必要性について
この度、インターネットの重要資源の世界的な管理・調整業務を行う団体ＩＣＡＮＮ（Internet Corporation for Assigned Names and Numbers）が、ＤＮＳ（ドメインネームシステム）において電子署名の正当性を検証するために使う暗号鍵の中で最上位となる鍵（ルートゾーンＫＳＫ）の更改を実施します。
これに伴い、キャッシュＤＮＳサーバーを運用する者（契約者向けにサービス提供するインターネットサービスプロバイダ、ＬＡＮ利用者向けにサービス提供する官庁、独法、学校、企業等。以下「運用者」という。）においては、別紙のとおり、速やかに事前公開されているルートゾーンＫＳＫの公開鍵の情報を更新する等の措置を講じる必要があります。
なお、本年９月１９日までに必要な措置が講じられない場合、web サイトへのアクセスやメールの送信ができない利用者が生じる可能性があります。
つきましては、貴センターから、各府省等担当部局を通じ、運用者に対して別紙の事項を周知いただきたく、ご協力をお願いします。
なお、本文書は、ＩＣＡＮＮから総務省に対する周知依頼文書（総基デ受 50）に基づき、発出するものです。

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

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

１

DNS応答の仕組み○ インターネット上の機器は、IPアドレスと呼ばれる番号で管理され、インターネット上の通信は、IPアドレスを宛先として行われる。 ホームページの閲覧やメールの送信をするためには、相手方の機器（サーバー）のIPアドレスを知っていることが必要。
○ IPアドレスは、例えば「203.0.113.1」など人には記憶・判別しにくいため、IPアドレスに対応したドメイン名（例：総務省のホームページの場合「www.soumu.go.jp」）が利用されている。
○ ドメイン名をインターネット上の宛先とするためには、対応するIPアドレスに変換する仕組み（DNS:
Domain Name System）を利用。
○ DNSでは、ドメイン名の各階層の管理者が管理情報（ドメイン名とIPアドレスの対応関係等）を自身の権威DNSサーバーに保持。インターネットの利用者は、ISPやLAN内のキャッシュDNSサーバーを通じて、上位階層の権威DNSサーバーから順にIPアドレスを問い合わせる。
＜総務省のホームページを見る場合＞
DNSの階層構造

IPアドレスとドメイン名の変換（管理者）①「www.soumu.go.jp」(ドメイン名)を入力④「203.0.113.1」を入力（したことになる）（IPアドレス）・・・

203.0.113.1○利用者のパソコン③「203.0.113.1」です。

DNS応答

総務省のホームページを提供する機器（ドメイン名）（ICANN）

jpドメインのDNSサーバー （JPRS）

soumu.go.jpドメインの（総務省）
DNSサーバー

www.soumu.go.jp②「www.soumu.go.jp」に対応するIPアドレスを教えてください。

DNS（Domain Name System）

・・・

ルートDNSサーバー

キャッシュDNS
サーバー(2)上位の権威DNSサーバーから順にIPアドレスを問い合わせる。

詳細(1)www.soumu.go.jpのIPアドレスは？

(3)「203.0.113.1」です。

利用者のパソコン

２

DNSの正当性を担保する電子署名（DNSSEC）の仕組み（1/2）○ 各階層の管理者は、自らのDNS応答の正当性を証明するために、秘密鍵と公開鍵を利用する。
○ まず、各階層の管理者は、問合せを受けたドメイン名に対応するIPアドレスとともに、秘密鍵による署名を併せて送付する。
○ 回答を受けたキャッシュDNSサーバーの運用者は、公開鍵により署名を復号し、IPアドレスの情報と一致することを確認することで、回答が途中で改ざんされていないことを確認する。
○ 以上に加えて、各階層の管理者が、上位の階層の管理者に公開鍵に関する情報を預け、当該上位の階層の管理者が自らの署名を行いキャッシュDNSサーバーの運用者に提供することで、公開鍵の正当性を検証することを可能としている。
JPゾーン

公開鍵の正当性を検証するための情報

公開鍵の正当性を検証
公開鍵キャッシュDNS
サーバー

IPアドレス： 203.0.113.1
署名：ri0e8f

上位の階層の管理者に公開鍵に関する情報を預ける

総務省ゾーン
www.soumu.go.jp

203.0.113.1

・・・

・・・

＆

署名

総務省DNSサーバー「203.0.113.1」「203.0.113.1」

3913

ri0e8f3913

公開鍵で復号

一致によりDNS応答の信頼性を確認

公開鍵

秘密鍵

IPアドレス

ハッシュ値を計算

3913

ri0e8f

秘密鍵で暗号化

ハッシュ値：ある値からハッシュ関数と呼ばれる計算方法で求められる値。同じ値から得られるハッシュ値は常に同じ値となるが、得られるハッシュ値から元の値を導くことはできない。

３

DNSの正当性を担保する電子署名（DNSSEC）の仕組み（2/2）○ 鍵の信頼性を確保するためには、鍵長を長くすることで解読されるリスクを小さくすること、鍵の定期的な更新を行うことが求められる。
○ しかし、前者については署名のための時間がかかる、後者については上位の階層の管理者が関与する仕組みからあまり頻繁な更新は難しいといった問題がある。
○ そこで、DNSSECにおいては、DNSデータに署名をするZSK（Zone Signing Key）とZSKに署名をするKSK（Key Signing Key）という、性質の異なる２種類の鍵を併用することで、問題を解決している。
JPゾーン

KSK公開鍵で復号

一致によりZSK公開鍵の信頼性を確認

zk37b17840
7840⑥公開鍵の正当性を検証するための情報一致によりKSK公開鍵の信頼性を確認

ハッシュ値を計算①IPアドレス：203.0.113.1②ZSKによる署名：ri0e8f「203.0.113.1」

3913

ri0e8f3913

公開鍵で復号

総務省ゾーン

一致によりDNS応答の信頼性を確認

zk37b1

KSK秘密鍵＆IPアドレス

www.soumu.go.jp

203.0.113.1

・・・

・・・

署名
ZSK秘密鍵ZSK公開鍵

＆署名

総務省DNSサーバー「203.0.113.1」

ハッシュ値を計算

秘密鍵で暗号化

7840

KSK公開鍵

③KSK公開鍵、 ④ZSK公開鍵⑤KSKによる署名：zk37b1

キャッシュDNS
サーバー

ハッシュ値を計算

上位の階層の管理者に公開鍵に関する情報を預ける

ハッシュ値を計算

3913

ri0e8f

秘密鍵で暗号化ZSK（Zone Signing Key）
ゾーンのDNSデータに署名するための鍵。鍵長は短く、署名のための時間が少なくすむ。署名の安全性を高めるために、鍵の更新を頻繁に行う必要がある。
KSK（Key Signing Key）
ZSK公開鍵等に署名をするための鍵。鍵長が長く署名の安全性が高いため、鍵の更新の頻度が少なくすむ。

４

DNSSECを利用したDNS応答の流れ○ 各階層の管理者は、あらかじめ自らのKSK公開鍵を上位の階層の管理者に預ける。
○ 各階層の管理者は、キャッシュDNSサーバーからの問合せに対し、自らのZSK秘密鍵による署名及び下位階層の管理者のIPアドレス及び当該下位階層の管理者のKSK公開鍵の情報を応答する。
○ 加えて、各階層の管理者は、自らのKSK秘密鍵による署名及びZSK公開鍵及びKSK公開鍵を送付する。
○ 応答を受け取ったISP等は、あらかじめ上位階層の管理者から受け取っていたKSK公開鍵の情報により、問合せ先からの応答の正当性を確認したうえで、次の問合せを行う。
ルートゾーン（最上位の管理者のため）
KSK公開鍵を事前公開

IPアドレス

公開鍵の情報jp203.0.113.2

aaa

uk

203.0.113.3

bbb

com

203.0.113.4

ccc

・

・・・

・・・

ルートDNSサーバー「www.soumu.go..jp」のIPアドレスは？

キャッシュDNS
サーバー

ZSK
署名

総務省のIPアドレス⑥総務省の公開鍵情報

KSK署名

JP
ZSK公開鍵

JP
KSK公開鍵＆署名＆署名ZSK秘密鍵

IPアドレス

公開鍵の情報soumu.go.jp

203.0.113.5

aaa

xxx.jp203.0.113.6

bbb

yyy.jp203.0.113.7

ccc

・・・・

・・・

JP DNSサーバー

KSK公開鍵

KSK秘密鍵＆署名＆署名
ZSK秘密鍵

KSK公開鍵※JPRS→JP
IPアドレス
www.soumu.go.jp

203.0.113.1

・・・

・・・

総務省DNSサーバー

ZSK公開鍵ZSK公開鍵上位の階層の管理者にKSK公開鍵を預ける

総務省ゾーン

インターネット利用者

KSK秘密鍵上位の階層の管理者にKSK公開鍵を預ける

JPゾーン

ルートDNSサーバーのKSK公開鍵の情報を事前に保有

KSK公開鍵

KSK秘密鍵＆署名＆署名
ZSK秘密鍵ZSK公開鍵

５

ルートKSKの更改（ルートKSKロールオーバー）について○ 2010年のルートKSKの導入以来、初めての鍵の更改が本年7月～来年3月にかけて予定されている。
○ これに伴い、キャッシュDNSサーバーを保有するISP等は、事前公開されているルートKSKの公開鍵の情報を更新する必要がある。
○ また、ルートKSKの円滑な更改のために、一時的に新旧両方のKSK公開鍵を送信する期間がある。当該期間は、送信されるデータ量が増大し、IPフラグメントが生じることがある※。ISP等の事業者は、自らのDNSの応答に係る経路上の機器の設定がIPフラグメントに対応可能か否かを事前に確認しておく必要がある。
※ なお、ルートDNSサーバーは、応答相手のDNSSEC対応・非対応に関わらず公開鍵情報を送信してしまうため、DNSSEC非対応の機器についてもIPフラグメントによる問題が生じる可能性がある。
ルートゾーン（最上位の管理者のため）
KSK公開鍵を事前公開①ルートDNSサーバーの公開鍵を新しいものに更新しておく必要

KSK公開鍵
IPアドレス

公開鍵の情報jp203.0.113.2

aaa

uk

203.0.113.3

bbbcom203.0.113.4

ccc・・・・・・・

KSK秘密鍵

今回初めて更改＆署名
ZSK公開鍵ZSK秘密鍵3ヶ月ごとに更改＆署名

ルートDNSサーバー

IPフラグメントとは・・・

ルートDNSサーバーの公開鍵の情報を事前に保有②データ量増大に伴うIPフラグメントが生じないことを確認しておく必要
キャッシュDNS
サーバー

通信のデータ量が通信機器の設定サイズを超過すると、当該データは分割されて転送される。これをIPフラグメントという。
さらにこの場合、経路上の機器の設定によっては、分割されたデータが破棄され、通信が正常に行われなくなる可能性がある。
今回のルートKSKの更改においては、定期的（3ヶ月ごと）に行われるルートZSKの更改とタイミングが重なる際に、IPフラグメントが生じることになる。
IPフラグメント
発生サイズ

＜通常時＞
ヘッダー

更改前ルートZSK公開鍵

更改前ルート
KSKによる署名
KSK公開鍵 KSK秘密鍵＜移行時（最大時）＞

インターネット利用者

ヘッダー

更改前ルートZSK公開鍵

更改前ルートKSK公開鍵

更改後ルートZSK公開鍵

＝更改後ルートKSK公開鍵KSKによる署名

クイックガイド:
ルート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月クリエイティブ・コモンズ表示-非営利

必要な操作新しいルートゾーンKSKは2017年2月に公開されており、ロールオーバーの実施前にいつでもシステムを更新できます。また、一部のシステムではすでに自動更新が行われている場合があります。以下の状況によって、実施する必要がある操作は異なります。

DNSSECトラストアンカー（RFC 5011）の自動アップデートがソフトウェアでサポートされている場合：

お使いのソフトウェアがDNSSECトラストアンカー（RFC 5011）の自動更新をサポートしていないか、または使用するように設定されていない場合：

KSKは適切なタイミングで自動的に更新されます。特にユーザーによる操作は必要はありません。
ロールオーバー中にオフラインになっているデバイスについては、ロールオーバーの完了後にオンラインになった場合、手動で更新する必要があります。

ソフトウェアのトラストアンカーファイルを手動で更新する必要があります。新しい
ルートゾーンKSKは、2017年3月以降、ここから入手できます。

ICANNは、2017年3月17日からテストベッドの提供を開始しています。
テストベッドを使用すると、事業者や関係者は、システムが自動更新プロセスを正しく処理できるかどうかを確認できます。詳細については、icann.org/kskrollをご覧ください。

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