.jprs DNS のローカルノード設置の技術実験
研究報告書
第 1.0 版

2017 年 10 月

株式会社日本レジストリサービス
北海道総合通信網株式会社
東北インテリジェント通信株式会社
北陸通信ネットワーク株式会社
株式会社ケイ・オプティコム
株式会社エネルギア・コミュニケーションズ
株式会社 STNet
株式会社 QTnet
沖縄通信ネットワーク株式会社
1

2017-10-31

Copyright © 2017
日本レジストリサービス,
北海道総合通信網株式会社,
東北インテリジェント通信株式会社,
北陸通信ネットワーク株式会社,株式会社ケイ・オプティコム,
株式会社エネルギア・コミュニケーションズ,株式会社 STNet,株式会社 QTnet,
沖縄通信ネットワーク株式会社
All Rights Reserved.

2

2017-10-31

目次
1

研究開発の概要.......................................................................................................................... 4

1.1

研究開発の背景・研究目的 ................................................................................................. 4

1.2

研究の目標 .......................................................................................................................... 9

1.3

研究体制 ............................................................................................................................ 10

1.4

当該研究開発の連絡窓口 ................................................................................................... 12

2

本論 ......................................................................................................................................... 13

2.1

全体 ................................................................................................................................... 13

2.2

株式会社日本レジストリサービス ..................................................................................... 17

2.3

北海道総合通信網株式会社 ............................................................................................... 20

2.4

東北インテリジェント通信株式会社 ................................................................................. 222.5

北陸通信ネットワーク株式会社 ........................................................................................ 25

2.6

株式会社ケイ・オプティコム ............................................................................................ 27

2.7

株式会社エネルギア・コミュニケーションズ ................................................................... 30

2.8株式会社 STNet ................................................................................................................ 32

2.9

株式会社 QTnet ................................................................................................................ 35

2.10

沖縄通信ネットワーク株式会社 ........................................................................................ 39

3

総括 ......................................................................................................................................... 41

3.1

まとめ ............................................................................................................................... 41

3.2

権威 DNS サーバーの設置方法の評価 ............................................................................... 41

3.3

副次的に得られた結果....................................................................................................... 42

3.4

今後の課題 ........................................................................................................................ 44

3.5

研究の成果 ........................................................................................................................ 44

3.6

注記事項 ............................................................................................................................ 46

3

2017-10-31

1 研究開発の概要
1.1

研究開発の背景・研究目的

1.1.1 研究の背景と目的
DNS は、インターネットを使用した階層的な分散型データベースシステムである。インターネッ
ト上で提供されるサービスは、その識別子としてドメイン名が使用されることが多い。そのドメイ
ン名を IP アドレスへ変換する「名前解決」が行われることで、サービス利用者はサービス提供者の提供サーバー等の IP アドレスを知ることができ、両者間の通信路を確立することができる。
図 1 は、ドメイン名の名前解決を行う際に登場する DNS クライアント、フルリゾルバ及び権威
DNS サーバーの関係を示した図である。ドメイン名の名前解決は、フルリゾルバが DNS クライアントからの名前解決の要求（①）を受け、ドメイン名の階層別に存在する権威 DNS サーバー（②、③）へ問合せを行うことで実現されている。
フルリゾルバ側
ネットワーク②問合せ
ルートサーバー①名前解決の要求
DNS クライアント

権威 DNS 側
ネットワークフルリゾルバ（Web ブラウザなど）③問合せ
権威 DNS サーバー

図 1：ドメイン名の名前解決における構成要素間の関係

図 1 で示すように、ドメイン名の名前解決は、階層別に存在する権威 DNS サーバーと名前解決を行うフルリゾルバとが相互に協調することで実現されている。ドメイン名の名前解決の過程において登場する各階層の権威 DNS サーバーのうち、いずれか 1 つの階層で正しく応答できない状態が発生すると、そのドメイン名の名前解決が行われなくなる。一般的に、各階層の権威 DNS サーバ
ーは異なる組織で運用されており、そのサービス基準も組織ごとに異なる。
各階層の権威 DNS サーバーの安定的かつ継続的に提供されることが、インターネットサービス全体の安定的かつ継続的な提供のための前提条件となる。
フルリゾルバと権威 DNS サーバー間の分断
大規模災害の発生等を起因として、ドメイン名の名前解決を行うフルリゾルバが設置された側のネットワーク（以下、フルリゾルバ側ネットワーク）と、各権威 DNS サーバーが属するネットワー
ク（以下、権威 DNS 側ネットワーク）とが分断されてしまうケースを考える。フルリゾルバ側ネットワーク及び権威 DNS 側ネットワークが分断されてしまうと、フルリゾルバ側ネットワークから権威 DNS 側ネットワークへの到達性は確保できないことから、フルリゾルバによるドメイン名の名前解決が中断する可能性が高まる。ドメイン名の名前解決は、DNS が有する階層的な分散型
4

2017-10-31

データベース構造だけではなく、フルリゾルバ及び権威 DNS サーバーの各々が属するネットワー
ク間の到達性にも依存していることがわかる。
また、両者間のネットワークが分断されることにより、権威 DNS サーバーが管理するドメイン名のデータ（ゾーンデータ）とフルリゾルバが一時的に記憶しているゾーンデータとの間にデータ不整合が生じ、ドメイン名の名前解決が適切に実施できなくなる可能性も高まる。
ここで説明した、フルリゾルバ及び権威 DNS サーバーが異なるネットワークに属する環境下においては、フルリゾルバ側ネットワーク内で提供されているインターネットサービスであっても、両者間のネットワークの分断によってドメイン名の名前解決が不可となると、フルリゾルバ側ネット
ワーク内のインターネットサービスの安定的な提供も不可となる。
本研究は、JPRS が管理する TLD「.jprs」の権威 DNS サーバーを参加事業者のネットワーク内に設置することにより、大規模災害が発生した場合においても、当該 TLD を使ったインターネット
上のサービスが継続的に利用できることの評価を目的とする。

1.1.2 実施対象の研究
権威 DNS サーバー及びフルリゾルバの設置方法
権威 DNS 側ネットワーク及びフルリゾルバ側ネットワーク間のネットワーク分断を想定したとき、その分断時においてもドメイン名の名前解決が継続可能とするためには、各々のネットワーク
内にフルリゾルバ及び権威 DNS サーバーの設置が考えられる。


設置 1：フルリゾルバ側ネットワークに、権威 DNS サーバーを設置する



設置 2：権威 DNS 側ネットワークに、フルリゾルバを設置する

一方、各々のネットワークへフルリゾルバ及び権威 DNS サーバーを設置する際、その設置する
DNS サーバーへ割り当てる IP アドレスの種別によって、ネットワーク分断時の振る舞いに影響を及ぼす可能性がある。この IP アドレスの割当方法としては、次の 2 方式が考えられる。


方式 A：設置先ネットワーク内に個別の専用ネットワーク（自律システム（AS））を設置
し、その中に DNS サーバーを設置する



方式 B：設置先ネットワークで払い出し済みの IP アドレスを DNS サーバーに割り当てる

本研究の検証環境としては、設置 1・2 と方式 A・B の組み合わせの４パターンが考えられる。
表 1：検証環境の構成パターン

ネットワーク名設置する DNS
サーバー種別パターン 1-A
パターン 1-B
パターン 2-A

フルリゾルバ側
ネットワーク
フルリゾル
権威
バ【主】
DNS
○
●
○
○
○
－
5

権威 DNS 側
ネットワーク
フルリゾル
権威
バ【従】
DNS
－
●
－
●
○
●
2017-10-31

パターン 2-B○－○：フルリゾルバ側ネットワークの払い出し IP アドレス●●●：権威 DNS 側ネットワークの払い出し IP アドレス
本研究では、1.1.1 で示したように、フルリゾルバと権威 DNS サーバー間の分断が発生した状況下
でも、DNS クライアントからはドメイン名の名前解決及びインターネットサービスが継続的に提供されることを検証（図 1 内の③が、不可の状況）する。DNS クライアントとフルリゾルバ間の分断が発生する状況下での検証は、本研究の範囲外とする（図 1 内の①が不可の状況）。パターン
1-A 及び 1-B を検証環境として構築のうえ、実施する。

以下は、検証対象であるパターン 1-A／1-B における模式図及び検証内容を記述する。

【パターン 1-A／パターン 1-B】フルリゾルバ側ネットワークへの、権威 DNS サーバーの設置
図 2 は、フルリゾルバ側ネットワークに権威 DNS サーバーを設置した場合の模式図である。
権威 DNS 側
ネットワークフルリゾルバ側
ネットワーク
権威 DNS

権威 DNS

フルリゾルバ【主】

DNS クライアント

図 2：フルリゾルバ側ネットワーク内に権威 DNS サーバーを設置

DNS クライアントは、フルリゾルバ側ネットワークに設置されているフルリゾルバに対して名前解決を要求する。フルリゾルバ側ネットワークと権威 DNS 側ネットワーク間の到達性が確保されている場合においては、権威 DNS 側ネットワークに存在する権威 DNS サーバー【主】へ名前解決の問合せが行われる（図 2 内の実線）。しかしながら、その間の到達性が確保されていない状況
下（図 2 内の×）においては、フルリゾルバ側ネットワークに設置した権威 DNS サーバー【従】
によって名前解決が実施される（図 2 内の太実線）と考えられる。
案 1 では、.jprs の権威 DNS サーバーをフルリゾルバ側ネットワークに設置（方式 A 及び B ともに実施する）した状況下における、フルリゾルバ側ネットワークと権威 DNS 側ネットワーク間の分断を題材として、次の研究を行う。
(ア) フルリゾルバ側ネットワークと権威 DNS 側ネットワークが分断されることで、フルリゾルバ
側ネットワークと権威 DNS 側ネットワークに各々に設置された権威 DNS サーバーが保持す6

2017-10-31

る.jprs ゾーンデータの不整合（SOA レコード、NS レコードの不一致等）が生じる。
フルリゾルバ側ネットワークから権威 DNS 側ネットワークへの到達性がない状況下においても、.jprs ゾーンデータの不整合の発生を許容することにより、.jprs ドメイン名の名前解決の提供が担保されることを、レジストリオペレーターの視点から検証する。
権威 DNS 側
ネットワーク- ASXXXX

フルリゾルバ側
ネットワーク - ASXXXX
権威 DNS 側
ネットワーク- ASXXXX
権威 DNS

権威 DNS

フルリゾルバ【主】

DNS クライアント

図 3：(ア)におけるシステム環境構成（方式 A）(イ) フルリゾルバ側ネットワーク内に、.jprs のセカンドレベルドメイン名（2LD）の権威 DNS サーバー及び当該 2LD のインターネットサービスの提供サーバーを設置した環境において、(ア)と同一の状況を生じさせる。
フルリゾルバ側ネットワークに設置したフルリゾルバから JPRS 側ネットワークへの到達性がない状況下においても、フルリゾルバ側ネットワークに.jprs の権威 DNS サーバーを設置し、当該 2LD の名前解決が行える条件下においては、そのインターネットサービスの提供が担保されることを検証する。
フルリゾルバ側ネットワーク - AS9999

example.jprs
権威 DNS

権威 DNS 側
ネットワーク- ASXXXX

権威 DNS 側
ネットワーク- ASXXXX

権威 DNS
権威 DNS

example.jprs
Web サーバー

フルリゾルバ【主】

DNS クライアント

7

2017-10-31図 4：(イ)におけるシステム環境構成（方式 A）

これらの研究を通じて、フルリゾルバ側ネットワークへの.jprs の権威 DNS サーバーの設置が、ネットワーク分断時における特定の条件下において、.jprs ドメイン名の名前解決及びインターネット
サービスの安定性の向上に寄与することを明らかにする。
本研究の副次的なメリットについて、以下に列挙する。
(1) 権威 DNS サーバー側ネットワークの運用組織（JPRS）


JPRS 内ネットワークに設置された.jprs 権威 DNS への問合せ数は、その全体数から見ると相対的に減少することになるため、サーバー負荷の軽減が見込める(2) フルリゾルバ側ネットワークの運用組織（ISP）
.jprs DNS サーバーとフルリゾルバのネットワークの距離が短くなることから、応答時間の短縮が見込める

1.1.3 予想される研究の限界(1) 本研究は、権威 DNS サーバーの名前解決の安定性の測定・評価に焦点を当てており、ルート
サーバーへの到達性は確保されているという前提条件がある。同様に、ルートサーバーも含めた複合的なドメイン名の名前解決の安定性及び継続性の測定・評価についても、今後研究が必要となるとの認識である。
(2) 権威 DNS 側ネットワーク及びフルリゾルバ側ネットワークを実際にインターネットから分断させることは、他の商用サービスへの影響を及ぼすため、実施不可であるため、擬似的にネッ
トワーク分断を再現させることで検証を行う。
なお、ネットワークの分断の方法については、研究参加組織の上位ネットワークへの接続形態に依存することから、協議の上、適切な方法で検証を行う。

1.1.4 制約事項
(1) .jprs 空間は、ICANN と JPRS との間で締結された.jprs Registry Agreement に従い、JPRSがレジストリオペレーターとして ICANN から委任を受けている。
.jprs を利用する研究・開発活動は、.jprs Registry Agreement を遵守のうえ推進する必要があり、これに抵触する状況を故意に発生させる研究・開発活動は実施してはならない。
(2) .jprs の委任手続き完了後の 90 日間（2015 年 7 月 9 日～10 月 6 日）は Name Collision 期間であるため、nic.jprs ドメイン名以外の 2LD のネームサーバー設定を有効とすることは不可である。
本研究は、.jprs の 2LD を用いて検証を行うため、Name Collision 期間経過後に実施可能となる。
(3) .jprs に登録可能とする 2LD の上限は、nic.jprs も含めて 100 件までである。

8

2017-10-31

1.2

研究の目標

1.2.1 2016 年 9 月末 目標
JPRS 及び ISP が本研究を実施するうえでの、検証環境の実装方針を定め、環境構築を行う。引き
続き、本研究の目的を達成するため、検証環境で実施する評価シナリオを定め、評価項目を決定する。
評価シナリオ及び評価項目に従い、検証環境での試験を実施し、完了する。
1.2.2 2017 年 6 月末 目標
実施成果を、適切な場所及びタイミングで公開する。
研究成果実施目標一覧表
種別
2016 年
9 月末
特許出願
0

1.2.3

2016 年
12 月末
02017 年
3 月末
02017 年
6 月末
0

0

0

0

0

1
CENTR R&D
2016/5

0

0

収録論文

0

0

1
APRICOT
2017/2 又はNANOG69
2017/2
0

学術解説等

0

0

0

0

外部機関誌論文

0

0

0

0

著書等

0

0

0

0

0

0

報道発表

1
JANOG38
2016/7
0

0

0

その他資料

0

0

0

1
JANOG39.5
2017/41
報告書公開2017/40

展示会（社外主催）

0

0

0

0

展示会（社内主催）

0

0

0

0

標準化提案

0

0

0

0

研究論文
外国発表予稿等

一般口頭発表90

2017-10-31

1.3

研究体制

1.3.1 研究組織及び管理体制（１）研究組織（全体）権威 DNS 側ネットワークの研究組織
株式会社日本レジストリサービス（計画立案組織）

フルリゾルバ側ネットワークの研究組織
北海道総合通信網株式会社

株式会社エネルギア・コミュニケーションズ

東北インテリジェント通信株式会社

株式会社 STNet

北陸通信ネットワーク株式会社

株式会社 QTnet

株式会社ケイ・オプティコム

沖縄通信ネットワーク株式会社（２）研究管理体制
株式会社日本レジストリサービス（JPRS）
技術本部

技術企画室

技術研究部

システム部

広報宣伝室

北海道総合通信網株式会社（HOTnet）
ソリューション運用部

サービスオペレーショングループ

東北インテリジェント通信株式会社（TOHKnet）
技術本部

技術部

10

2017-10-31

北陸通信ネットワーク株式会社（HTNet）
経営企画部

経営企画グループ

サービス運用部

プラットフォームオペレーションセンター

株式会社ケイ・オプティコム（K-OPT）
経営戦略 G

コーポレート広報 T

計画開発 G

ネットワーク技術開発 T

株式会社エネルギア・コミュニケーションズ（エネコム）
通信技術本部

局内設備構築部

株式会社 STNet（STNet）
通信システム本部

サービス技術部

ネットワークセンター

株式会社 QTnet（QTnet）
技術本部

サービスオペレーションセンター

通信サービス設備部

沖縄通信ネットワーク株式会社（OTNet）
技術部

技術グループ11

2017-10-31

1.4

当該研究開発の連絡窓口

株式会社日本レジストリサービス（JPRS）
TEL: 03-5215-8451 FAX: 03-5215-8452
E-mail: dotjprstestbed-sec@jprs.co.jp〒101-0065 東京都千代田区西神田 3-8-1 千代田ファーストビル東館 13 階

122017-10-31

2 本論
本研究開発の全体概要及び参加組織ごとの実施内容を示す。

2.1

全体

2.1.1 研究開発活動の名称について
正式名称.jprs DNS のローカルノード設置の技術実験
略称（コード名称）
maguro （鮪、まぐろ）

2.1.2 システム構成
本研究開発の実施環境について、システム構成を示す。
tld1.nic.jprs(AS18149)

tld3.nic.jprs(AS12041)

The Internet

Global Node(GN#1)

Global Node(GN#2)

Global Node(GN#3).jprs DNS
tld4.nic.jprs(AS131905) Global Node(GN#4)

tld2.nic.jprs(AS2914)

HOTnet(AS7682)TOHKNet(AS7516)

HTNet(AS7668)

K-OPT(AS17511)

エネコム(AS7670)

STNet(AS7522)

QTnet(AS7679)

OTNet(AS9621)

Full Resolver(FR)

Full Resolver(FR)

Full Resolver(FR)

Full Resolver(FR)

Full Resolver(FR)

Full Resolver(FR)

Full Resolver(FR)

Full Resolver(FR)

Local Resolver Local Resolver
(LR)
(LR)

Local Resolver(LR)

Local Resolver Local Resolver Local Resolver Local Resolver Local Resolver
(LR)
(LR)
(LR)
(LR)
(LR)

.jprs DNS
(AS131905).jprs DNS
(AS131905)

方式 A
Local Node
(LN)

方式 A
Local Node
(LN)

.jprs DNS
(AS131905)
方式 B
Local Node
(LN)

方式 A
Local Node
(LN)

方式 B
Local Node
(LN)

13

方式 B
Local Node
(LN)

.jprs DNS
(AS131905).jprs DNS
(AS131905)

方式 A
Local Node
(LN)

方式 A
Local Node
(LN)

2017-10-31

2.1.3 実験シナリオ
ローカルノードの設置状況下において、ISP ネットワークが外部ネットワークと孤立した状況となった場合でも、.jprs TLD の名前解決の継続性が確保されるかを評価するため、実験シナリオを作成した。実験シナリオは、参加組織が個別実施する詳細版シナリオ（表 2）と、参加組織が合同で実施する簡易版シナリオ（表 3）の 2 種を準備した。
表 2：研究組織別実施の実験シナリオ
ローカルノード設置

項番

シナリオ名

未設置

1

初期状態(ローカルノード(LN)設置前)の評価
GN#4 側で LR からのパケットを落とす(Reject)

5

スタブリゾルバ(SR)からクエリを発生させ、ローカルリゾルバ(LR)からのクエリがグローバルノード(GN)#1～5 に分散されることを確認する
GN#4 側で LR からのパケットに unreachable を返し(named が落ちた状態を想定)、
LR から分断する。それにより、LR からの.jprs ドメインへのクエリが GN#1・2・3・
5 に分散されること(その偏りの割合)を調べる
項番 2 の状態を解除する GN#4 の分断が解除されたことにともない項番 1 の状態に復帰することを確認する
GN#4 側で LR からのパ GN#4 側で LR からのパケットをブラックホールに落とし(NW が落ちた状態を想定)、
ケットを落とす(Drop)
LR から分断する。それにより、LR からの.jprs ドメインへのクエリが GN#1・2・3・
5 に分散されること(その偏りの割合)を調べる
項番 4 の状態を解除する GN#4 の分断が解除されたことにともない項番 1 の状態に復帰することを確認する

6

LN 設置直後の評価

7

GN#4 側で LR からのパケットを落とす(Drop)
GN#1・2 で LR からのパケットを落とす(Drop)

2

3
4

設置済み

シナリオ概要8

9

GN#3・5 で LR からのパケットを落とす(Drop)10

項番 7～9 の状態を解除す
る

LN の運用を開始し、GN#4 から LN にクエリがシフトすることを確認する
LN から GN#1・2・3・5 へのクエリの割合の変化を調べる
GN#4 側で LR からのパケットをブラックホールに落とし、LR から分断する
項番 6 の状態が保たれることを確認する
項番 7 の状態に加えて、GN#1・2 側でも LR からのパケットをブラックホールに落とし、LR から分断する
それにより LR からのクエリが LN および GN#3・5 に分散されること(その偏りの割合)を調べる
項番 8 の状態に加えて、GN#3・5 側でも LR からのパケットをブラックホールに落とし、LR から分断する
それにより LR からのクエリが LN のみに到達することを調べる
項番 6 の状態に復帰することを確認する
14

2017-10-31

ローカルノード設置

項番
11

12
13
14

15

16

17
18

19
20
21

シナリオ名

シナリオ概要LN 側で LR からのパケッ LN 側で LR からのパケットに unreachable を返し(named が落ちた状態を想定)、LRトを落とす(Reject)から分断する。それにより LR からの.jprs ドメインへのクエリが GN#1・2・3・5 に分散されること(その偏りの割合)を調べる
GN#4 側で LR からのパ 項番 11 の状態に加えて、GN#4 側でも LR からのパケットをブラックホールに落とし、ケットを落とす(Drop)
LR から分断する。項番 11 の状態が保たれることを確認する
項番 11～12 の状態を解 項番 10 の状態に復帰することを確認する
除する
LN 側で LR からのパケッ LN 側で LR からのパケットをブラックホールに落とし(NW が落ちた状態を想定)、LRトを落とす(Drop)
から分断する。それにより LR からの.jprs ドメインへのクエリが GN#1・2・3・5 に分散されること(その偏りの割合)を調べる
GN#4 側で LR からのパ 項番 14 の状態に加えて、GN#4 側でも LR からのパケットをブラックホールに落とし、ケットを落とす(Drop)
LR から分断する
項番 14 の状態が保たれることを確認する
GN#1・2 で LR からのパ 項番 15 の状態に加えて、GN#1・2 側でも LR からのパケットをブラックホールに落とケットを落とす(Drop)
し、LR から分断する。それにより LR からのクエリが GN#3・5 のみに送られることを調べる
項番 14～16 の状態を解 項番 13 の状態に復帰することを確認する
除する
LN 側で LR からのパケッ LN 側で LR からのパケットをブラックホールに落とし(NW が落ちた状態を想定)、LRトを落とす(Drop)
から分断する。それにより LR からの.jprs ドメインへのクエリが GN#1・2・3・5 に分散されること(その偏りの割合)を調べる
LN 側で経路の広告/静的 項番 1 の状態に変わることを確認する
経路を削除する
項番 18 の状態を解除する LN が復帰しても経路が削除された状態であれば項番 19 の状態から変わらないことを確認する
項番 19 の状態を解除する 項番 17 の状態に復帰することを確認する
表 3：研究組織合同実施の実験シナリオ15

2017-10-31

ローカルノード

項番

シナリオ名

シナリオ概要1

初期状態(ローカルノード(LN)設置前)の評価

スタブリゾルバ(SR)からクエリを発生させ、ローカルリゾルバ(LR)からのクエリがグ
ローバルノード(GN)#1～5 に分散されることを確認する

設置
未設置

LN の運用を開始し、GN#4 から LN にクエリがシフトすることを確認する
LN から GN#1・2・3・5 へのクエリの割合の変化を調べる
3
GN#1・2・3・4・5 側で GN#1・2・3・5 及び GN#4 側で LR からのパケットをブラックホールに落とし(NW
LR からのパケットを落が落ちた状態を想定)、LR から分断する。それにより、LR からの.jprs ドメインへのとす(Drop)
クエリが LN#4 に分散されること(その偏りの割合)を調べる
4
GN#1/2/3/4/5 の分断が解除されたことにともない項番 3 の状態に復帰することを確認
項番 3 の状態を解除する
する
なお、システム環境の構築状況によって各研究組織の実験シナリオの実施時期が相違している。以下の表 4 は、研究組織毎の実験シナリオの実施時期をまとめたものである。
設置済み

2

LN 設置直後の評価

表 4：研究組織毎の実験シナリオ実施一覧
実験シナリオ

研究組織別実施実施時期

HOTnetTOHKnet

HTNet

K-OPT

エネコム

STNet

QTnet

OTNet

2016 年 2 月 22 日～

○

－

○

－

○

○

○

○

○

○

○
項番 5～
○

－

○

○

○

－

－

－

－

○

－

－

－

－

○

－

－

－

－

－

－

○

○

○

○

○

○

○

○

2016 年 4 月 8 日
2016 年 4 月 13 日～
2016 年 6 月 8 日
2016 年 7 月 6 日～
2016 年 8 月 29 日
2017 年 6 月 19 日～
2017 年 6 月 30 日

研究組織合同実施

2016 年 6 月 22 日～
2016 年 6 月 29 日

16

2017-10-31

2.2

株式会社日本レジストリサービス

2.2.1

目的

∙

サーバーホスティングに近い形の構成で、ローカルノードを各実験参加組織に設置して稼動させることができることを確認する。グローバルノードと同様にサービス監視が行えることを確認する。

∙

実験の各ステップで行う経路広告設定の変更などの作業を通して、運用中に起こりえる設定変
更作業をローカルノードに対して実行できることを確認する。

2.2.2
∙

全体のシステム構成

全体の構成
方式 A 群
HOTnetAS7682JPRS
AS131905

TOHKnetAS7516JPRS
AS131905

tld1.nic.jprs
AS18149

K-OPT
AS17511

JPRS
Private AS

tld2.nic.jprs
AS2914

QTnet
AS7679JPRS
AS131905

tld[35].nic.jprs
AS12041

OTNet
AS9621JPRS
AS131905

tld4.nic.jprs
AS131905

方式 B 群The Internet

G

∙

HTNet
AS7668

L

L

L

L

L

L
凡例

エネコム
AS7670L

STNet
AS7522

L

G
N
L

グローバルノード
ローカルノード

DNS サーバー（ローカルノード）

できたこと・できなかったこと


実験参加組織に設置した DNS サーバーをローカルノードとして機能させることができた。設置した AS からの tld4.nic.jprs 宛の通信がローカルノードに到達して処理されていることを確認できた。



設置したローカルノードについて、DNS サービスの監視を JPRS から行うことができた。
17

2017-10-31





∙

共通でできたこと・個別対応になったこと

ローカルノードについてベアメタルと仮想化環境が各組織で混在した構成となっていた。本研究の範囲では性能面が問題になることはなく、運用上の支障はなかった。



ディストリビューションやバージョンが混在していたため、インストールするパッケ
ージの種類等を共通化することはできなかった。今後の課題としたい。

経路制御




できたこと・できなかったこと


方式 A の組織については、ローカルノードがダウンして経路広告が行われなくなった
際に、通信がグローバルノードに迂回することを確認できた。



named のプロセスが停止した・クエリに応答しなくなったなどの異常が発生した際に経路広告を自動的に止める仕組みについては実験できなかった。今後の課題としたい。

共通でできたこと・個別対応になったこと


2.2.3
∙

ノードのメンテナンスを行う際に、JPRS・参加組織の 2 社から監視を行っているが、連携してアラート抑止等の対応を行うことができた。

方式 A の中でもルーティングプロトコルを共通化することができなかった。これにより各組織によって操作手順が異なることとなった。今後の課題としたい。

得られた知見

各実験参加組織にローカルノードを設置し、.jprs の名前解決を行うことができることを確認できた。

∙

構築作業を容易にするためにインストール対象ソフトウェアをパッケージ化していたことにより、すべてのローカルノードに対してネームサーバーソフトウェアの設定手順をほぼ統一化でき、一定の作業品質を保つことができた。本研究のように複数の異なる環境における構築において、手順の簡素化・統一化をはかることがコスト面、品質面で有用であることが確認できた。

∙

方式 A・方式 B の 2 種類のノードを用意したが、フルリゾルバ側の設定変更が不要で、ローカ
ルノード側の操作で経路広告の開始・停止を行えるのは方式 A である。方式 A を採用しておくと、ローカルノードの障害時に迅速にグローバルノードに切り替えることが可能となると確
認できた。

∙

経路制御方式がグローバルノードとほぼ近い構成のローカルノードにおいては、JPRS 社内で作成し、実績のある運用手順書を適用することができた。
18

2017-10-31∙

ローカルノードの障害を模擬するシナリオで、サービス監視のアラートが発報し、想定どおり監視できていることを確認できた。

2.2.4
∙

課題

方式 A と方式 B との 2 つの異なる経路制御方式が混在していること、また同じ方式 A でもルーティングプロトコルを統一していなかったことから、実験の各ステップで複数の手順を用意する必要があった。実運用環境では、可能であれば環境と手順を統一しておくことで、作業工数の削減を図ることが必要だと考えられる。

∙

実験参加組織ごとにポリシーが異なることから、追加の作業が必要になることがあった。たとえば、ICANN から報告を求められている DNS 関連の統計情報を収集するため.jprs レジスト
リシステムから定期的にデータの取り込みを受け付ける必要があるが、ポリシー上実現困難な例があった。事前にポリシーを相互に確認し、共通認識を持つことが必要である。

∙

今回、サーバーのセットアップについては実験参加組織の協力を得て行った。環境を統一する
観点からは、JPRS にて OS レベルから構成管理ソフトウェア等を利用して構築を行い、設定変更の際には段階的に、または一括して全ローカルノードに適用するなどの運用を可能にするなどが考えられる。

∙

構築中や運用開始後の実験参加組織との連絡は電話や電子メールで行っていた。特に運用中のトラブル対応等においては、操作内容やエラーメッセージ等を共有しながらコミュニケーションを行えるオンラインビデオ会議等の方法も検討したい。

19

2017-10-31

2.3

北海道総合通信網株式会社

2.3.1 目的
北海道は東京・大阪から地理的に離れており、大規模障害時に TLD DNS サーバーを利用できな
くなるリスクが高い。また、復旧に時間がかかる可能性がある。そのような状況を想定し、当社ネットワークにローカルノードを設置することにより、名前解決を継続して行うことができることの技術検証及び評価を行う。
2.3.2 システム構成【方式選定】
ISP 内に個別の専用ネットワークを構築し、ローカルノードの設置を行うことで、ISP 網内のユーザだけではなく、ISP 網外のユーザに対してもサービスの提供が継続して可能となる方式 A を採用した。
【ネットワーク構成】
ISP 内ネットワークは商用環境の配下に実験環境を構築した。ローカルノードは Policy Routing
により、名前解決とノード管理のネットワークを分離した。

The Internet.jpsrの名前解決リクエスト

サーバ管理とゾーン転送

RouterBGP
Router

ネットワーク:A

Quagga

AS7682

ネットワーク:B

FirewallAS131905

2LD
ネットワーク:D

ネットワーク:C

Cache

eth1

ローカル
ノード

eth0

Stub

ネットワーク:E

20

2017-10-31

2.3.3 実験シナリオ
JPRS 準備のシナリオに従い実証実験を行った。

2.3.4 実験結果
シナリオ記載の 21 項目の内、17 項目を正常に実施し概ね期待した通りの試験結果を得ることができた。なお、項番 1、2、6、7 について、試験環境の都合により一部データの取得が行えていな
い。

2.3.5
1.

実験結果の評価
当社からの名前解決がローカルノードでなされることにより RTT が約 17ms～18ms から
約 0.5ms～0.9ms へ短縮されることが確認できた。

2.

グローバルノードで障害が発生した場合はローカルノードで名前解決が継続して行えることが確認できた。

3.

ローカルノードで障害が発生した場合はグローバルノードで名前解決が継続して行えることが確認できた。

2.3.6 得られた知見【名前解決の継続性】
当社ネットワークが孤立した場合においても、ローカルノードにより名前解決の提供が継続して可能であることを確認した。また、ローカルノードを設置するとにより RTT が小さくな
り、応答速度が向上することを確認した。
【方式 A 選定のメリット、デメリット】
・メリット
既存の DNS 設備を変更することなくローカルノードを設置することができる。
そのため、DNS の運用においてローカルノードの存在を意識する必要がない。
・デメリット
ローカルノードが停止した際に、経路広報を停止する方法を考慮する必要がある。
ローカルノード用に個別のネットワークを作成するため、ネットワークオペレータとの連携が必要。また、管理用ネットワークを別途構築する必要がある。

2.3.7
1.

課題
ローカルノードが正常に稼動していることの確認や障害の検知方法について、決まっていないため考慮する必要がある。

2.

今回は試験環境としてローカルノードは 1 台で動作しているが、運用する際は負荷分散や障害に備えた冗長構成を考慮する必要がある。

21

2017-10-31

2.4

東北インテリジェント通信株式会社

2.4.1 目的
DNS は、ドメイン名と IP アドレスを相互に変換する「名前解決」を行う階層的な分散システム
で、インターネットサービスを支える基幹技術の一つである。
しかし、大規模災害等の発生により、TOHKnet のネットワークからグローバル上の TLD 権威
DNS（以下、「グローバルノード」という。）への接続性が失われた際は、グローバルノードに対する問い合わせができず、「名前解決」が不可能となり、結果としてユーザがインターネットサー
ビスを利用できなくなる。
そのため、本研究では、TLD 権威 DNS と同一のゾーン情報を有するレプリカ（以下、「ローカ
ルノード」という。）を TOHKnet のネットワーク内に設置することで、継続的に「名前解決」を可能とする手法の有効性を評価することを目的とした。
2.4.2 システム構成
実験用の仮想基盤上にローカルノードをはじめとするサーバー群や仮想ルーターを配置し、商用設備と接続する構成とした。
実験方式は、グローバルノードと同一のネットワークを構築し、IP Anycast 技術を利用する方式
A を採用した。
実験環境は以下のとおり。
AS131905

The Internet

JPRS
tld4

TOHKnetAS7516

グローバルノード（JPRS設備）

tld1

core

tld2

tld3

tld5

仮想基盤（vSphere ESXi）
仮想スイッチ vSwitch0 (layer2)
ゾーン転送
専用

仮想ルーター(quagga）

AS131905

tld4

DNSクライアント（スタブリゾルバ）

DNSキャッシュ（フルリゾルバ）

リバースプロキシ

２ＬＤサーバー（wwwサーバー）

22

ローカルノード（JPRS設備）2017-10-31

2.4.3 実験シナリオ
JPRS セクション 2.1.3 に記載のシナリオで実験を行った。
2.4.4 実験結果
ローカルノード設置後、グローバルノード全断後の実験結果を以下に示す。
ローカルノード設置後
ping IPv4

traceroute IPv4

dig IPv4

wget IPv4

グローバルノード全断後
ping IPv4

traceroute IPv4

dig IPv4

wget IPv4

23

2017-10-31

2.4.5 実験結果の評価
ローカルノード設置後からグローバルノードに対する Ping IPv4 の応答時間が 7msec から
0.5msec へ減少し、traceroute IPv4 のホップ数も 7 から 3 へ減少している。
これは、「名前解決」の問い合わせ先がグローバルノードからローカルノードへ切り替わったことを示している。その場合においても、web サーバーへのアクセスが継続的に可能となっていることから、ローカルノードによる「名前解決」が可能であることが確認できる。
以上の結果から、ローカルノードを設置することにより、期待どおりグローバルノードとの接続性が失われた場合においても継続的にインターネットサービスを提供可能である結果を得られた。

2.4.6 得られた知見
ローカルノードを設置することにより、大規模災害の発生等でグローバルノードとの接続性が失われた場合においても、継続的に「名前解決」が可能であることを確認した。
また、本実験をとおして、グローバルノードとローカルノードに同一の IP アドレスを設定する
IP Anycast 技術を利用する方式の実用化に向けた課題が明確となった。

2.4.7 課題
今回は実験であったため、建設・保守・運用等を考慮していなかったが、ローカルノードを商用設備として運用する場合は、それらの責任分界点や連携等を明確にする必要がある。

24

2017-10-31

2.5

北陸通信ネットワーク株式会社

2.5.1 目的
東日本大震災においてインターネットは被災地支援活動を行う上で非常に有効な手段であった。
インターネットは日常生活だけではなく、非日常においても欠かせない存在となり、そのインター
ネットをより安定した形で提供するために、根幹である DNS の発展・向上を目的とした本研究に一事業者として微力ながら協力し、技術ノウハウの共有、技術スキル向上も期待できると考える。

2.5.2 システム構成
研究環境はその過程において、・商用環境へ影響を与えない・セキュリティ面での安全確保・研究を進める上でのオペレーションのし易さを考慮し、商用環境から独立した研究環境を構築した。
上記条件と共に研究環境構築までのリードタイムを短縮するため、検証環境の仮想サーバーで環境を構築した。また、検証環境の構成上、static-stub を利用した方式 B を採用した。

2.5.3 実験シナリオ
JPRS が準備したシナリオに沿って実験を実施した。

2.5.4 実験結果
各シナリオにおいて継続して名前解決が行え、概ね期待通りの結果であった。
25

2017-10-31しかし、研究環境の機器の都合により、応答時間のデータが取得できないシナリオがある。

2.5.5 実験結果の評価
研究環境の機器の障害により、応答時間のデータが取得できない事があった為、結果を完全に評
価できるレベルのデータが未取得となった。
項番９でもデータ未取得の為、インターネットサービスの継続性を確認する為の結果が得られなかった。
2.5.6 得られた知見
方式 B において、ローカルノードを ISP のネットワーク内に設置することにより、大半のクエリがローカルノード向けになる事が確認できた。これは BIND のアーキテクチャーによるものと推測する。
また、各ノードの問合せ応答時間については大きな差が無いことが確認できた。

2.5.7 課題
今回、研究環境の機器の状況により取得できないデータも存在した為、機器の状況を監視し早急に復旧しデータ取得を復旧する必要があると感じた。
また、グローバルノードと分断された場合でもローカルノードを設置することにより名前解決を継続して行えることを確認することができたが、方式 B では大半のクエリがローカルノードにむく
ため、サーバー側の負荷の問題、冗長性の問題、ユーザからの問合せ対応など課題があるのだろう
と考える。

26

2017-10-31

2.6

株式会社ケイ・オプティコム

2.6.1 目的
電気通信事業者の設備内における gTLD ドメイン名空間の名前解決の継続性を高めることにより、
DNS サーバー群全体や、ネットワーク接続機器などへの影響、問題の洗い出し等を行う。また、
本実験を JPRS と共同で行うことで当社の知見が深まることを期待する。

2.6.2 システム構成
本研究を実施するにあたり、以下に示す研究用インフラを構築した。

【インターネット接続回線】
インターネットへの接続方式は当社法人向け回線サービスを利用し、BGP にて接続を行った。
【権威 DNS サーバー及びフルリゾルバの設置方法】
方式 A を採用し、設置先ネットワーク内に個別の専用ネットワーク（自律システム（AS））を設置し、その中に DNS サーバーを設置した。

27

2017-10-31

【サーバインフラ】
本研究に必要となったノード(BGP ルーター、ローカルノード DNS サーバー、リゾルバ DNS サーバー)すべては、１台の物理サーバー上で仮想化にて構築を行った。仮想環境を以下に示す。

2.6.3 実験シナリオ「2.1.3 実験シナリオ」に従い、実証実験を行った。

2.6.4 実験結果
・ LN の設置後、正常時、及び GN の分断時において、問題なく名前解決ができることを確認できた。
・ 問い合わせ先の切り替わり時において、一部の GN においては、遅延、traceroute の応答がな
い結果が見受けられたが、環境依存の外部要因と推測される。
・ LN の設置後、LN での Reject(named 停止想定)、Drop(NW 停止想定)、経路削除(BGP
Anycast)いずれの場合も、GN へクエリが分散された。

2.6.5 実験結果の評価
・ 各シナリオにおいて GN、LN いずれかの応答が無い場合でも、継続して、名前解決が行えており、期待通りの結果であった。
28

2017-10-31

・ GN、LN の応答が復旧した際にも、名前解決の遅延が見受けられた。
2.6.6 得られた知見
Bind 実装の特性において、再起問い合わせ時に RTT の小さいノードを優先して選択するため、ローカルノード利用時の応答速度の向上について優位性が確認できた。

2.6.7 課題
名前解決の継続性および、応答速度の改善が見込めることが確認できたが、gTLD のなかでも.JP ドメインは.COM ドメインの約 1/100 程度であり、インターネット全体の安定運用にかかる効果について測定が困難である。
ローカルノードを事業用設備として運用する場合、gTLD ドメイン運用者とローカルノード設置の ISP 運用者間での責任分解点の取り決めが必要である。(直接的な利害関係が発生する CDN 業者とのローカルキャッシュの場合とは事情が異なる。)

29

2017-10-31

2.7

株式会社エネルギア・コミュニケーションズ

2.7.1 目的
日本のネットワーク経路のほとんどが東京、大阪に集中しているため、そこで大規模な災害が発生し、当社ネットワークとの接続が途絶えた場合、当社キャッシュ DNS サーバーは権威 DNS サ
ーバーへの接続を失い、名前解決を行うことが困難となるため、インターネットサービスの提供において極めて大きな制約になると考えられる。
よって、今回の研究では、権威 DNS サーバーを当社ネットワークに配置し、東京や大阪が被災した場合でも引き続きインターネットサービスが継続して利用できるかどうかの検証を行い、本研究から得られる知見と課題の洗い出しを行う。
また、複数の ISP と同一の研究を共同実施することで、より信頼性の高い研究成果と情報の共有を行うことを目指す。
2.7.2 システム構成
今回の合同研究では、当社はパターン 1-B の構成を採用した。
検証環境は、仮想基盤上にサーバーを構築し、負荷試験を目的としていないことからサーバーのリソースは検証できる最低限とした。
当社で用意した検証環境は以下のとおりである。

2.7.3 実験シナリオ
JPRS 準備のシナリオに従い実証実験を行った。

30

2017-10-31

2.7.4 実験結果
・グローバルノードがダウンした際はローカルノードで名前解決を行い、Web サーバーへアクセスすることを確認した。
・ローカルノードがダウンした際はグローバルノードで名前解決を行い、Web サーバーへアクセスすることを確認した。
2.7.5 実験結果の評価
グローバルノード、ローカルノードのどちらがダウンしても、想定どおりインターネットサービ
スが継続して利用できることをフィールドで確認できた。
この方法が大規模な災害発生等グローバルノードへの到達性がなくなった場合においてもインターネットを継続して利用するための有効な方法のひとつであると考えられる。
2.7.6 得られた知見
・ローカルノードを設置することで、名前解決の応答時間が短縮されることが確認できた。
・今回採用した方式 B はグローバルノード、ローカルノードそれぞれの IP アドレスをキャッシ
ュ DNS サーバーへ事前登録しておくことで対応でき、ネットワークの構成変更が不要であるため、容易に対応できた。
2.7.7 課題
実運用化という点では、主に次の技術的な課題がある。
・ローカルノードを利用する場合、実運用の負荷に耐えるスペックや構成を検討する必要がある。
・ローカルノード故障時の対応について JPRS との責任分界点を明確にしておく必要がある。

31

2017-10-31

2.8

株式会社 STNet

2.8.1 目的
大規模災害時に、地理的に孤立してトップレベルドメインの DNS サーバーが利用できなくなった場合、DNS ツリーが正常に働かなくなるため、エリア外との通信ができなくなるばかりでな
く、エリア内の通信もできなくなる。
今回、ローカル環境にトップレベルドメインの権威 DNS を設置することで、孤立時においてもインターネットが継続して利用可能であることを確認し、影響（副作用）や課題について研究する。また、研究に参加する社員の技術力向上や、参加各社との DNS に関する情報共有も目指す。

2.8.2

システム構成本研究を行うにあたり、STNet では方式 B を採用した。
方式 B は、個々のフルリゾルバに静的な設定を追加する必要があるものの、ネットワークのルー
ティングを変更する必要が無いため、DNS サーバーの作業だけで環境を実現したい場合や、フルリゾルバの台数が少ない ISP では、比較的実現が容易な方式である。

【ネットワーク構成】
本研究用に法人向けインターネット回線を用意し、独立した研究環境を構築することで、あたかも小規模な ISP を模擬する環境を用意した。
【サーバー構成】32

2017-10-31

各サーバーについては、仮想サーバーにて構築したことで、急遽必要となった WEB サーバーや
2LD サーバーも機材を追加することなく準備できた。

2.8.3 実験シナリオ「2.1.3 実験シナリオ」に従い、実験を実施した。
・ 研究組織別実施の実験シナリオでは、1 サイクル目（2/22～4/8）において、一部項番で、ログファイルの退避が間に合わずディスク不足が発生し欠測したため、2 サイクル目（4/13～6/8）
にて、再測定し、全項番のデータを取得することができた。
・ 研究組織合同実施の実験シナリオ（6/22～6/29）では、1 回の測定で全項番のデータを取得することができた。

2.8.4 実験結果
・ 実施した全項番で期待した結果が得られた。
・ 研究組織合同実施の実験シナリオでは、各 TLD 権威 DNS サーバーの DNS クエリ数データを取得したので、それをデータをグラフ化したものを下記に示す。

項番１は、通常運用状態であり、各サーバーへのクエリ数はほぼ均等に分散しているが、遅延が少ない GN#2:大阪へのアクセスが少し多い状態であった。
項番２は、GN#4 から LN#4 へ切替を実施した状態である。各サーバーへのクエリ数は LN#4 へ大幅に偏った状態となった。
項番３は、孤立を模擬した状態であり、ほぼ全てのクエリが LN#4 へ集中する状態となった。
項番４は、孤立から回復した状態であり、項番２と同様なグラフとなっている。

2.8.5 実験結果の評価
・ ローカルノードを活用した名前解決ができることを確認できた。
33

2017-10-31

・ 実験シナリオに沿った切替動作が確認でき、期待した通りの結果を得ることができた。
・ 各 TLD 権威 DNS サーバー毎の DNS クエリ数の変化から、平常時の動作において、レスポンス(RTT)が良好なサーバーが優先的に選択されることが分かった。
・ 一部のノードへの RTT や HOP 数に変動が見られたが、実験シナリオとは関係のない外乱と思われる。

2.8.6 得られた知見
・ 孤立した際は、ローカルノードにて期待通り動作が継続され、エリア内に TLD 権威 DNS サー
バーがあれば大規模災害で分断された場合でも該当 TLD の名前解決ができ、エリア内の通信が可能であることが確認できた。
・ 方式 B は、ルーティングについての作業は全く伴わずに環境を構築できたので、フルリゾルバの台数が少ない小規模な ISP や、自身がルーティングを管理していないクラウド環境などでも構築できることが分かった。

2.8.7 課題・ 方式 B は、フルリゾルバに静的に設定を追加する必要があるため、TLD サーバーの IP アドレ
スが変更される場合は、その情報の正確な連携と変更タイミングの調整が必要になる。また、
ISP のキャッシュサーバを利用していない(フォワーダーしていない)DNS 運用ユーザはこの恩恵を受けられない。
・ 方式 B は、レスポンスの良いローカルノードへクエリが集中するため、負荷の偏りに対しての評価が必要である。特に、ローカルノードを常時運用とした場合、グローバルからのアクセスをどうするか。どちらの方式にせよ、レスポンスの良いローカルノードへクエリが集中するため、グローバルからのアクセスを許可するのであれば負荷についても十分に考慮する必要がある。
・ 今回の実験では１つの TLD についての考察となる。ルートサーバー、その他 TLD についてど
うするか今後の検討課題である。
・ エリア内の通信の確保という観点から有効ではあるが、四国内の他社 ISP との通信は IX を経由している場合が多く、大規模災害時は疎通が取れない可能性が大きいことから、それらの通信についての考察も必要である。

34

2017-10-31

2.9

株式会社 QTnet

2.9.1 目的
日本のインターネットの構造は東京と大阪に大きく依存していることから、大規模災害などによりネットワーク的に九州が孤立した場合、ISP 内のキャッシュ DNS サーバーからルートサーバー
やトップレベルドメインの DNS サーバーへの到達性が失われる。このとき、キャッシュ DNS サ
ーバーが正常であったとしても名前解決が困難となり、インターネットサービスの継続提供が困難となる問題がある。この問題は、名前解決の仕組みがキャッシュ DNS から権威 DNS へのネット
ワークの到達性に依存していることに起因する。
上述の問題点を解決するために、ISP のネットワーク内にトップレベルドメインの権威 DNS(.jprs)を設置し、ISP 内のキャッシュ DNS から権威 DNS への到達性を担保する手法を用いること
で問題点の解決を目指す。特に、ネットワーク的に九州が孤立するシナリオにおいても名前解決が継続できることを検証することで、九州の ISP としてこの手法が有効であることの確認や問題点の洗い出しを行うことを主な目的とする。
また、研究参加者の技術力の向上や参加各社とのノウハウの共有促進を目指す。
2.9.2 システム構成
本研究を行うための環境として、QTnet では以下に示す環境を構築した。
【特徴】
仮想化基盤に起因する測定結果への影響を排除するために、物理サーバーで構築を行なった。本研究ではフルリゾルバとローカルノードの耐障害性についてはスコープ外であることから、冗長構成とはせず、それ以外の構成要素は運用環境に近似した環境とした。

35

2017-10-31

【方式選定理由】
今後のサービス化を見据えて、フルリゾルバの設定変更が不要であり経路広告の制御によってローカルノードの障害の際に迅速に対応可能な方式 A を採用した。

【各構成の諸元】
各構成の諸元については、非公開情報を含むため省略。ただし、ローカルノードを除く DNS サ
ーバーは各シナリオ実施時において最新の BIND9.9 系をソースからコンパイルし評価試験に用いた。

2.9.3 実験シナリオ「2.1.3 実験シナリオ」に従い、実証実験を行った。

2.9.4 実験結果
・シナリオ記載の項番 1 から 21 までの 21 項目を含む 25 項目を 1 回実施(2015/12/14～2/10)
・シナリオ記載の項番 1 から 21 までの 21 項目を 2 回実施(2016/2/22～4/8、4/13～6/8)
・シナリオ記載の項番 1 から 4 までの 4 項目を 1 回実施(2016/6/22～6/29)

上述のシナリオから項番 6(LN 設置直後の評価)及び JPRS と QTnet の 2 社間にて行ったシナリ
オ(2015/12/14～2/10)から、九州のネットワーク的な孤立を想定した部分のみ抜粋して記載する。

【LN 設置直後の結果】

36

2017-10-31左図は LN 設置直後のフルリゾルバから各 GN、LN への RTT と Hop 数の推移とフルリゾルバ
からのクエリ数を表しており、LN 設置前ではフルリゾルバと tld4 間の hop 数は 12hop であったが、設置後は 4hop となり、RTT の値も設置前の約 18ms から設置後は 1ms 以下となった。
右図は LN 設置直後のフルリゾルバから各 GN、LN へのクエリ数の推移を表している。LN 設置
前では tld2 へのクエリ数が他のノードと比較し約 2 倍であったが、LN 設置後では tld2 へのクエ
リ数は他のノードと同様のクエリ数となり、tld4 へのクエリ数は他のノードと比較して約 2 倍となった。
これらの結果から、LN を設置した際に期待通り LN へルーティングできていることを確認でき、名前解決についても継続できることが確認できた。この際、tld4(LN)へのクエリ数が増加していることから、今回評価に用いた BIND では RTT の小さなノードを選択するアルゴリズムである
ことを示唆している。

【九州のネットワーク的な孤立を想定したシナリオ】
・評価プロセスについての補足

上図は、九州のネットワーク的な孤立を想定したシナリオを実施した際の各評価プロセスにおけるフルリゾルバから各 GN、LN への疎通性について、状態の遷移を表したものである。評価プロ
セス#1、#5 はフルリゾルバから全ての GN、LN と疎通性があることを表しており、評価プロセス#2、#3 と段階的に疎通性がないノードを増やし、#4 で九州のネットワーク的な孤立を想定し、LN以外の全てのノードと疎通性がない状態とした。
・実験結果

37

2017-10-31上図は前述したシナリオ実施時のフルリゾルバから各 GN、LN へのクエリ数の推移を表している。
評価プロセス#1 では、全てのノードと疎通性がある状態とし、各ノードへのクエリの分布は tld1
～5 へほぼ均等に分布する結果となった。
#2 では tld4(GN)への疎通性がない状態とし、各ノードへのクエリの分布は#1 と同様の結果が得られた。
#3 では#2 に加えて tld1、2(GN)への疎通性がない状態とし、各ノードへのクエリの分布は tld3、5(GN)は#1、#2 と同様の結果となった。その際、tld4(LN)へのクエリ数は tld3、5(GN)と比較して約 3 倍となった。
#4 では#3 に加えて tld3、5(GN)への疎通性がない状態とし、各ノードへのクエリの分布はtld4(LN)にすべてが偏る結果となった。
#5 では全てのノードと疎通性がある状態とし、各ノードへのクエリの分布は tld1～5 へほぼ均等に分布する結果となった。
これらの結果から、各評価プロセスにおいて GN への障害を模擬した際、想定通り LN へルーテ
ィングできていることが確認でき、フルリゾルバから複数の GN に対して疎通性に問題が発生した際においても、LN に対して疎通性がある限り、名前解決が継続できる結果が得られた。また、GNへの疎通性が回復した評価シナリオにおいて、フルリゾルバから各 TLD へのクエリの分布が初期状態と同様であったことから、疎通性が回復した際のフルリゾルバの動作について、復元性がある
ことが確認できた。
2.9.5 実験結果の評価
大規模災害の発生などにより、ISP 網外の権威 DNS への疎通性に問題が生じたとしても、ISPのネットワーク内に LN を設置することで ISP 内のキャッシュ DNS サーバーから権威 DNS サー
バーへの到達性を確保することで、インターネットサービスの継続提供が可能であることを確認できた。
弊社のフルリゾルバでは、.JP ドメインの名前解決が全体の約 3 割を占めている(janog35 DNSの可用性と完全性について考える)。このことから、.JP の LN を ISP 網内へ設置することは DNSの耐障害性の向上と応答速度の向上を図るうえで効果的であると言える。

2.9.6 得られた知見
今回評価に用いた BIND では RTT が小さなノードを選択するアルゴリズムであることを示唆する結果が得られた。この結果から、LN の設置は耐障害性の向上だけではなく平常時においてもDNS の応答速度の向上が期待でき、お客さまにより快適なインターネットサービスが提供できるとの知見が得られた。

2.9.7 課題
本研究では、ルートサーバーへの到達性は担保されている前提条件を元に評価を実施した。そのため、ルートサーバーも含めた測定及び評価は未実施である。.JP の LN の実運用化に向けては、
今回未評価であるルートサーバーも含めた構成にて、今後評価を行う必要がある。
38

2017-10-31

2.10 沖縄通信ネットワーク株式会社
2.10.1 目的
沖縄県は日本の中で地理的に東京から一番遠い場所に位置しており、他府県と比較して災害発生時に影響を受けるリスクが高いと考えている。また TLD ゾーンを保持する DNS へのアクセスについても他府県と比較して伝送距離が長くなるため、どうしても伝送遅延(RTT)が長くなる事情がある。上記問題はローカル環境に TLD ゾーンデータのコピーを置く事で解決できる可能性があり実証実験に参加した。

2.10.2 システム構成

BGP Anycast 技術で冗長構成のノウハウを習得したかったため、方式 A を採用
一般の法人顧客収容機器に実証実験環境を接続。商用環境と同等の環境を準備した。

2.10.3 実験シナリオ
基本的に、JPRS 側で準備したシナリオに従い実験を実施。ただし実証実験用 BGP ルーターについては物理ルーターを準備。ローカルノードからの経路広報停止のシナリオでは、弊社側でルーターの操作を行う必要があった（標準構成では、ローカルノードにソフトウェアルーターを構築
し、JPRS 側で管理）.

2.10.4 実験結果
殆どの実験については想定通りの結果を示したが、ローカルノード側にハードウェアルーターを準備した事に起因して項番 11、12、14、15 の実験で想定外の結果が観測された（原因は特定済）。

392017-10-31

2.10.5 実験結果の評価
実証実験への準備不足等もあり、本来取得すべきデータが十分には取得出来てなかったり、意図した内容でのテストが実施できなかったりした項目が存在。以下の評価となった。

確認できた項目）
・AnyCast 技術を利用した、ノード冗長の有効性
・ローカルノード設置にともなう、伝送遅延の改善確認できなかった項目）
・DNS 問い合わせベースの解析結果(データー欠損有り)
・複数 GN 存在時の、GN 選択特性の確認(低 RTT の GN が優先選択されるかなど)
・ローカルノードと物理ルーター間の最適な経路制御方法の確認

2.10.6 得られた知見
複数の TLD ノードへの通信結果を確認した所、一部の TLD ノード向け通信で通信品質が劣化する事が確認できた。通信の安定性にはかなりバラツキがあり、通信品質が安定しているノード、一日に複数回通信障害が派生するノードが確認できた。IPv4 で通信が劣化した時は IPv6 の通信も劣化しており、IP プロトコルバージョンに起因する問題は確認できなかった。

2.10.7 課題
通信の安定性を第一に考えるのであればローカルノード側の経路制御は専用機器を利用するのがベストと考えた。実際にローカルノードをハードウェアルーターとの構成で動作させた場合、ロー
カルノードの擬似障害発生時に経路広報が止まらないケースがあるなど、数々の問題が発生した。
商用環境での運用を考慮した場合、DNS サーバーの状態を経路広報に確実に反映させる必要があ
るため、この部分では細かい検討/実装が必要になると認識した。

40

2017-10-31

3 総括
3.1

まとめ

フルリゾルバ側ネットワーク内への権威 DNS サーバーの設置することがドメイン名の名前解決及びインターネットサービスの安定性の向上に寄与することを、前章で示した研究組織 8 社（2.3、2.4、2.5、2.6、2.7、2.8、2.9、2.10）の実験シナリオ実施結果から確認することができた。

3.2

権威 DNS サーバーの設置方法の評価

ここでは、フルリゾルバ側ネットワーク内への権威 DNS サーバーの設置方法として採用した 2 方式について、いずれの方式が DNS の名前解決の安定的な提供の視点から優位であるかの考察を示す。
フルリゾルバ側ネットワークの各研究組織は、各社の本研究の実施目的及び準備可能な研究環境に適する方式を選択した。


方式 A：設置先ネットワーク内に個別の専用ネットワーク（自律システム（AS））を設置
し、その中に DNS サーバーを設置する



方式 B：設置先ネットワークで払い出し済みの IP アドレスを DNS サーバーに割り当てる

表 5 は、各フルリゾルバ側ネットワーク研究組織が採用した方式の一覧である。
表 5：各フルリゾルバ側ネットワーク研究組織における採用方式
フルリゾルバ側
ネットワーク
研究組織
HOTnetTOHKnet
HTNet
K-OPT
エネコム
STNet
QTnet
OTNet

採用
方式

研究環境の特性

A
A
B
A
B
B
A
A

ソフトウェアルーターによる経路制御
ソフトウェアルーターによる経路制御
フルリゾルバによる権威 DNS サーバーの IP アドレス静的指定
ソフトウェアルーターによる経路制御。Private AS の使用
フルリゾルバによる権威 DNS サーバーの IP アドレス静的指定
フルリゾルバによる権威 DNS サーバーの IP アドレス静的指定
ソフトウェアルーターによる経路制御
ハードウェアルーター（ベアメタル）による経路制御

権威 DNS サーバーへの接続性の観点から各方式を評価した。
3.2.1 権威 DNS 側ネットワーク内の権威 DNS サーバーへの接続性
フルリゾルバ側ネットワーク内に.jprs の権威 DNS サーバーを設置することで、フルリゾルバ側ネットワークから権威 DNS 側ネットワークへの接続性が失われた場合であっても、.jprs ドメイン名の名前解決及びインターネットサービスの安定性の向上に寄与することが、フルリゾルバ側ネット
ワークの研究組織 8 社（2.3、2.4、2.5、2.6、2.7、2.8、2.9、2.10）の実験シナリオ実施結果から
得られた。
41

2017-10-31

この結果は、方式 A 及び B のいずれにおいても相違ないことを確認した。
3.2.2 フルリゾルバ側ネットワーク内の権威 DNS サーバーへの接続性
方式 A の実施結果
方式 A を採用した実験シナリオの実施結果からは、フルリゾルバ側ネットワーク内に設置した権威
DNS サーバーへの接続性が失われた場合、権威 DNS 側ネットワーク内に設置した権威 DNS サー
バーへの問い合わせの切り替えが、経路制御プロトコルレベルで行われることが確認できた。また、その接続性が復旧した際も、経路制御プロトコルレベルでの切り替えが行われることが確認できた。
方式 B の実施結果
方式 B を採用した実験シナリオの実施結果からは、フルリゾルバ側ネットワーク内に設置した権威
DNS サーバーへの接続性が失われた場合、権威 DNS 側ネットワーク内に設置した権威 DNS サー
バーへの切り替えは行われないことを確認した。これは、フルリゾルバのアプリケーション設定として、.jprs の権威 DNS サーバーの IPv4/IPv6 アドレスを静的に指定しているためである。
3.2.3 各方式の評価
方式 A では、フルリゾルバ側ネットワーク及び権威 DNS 側ネットワークの両方に設置した権威
DNS サーバーが名前解決時に使用されうるが、方式 B ではフルリゾルバ側ネットワーク内に設置した権威 DNS サーバーのみが使用されることを意味する。DNS の名前解決の安定的な提供の視点
からは、方式 A が優位と考える。

3.3

副次的に得られた結果

ここでは、当初の目的以外に得ることができた結果及び知見等を示す。
3.3.1 参加組織の地理的特性を踏まえた権威 DNS サーバー設置の考察
ローカルノードを設置することで、権威 DNS サーバーからの応答の RTT がグローバルノードによる応答に比べて短くなる事が確認された。これによりフルリゾルバは名前解決にかかる時間が短縮
され、サービス品質の向上が確認できた。
また、権威 DNS サーバーからの応答の RTT が短くなることで、フルリゾルバによる権威 DNS サ
ーバーの問い合わせ先の選択がローカルノードを持つネームサーバーに偏る傾向が観測された。これにより東京・大阪をはじめとするグローバルノードへの問い合わせが減少しており、東京・大阪への通信の集中が緩和されることができるものと考えられる。

3.3.2 フルリゾルバの実装仕様に関する知見
フルリゾルバ側ネットワーク内の権威 DNS サーバーへの接続性の喪失及び復旧から数時間（2～3時間）程度をもって、.jprs の各権威 DNS サーバーの DNS クエリ分布が安定することが測定デー
タから明らかとなった。
.jprs の各権威 DNS サーバーの DNS クエリ分布が方式 A と比較して、フルリゾルバ側ネットワー
ク内に設置した権威 DNS サーバーへより偏ることが明らかとなった。これは RTT の小さい権威
DNS サーバーを選択するアルゴリズムを、フルリゾルバが採用しているためと考える。
42

2017-10-31

3.3.3 運用管理に関する知見方式 A でも、参加組織によって構成要素に差異があった。作業工数の削減や設定情報の統一化を目的として、使用するプロトコルや構成を統一するのがよいと考えられる。表 6 に、本実験における方式 A の要素の違いと、望ましい選択肢を記す。
表 6：各フルリゾルバ側ネットワーク研究組織における採用方式

要素

取りうる選択肢・AS131905
・プライベート AS

AS 番号

参加組織のルーターとの接続構成

・ローカルノードが直接接続
・ハードウェアルーターを介して接続

ルーティングプロトコル

・BGP
・OSPF

ローカルノード管理用ネットワークに対する外部からの直接アクセス・SSH も許可
・DNS 以外不許可

望ましい選択肢
RPKI の導入等を考えると、
AS131905 として参加組織のルーターと接続するのが望ましい。
ハードウェアルーターを介する場
合、障害点が増えることになる。ローカルノードが直接接続することが望ましい。
ローカルノードが直接接続する形態
では、EGP として利用できる BGPを採用する必要がある。
統計情報の取得等、限定されたホストから DNS 以外の通信を直接ローカ
ルノードに行う必要がある。

これらの望ましい選択肢で構成したローカルノードの接続図を図 5 に示す。
ローカルノード
設置組織の AS

AS131905(BGP) 103.198.210.0/24

サービス用（203.0.113.64/30）

198.51.100.242

203.0.113.65

203.0.113.66
198.51.100.242

管理用（198.51.100.240/30）

図 5：望ましい選択肢で構成したローカルノードの接続図

432017-10-31

3.4

今後の課題

本研究では、TLD（.jprs）の権威 DNS サーバーでの名前解決の安定性を評価することに焦点を当てた。ここでは今後、解決していく必要がある課題を示す。
3.4.1 研究課題
DNS は、階層的な分散型データベースシステムである。本研究では評価の単純化を目的として、
特定 TLD の権威 DNS サーバーに限定して評価を行った。ルートサーバー、他の TLD も含めた複合的なドメイン名の名前解決の安定性及び継続性の測定・評価が必要である。
3.4.2 実用化の課題.jp での実用化に向けて、前段の名前解決の安定的な提供の評価（方式 A）を踏まえて、技術面に関する追加評価だけでなく、提供ポリシーの検討が必要である。
性能の評価
フルリゾルバ側ネットワーク内に設置する権威 DNS サーバーに関わる DNS の名前解決の応答性能の評価。
運用管理の評価
フルリゾルバ側ネットワーク及び権威 DNS サーバー側ネットワークの各管理者間での平時・障害発生時の運用管理手順の評価。
提供ポリシーの検討
実用化時の契約形態、運用形態の検討。
フルリゾルバ側及び権威 DNS サーバー側のネットワーク間の責任分界点の明確化。

3.5

研究の成果

ここでは、1.2.3 の研究成果実施目標に対し、実施された成果を記す。
研究成果一覧表
種別
2016 年
9 月末
特許出願
0

3.5.1

2016 年
12 月末
02017 年
3 月末
02017 年
6 月末
02017 年
10 月末
0

0

0

0

0

0

0

0

0

1
APRICOT
2017/2
0

0

収録論文

1
CENTR R&D
2016/5
0

0

0

学術解説等

0

0

0

0

0

外部機関誌論
文

0

0

0

0

0

研究論文
外国発表予稿等

44

2017-10-31

0

0

0

0

0

1
JANOG38
2016/7

0

0

0

報道発表

0

0

0

1
DNS SummerDay
2017/6
0

その他資料

0

0

0

0

展示会（社外主催）
展示会（社内
主催）
標準化提案

0

0

0

0

1
報告書公開
2017/101
報告書
2017/10
0

0

0

0

0

0

0

0

0

0

0

著書等
一般口頭発表45

2017-10-31

3.6

注記事項

本報告書は下記の各社が共同で作成したものであり、著作権などの関係権利は各社が保有する。

株式会社日本レジストリサービス
北海道総合通信網株式会社
東北インテリジェント通信株式会社
北陸通信ネットワーク株式会社
株式会社ケイ・オプティコム
株式会社エネルギア・コミュニケーションズ
株式会社 STNet
株式会社 QTnet
沖縄通信ネットワーク株式会社

46

2017-10-31