1
特集●ネットワーク技術

DNS 探索グラフによる IPv4/IPv6 トランスポートを考慮した DNS 委譲構造の分析
浅井 大史

福田 健介

江崎 浩

DNS (Domain Name System) は現在のインターネットにおいて欠くことのできない名前解決システムとなっており，Web サービスやメールシステムなどの数多くのサービス・システムが DNS に依存している．そのため，DNSの障害は他のサービスやシステムにまで影響を及ぼすことが少なくなく，権威サーバの設定の妥当性や耐障害性を評価することは DNS に依存したサービスおよびシステムを安定運用する上で重要である．とりわけ IPv6 の導入に伴い，従来の IPv4 のみの単純な委譲関係だけではなくトランスポートを考慮した複雑な委譲構造を考慮する必要があ
る．本論文では，トランスポートを考慮した名前解決における委譲に基づいた DNS の木構造データベースの探索
過程をラベル付き有向グラフ構造（DNS 探索グラフ）として表現する手法を導入し，世界的な IPv6 運用試験イベ
ント期間中およびその前後に計測した DNS 探索グラフデータセットに対して，IPv4 および IPv6 の異なるトラン
スポートによる A レコードおよび AAAA レコードの名前解決における探索経路の傾向分析を行う．これにより，IPv6 アドレスを示す AAAA レコードの解決においても 81% ものドメイン名で IPv4 トランスポートが不可欠であり，また，世界的な IPv6 運用試験において，AAAA レコードを持つドメイン名の数は増加したが IPv6 トラン
スポートのみにより AAAA レコードを解決できるドメイン名の数は大きく変化しなかったことから，DNS の権威
サーバの IPv6 トランスポートへの対応が課題であることを示す．
The domain name system (DNS) has become a key infrastructure on the Internet, which is a tree-structured
directory service to look up resources, such as corresponding IP addresses, from domain names. Many
services and systems, such as Web services and E-mail systems, deeply rely on DNS. A DNS fault could
make a crucial impact on these services and systems. Therefore, evaluating the impact of misconfigurationand the fault tolerance is essential to keep services stable. Moreover, the DNS delegation relationships
recently become more complex because the DNS runs on the IPv4 & IPv6 coexisting Internet. In thispaper, we employ the DNS lookup graph that represents the domain name lookup procedure as a labeled
directed graph to show trends of the DNS lookup path in resolving A and AAAA records with IPv4 andIPv6 transport protocols using the datasets measured before, during, and after World IPv6 Day, and afterWorld IPv6 Launch. The results reveal that these IPv6 events have promoted to add AAAA records toeach domain name but most of them cannot be resolved only with IPv6 transport; i.e., IPv4 transport isrequired to resolve most (about 81%) of the AAAA records.

1 はじめにA Graph-based Analysis on DNS Delegation Relationships in IPv4 & IPv6 Coexisting Internet
Hirochika Asai, 東京大学大学院情報理工学系研究科,
Graduate School of Information Science and Technology,The University of Tokyo.
Kensuke Fukuda, 国立情報学研究所, National Instituteof Informatics.
Hiroshi Esaki, 東 京 大 学 大 学 院 情 報 理 工 学 系 研 究 科,
Graduate School of Information Science and Technology,The University of Tokyo.
コンピュータソフトウェア, Vol.0, No.0 (0), pp.0–0.
[研究論文] 2012 年 6 月 22 日受付.

DNS (Domain Name System) は現在のインター
ネットにおいて欠くことのできない名前解決システムとなっており，Web サービスやメールシステムなどの数多くのサービス・システムが DNS による名前解決を前提としている．そのため，DNS の障害や誤設定による品質低下はこれらのサービスやシステムにまで影響を及ぼすことが少なくなく，DNS に依存したサービスおよびシステムを安定運用する上で DNS
サーバの設定におけるその性能や耐障害性を評価する

コンピュータソフトウェア

2

ことは重要である．そのため，DNS の名前解決におおける IPv6 トランスポートへの対応が課題であるこける性能および品質や権威サーバにおける委譲関係のとを議論する．

誤設定による影響を評価する研究は従来から数多く

本論文の貢献は次の二つである．

行われてきた [10] [14] [4] [15] [7] [17] [16]．しかし，近年

1. 名前解決における委譲に基づいた DNS の木構の IPv6 の普及により，IPv6 アドレスを示す AAAA

造データベースの探索過程について，異なるトラレコードの解決や IPv6 トランスポートでの名前解決

ンスポートによる委譲関係を効率的に扱うことが加わり，DNS の名前解決過程はより複雑になった．

ができる表現手法を導入したこと．

例えば，A レコードしか持たないドメイン名に対し2. DNS 探索グラフを用いた分析により，IPv4 おても AAAA レコードの名前解決が行われることによ

よび IPv6 が混在する現在のインターネットにおり応答速度が低下したり，IPv6 アドレスを持つホス

いて DNS の IPv6 対応に関する課題を明らかに

トの AAAA レコード解決においても権威サーバがしたこと．

IPv6 対応していない場合は IPv4 トランスポートが必要となるという問題が発生している．そこで，これ2 関連研究らの問題に対し，名前解決の探索経路におけるトラン

DNS において名前解決時間の短縮や権威サーバのスポートまで含めた DNS の委譲構造の分析手法が必

負荷軽減を目的として導入されているキャッシュサー

要になってきている．

バの性能解析および性能向上手法の研究は数多くされ本論文では，名前解決クエリのトランスポートとしてきた [14] [7]．また，DNS 探索ツリーの委譲関係をて IPv4 および IPv6 の両方を用いたアクティブ計測

解析することで RFC1912 [3] で紹介されている DNSを行うことで，名前解決における委譲に基づいた DNS

権威サーバの誤設定が実際のインターネット上でどれの木構造データベースの探索過程をトランスポート情くらい発生しているかを調査し，その誤設定による報をラベルとして付与したラベル付き有向グラフ構

名前解決の耐障害性への影響を解析する研究も行わ

造（DNS 探索グラフ）として表現する手法を導入し，れてきた [17]．しかし，近年の IPv6 の普及により，世界的な IPv6 運用試験イベントである World IPv6
Day †1 （2011 年 6 月 8 日）の期間中およびその前

AAAA レコードの解決や IPv6 トランスポートによる名前解決過程が加わり，名前解決における探索経路

後，World IPv6 Launch †2 （2012 年 6 月 6 日）以においてトランスポートまで含めた新たな分析が必降に計測した DNS 探索グラフデータセットに対して，

要になってきている．

IPv4 および IPv6 の異なるトランスポートによる A

Plonka ら [18] は，DNS のキャッシュサーバにおいレコードおよび AAAA レコードの名前解決におけるて名前解決クエリ・レスポンスをパッシブ計測する

探索経路の傾向分析を行う．これにより，AAAA レ

ことで，実インターネットにおける DNS トラフィッ

コードの名前解決に対しても IPv4 トランスポートがクの特徴を分析した．より具体的には，1) IP アドレ

不可欠であり，また，A レコードの解決に IPv6 トラス（A レコード・AAAA レコード）や電子メールのンスポートを用いることで名前解決の品質が低下して配送先（MX レコード）の解決といった RFC で意図しまう恐れがあることを示す．また，世界的な IPv6

された DNS トラフィック，2) ブラックリストの確認

運用試験においても AAAA レコードを持つドメインなど他のサービスに利用されている DNS トラフィッ

名の数は増加したが IPv6 トランスポートのみにより

ク，3) 存在しないトップレベルドメイン（TLD: Top

AAAA レコードを解決できるドメイン名の数は大きLevel Domain）の問い合わせなど名前解決不可能な

く変化しなかったことを示し，DNS の権威サーバに

DNS トラフィックの 3 種類の DNS トラフィックについて，それぞれ分析・分類を行った．Plonka らは†1 http://internetsociety.org/ipv6/archive-2011-worldAAAA レコードの解決も分析対象として扱っている
ipv6-day†2 http://www.worldipv6launch.org/
が，この分析では名前解決クエリ・レスポンスのパッVol. 0 No. 0

1983

3

シブ計測に基づいているため，DNS 委譲構造に対す(A)る名前解決過程におけるトランスポートの差異につQuery label
www.example.com AAAA @192.0.2.100

いては考慮されていない．また，IPv6 トランスポー

QNAME

QTYPE

トを用いた名前解決の性能評価に関する研究 [6] [8] も行われているが，これらの研究においても DNS の委
譲関係および探索経路の分析は行われていない．

Response label
ns1.example.com (192.0.2.201)
Resource record(B)
NS
RR type

Query label
www.example.com AAAA @192.0.2.201
QNAME

QTYPE

NAME SERVER

NAME SERVER(B)

Response label
ns2.example.com (192.0.2.202)
Resource record

NS
RR type

Query label
www.example.com AAAA @192.0.2.202
QNAME

QTYPE

NAME SERVER

Pappas ら [16] は DNS 設定の特徴を解析し影響を及ぼす誤設定を検出するため，複数の計測点から

DNS 探索を行う手法を提案した．彼らは DNS ツリー(C)

Response label
2001:db8::cafe

AAAA

Resource record

RR typeの委譲関係をグラフ構造として表すことで DNS 権威
サーバの誤設定を検出するツールを提供しているが，このグラフは委譲関係のみを表しておりトランスポー
トに使われるネットワーク層のプロトコル（すなわち IPv4 および IPv6）については表現できていない．

DNS の委譲関係を有向グラフとして表し，ドメイン間の依存関係を確率遷移として表すことで，名前解決の品質を解析した Deccio らの研究 [11] は，DNS に(A) 探索の根となるルート DNS サーバへのクエリ(B) レスポンス（Answer または Authority セクション中の 1 レコード）およびこのレスポンスに応じた次の問い合
わせクエリ(C) Authoritative answer かつ最終的な回答であるレスポ
ンス
図1

DNS 探索グラフのラベル付け例

おける権威サーバの依存関係を有向グラフとして表す点においては，本研究のアプローチと類似していスポートを考慮した DNS 委譲構造の耐障害性や権威る．しかし，彼らの研究では名前解決に用いるトランサーバの誤設定が評価できることを示す．

スポートの違いについては考慮されていない．

DNS の名前解決過程において，通常，ある問い合

我々は，予備実験として，DNS の名前解決におけ

わせに対する回答（Answer または Authority セク

るトランスポートを考慮した DNS 探索グラフの可視ション）は複数あり一対多の関係である．一方，回化により DNS 権威サーバにおける誤設定の検出やボ答内のある 1 レコードに対する次の問い合わせは一トルネックの評価への応用可能性を示したが，DNS意に定まる．そこで，DNS 探索グラフでは，グラフ

探索グラフの特性に対する詳細な分析については行っの頂点はレスポンス（Answer または Authority セクてこなかった [21]．

ション中の 1 レコード）とこのレスポンスに対応する次の問い合わせクエリの組み合わせを表し，辺は3 DNS 探索グラフ

その問い合わせクエリに対するサーバからの回答に

DNS における名前解決は委譲に基づいた木構造の含まれる各レスポンス（レコード）への関係を表す．

データベースに対して再帰的に問い合わせることに

すなわち，DNS 探索グラフにおける頂点には，図 1より行われる．Pappas らの手法 [16] では DNS の委に示すように，レスポンスに関するラベル（リソース

譲関係から有向グラフを構成しているが，本論文でレコード，リソースタイプ）およびクエリに関するラは，DNS の委譲関係だけでなく名前解決におけるトベル（問い合わせ名，問い合わせタイプ，問い合わせ

ランスポートも考慮し，DNS の委譲に基づく木構造

先ネームサーバ）の二種類のラベルが付与される．よデータベースの探索過程をラベル付き有向グラフとり具体的には，レスポンスラベルとクエリラベルは頂して表す手法を提案する．なお，このラベル付き有点の種別ごとに次の 3 つの規則により付与される．

向グラフを DNS 探索グラフと呼ぶ．本節では，アク1. 探索の根となるルート DNS サーバへのクエリ：

ティブ計測による DNS 探索グラフの構築法を示すと探索の根であるためこの頂点にレスポンスラベ

ともに，そのグラフ特性から名前解決におけるトラン

ルは付与されず，ルート DNS サーバへの問い合コンピュータソフトウェア

4

わせに関するクエリラベルのみが付与される．

• CNAME：CNAME は Authoritative answer

2. レスポンス（Answer または Authority セクショのレスポンス内の Additional レコードから最終

ン中の 1 レコード）およびこのレスポンスに応的な回答を得られない場合は，ルート DNS サー

じた次の問い合わせクエリ：レスポンスラベルとバから CNAME を解決する．

それに対応したクエリラベルが付与される．な• キャッシュ：アクティブ計測において権威サーバ

お，レスポンスに対応した次の問い合わせクエリ

からのレスポンスのキャッシュは行わない．但し，とは，DNS の委譲（Authority セクション）に単一の DNS 探索グラフの構築過程において，同従った再帰問い合わせ，Authority セクションの一のネームサーバへの同一クエリは二度目以降

NS レコードや Answer セクションの CNAME

は問い合わせを行わずに DNS 探索グラフにおいレコードの名前解決を行うクエリのことである．

て辺を接続することにより探索試行の無限ルー

3. Authoritative answer かつ最終的な回答である

プを防ぐ．

レスポンス：最終的な回答であるレスポンスであ• DNS パケット：本論文では，DNS の問い合わるため，この頂点にはこれに応じた再帰問い合わ

せには最大 512 バイトのメッセージ長の UDP でせのクエリラベルは付与されず，レスポンスラベ計測を行う．

ルのみが付与される．

このような条件の下でアクティブ計測を行い DNS

なお，この DNS 探索グラフはアクティブ計測によ探索グラフを構築する．図 2 は www.google.com のり構築する．通常の DNS クライアント（リゾルバ）

A レコードを解決するときの DNS 探索グラフを可視による名前解決ではその委譲ツリーに従い深さ優先化した例である．この図において，(A) の頂点群は探で探索するが，DNS 探索グラフの構築においては幅索の根となるルート DNS サーバへのクエリ，すなわ

優先（全ての委譲先ネームサーバへの問い合わせ）ち [a-m].root-servers.net への www.google.com

で取り得る全ての探索過程を計測する．以下に，本の問い合わせを表し，(C) の頂点群は最終的なレス

論文における DNS 探索グラフの構築のためのアクポンスを表している．また，各頂点について，トラティブ計測について，使用するルート DNS サーバ，

ンスポートに IPv4 を用いたクエリを四角，IPv6 をAuthority セクションとグルーレコードの取り扱いお用いたクエリを円で表している．この DNS 探索グ

よび CNAME の探索，キャッシュの取り扱い，DNS

ラフを用いたトランスポートを考慮した分析は，クパケットについてまとめる．

エリラベルのトランスポートに従い頂点または辺を• ル ー ト DNS サ ー バ：ル ー ト DNS サ ー

除去することで得た部分有向グラフを分析すること

バは名前解決において探索の根となる．

で実現できる．例えば，トランスポートに IPv6 の[a-m].root-servers.net の 13 個全てのルーみを用いて名前解決が可能かどうかを判断する場

ト DNS サーバを使用する．

合には，この図の四角の頂点を除去した（円で表さ• Authority セクション（NS レコード）とグれる頂点のみを辿る）部分有向グラフ上で，探索のルーレコード：Authority セクションの NS レ

根となるルート DNS サーバへのクエリから最終的コードに対してグルーレコード（レスポンス内のなレスポンスを得ることができるかを判定すれば良Additional レコード）が指定されている場合は，い．なお，{a,c,e,i,j}.root-servers.net の 5 つ

このレスポンスに応じたクエリでグルーレコーのルート DNS サーバは DNS メッセージの 512 バ

ドで指定されたサーバ（アドレス）に再帰問い合

イト制限のため，.com の権威サーバの一つであるわせをする．グルーレコードが指定されていな

m.gtld-servers.net のグルーレコードを返さない．

い場合は，Authority セクションの NS レコード

そのため，図 2 では (X) および (Y) で示したようにに対して A レコードおよび AAAA レコードを

m.gtld-servers.net の名前解決を行う部分グラフ

ルート DNS サーバから再帰的に解決する．

が存在している．

Vol. 0 No. 0
Box : IPv4 transport
Oval: IPv6 transport!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;:$<?:-$$6$:;%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'7'7'684%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;6'46'6>'::%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'::'8'46%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$+A:$$:7%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;:$A6>$$6$:;%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%345B'84';'8%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'7B'46B':;%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;;$4$ B;:C$6:7%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'66B'>5'6;4%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$>C-$$7:%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;;$6C$$C%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'446':@'8%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456':@'48B'4>%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%346B'@:'6'7:%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%346B'B'4;'5;%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'6;:'6:;'4;%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$>C+$$4%!!!!

!"#$%<'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;:$6:4+$$6$:;%!!!!

!"#$%E'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'8B'>5':;%!!!!

!"#$%9'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'78'446':;%!!!!

!"#$%-'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'46'58':;%!!!!

!"#$%('()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'86'5:':;%!!!!

!"#$%='()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'8:'4>6':;%!!!!

!"#$%?'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'7'@':;%!!!!

!"#$%*'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'84'4@6':;%!!!!

!"#$%A'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'6@'56':;%!!!!

!"#$%?'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;:$?B:-$$6$:;%!!!!

!"#$%<'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'::'48':;%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'77'B:':;%!!!!

!"#$%C'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456':7'74':;%!!!!

!"#$%D'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'76'4>B':;%!!!!

!"#$%+'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456':4'B;':;%!!!!

!"#$%?6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;:$?B:-$$6$:4%!!!!

!"#$%+6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456':4'B;':4%!!!!

!"#$%A6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;:$B:-<$$6$:4%!!!!

!"#$%*6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'84'4@6':4%!!!!

!"#$%96'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'78'446':4%!!!!

!"#$%(6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'86'5:':4%!!!!

!"#$%A6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'6@'56':4%!!!!

!"#$%C6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456':7'74':4%!!!!

!"#$%?6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'7'@':4%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3455'>'B:'86%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;;$:$ 86%!!!!

!"#$%-6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'46'58':4%!!!!

(X) To resolve AAAA records ofm.gtld-servers.net. (not in glue)!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%345:';'48'465%!!!!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$>C-$$7:%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;;$6C$$C%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%346B'@:'6'7:%!

1983

5

(A) Queries to root DNS servers

2$%FFF'(GG(*-'AG&'%3456':@'48B'4>%!

2$%FFF'(GG(*-'AG&'%345B'84';'8%!

2$%FFF'(GG(*-'AG&'%36;;4$7;:$A6>$$6$:;%!

2$%FFF'(GG(*-'AG&'%3456'6;:'6:;'4;%!

2$%FFF'(GG(*-'AG&'%36;;4$>C-$$7:%!

2$%FFF'(GG(*-'AG&'%36;;4$7;:$<?:-$$6$:;%!

2$%FFF'(GG(*-'AG&'%3456'7B'46B':;%!

2$%FFF'(GG(*-'AG&'%3456'::'8'46%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'7'7'684%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'446':@'8%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;6'46'6>'::%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456':@'48B'4>%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%346B'B'4;'5;%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;;$4$ B;:C$6:7%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;:$<?:-$$6$:;%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$+A:$$:7%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'::'8'46%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'66B'>5'6;4%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'7B'46B':;%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;:$A6>$$6$:;%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'6;:'6:;'4;%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%345B'84';'8%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$>C+$$4%!

2$%FFF'(GG(*-'AG&'%346B'B'4;'5;%!

!"#$%<'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;:$6:4+$$6$:;%!

!"#$%+'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456':4'B;':;%!

!"#$%?'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'7'@':;%!

!"#$%D'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'76'4>B':;%!

!"#$%*'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'84'4@6':;%!

!"#$%='()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'8:'4>6':;%!

!"#$%<'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'::'48':;%!

!"#$%-'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'46'58':;%!

!"#$%A'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'6@'56':;%!

!"#$%?'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;:$?B:-$$6$:;%!

!"#$%9'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'78'446':;%!

!"#$%C'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456':7'74':;%!

!"#$%('()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'86'5:':;%!

!"#$%E'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'8B'>5':;%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'77'B:':;%!

!"#$%(6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'86'5:':4%!

!"#$%+6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456':4'B;':4%!

!"#$%?6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;:$?B:-$$6$:4%!

!"#$%-6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'46'58':4%!

!"#$%*6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'84'4@6':4%!

!"#$%A6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'6@'56':4%!

!"#$%C6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456':7'74':4%!

!"#$%?6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'7'@':4%!

!"#$%96'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3456'78'446':4%!

!"#$%A6'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;:$B:-<$$6$:4%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%345:';'48'465%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%3455'>'B:'86%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%36;;4$7;;$:$ 86%!

!"#$%<'()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%36;;4$7;:$6:4+$$6$:;%!

!"#$%?'()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%3456'7'@':;%!

2$%FFF'(GG(*-'AG&'%36;;4$7;;$4$ B;:C$6:7%!

!"#$%<'()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%3456'::'48':;%!

2$%FFF'(GG(*-'AG&'%345:';'48'465%!

!"#$%+'()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%3456':4'B;':;%!

2$%FFF'(GG(*-'AG&'%36;6'46'6>'::%!

!"#$%-'()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%3456'46'58':;%!

2$%FFF'(GG(*-'AG&'%3456'7'7'684%!

!"#$%D'()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%3456'76'4>B':;%!

2$%FFF'(GG(*-'AG&'%36;;4$+A:$$:7%!

!"#$%*'()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%3456'84'4@6':;%!

2$%FFF'(GG(*-'AG&'%3456'446':@'8%!

!"#$%('()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%3456'86'5:':;%!

2$%FFF'(GG(*-'AG&'%3456'66B'>5'6;4%!

!"#$%?'()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%36;;4$7;:$?B:-$$6$:;%!

(Y) To resolve A records ofm.gtld-servers.net. (not in glue)!"#$%&'()*+,#-./-.#'"-)'%01
2$%&'()*+,#-./-.#'"-)'%34556$758$9:8-$$4$85%!!!!

2$%FFF'(GG(*-'AG&'%36;;4$7;;$:$ 86%!

!"#$%A'()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%3456'6@'56':;%!

2$%FFF'(GG(*-'AG&'%346B'@:'6'7:%!

!"#$%E'()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%3456'8B'>5':;%!

2$%FFF'(GG(*-'AG&'%36;;4$7;;$6C$$C%!

!"#$%C'()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%3456':7'74':;%!

2$%FFF'(GG(*-'AG&'%36;;4$>C+$$4%!

!"#$%9'()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%3456'78'446':;%!

!"#$%&'()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%3456'77'B:':;%!

Queries to authoritative
servers for ".com"
Queries to authoritative
servers for ".google.com"!"#$%456'77'B:':;%!
2$%FFF'(GG(*-'AG&'%3456'77'B:':;%!

Answer/Authority

図2

2$%FFF'(GG(*-'AG&'%3455'>'B:'86%!

!"#$%='()*+,#-./-.#'"-)'%01
2$%FFF'(GG(*-'AG&'%3456'8:'4>6':;%!

!"#$%"#6'(GG(*-'AG&'%01
2$%FFF'(GG(*-'AG&'%364@'6:5':8'4;%!

!"#$%>6'48'6;:'55%!

!"#$%"#:'(GG(*-'AG&'%01
2$%FFF'(GG(*-'AG&'%364@'6:5':@'4;%!

!"#$%>6'48'6;:'4;@%!

!"#$%>6'48'6;:'4;7%!

!"#$%"#8'(GG(*-'AG&'%01
2$%FFF'(GG(*-'AG&'%364@'6:5':B'4;%!

!"#$%>6'48'6;:'4;8%!

!"#$%"#4'(GG(*-'AG&'%01
2$%FFF'(GG(*-'AG&'%364@'6:5':6'4;%!

!"#$%>6'48'6;:'48>%!

!"#$%>6'48'6;:'4;:%!

(C) Authoritative answers!"#$%"#&'())(*+',)-'%./
0$%111'())(*+',)-'%23&4'356'53'&7%!
QNAME=ns1.google.com

DNS 探索グラフ：www.google.com（A レコード）

DNS 探索グラフは再帰問い合わせで取り得る全て

誤設定の検出や DNS 委譲構造に対する耐障害性の評の探索過程を計測しているため，予備実験 [21] でも価ができることを示した．本節では，大規模なドメイ示したように，DNS 探索グラフの可視化およびそのン名データセットに対して，IPv4 および IPv6 の異グラフ特性は現在の設定の妥当性やボトルネック，単なるトランスポートによる A レコードおよび AAAA

一故障点などを評価するのに有用である．また，DNS

レコードの名前解決における探索経路の傾向分析を探索グラフはラベル付き有向グラフとして表される

行う．ここで，トランスポートを考慮した DNS 委譲

ため，既存のグラフ解析手法を応用し DNS 探索グラ

構造の分析を行うために前節で説明した DNS 探索グ

フの特性を定量的に分析することが可能である．例え

ラフを応用する．

ば，DNS 探索グラフにおいて循環路を検出することで権威サーバの誤設定の一つである委譲関係のルー

4. 1 データセット

プを検出することができる．実際に，100 頂点の規模

まず本論文で解析に用いるドメイン名データセッの DNS 探索グラフにおいて循環路を発見することにトについて説明する．DNS においてドメイン名はツより権威サーバの誤設定を検出できた．また，頂点間リー構造のデータベースにより分散管理されており，の辺に遷移確率を設定することで各頂点への到達確

大量のドメイン名リストを取得することは非常に困率を計算することができ，この確率により障害発生時難である．Brownlee ら [4] による実験のように Rootの影響度を評価することができる．さらに，この遷移

DNS サーバでのパッシブ計測データを用いることで確率を応用することで，図 2 における (X) のように，問い合わせのあったドメイン名のリストを得ることがグルーレコードを含まないレスポンスにおいてネー

できるが，ルート DNS サーバへの問い合わせデータ

ムサーバの名前解決に失敗し，別の探索経路を再試行

は一般に公開されていない．また，Internet Systems（フォールバック）するような名前解決速度の低下をConsortium (ISC) により，ドメイン名データ [9] も引き起こす探索経路への到達確率を評価できる．実際

公開されているが，1997 年以降は調査方法が正引きに図 2 の例では，ある頂点から別の頂点への遷移確（ゾーン転送）ではなく逆引きによるドメイン名の調率について Authority セクションの複数の候補から査に変更されたため，本論文で解析の対象とする正引

無作為に選択すると仮定すると，頂点間の遷移確率かきのデータは提供されていない．

ら (X) に到達する確率が 1.48% であることがわかる．

そ こ で ，本 論 文 で は Web ペ ー ジ の ハ イ パ ー
リンクを巡回することでドメイン名リストを

4 DNS 探索グラフの解析

収 集 し た ．Web ペ ー ジ の ハ イ パ ー リ ン ク の 巡 回

前節で DNS 探索グラフの可視化およびその特性のは，http://directory.google.com/ および http:分析によりトランスポートを考慮した権威サーバの//www.ietf.org/ を起点として，各 Web サイトの

コンピュータソフトウェア

6
表1

各 DNS 探索グラフデータセットに含まれる有効ドントであり全ドメインへの計測は実施できなかったた

メイン数
データセット名

Before IPv6 Day
During IPv6 Day
After IPv6 Day
IPv6 Launch

は，World IPv6 Day は 24 時間のみ実施されたイベ

有効ドメイン数めである．そのため，World IPv6 Day 前日（Before

41524
41518
41524
39265

IPv6 Day）に無作為順序により 24 時間以内に計測が完了した 54638 ドメインのみを用いた．この 54638
ドメインは無作為に抽出され，また全有効なドメイ
ンの 29% にあたるため，解析結果に影響はないと考

robots.txt ファイルに指定されている巡回ポリシー

えられる．なお，選択した 54638 ドメインのうち 67に従い実施した．Web ページのハイパーリンクの巡ドメインが Alexa Top 500 Global Sites [1] に含まれ回により，2011 年 1 月 17 日から 2011 年 3 月 26 日ており，選択したドメインは特殊なものばかりではな

までに約 490 万のユニーク URL を取得し，これら

くアクセス数の多い Web サイトのドメイン名も多くの URL から 320058 のドメイン名を得た．このうち，含んでいた．また，World IPv6 Day 以外は時間の制

巡回時に A レコードまたは AAAA レコードのいず

約はなかったが，異なるデータセット間での傾向を比れかが解決できた有効なドメイン数は 185785（58%）

較するために各データセットの計測において同一のであった. 残りの解決できなかったドメイン名は主と54638 ドメインを用いた．

してスパム等に用いられる一時的なドメイン名であることを確認した．

4. 2 IPv6 トランスポートによる名前解決

本論文では，これらの有効なドメインのうち無作

近年の IPv6 の普及により，AAAA レコードの解為に選択した 54638 ドメインに対し，世界的な IPv6

決や IPv6 トランスポートによる名前解決過程が加運用試験イベントにあわせ，次の 4 回の A レコード

わり，名前解決における探索経路は複雑になってき

および AAAA レコードの名前解決によるアクティブているが，トランスポートを含めた DNS の委譲構

計測により，4 つの DNS 探索グラフデータセットを造についてはこれまで調査分析されてこなかった．

得た．

RFC4472 [13] では，全てのゾーンに対して少なくと• Before IPv6 Day：2011 年 6 月 7 日（World
IPv6 Day 前）• During IPv6 Day：2011 年 6 月 8 日（World
IPv6 Day 期間中）
• After IPv6 Day： 2011 年 6 月 15 日（World
IPv6 Day 後）• IPv6 Launch： 2012 年 6 月 6 日（World IPv6
Launch 以降）

も 1 つの権威サーバは IPv4 での接続性を提供すべきであると規定しているため，権威サーバが RFC4472
に従い運用されていれば IPv4 トランスポートのみによる名前解決は保証される．しかし，RFC4472 では
権威サーバにおける IPv6 の設定については規定されていないため，IPv6 トランスポートによる名前解決は保証されておらず各ゾーンの運用ポリシーおよび設定に依存する．本小節では，DNS 探索グラフを用

各データセットに含まれる各計測時に A レコードまいて IPv6 トランスポートによる名前解決の能否と品たは AAAA レコードのいずれかが解決できた有効な質への影響について傾向を分析する．

ドメイン数を表 1 にまとめる．本論文では，これらの

まず，IPv6 Launch データセットに含まれる各ド

データセットにおける DNS 探索グラフを対象に分析

メイン名について，IPv4 トランスポートおよび IPv6を行った．なお，World IPv6 Day は 24 時間限定で

トランスポート，またはそれらのどちらか一方を用い

IPv6 運用試験を行う趣旨のイベントであり，Worldた場合の A レコードおよび AAAA レコードに対す

IPv6 Launch はこれ以降恒久的に IPv6 を有効化する

る名前解決の能否をまとめ，その傾向について議論す趣旨のイベントであった．ここで，有効な 185785 ドる．特定のトランスポートを用いた名前解決の能否をメインから無作為に 54638 ドメインを選択した理由判定する問題は，DNS 探索グラフからクエリラベル

Vol. 0 No. 0

1983

表2

(I) A via IPv4

(II) AAAA via IPv4

7

IPv6 Launch データセットにおける各集合に属す
るドメイン名の数
ドメイン名の数(III) A via IPv6

図3(IV) AAAA via IPv6

名前解決におけるレコード種別とトランスポートのトランスポートに基づき特定のトランスポート以

総数
A レコードあり
AAAA レコードあり
集合 I
集合 II
集合 III
集合 IV
集合 II \ 集合 IV
集合 IV \ 集合 II
集合 III \ 集合 I

39265
39245
4725
39150
4662
3513
839
3837
14
0

外の頂点を除外した部分有向グラフの到達性問題であり，既存のグラフ解析手法を用いることができる．

ランスポートから解決できるドメイン名，集合 III は

ここで，有向グラフの到達性問題は，有向グラフを

A レコードを IPv6 トランスポートから解決できるド

隣接行列 A と表したとき次のように表される．x 行

メイン名，集合 IV は AAAA レコードを IPv6 トラ

x 列に対応する頂点 vx から y 行 y 列に対応する頂点

ンスポートから解決できるドメイン名を表している．

vy までの到達性を判定するとき，
8<sij = 1 where i = j = x“ ” >S = sij>:sij = 0 otherwise
8><tij = 1 where i = j = y“ ”
T = tij>:tij = 0 otherwiseとすると，これに従うと，例えば，A レコードを IPv4 トランスSA(i−1) T = O(∀i ∈ N | 1 ≤ i ≤ n)であるとき vx から vy への到達性がないと判定できる．なお，DNS 探索グラフからクエリラベルに基づ
きトランスポートを考慮した部分有向グラフを構築する必要があるが，クエリラベルに基づき DNS 探索グ
ラフからトランスポートを考慮した部分有向グラフを得る計算は隣接行列への変換と同時に行えるため，計算上の損失はほとんどない．
ドメイン名の正引きにおいて，IPv4 アドレスを表すリソースには A レコード，IPv6 アドレスを表すリ
ソースには AAAA レコードが使用される．また，これらのレコードを解決するためのトランスポートとして，IPv4 または IPv6 が使用される．図 3 に名前解決におけるレコード種別（A/AAAA）とトランスポート（IPv4/IPv6）の組み合わせをまとめる．集合

I は A レコードを IPv4 トランスポートから解決できるドメイン名，集合 II は AAAA レコードを IPv4 ト

ポートでも IPv6 トランスポートでも解決できるドメ
イン名は集合 I および III の積集合に属する．なお，
トランスポートに IPv4 と IPv6 の両方を利用しないと解決できないドメイン名も理論上は存在しうるため，集合 I–IV 以外に属するドメイン名も存在しうる．
例えば，foo.bar.example.net の名前解決に対して，

example.net ゾーンの権威サーバが全て IPv6 非対応でかつ bar.example.net ゾーンの権威サーバが全て IPv4 非対応である場合などが集合 I–IV 以外に属するドメイン名に該当する．ただし，RFC4472 [13]では，全てのゾーンに対して少なくとも 1 つの権威サーバは IPv4 での接続性を提供すべきであると規定しているため，IPv4 非対応の権威サーバは多くは存在しないと考えられる．
表 2 に IPv6 Launch データセットにおける各集合に属するドメイン名の数をまとめる．[集合 III \ 集合

I] は A レコードが付いているドメイン名のうち IPv4
トランスポートで解決できないものを表しているが，このようなドメイン名は IPv6 Launch データセットには含まれなかった．一方，[集合 IV \ 集合 II] は

AAAA レコードが付いているドメイン名のうち IPv4
トランスポートで解決できないものを表しており，こちらは AAAA レコードが付いているドメイン名全体

コンピュータソフトウェア

8問い合わせが失敗し A レコードを再探索するため，

1
A w/ IPv4
A w/ IPv4/IPv6 (IPv6-preferred)
A w/ IPv4/IPv6 (random)
AAAA w/ IPv4/IPv6 (IPv6-preferred)
AAAA w/ IPv4/IPv6 (random)

0.8

このフォールバックによるオーバーヘッドが発生し，名前解決において応答速度が遅くなるなど性能低下が生じてしまう．なお，ネームサーバの名前解決（特

CCDF

0.6

に AAAA レコードの解決）の失敗以外によるフォー
ルバックの原因として，パケットロスや一時的なネッ

0.4

トワークまたは権威サーバの障害，誤設定が挙げられ

0.2

るが，これらはネームサーバの名前解決によるフォー
0
0

図4

0.2

0.4
0.6
Fallback probability

0.81

各名前解決戦略におけるフォールバック発生確率

ルバックと比較して稀であると考えられるため，本論
文では対象としない．フォールバックが発生する確率
は，DNS 探索グラフにおいて，ある頂点から別の頂点に遷移する確率を名前解決戦略に応じて設定するの 0.30% (14/4725) であり非常に少ない割合である．

ことで計算できる．本論文では次の 3 つの名前解決

これは RFC4472 で規定されているように各ゾーン戦略についてフォールバック発生確率を評価する．

に対する権威サーバが IPv4 で DNS サービスを提供

1. “A w/ IPv4”: IPv4 トランスポートのみを用いしているためであるが，この結果から AAAA レコーて A レコードを解決する戦略．DNS 探索グラフ

ドの名前解決においては RFC4472 に従わず IPv6 トからクエリラベルに基づき IPv6 トランスポート

ランスポートを用いなければ解決できない AAAA レの頂点を取り除いた部分有向グラフ上の頂点間

コードが少数ではあるが存在することが示された．[集を等確率で遷移する．

合 II \ 集合 IV] は AAAA レコードが付いているド2. “A/AAAA w/ IPv4/IPv6 (IPv6-preferred)”:

メイン名のうち IPv6 トランスポートで解決できない

IPv6 トランスポートを優先的に利用して IPv6

ものを表しており，AAAA レコードが付いているドトランスポートが利用できない条件でのみ IPv4

メイン名全体の約 81% (3837/4725) にも及ぶ．つまを利用して A/AAAA レコードを解決する戦略．

り，IPv6 に対応したサービスを提供しておりドメイ

DNS 探索グラフからクエリラベルに基づき，IPv6

ン名に AAAA レコードを設定していても，多くの場

トランスポートの隣接頂点への辺が存在する全

合 DNS における名前解決には IPv4 トランスポートての頂点からの IPv4 トランスポートの隣接頂点が不可欠であるということを示している．すなわち，への辺を取り除いた部分有向グラフ上の頂点間

DNS の名前解決における探索経路においては，IPv6を等確率で遷移する．

トランスポートは IPv4 アドレスを表す A レコード

3. “A/AAAA w/ IPv4/IPv6 (random)”: IPv4

のみならず IPv6 アドレスを表す AAAA レコードのおよび IPv6 トランスポートの差異を考慮せずに解決に対しても不十分であり，IPv4 トランスポート

無作為に選択して A/AAAA レコードを解決すが必須であると言える．

る戦略．DNS 探索グラフ上の頂点間を等確率で遷移する戦略であり，DNS 探索グラフ上のラン

4. 3 フォールバック発生確率の評価

ダムウォークに該当する．

予備実験 [21] および第 3 節でも指摘したように，

図 4 はそれぞれの名前解決戦略を取った場合のフォー

DNS の委譲はドメイン名により行われるため，グ

ルバック発生確率の CCDF を表している．この図ルーレコードが存在せずにネームサーバのアドレスを

は大きく三つの傾向を表している．まず一つ目の傾解決する必要がある場合は，ネームサーバの AAAA

向は，IPv4 トランスポートのみを用いて A レコー

レコードの解決が行われる可能性がある．しかし，対ドを解決する戦略（“A w/ IPv4”）は他の戦略と比象のネームサーバが IPv6 対応していない場合はこの較してフォールバック発生確率が最も低いことであVol. 0 No. 0

1983
40000

ており，A レコードが設定されているため，IPv4 ト

35000

ランスポートを利用するためのネームサーバの A レ

30000

コードの解決に失敗する確率が低いためである．二つ目の傾向は，A レコードの解決に IPv6 トランス
ポートを利用する戦略（“A w/ IPv4/IPv6 (IPv6-# of domain names

る．これは，多くのネームサーバが IPv4 に対応し

25000
20000

10000

他の戦略と比較して非常に高いことである．A レコー

5000

ドの解決に IPv6 トランスポートを用いた場合，43%0Before IPv6 DayDuring IPv6 Day After IPv6 Day
Datasetのドメイン名でフォールバックが発生している．こポート対応のネームサーバが少ないためである．三つ目の傾向は，AAAA レコードの解決に IPv6 トラ(I) A w/ IPv4
(II) AAAA w/ IPv4
(III) A w/ IPv6
(IV) AAAA w/ IPv6

15000

preferred/random)”）のフォールバック発生確率が，

れは，AAAA レコードの設定された IPv6 トランス9

図5

IPv6 LaunchWorld IPv6 Day 期間中およびその前後とWorld IPv6 Launch 以降のデータセットにおけるレ
コード種別とトランスポートの分類

ンスポートを利用する戦略（“AAAA w/ IPv4/IPv6(IPv6-preferred/random)”）のフォールバック発生確

図 5 に World IPv6 Day 期間中およびその前後率が，IPv4 トランスポートのみを用いて A レコーと World IPv6 Launch 以降のデータセットにおけドを解決する戦略よりも高く，A レコードの解決にるレコード種別とトランスポートの分類を示す．こIPv6 トランスポートを利用する戦略よりも低いことの図より，World IPv6 Day 当日および World IPv6

である．これらの傾向をまとめると，IPv6 トランス

Launch 以降は IPv4 トランスポートにより解決できポートを利用する戦略，特に A レコードの解決におる AAAA レコードの数が増加しているが，IPv6 ト

いて IPv6 トランスポートを利用する戦略は名前解決

ランスポートにより解決できる A および AAAA レの性能低下につながることが示された．なお，どの戦

コード数はほぼ変化しなかったことがわかる．すなわ

略においてもフォールバック発生確率が 0.5 を超える

ち，World IPv6 Day および World IPv6 Launch でものが少ないのは，フォールバックが発生しうるネー

はサービスを提供するドメイン名に AAAA レコード

ムサーバの名前解決に対して A レコードと AAAA レが付与されたものの，各権威サーバの IPv6 トランス

コードの探索経路があるが，権威サーバにおける誤設

ポートへの対応が大きく行われなかったことがわか

定やパケロス，ネットワークまたは権威サーバに障害る．また，World IPv6 Day 後はイベント前のようにが発生していなければ，これらのうち少なくとも一方戻っていた．しかし，IPv6 トランスポートにより解は解決できるためである．

決できる A および AAAA レコード数（図 3 における集合 (III) および集合 (IV)）は，傾きは大きくない

4. 4 IPv6 運用試験イベントの分析

ものの単調増加傾向にあり，権威サーバの IPv6 トラ

本小節では第 4. 1 項で定義した 4 つのデータセット

ンスポートへの対応はイベントによる巨視的な対応に対して，第 4. 2 項で行った名前解決におけるレコー

はないものの少しずつ進んでいることが見て取れる．

ド種別とトランスポートの分析を行い，World IPv6

図 6 は AAAA レコードが付いているドメイン名

Day および World IPv6 Launch による DNS の委譲のうち IPv6 トランスポートで解決できないドメイン

構造の変化について議論する．まず，4 つのデータの数およびその割合と AAAA レコードが付いている

セットについて，各データセットで計測した 54638 ド

ドメイン名のうち IPv6 トランスポートで解決できるメインの内，全てのデータセットにおいて A レコー

ドメインの数を示しており，この図からも AAAA レドまたは AAAA レコードが解決できた 37678 個のドコードの付いているドメイン数は World IPv6 Day

メイン名を分析対象とした．

および World IPv6 Launch により大幅に増加したもコンピュータソフトウェア

10はない．一方，DNS 探索グラフでは名前解決に対し
5000

1# of AAAA# of (II) \ (IV)# of AAAA - [(II) \ (IV)]
Ratio of [(II) \ (IV)] / AAAA4500

DNS の木構造データベースを全探索した結果をグラフ構造として保持するため，到達性判断やフォール

0.8

3500

バック発生確率の計算を確実に行うことができる．ま

3000

0.6
Ratio

# of domain names

4000

2500
2000

0.4

1500
1000

0.2

表現されるため，グラフの特徴量解析やグラフマイニ
ングなど，他のグラフ分析手法を広く応用できる点でも優位であると考える．

500
0

0
Before IPv6 DayDuring IPv6 Day After IPv6 Day
Dataset

図6

た，DNS 探索グラフはラベル付き有向グラフとして

IPv6 LaunchWorld IPv6 Day 期間中およびその前後と

DNS 探索グラフの分析結果に対する議論
本論文において第 4 節で行った DNS 探索グラフの分析から得られた知見を以下にまとめ，DNS の IPv6

World IPv6 Launch 以降の AAAA レコードに関するへの移行について議論する．IPv6 運用試験イベント

分析結果などにより AAAA レコードの設定は促進されたが，DNS の権威サーバにおける IPv6 トランスポートへのの，AAAA レコードが付いているドメイン名のうの対応（ネームサーバへの AAAA レコードの設定）

ち IPv6 トランスポートで解決できるドメインの数のは進んでおらず，名前解決において IPv4 トランス

増加は少なく，権威サーバの IPv6 トランスポートへポートが必要不可欠である．また，このような状況での対応が大きく行われなかったことがわかる．

IPv6 トランスポートを使用しようとネームサーバの
AAAA レコードを解決すると名前解決の再起問い合

5 考察

わせにおいてフォールバックが発生し，名前解決速度

DNS 探索グラフの優位性の低下を引き起こす可能性ある．特に A レコードの第 4 節では DNS 探索グラフを用いて IPv6 運用試

解決において IPv6 トランスポートを使用する場合，

験イベント期間中および前後の計測データセットに

43% ものドメイン名でフォールバックが発生するこ対して DNS の委譲構造の分析を行った．第 4 節で分とが示された．さらに，RFC4472 では，全てのゾー

析したように，IPv6 の普及により，AAAA レコードンに対して少なくとも 1 つの権威サーバは IPv4 でのの解決や IPv6 トランスポートによる名前解決過程

接続性を提供すべきであると規定しているため，現が加わることで，DNS の名前解決における探索経路

状では名前解決には IPv4 トランスポートを用いるこは複雑になってきている．DNS 探索グラフは従来手とが名前解決の性能維持にはより良いと考えられる．

法 [16] とは異なり，名前解決におけるトランスポー

しかし，このような状況では DNS は IPv4 トランス

トを含めた探索過程をラベル付き有向グラフとしてポートが必須となり，IPv6 への移行が促進されない表現することができ，IPv4 および IPv6 が混在する

ため，移行技術や方針が必要となると考える．

環境における DNS の委譲構造の分析を可能とした．

フォールバック発生確率の分析について

なお，本論文で行った到達性判断やフォールバック

第 4. 3 項ではフォールバック発生確率による DNS

発生確率の計算については DNS 探索グラフを用いずの委譲構造の性能評価を行った．しかし，本論文でに，通常の DNS クライアントによる名前解決のようは，フォールバックの発生する条件を DNS 探索グラに DNS の木構造データベースを辿り一定回数またはフの葉として表現したため，フォールバック後の再一定時間以内に名前解決ができるかを判定したり，同探索における遷移確率を DNS 探索グラフ上で定義で様の手法でにフォールバック率を計測する方法が考きない．今後，フォールバックした場合の DNS 探索

えられるが，このような手法は DNS の木構造データ

グラフの構築法として，フォールバックした頂点かベースに対して全探索を行わないため結果が確実でらさらにグラフを成長させる方法を検討する．なお，

Vol. 0 No. 0

1983

11

DNS 探索グラフにおける遷移確率は，フォールバッ

トランスポートが不可欠であり，また，A レコード

ク発生確率の計算以外にもループの検出および発生の解決に IPv6 トランスポートを用いた場合は名前解確率の評価や権威サーバまたはネットワーク障害によ

決の品質が低下してしまう恐れがあることを示した．

る影響評価に応用することができると考えられる．

さらに，これらの IPv6 運用試験イベント期間中とそアクティブ計測についての前後の傾向を分析することで，これらのイベント

本論文におけるアクティブ計測では DNS の問い合で多くのドメイン名に AAAA レコードが設定された

わせには最大 512 バイトのメッセージ長の UDP で計が，権威サーバの IPv6 トランスポートへの対応は大測を行い，EDNS0 [19] や TCP での計測には対応しきくは進んでいないことがわかった．RFC4472 ではなかったが，第 3 節で例示したようにメッセージ長が全てのゾーンに対して少なくとも 1 つの権威サーバ

512 バイトを超えてしまうために Addtional セクショ

は IPv4 での接続性を提供すべきであると規定していンにグルーレコードを含まないレスポンスを返すネー

るが，今後の IPv6 への移行に際して IPv6 トランス

ムサーバが存在し，これによりフォールバックが発生

ポートを名前解決に用いた場合の性能の低下を排除すする可能性がある．しかし，このようなネームサーバる技術（例えば，Happy Eyeballs [20] のような技術）

は，Authority セクションおよび Additional セクショが必要となると考える．本論文では，このような分析

ンに多数のレコードを含むものであるため，ルート

を通じて DNS 探索グラフがトランスポートを考慮しDNS サーバや TLD の権威サーバであると考えられ，

た DNS 委譲構造の分析に有効であることを示した．

第 3 節で示したように，このような場合のフォール

なお，DNS の委譲関係の可視化および解析は，バック確率は低いため無視できると考えられる．ただDNSSEC における認証の依存関係の分析にも応用可

し，今後は DNS Security Extensions (DNSSEC) [2]

能であると考えられる．DNSViz [12] では，DNSSECの普及によりルート DNS サーバや TLD の権威サーの認証順序を可視化し，検証するツールを提供してバ以外の権威サーバからのレスポンスについてもメッいるが，ドメイン名の委譲関係に基づいて検証を行っセージ長の増大が予想される一方，2009 年時点で既ているため，CNAME や別ゾーンの NS レコードのに 50% 以上のクエリが EDNS より長いメッセージ長

参照など，実際の名前解決過程に対する DNSSEC のに対応しておりこの割合は増加傾向にあることが報検証は実現できていない．今後，DNS 探索グラフを

告されている [5] ため，今後は EDNS0 や TCP によ

DNSSEC の検証に応用し，名前解決過程に対して検る長いメッセージ長でも計測を行い，メッセージ長に証のボトルネックや誤設定の影響を評価する手法およよる影響を考慮したより詳細な分析に対応する．

びツールを研究・開発する．
謝辞 本研究は科研費 (23680005) の助成を受けた6 まとめものである．

本論文では，名前解決クエリのトランスポートとして IPv4 および IPv6 の両方を用いたアクティブ参 考 文 献計測により，名前解決のトランスポートを考慮した[ 1 ] Alexa Internet, Inc.: Alexa Top 500 Global Sites,
http://www.alexa.com/topsites.
[ 2 ] Arends, R., Austein, R., Larson, M., Massey, D.,
and Rose, S.: DNS Security Introduction and Requirements, RFC 4033 (Proposed Standard), March2005.
[ 3 ] Barr, D.: Common DNS Operational and Configuration Errors, RFC 1912 (Informational), February 1996.
[ 4 ] Brownlee, N., Claﬀy, K., and Nemeth, E.: DNS
measurements at a root server, IEEE GLOBECOM’01, Vol. 3, 2001, pp. 1672 –1676 vol.3.

DNS の木構造データベースの全探索過程をグラフ構造（DNS 探索グラフ）として表現する手法を提案し，
この DNS 探索グラフを用いて，世界的な IPv6 運用
試験イベントにて計測した DNS 探索グラフデータ
セットに対して，IPv4 および IPv6 の異なるトラン
スポートによる A レコードおよび AAAA レコードの名前解決における探索経路の傾向分析を行った．この結果，AAAA レコードの名前解決に対しても IPv4

12

コンピュータソフトウェア[13] Durand, A., Ihren, J., and Savola, P.: Opera[ 5 ] CAIDA: Cooperative Association for Internet
tional Considerations and Issues with IPv6 DNS,
Data Analysis: DNS Evolution, http://www.caida.org
RFC 4472 (Informational), April 2006.
/research/dns/roottraﬃc/evolution/.
[14] Jung, J., Sit, E., Balakrishnan, H., and Mor[ 6 ] Cho, K., Luckie, M., and Huﬀaker, B.: Idenris, R.: DNS performance and the eﬀectivenesstifying IPv6 network problems in the dual-stackof caching, ACM SIGCOMM IMW ’01, 2001,
world, ACM SIGCOMM workshop on Network
pp. 153–167.
troubleshooting: research, theory and operations[15] Liston, R., Srinivasan, S., and Zegura, E.: Dipractice meet malfunctioning reality, NetT ’04,
versity in DNS performance measures, ACM SIGACM, 2004, pp. 283–288.
COMM IMW ’02, 2002, pp. 19–31.
[ 7 ] Cohen, E. and Kaplan, H.: Proactive caching of[16] Pappas, V., Fältström, P., Massey, D., andDNS records: addressing a performance bottleneck,
Zhang, L.: Distributed DNS troubleshooting, ACM
Computer Networks, Vol. 41, No. 6(2003), pp. 707
SIGCOMM NetT ’04, 2004, pp. 265–270.
– 726.
[17] Pappas, V., Xu, Z., Lu, S., Massey, D., Terzis,[ 8 ] Colitti, L., Gunderson, S., Kline, E., and Refice,A., and Zhang, L.: Impact of configuration errors
T.: Evaluating IPv6 adoption in the Internet,
on DNS robustness, ACM SIGCOMM ’04, 2004,
Passive and Active Measurement, Lecture Notes
pp. 319–330.
in Computer Science, Vol. 6032, Springer, 2010,[18] Plonka, D. and Barford, P.: Context-aware cluspp. 141–150.
tering of DNS query traﬃc, ACM SIGCOMM IMC[ 9 ] Consortium, I. S.: The ISC Domain Survey,’08, 2008, pp. 217–230.
http://www.isc.org/ds/.
[10] Danzig, P. B., Obraczka, K., and Kumar, A.: An[19] Vixie, P.: Extension Mechanisms for DNS
analysis of wide-area name server traﬃc: a study(EDNS0), RFC 2671 (Proposed Standard), August
1999.
of the Internet Domain Name System, ACM SIG[20] Wing, D. and Yourtchenko, A.: Happy Eyeballs:
COMM ’92, 1992, pp. 281–292.
[11] Deccio, C., Chen, C.-C., Mohapatra, P., SeSuccess with Dual-Stack Hosts, RFC 6555 (Prodayao, J., and Kant, K.: Quality of name resolution
posed Standard), April 2012.
in the Domain Name System, Network Protocols,[21] 浅井大史, 福田健介, 江崎浩: DNS 探索グラフの可2009. ICNP 2009. 17th IEEE International Con視化と解析, The Tenth Workshop on Internet Technology – WIT2011, June 2011.
ference on, oct. 2009, pp. 113 –122.
[12] DNSViz: A DNS visualization tool, http://dnsviz.net/.