4-2

DNS

1

DNSの動向2
森下 泰宏●株式会社日本レジストリサービス（JPRS） 広報宣伝室 技術広報担当

DNS の品質向上と機能拡張の推進を図るための「DNS flag day」が2019年2月1日に実施。DNSプライバシーの実装が進む一方、BIND
以外の脆弱性報告が増加している。

3

4■ルートゾーンKSKロールオーバーの状
況

間の連携や連絡体制の強化、さらなる情報提供1

2018年10月11日（協定世界時）、ルートゾーン

それらの活動や、ルートサーバーにおけるトラ

KSK ロールオーバーの作業ステップ「新 KSK（以ストアンカーの観測結果2 を踏まえ、ICANN では

下、KSK-2017）による署名開始」が実施された。

再延期の必要はないと判断。2018 年 9 月 16 日に

本作業は当初、1 年前の 2017 年 10 月 11 日に実開かれた理事会で、KSK-2017 による署名開始を施予定であった。しかし、準備が整っていないと当初予定から 1 年後となる、2018 年 10 月 11 日午考えられるフルリゾルバー（キャッシュDNSサー

後 4 時（協定世界時）に実施する旨を決定した3 。

などを実施してきた。

バー）が想定よりも多いことが調査により判明したため、延期されていたものである。

●作業の状況
2018年10月11日に実施されたKSK-2017によ●ルートゾーン KSK ロールオーバーとはる署名開始において、大きな問題の発生は報告さルートゾーン KSK ロールオーバーは、ルートれなかった。ICANN では 2018 年 10 月 15 日に、ゾーンのDNSSECで使われている鍵署名鍵（KSK）

いくつかの問題の発生が報告されたがそれらは迅を複数の作業ステップを経て、新しい鍵に更新す

速に対応され、KSK-2017 への更新は成功したとる作業である。ルートゾーンKSKロールオーバーする旨のプレスリリースを発表した4 。

そのものの概要と必要な作業、作業延期の経緯に

なお、.nlのレジストリSIDNが、作業中にRIPE

ついては『インターネット白書 2018』の「DNS

Atlas5 で観測された、署名の切り替わりの状況の動向」で解説しているので、そちらを参照されを公開している（資料 4-2-1）。キャッシュされたい。

た 署 名 が TTL 値 の 172800（48 時 間 ）に 従 い 、KSK-2010（id: 19036）によるものからKSK-2017●作業延期後の ICANN の対応
ICANN では問題解決のため、問題となったソ（id: 20326）によるものに切り替わっていく状況
が、グラフで示されている。

フトウェアの調査と特定、未対応のフルリゾル
バーが設置されている組織への個別連絡、関係者

インターネット白書／ ©1996-2019 Impress R&D
第4部

サイバーセキュリティ動向

203

5

1

●今後の作業予定

サーバーの双方が EDNS0 に対応している必要

今後、旧 KSK（KSK-2010）を失効させる作業がある。また、通信途中のネットワーク機器がが、2019 年 1 月 11 日から 3 月 22 日まで実施され

EDNS0 機能を有効にした問い合わせ／応答を、

6

2

る予定である 。この作業の期間中、ルートゾー
ンの DNSKEY リソースレコードの応答サイズが、1425 バイトに増大する（資料 4-2-2）。

3

適切に中継する必要がある。
しかし、送信先の権威DNSサーバーや通信途中のネットワーク機器が EDNS0 に対応していない

この作業により、今回のルートゾーンKSKロー

ことで、権威DNSサーバーからの応答が得られな

ルオーバーの一連の作業ステップは完了となる。

い場合がある。こうした場合に対応するため、主要な DNS ソフトウェアでは EDNS0 機能を有効に

45■ DNS flag day の実施した問い合わせの応答が得られなかった場合、問2019 年 2 月 1 日に「DNS flag day」というイベい合わせた側が EDNS0 機能を無効にして同じ内

ントが、DNS関係者の間で実施される。本イベン

容を再問い合わせする「ワークアラウンド処理」

トでは、2019 年 2 月 1 日以降にリリースされる主が実行される（資料 4-2-4）。

要な DNS ソフトウェアから EDNS0 に関するワー
クアラウンド処理（後述）が削除される。
この動作の変更に伴う名前解決エラーや名前解

今回の DNS flag day により、このワークアラ
ウンド処理が、主要な DNS ソフトウェアから削除される。

決の遅延の発生を防ぐため、EDNS0 に対応していない権威 DNS サーバーやネットワーク機器において、対応作業が必要になる可能性がある。

● DNS flag day の背景／理由
DNS flag day の実施に至った背景／理由として、以下の 2 つが挙げられる。
1 つは、DNS ソフトウェア／サービスの品質と● DNS flag day の概要
2018年12月5日現在、資料4-2-3に挙げたオー

パフォーマンスの向上である。

プンソースの DNS ソフトウェアベンダーとパブワークアラウンド処理は例外処理であり、バグ

リック DNS サービスの事業者が、DNS flag day

や脆弱性の要因となる。また、再送処理により全への参加・サポートを表明している。

体のパフォーマンスも低下する。こうした処理を【EDNS0 の概要とワークアラウンド処理】減らして、DNSの安定性と効率の向上を図る狙い

DNS flag day の概要と背景、その影響を知るがある。

には、EDNS0 の概要と現在の対応状況を知る必

もう 1 つは、DNS における新機能の導入・機能要がある。ここでは、それらについて説明する。

拡張の推進である。ワークアラウンド処理は短期

EDNS0 は RFC 6891 で定義される、DNS の機的な問題解決手段としては有効であるが、EDNS0

能拡張方式である。DNSSEC や DNS の IPv6 対応を用いた新機能の導入や機能拡張を図る上での障をはじめとするさまざまな機能拡張に対応するた害となる。ワークアラウンド処理を取りやめるこめ、512バイトを超える大きなDNSメッセージをとで EDNS0 への対応を進め、新機能の導入・機通信コストの低い UDP で扱えるようにし、応答能拡張の推進を図る狙いがある。

のフラグや応答コードも拡張する。
EDNS0 対応では、フルリゾルバーと権威 DNS

インターネット白書／ ©1996-2019 Impress R&D

204

第4部

サイバーセキュリティ動向

資料 4-2-1

RIPE Atlas における署名鍵の変化の状況（SIDN Labs の調査）

1

2

3

4

5
出典：SIDN : A successful root KSK rollover: a brief look backge̲id=2

資料 4-2-2

https://www.sidnlabs.nl/a/weblog/a-successful-root-ksk-rollover-a-short-look-back?langua

ルートゾーン KSK ロールオーバーの作業ステップと実施時期

出典：筆者作成● DNS flag day の影響

果、特定のドメイン名の名前解決エラーや、名前

ワークアラウンド処理が削除されるため、解決の遅延が発生する可能性がある（資料4-2-5）。

EDNS0 に対応していない権威 DNS サーバーか

DNS flag day では、通信途中のネットワーク機らの応答が得られなくなる可能性がある。その結インターネット白書／ ©1996-2019 Impress R&D
第4部

サイバーセキュリティ動向

205

1

資料 4-2-3 DNS flag day への参加・サポートを表明しているオープンソース DNS ソフトウェアベンダー・パブリック DNS サービス事業者（2018 年 12 月 5 日現在）

2

3

4

出典：https://dnsflagday.net/

資料 4-2-4

フルリゾルバーにおけるワークアラウンド処理

5

出典：筆者作成

器の EDNS0 対応にも注意が必要である。通信途の処理が適切でない場合などが挙げられる。

中に EDNS0 に対応していないネットワーク機器があった場合、前述したケースと同様、名前解決
エラーや名前解決の遅延が発生する可能性がある●影響が出る時期
DNS flag day で動作が変更されるのは、2019
年 2 月 1 日以降にリリースされる DNS ソフトウェ（資料 4-2-6）。
該当する機器の例として、EDNS0 機能を有効アである。そのため、各組織のフルリゾルバーににしたパケットがドロップされる場合や、IP フラ

おいて DNS flag day の影響が出るのは、2019 年

7

グメンテーション により断片化されたパケット

2 月 1 日以降にリリースされたバージョンにフル

インターネット白書／ ©1996-2019 Impress R&D

206

第4部

サイバーセキュリティ動向

資料 4-2-5

DNS flag day の影響（1）

1

2

3

4

5
出典：筆者作成

資料 4-2-6

DNS flag day の影響（2）

出典：筆者作成

リゾルバーを更新後、EDNS0 に対応していない

ソフトウェアを適切に更新してシステムを最新権威 DNS サーバーが管理するドメイン名を名前の状態に保つことは、セキュリティレベルの維持解決しようとしたタイミングとなる。

やシステムの安定運用における必須項目である。

【DNS ソフトウェアの更新の必要性】

DNS flag day の影響を回避するために古いバー

インターネット白書／ ©1996-2019 Impress R&D
第4部

サイバーセキュリティ動向

207

1

ジョンの DNS ソフトウェアを使い続けることは、術の概要と、現在の実装状況について解説する。

セキュリティやシステム運用における大きなリス● DNS におけるプライバシー上の懸念点とそのクとなるため、推奨されない。

2

解決方法●対応状況の確認方法

DNS におけるプライバシー上の懸念点を、資8

DNS flag day の公式サイト で、指定したド

3

4

5

料 4-2-8 に示す。

メイン名が DNS flag day の影響を受けるかどう

従来の DNS 通信は暗号化されておらず、ネッ

かを確認可能である（資料 4-2-7）。
「Test yourトワーク上を平文でやりとりされる。そのため、

domain」の入力フォームにドメイン名を入力し、スタブリゾルバー（クライアント）からフルリゾ「Test」ボタンをクリックすると、テスト結果が表ルバーへの通信をモニターすることで、どのホス示される。

トが、いつ、何を問い合わせたのかという情報を結果は、「GO」「！」「SLOW」の 3 種類のアイ得ることができる（懸念点 1）。また、フルリゾル

コンで表示される。「SLOW」アイコンが表示さ

バー上でアクセスログを収集することでも、同様れた場合、そのドメイン名を管理する権威 DNSの情報を得ることができる（懸念点 2）。

サーバーや、その権威 DNS サーバーが接続されまた、フルリゾルバーはスタブリゾルバーかているネットワーク機器において、確認・対応作

ら受け取った問い合わせ内容（ドメイン名／タイ業が必要になる。

プ）を、権威 DNS サーバーにそのまま問い合わ

ま た 、公 式 サ イ ト で は DNS 管 理 者 向 け に 、9せる。そのため、ルートサーバーや TLD の権威

ednscomp を 用 い た 確 認 を 呼 び か け て い る 。

DNSサーバーではフルリゾルバーを介して、クラednscomp は BIND の開発元の ISC が公開していイアントが問い合わせた内容を、ある程度得られ

る EDNS0 の対応状況を調べるツールで、実行することになる（懸念点 3）。

ると、詳細な調査結果が表示される。

そのため、これらの懸念点に対応するための活動が IETF で進められることとなった。その結果、■ DNS プライバシーの概要と実装状況

懸念点 1 については、スタブリゾルバーとフルリ

プライバシー保護に対する意識の高まりを受ゾルバーの間の通信を暗号化するための方式が標け、DNS においてもプライバシー保護のための準化された。また、懸念点 3 については、名前解技術が注目されている。2018 年には主要なパブ

決のアルゴリズムを変更し、フルリゾルバーが権

リックDNSサービス、スマートフォン、ウェブブ

威 DNS サーバーに必要最低限の情報のみを送る

ラウザーなどのコンシューマー向けの環境においようにするための方式が標準化された。

て、DNS プライバシー関連技術の実装・普及が進懸念点 2 については、日本の ISP では憲法／電気通信事業法における、通信の秘密の保護の対象んだ。
また、この技術はいわゆる DNS ブロッキングとなっている。ただし、会社や学校などの組織はの回避手段としても利用可能である。そのため、電気通信事業者ではないため、独自のモニタリン

DNS ブロッキングに対する関心の高まりと共に、

グや、その結果を利用した独自のブロッキング、

インターネット利用者の関心も高まっている。

フィルタリングを実施している場合がある。

本節では、DNSプライバシーを実現する要素技

なお、パブリック DNS サービスにおけるアクインターネット白書／ ©1996-2019 Impress R&D

208

第4部

サイバーセキュリティ動向

資料 4-2-7

DNS flag day 公式サイトでの確認結果とその意味

1

2

3

4

5
出典：筆者作成

資料 4-2-8

DNS におけるプライバシー上の懸念点

出典：筆者作成

セスログの取り扱いについては、別途後述する。

DNS over TLS は、DNS の通信を TLS10 で保護／暗号化するための技術である。

● DNS over TLS の概要と実装状況【DNS over TLS の概要】

DNS over TLS の通信には、TCP のポート 853
番が割り当てられている。通信の内容は従来のインターネット白書／ ©1996-2019 Impress R&D
第4部

サイバーセキュリティ動向

209

1

TCP の DNS と同じものを、TLS で保護／暗号化をそのフォーマットのままで取り扱う。たとえしたものである。

ば、GETで資料4-2-10のようなリクエストを送る

DNS over TLS は、スタブリゾルバーとフル

2

3

リゾルバーの間の通信に使うことが想定されて

5【DNS over HTTPS の実装状況】

いる。DNS over TLS を使うことでスタブリゾル

前述した1.1.1.1が、DNS over HTTPSを実装しバーとフルリゾルバーの間の通信が保護され、通ている。1.1.1.1 では RFC 8484 方式の DNS over

信内容を傍受することができなくなる。

HTTPS に加え、データを JSON13 で表現した独【DNS over TLS の実装状況】

自方式の DNS over HTTPS を実装している。な

NLnet Labsが開発しているUnboundが、DNS

4と、DNS パケットのフォーマットで応答が返る。

over TLS を実装している。パブリック DNS サー

お、Google Public DNSも、独自方式のDNS over
HTTPS を実装している。

ビ ス で は 、CleanerDNS が 運 用 す る Quad9 やスタブリゾルバーではウェブブラウザーのCloudflare と APNIC が共同運用する 1.1.1.1 が、Firefox が、DNS over HTTPS を実装している。

DNS over TLS を実装しており、Google Public

ただし、デフォルトでは無効に設定されており、DNS も 2019 年 1 月 9 日から、DNS over TLS の使用する場合、ネットワーク設定のメニューで有サービスを開始している11 。

効にする必要がある（資料 4-2-11）。
12

スタブリゾルバーでは getdns API が、DNS

また、Alphabet（Googleの持株会社）の子会社のover TLS を実装している。また、Android 9.0 以

Jigsawが、DNS over HTTPSを実装したAndroid

降のスタブリゾルバーには DNS over TLS が標準用アプリ「Intra」を公開しており、無償で利用可能

で組み込まれており、指定されたフルリゾルバー

である14 。Intra では問い合わせ先として Google

で DNS over TLS が利用可能な場合、自動的に有Public DNS、1.1.1.1、それ以外を指定できる。

効に設定されるようになっている（資料 4-2-9）。

Intra はオープンソースソフトウェアであり、GitHub でソースが無償公開されている15 。ソー● DNS over HTTPS の概要と実装状況

スコードによるとGoogle Public DNSを指定した【DNS over HTTPS の概要】

場合、前述した独自方式の DNS over HTTPS が

DNS over TLS では、TCP のポート 853 番が通使われるようになっている。

信に使われる。しかし、制限されたネットワーク
環境ではこのポートへの通信がブロックされてい● QNAME minimisation の概要と実装状況る場合があり、DNS over TLS を使えないことに【QNAME minimisation の概要】

なる。

QNAME minimisation は、フルリゾルバーの名

そうした背景から、DNS の通信にウェブの通前解決アルゴリズムを変更し、ルートサーバーや信で使われる HTTPS を使うアイデアが提案されTLD の権威 DNS サーバーには名前解決に必要なた。このための技術が、DNS over HTTPS であ

最低限の情報のみを問い合わせるようにする技術

る。DNS over HTTPS では、DNS の通信はウェである。

ブの通信と同様、HTTPS で保護／暗号化される。
RFC 8484で定義されているDNS over HTTPS
では GET/POST メソッドにより、DNS パケット従 来 の フ ル リ ゾ ル バ ー の 動 作 と QNAME
minimisation の比較を、資料 4-2-12 に示す。
QNAME minimisationにより、フルリゾルバー

インターネット白書／ ©1996-2019 Impress R&D

210

第4部

サイバーセキュリティ動向

資料 4-2-9

Android 9.0 の DNS over TLS 設定画面

1

2

3

4

5
出典：https://developers-jp.googleblog.com/2018/05/dns-over-tls-support-in-android-p.html

資料 4-2-10

DNS over HTTPS のリクエストの例

出典：RFC 8484

はクライアントが問い合わせたドメイン名・タイ

問い合わせたドメイン名、タイプを知ることがでプをルートサーバーや TLD の権威 DNS サーバーきなくなる。

に送信しなくなる。そのため、ルートサーバーや

ただし、DNSではドメイン名のラベルの区切り

TLD の権威 DNS サーバーでは、クライアントがとゾーンの境界（ゾーンカット）は、必ずしも一

インターネット白書／ ©1996-2019 Impress R&D
第4部

サイバーセキュリティ動向

211

1

資料 4-2-11

Firefox 63.0.3 の DNS over HTTPS 設定画面

2

3

4

5
出典：筆者作成

資料 4-2-12

従来の動作（左）と QNAME minimisation（右）の比較

出典：筆者作成

致していない。そのため、QNAME minimisation【QNAME minimisation の実装状況】

を適用した場合、フルリゾルバーから権威 DNSCZ.NIC が開発している Knot Resolver や前述

サーバーに対し、無駄な問い合わせが発生する可した Unbound など、複数のフルリゾルバーが能性がある。

QNAME minimisation を実装しており、標準でインターネット白書／ ©1996-2019 Impress R&D

212

第4部

サイバーセキュリティ動向

有効になっている。また、BIND も開発版のバー化と、2017 年から 2018 年にかけて発生した 2 つ

ジョン 9.13.2 で、QNAME minimisation を実装の特徴的な事例を紹介するとともに、ドメイン名している。

ハイジャックに備えるための、各組織における対パブリック DNS サービスでは前述した 1.1.1.1

策について解説する。

1

2

が QNAME minimisation を実装しており、標準●ドメイン名ハイジャックの目的の変化

で有効になっている。

実利の獲得を狙った目的の具体例としては、ア●パブリック DNS サービスにおけるアクセスロ

カウント情報の不正入手、仮想通貨の不正送金、グの取り扱い計算機資源の不正使用（例：仮想通貨のマイニン

パブリック DNS サービスではそれぞれの運用元により、アクセスログとして取得・保存する情報の内容や取り扱いが異なっている。

3グ）などが挙げられる。
以下で紹介する 2 つの事例も、実利の獲得を4図ったものである。いずれも、2017 年から 2018

Google Public DNS はDDoS攻撃の検知や問題の修正のため、送信元のIPアドレスをアクセスロ

年にかけて発生した。

5

事例 1：Fox-IT 社

グに一時的に保存している。また、保存用のログ

2017 年 12 月に、オランダのセキュリティ企業には送信元の都市レベルの位置情報が含まれておであるFox-ITが、自社の顧客向けポータルサイト

16

り、ランダムサンプリングで抽出・保存される 。

がドメイン名ハイジャックの被害を受けた際の経

一方、1.1.1.1 は送信元の IP アドレスをアクセ

過と対応をまとめた、レポートを公開した18 。

スログに保存しておらず、保存用のログには位置17情報が含まれていない 。

この事例では、ドメイン名ハイジャックがサー
バー証明書の不正発行・不正使用のために使わ

また、Cloudflareでは1.1.1.1から得られたデー

れ、HTTPS に対する攻撃が行われた。攻撃者はタを、共同運用する APNIC 以外の第三者に提供

レジストラのログインID・パスワードをクラックしないことを表明しており、APNIC が利用可能

して、ドメイン名 fox-it.com の設定を書なデータの用途を、共同研究契約に基づく非営利

き換える権限を入手した後、以下の 2 段階の手順の運用研究に限定している。

により、HTTPS への攻撃を成功させた。

■ドメイン名ハイジャックの状況

1. メール関連のDNS設定を不正変更した後、メードメイン名ハイジャックは、ドメイン名の管理

ル認証を用いてサーバー証明書の発行を認証局に権限を持たない第三者が、不正な手段で他者のド申請、正規の手順でサーバー証明書を不正発行／

メイン名を自身の支配下に置く行為である。

不正入手した（資料 4-2-13）。

ドメイン名ハイジャック自体は、以前から知ら

2. 不正入手したサーバー証明書をインストール

れている攻撃手法である。しかし、最近の事例でして顧客向けポータルサイトの偽サイトを作成、は攻撃の目的が、従来よく見られた示威行為や主

当該サイトの IP アドレスを変更して、顧客のア

義・主張のアピールから、実利の獲得を狙ったもクセスを偽サイトに誘導した。なお、この偽サイのに変化している。

トは受け付けた入力を、本物のポータルサイト

本節では、ドメイン名ハイジャックの目的の変にリダイレクトするように設定されていた（資料

インターネット白書／ ©1996-2019 Impress R&D
第4部

サイバーセキュリティ動向

213

1

資料 4-2-13

メール関連の DNS 設定を変更後、正規の手順でサーバー証明書を不正発行

2

3

4

5
出典：筆者作成

偽の権威 DNS サーバーに誘導された。その結果、

4-2-14）。
この結果、Google Public DNS に偽の DNS 応答が注入され、・URL のドメイン名は正しいが、接続先は偽サ被害が拡大した19 。

イトである・HTTPS接続の際、Webブラウザーが警告を表●ドメイン名ハイジャックの対策
前述したように、ドメイン名ハイジャックの主示しないという状況となり、偽サイトであると気付かずにな目的が示威行為や主義・主張のアピールから、ログインを試みた複数の顧客のアカウント情報

実利の獲得にシフトしている。そのため、著名企が、攻撃者に流出した。

業やポータルサイトのドメイン名に加え、顧客向

事例 2：MyEtherWallet

けポータルサイトや仮想通貨の保管・取引に使う

2018 年 4 月に、仮想通貨イーサリアムのウォ

ドメイン名なども、攻撃の標的となっている。

レット（保管所）を提供する MyEtherWallet が、一方、ドメイン名ハイジャックに用いられる手

ドメイン名ハイジャックの被害を受けた。この事

法は従来と同様、レジストリの登録情報の不正書

例では攻撃手法として、MyEtherWallet が当時、き換えによるものが中心である。それに加え、経ドメイン名 myetherwallet.com の管理に使用し路ハイジャック、サーバー証明書に対する攻撃ていた Amazon Route 53 を標的とした、経路ハとの併用・攻撃の隠蔽など、これまであまり見らイジャックが用いられた。

れなかった手法や、手法の洗練も見られるように

本件では、Google Public DNSからのDNSクエ
リが経路ハイジャックによって攻撃者が準備したなってきている。
こうした状況に対応するためには、ドメイン名

インターネット白書／ ©1996-2019 Impress R&D

214

第4部

サイバーセキュリティ動向

資料 4-2-14

HTTPS を終端・復号後、正規のサイトに転送

1

2

3

4

5
出典：筆者作成／ DNS 単体での対策ではなく、組織そのもののBIND であるが、2018 年は脆弱性の報告件数は

リスクマネジメントの一環としてとらえ、対策す6 件と、昨年の 12 件に比べ減少した。

ることが重要である。具体的な対策としては、自資料4-2-15に、2018年中にJPRSが注意喚起し組織で使っているドメイン名の状況把握、信頼でた BIND の脆弱性の一覧を示した。これらのうちきる事業者やサービスの利用、事業者が提供する緊急のものは 1 件であり、こちらも昨年の 5 件にロックサービスや認証サービスの利用、監視サー比べ減少している。

ビスの導入・利用などが挙げられる。
なお、経路ハイジャックについては DNS 運用● BIND 以外の DNS ソフトウェアの状況

者における対策は困難であり、AS 運用者におけ

BINDの脆弱性報告数が減少した一方、BIND以る対策が必要である。その 1 つとして、Amazon

外の DNS ソフトウェアの脆弱性がコンスタント

Route 53 では MyEtherWallet の事例の後、経路に報告されるようになった。資料4-2-16に、2018

ハイジャックの影響を最小限に抑えるための対年中に JPRS が注意喚起した BIND 以外の DNS ソ

20

策 を実施している。

フトウェアの脆弱性の一覧を示した。
脆弱性の報告件数が増加した背景として、BIND■ DNS サーバーソフトウェアの脆弱性の状況

以外のソフトウェアの開発が進み、それらのソフ● BIND の脆弱性の状況挙げられる。

トウェアの利用者や、利用機会が増加したことがこれまで数多くの脆弱性が報告されてきたインターネット白書／ ©1996-2019 Impress R&D
第4部

サイバーセキュリティ動向

215

1

資料 4-2-15

2018 年に JPRS が注意喚起した BIND の脆弱性

2

3
出典：筆者作成

資料 4-2-16

2018 年に JPRS が注意喚起した BIND 以外の DNS ソフトウェアの脆弱性

45

出典：筆者作成

1.

ICANN、KSK ロールオーバーにおける注意事項についての包括的なガイドを発行‒ ICANN

2.

9-ja
5.

れたプローブ（測定のために設置される専用の機器）からデー

7-ja

タを収集し、さまざまな調査・研究に活用することを目的とし

RFC 8145 Root Trust Anchor Reportshttp://root-trust-aている。

nchor-reports.research.icann.org/
3.

4.

RIPE NCC が進めているプロジェクトの 1 つ。世界中に設置さhttps://www.icann.org/news/announcement-2018-08-2

ニ ュ ー ス リ リ ー ス：KSK の ロ ー ル に 関 す る 理 事 会 の 承 認 ‒https://atlas.ripe.net/
6.

The Recent KSK Rollover: Summary and Next Steps ‒

ICANN

ICANN

https://www.icann.org/resources/press-material/releas

https://www.icann.org/news/blog/the-recent-ksk-rollove

e-2018-09-18-ja

r-summary-and-next-steps

最初のルート KSK ロールオーバーが正常に完了‒ ICANN
https://www.icann.org/news/announcement-2018-10-1

7.

サイズの大きな IP パケットを、その IP パケットのサイズより小さな最大転送単位（MTU）を持つネットワークを通して中継す

インターネット白書／ ©1996-2019 Impress R&D

216

第4部

サイバーセキュリティ動向

る際に必要となる仕組み。MTU を超える IP パケットは MTU を

1

超えないサイズに分割され、分割された IP パケットは、以降、そのままの形で転送される。
8.

DNS flag day

9.

EDNS Compliance Tester

https://dnsflagday.net/
https://ednscomp.isc.org/edn

2

scomp/
10. TCP のようなコネクション型の通信を保護するためのプロトコル。以前は SSL という名前で開発されていたが、したが、IETF
での標準化の際、TLS という名称に変更された。
11. Google Public DNS now supports DNS-over-TLS

3https://security.googleblog.com/2019/01/google-publi
c-dns-now-supports-dns-over.html
12. Welcome to getdns!https://getdnsapi.net/
13. JavaScript Object Notation。JavaScript のオブジェクト表記

4

方法に由来する、簡便なデータ記述方法。
14. Intra - Google Play のアプリhttps://play.google.com/store/
apps/details?id=app.intra
15. GitHub - Jigsaw-Code/Intra: An experimental tool that allows you to test new DNS-over-HTTPS services on Android

5

https://github.com/Jigsaw-Code/Intra
16. Your Privacy/Public DNS/Google Developers
https://developers.google.com/speed/public-dns/privacy
17. Cloudflare 1.1.1.1 CLOUDFLARE RESOLVER PRIVACYFREQUENTLY ASKED QUESTIONS
https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/privacy-policy/
18. Lessons learned from a Man-in-the-Middle attack ‒ Fox-IT
International blog
https://blog.fox-it.com/2017/12/14/lessons-learned-fro
m-a-man-in-the-middle-attack/19. Official statement regarding DNS spoofing of MyEtherWallet domain ‒ MyEtherWallet
https://www.reddit.com/r/MyEtherWallet/comments/8elo
o9/official̲statement̲regarding̲dns̲spoofing̲of/
20. 広告する経路を、グローバルな経路広報が可能な最小サイズである/24 に変更。

インターネット白書／ ©1996-2019 Impress R&D
第4部

サイバーセキュリティ動向217［インターネット白書 ARCHIVES］ご利用上の注意

このファイルは､ 株式会社インプレスR&D が 1996年〜 2019 年までに発行したインターネットの年鑑『インターネット白書』の誌面をPDF 化し､ ｢インターネット白書 ARCHIVES｣として
以下のウェブサイトで公開しているものです。

https://IWParchives.jp/
このファイルをご利用いただくにあたり、下記の注意事項を必ずお読みください。
●記載されている内容（技術解説、データ、URL、名称など）は発行当時のものです。
●収録されている内容は著作権法上の保護を受けています｡ 著作権はそれぞれの記事の著作者（執筆者、写真・図の作成者､ 編集部など）が保持しています。
●著作者から許諾が得られなかった著作物は掲載されていない場合があります。
●このファイルの内容を改変したり、商用目的として再利用したりすることはできません。あくま
で個人や企業の非商用利用での閲覧、複製、送信に限られます。
●収録されている内容を何らかの媒体に引用としてご利用される際は、出典として媒体名および年号、該当ページ番号、発行元（株式会社インプレスR&D）などの情報をご明記ください。
●オリジナルの発行時点では、株式会社インプレスR&D（初期は株式会社インプレス）と著作権者は内容が正確なものであるように最大限に努めましたが､ すべての情報が完全に正確であることは保証できません｡このファイルの内容に起因する直接的および間接的な損害に対して、一切の責任を負いません。お客様個人の責任においてご利用ください。

お問い合わせ先│株式会社インプレス R&D│

U iwp-info@impress.co.jp│©1996-2019 Impress R&D