自律分散協調システム論

自律分散協調システム論
第11回「DNS (Domain Name System)」
中村修
[email protected]
今日の概要
• DNS
– DNSとは？
– DNSに対する要求
– 名前空間の委譲
– キャッシュの利用
– サーバの分散
• DNSの応用
– ENUM
• 自律分散システムとセキュリティ
– dnssec
DNSとは？
• 名前解決機構: ホスト名とIPアドレスの対応を解決
– ホスト名
– IPアドレス
: 人間に分かりやすい計算機の識別子
: IPにおける通信ノードの識別子
ホスト名
www.sfc.keio.ac.jp
IPアドレス
133.27.4.127
• 世界中の計算機のIPアドレスと名前の対応を管理
する大規模分散データベースといわれる
• 自律分散協調して動作するものの代名詞だが…
身近な例：SFCのWebサーバを見る時
• ブラウザでは
http://www.sfc.keio.ac.jp/
と入力
• 実はホスト名⇔IPアドレス
の変換が行われている
www.sfc.keio.ac.jp
が見たいんだけど…
ユーザ
133.27.4.127のサーバに
アクセスしてください
WEBサーバ
133.27.4.127
ネームサーバ
DNSへの要求(1/3) エントリは？
• 世界中のホストは調べられるだけでも約２億５千万
• この数だけエントリを持たねばならない
DNSへの要求(2/3) サービスの提供は?
• サービスを提供する対象も多い！
– 世界中のホスト（2.5億）だけではない
– NATの裏側とか、本当はもっと多い
– 世界に向けて潤沢な回線ももちろん必要
ＤＢ
DNSへの要求(3/3) 更新頻度
• IPアドレスが変わるとデータベースを更新
– 配置換え・構成変更・引越し
Alpha館
133.27.1.0/24
host.sfc.keio.ac.jp
133.27.1.100
host.sfc.keio.ac.jp
133.27.2.100
Iota館
133.27.2.0/24
※実際のネットワーク構成とは関係ありません
• ひとつのホストが１年に一度移動するとしても・・・
２００,０００,０００
３６５ｘ８６４００
＝
６．３５[更新／秒］
という更新頻度になる
要求事項の整理
• DNSとは、
– 2億のエントリを持つ、
– 2億のホストから参照され、
– 頻繁に更新されるデータベース
であり、
• かつ、インターネットにとって必要不可欠なので、
絶対に止めてはいけない
解決策: 自律分散協調を導入
• 管理権限委譲による自律分散化
– 各サーバは自律動作
– 各サーバは上位（親）と下位（子）のみを知っている
• 他のサーバの変化は関知しない
• 祖父や孫は知らない
• 全体のつながりも当然知らない
• キャッシュによる効率化
• ルートDNSサーバの分散化
– 協調して動作する複数のルートDNSサーバを有効に選
択する
ドメイン名の構造
• 住所のように情報を階層化して、扱う
– 一単語では重複が発生する
– 名前空間を分割することで委譲を可能にする(後述)
下位
上位
www . sfc . keio . ac . jp
www
サ
ー
バ
湘
南
キ藤
ャ沢
ン
パ
ス
慶
應
義
塾
大
学
学
術
日
本
欧米の住所は、日本とは逆に細かい情報から先（左）に書く
日本風に言うと、
「日本の学術機関の慶應義塾大学の湘南藤沢キャンパスのwwwサーバ」
ドメインツリー
Root Domain
・
• 階層的な名前空間
– 例：www.sfc.keio.ac.jp
ccTLD
gTLD
uk …… com net
jp
SLD
ad … ac
TLD: Top Level Domain
gTLD: generic TLD
ccTLD: Country Code TLD
SLD: Second Level Domain
wide
co
keio … u-tokyo
sfc
cc
www.sfc.keio.ac.jp
or
cnn
管理権限の委譲
• 自分より下位（左）の管理権限を委譲する
– 委譲している情報を聞くと、委譲した先のサーバを教えてくれる
– 例：慶應義塾大学は、SFCの名前空間管理をSFCに委譲
慶應義塾のサーバ
sfc.keio.ac.jpを委譲
www.sfc.keio.ac.jp のアドレスは？
それは「ＳＦＣのサーバ」が知ってるよ
ＳＦＣのサーバ
• 上位は下位の情報に関して関知しない
– 例：SFCのwwwサーバのアドレスを変更しても
慶應義塾大学のサーバは関知しない
委譲と更新頻度
• ２億個のデータが含
まれる名前分割する
• ひとつのサーバが担
当する量を減らしてい
る
• これで更新頻度の問
題は解決できた
が・・・・
移譲された名前空間
Root Domain
・
ccTLD
iTLD
jp
uk
……
com
SLD
ad
wide
… ac
co
keio … u-tokyo
sfc
cc
www.sfc.keio.ac.jp
or
cnn
edu
名前解決の流れ : Rootへのアクセスの集中
www.sfc.keio.ac.jpを問い合わせ
左右の図を見ると、かならずRootを
通ることがわかる！
Rootのサーバ
jpのサーバを返答
www.sfc.keio.ac.jpを問い合わせ
Rootは２億のアクセスを捌く？
Jpのサーバ
ac.jpのサーバを返答
Root Domain
www.sfc.keio.ac.jpを問い合わせ
ac.jpのサーバ
・
問い合わせ側
ccTLD
keio.ac.jpのサーバを返答
iTLD
uk ……com edu
jp
www.sfc.keio.ac.jpを問い合わせ
keio.ac.jp
のサーバ
SL
adD … ac
sfc.keio.ac.jpのサーバを返答
www.sfc.keio.ac.jpを問い合わせ
sfc.keio.ac.jp
のサーバ
wide
co
keio …
u-tokyo
sfc
cc
www.sfc.keio.ac.jpのアドレスを返答
www.sfc.keio.ac.
jp
or
cnn
ＤＮＳとキャッシュ
• キャッシュ:
– 問い合わせに対して返答があった場合、その答えを一定期間保
持する
– 同じ名前に関しては問い合わせを出さない
• リゾルバサーバ(キャッシュサーバ)の利用
– クライアントからの要求を受け、問い合わせを出すサーバ
– キャッシュを多くのホストで共有し、効率化
• 効果
– Rootの近く(jpやcomなど)では再利用性が高い
– 問い合わせを Root に出すことはほとんど無くなる
リゾルバサーバの動作(1)
• DNSへの問い合わせの段階で、
キャッシュを保存しておく
root
ネームサーバ
jp
ネームサーバ
ac.jp
ネームサーバ
keio.ac.jp
ネームサーバ
sfc.keio.ac.jp
ネームサーバ
www.sfc.keio.ac.jpを問い合わせ
jpのネームサーバを返答
www.sfc.keio.ac.jpを
問い合わせ
www.sfc.keio.ac.jpを問い合わせ
ac.jpのネームサーバを返答
www.sfc.keio.ac.jpを問い合わせ
keio.ac.jpのネームサーバを返答
リゾルバ
サーバ
クライアント
www.sfc.keio.ac.jpを問い合わせ
sfc.keio.ac.jpのネームサーバを返答
www.sfc.keio.ac.jpを問い合わせ
www.sfc.keio.ac.jpのアドレスを返答
www.sfc.keio.ac.jpの
アドレスを返答
リゾルバサーバの動作(2)
• 一旦名前を引けば、
• 同じ名前に関しては、外に
問い合わせを出さずに返
答する
www.sfc.keio.ac.jpなら
知ってる！
root
ネームサーバ
www.sfc.keio.ac.jpを問い合わせ
jpのネームサーバを返答
jp
ネームサーバ
www.sfc.keio.ac.jpを
問い合わせ
www.sfc.keio.ac.jpを
問い合わせ
www.sfc.keio.ac.jpを問い合わせ
ac.jpのネームサーバを返答
ac.jp
ネームサーバ
www.sfc.keio.ac.jpを問い合わせ
リゾルバ
サーバ
クライアント
リゾルバ
サーバ
クライアント
keio.ac.jpのネームサーバを返答
keio.ac.jp
ネームサーバ
www.sfc.keio.ac.jpを問い合わせ
sfc.keio.ac.jpのネームサーバを返答
sfc.keio.ac.jp
ネームサーバ
www.sfc.keio.ac.jpを問い合わせ
www.sfc.keio.ac.jpのアドレスを返答
www.sfc.keio.ac.jpの
アドレスを返答
www.sfc.keio.ac.jpの
アドレスを返答
リゾルバサーバの動作(3)
• 名前解決の過程で問い合
わせたサーバは記録して
いるので、
root
ネームサーバ
mail.sfc.keio.ac.jpのことは知らない。
でも、sfc.keio.ac.jpをどのサーバが
管理してるかは知ってるぞ！
www.sfc.keio.ac.jpを問い合わせ
jpのネームサーバを返答
jp
ネームサーバ
• 違う名前を問い合わせでも、
必要最低限の相手にしか
問い合わせを出さない
www.sfc.keio.ac.jpを
問い合わせ
www.sfc.keio.ac.jpを問い合わせ
mail.sfc.keio.ac.jpを
問い合わせ
ac.jpのネームサーバを返答
ac.jp
ネームサーバ
www.sfc.keio.ac.jpを問い合わせ
リゾルバ
サーバ
mail.sfc.keio.ac.jp
を問い合わせ
クライアント
keio.ac.jpのネームサーバを返答
keio.ac.jp
ネームサーバ
www.sfc.keio.ac.jpを問い合わせ
sfc.keio.ac.jp
ネームサーバ
リゾルバ
サーバ
クライアント
sfc.keio.ac.jpのネームサーバを返答
sfc.keio.ac.jp
ネームサーバ
www.sfc.keio.ac.jpを問い合わせ
www.sfc.keio.ac.jpのアドレスを返答
www.sfc.keio.ac.jpの
アドレスを返答
mail.sfc.keio.ac.jp
のアドレスを返答
mail.sfc.keio.ac.jpの
アドレスを返答
キャッシュと有効期限(TTL)
• キャッシュに有効期限を設けて、その時間が経過
したらキャッシュを破棄する
• データを変更しても、キャッシュの有効期限の間は
古いデータを参照される可能性がある
• 効率と整合性はトレードオフ
• 有効期限の設定:根元は長く、末端は短く
変化が世界に早く伝播する
問い合わせを受ける量が増える
短い
変化が伝播するのが遅い
問い合わせを受ける量が減る
キャッシュ有効期限
長い
耐故障性
• インターネットのサービスはDNSに依存
– wwwを見るのにも(URL)
– メールを出すのにも(メールアドレス)
• 根元に近いところが落ちると？
– それ以下の名前が検索できなくなる
サーバの分散化
• ひとつのゾーンに関して、複数のサーバで管理
• 上位はそれらすべてに関して情報を持つ
• サーバ１が不調の場合でも・・・
– サーバ２かサーバ３に聞けば分かる
– １が使えなかった場合は２か３に聞く
www.sfc.keio.ac.jp のアドレスは？
慶應義塾のサーバ
それは「ＳＦＣのサーバ１」と
「ＳＦＣのサーバ２」と
「ＳＦＣのサーバ３」が知ってるよ
sfc.keio.ac.jpを委譲
ＳＦＣのサーバ１
ＳＦＣのサーバ２
ＳＦＣのサーバ３
ルートネームサーバの分散
• ルートネームサーバ
– TLDの情報を管理するサーバ
– 理論上、すべての問い合わせは最初にルートネームサーバに来
る
– 名前解決を行うためには、ローカルネームサーバからルートへ
の接続性が必要
• ルートサーバの分散
– 地理的、ネットワーク的に分散している
– どれか１つが落ちたとしても他に回る
– 2000年問題などの致命的な問題（の可能性）があった場合も対
処可能
ルートサーバの発見: ヒントファイルの存在
;
This file holds the information on root name servers needed to
;
initialize cache of Internet domain name servers
;
(e.g. reference this file in the "cache . <file>"
;
configuration file of BIND domain name servers).
;
;
This file is made available by InterNIC
;
under anonymous FTP as
;
file
/domain/named.root
;
on server
FTP.INTERNIC.NET
;
;
last update:
Nov 5, 2002
;
related version of root zone:
2002110501
;
;
; formerly NS.INTERNIC.NET
;
.
3600000 IN NS
A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.
3600000
A
198.41.0.4
;
; formerly NS1.ISI.EDU
;
.
3600000
NS
B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
3600000
A
128.9.0.107
;
; formerly C.PSI.NET
;
.
3600000
NS
C.ROOT-SERVERS.NET.
;
; housed in Japan, operated by WIDE
;
.
3600000
NS
M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.
3600000
A
202.12.27.33
; End of File
リゾルバサーバは同じ
ヒントファイルを使用
Root
・
ccTLD
iTLD
uk ……com edu
jp
SL
adD … ac
wide
co
keio …
u-tokyo
sfc
cc
www.sfc.keio.ac.
jp
or
cnn
DNS Root Server
I-NORDUnet: Stockholm, other 28sites
E-NASA: Mt View
F-ISC: Palo Alto, other 39sites
J-VeriSign: Mt View
M-WIDE: Tokyo, Seoul,
Paris, SanFrancisco
B-ISI: Marina Del Rey
L-EPB: Marina Del Rey
K-Ripe: London, other 17sites
A-Verisign: Dulles
C-Cogent: Herndon, NY, LosAngeles, Chicago
D-UMD: College Park
G-DNIC Network: Columbus
H-ARL: Aberdeen
ルートネームサーバの運用基準
RFC2780(Root Name Server Operational Requirements)
1. ネームサーバはBINDを使用する
2. UDPチェックサムを使う
3. 専用ホストであること（他のサービスをしていない）
4. 相互に時刻同期を行う
5. もっとも“良い”インターフェースのアドレスを広告する
6. 安全な場所（出入りが厳重に管理されている場所）に配置する
7. 安全なネットワーク上に配置する
8. 平均CPU時間は最大値の３分の１以下でなければいけない
9. 障害報告のメールに24時間以内に応答する
10.問い合わせが障害を引き起こすものでない限り、あらゆるホストからの問い
合わせを受け付ける
11.AXFRに応答してはいけない
12.再起的な問い合わせは行わない
13.アナウンスは変更を行う１２時間前に行う
14.将来的に、ルートゾーンの署名を行う
15.Etc…..
ルートネームサーバの選択
• ローカルネームサーバは、１３個のサーバを入れ替わり
使う
• 応答にかかった時間が短いサーバを優先的に使い、結
果的に効率の良いサーバを頻繁に使うことになる
• 選択確率（BINDでの実装)
– 使用頻度をy、
平均応答時間をxとすると、
平均7.7%
10
Y = log(0.98 *
)
7+3x
– 測定した結果、日本の場合約６割強の問い合わせが1つの
サーバに寄せられる
DNSサーバのAnycast化への契機
• DNSサーバへのDDoS攻撃
– 2002年10月22日
– ICMPリクエストの大量送出による
– ISCのDNSサーバでは一時的に80Mbpsまでトラフィッ
クが増加
• 13のルートサーバのうち動作を続けたのは4つ
• この攻撃によるDNS機能への影響はなかった
– 長時間の攻撃が続いたとすると状況は分からなかった
Anycast
• IPv6から提供されているアドレス割当手法
– Anycastを利用しない場合
• IPアドレス＝一意のホストという関係
– Anycastを利用する場合
• IPアドレス＝一意のサービスという関係
203.178.138.99
203.178.138.99
www.soi.wide.ad.jp
www.soi.wide.ad.jp(JP)
www.soi.wide.ad.jp(CA)
www.soi.wide.ad.jp(US)
同じサービスを提供しているホスト
BGP Anycast
• RFC3258に定義
– 独立した専用の AS および IP ア
ドレスブロックを複数の拠点から
BGP 的に広報
– 同一の IP アドレスを多拠点から
サービスすることを可能とする
AS-F
AS-A
AS-B
• BGPの経路選択によって「最も
近い」サーバを選択
AS-C
AS-D
AS-E
AS-F
• ただし必ずしも最も近いとは限
らない
Anycast Solution
San Jose
London
192.168.100.0/24
192.168.101.0/24
192.168.102.0/24
192.168.100.0/24
192.168.101.0/24
192.168.102.0/24
ISP
San Jose
Hong Kong
192.168.100.0/24
192.168.101.0/24
192.168.102.0/24
Hong Kong
London
Anycast化のポイント
• メリット
– DNSサーバ複製によりサーバ最大数に縛りがなくなる
– 地理的な問題が解決される
– 可用性の向上
– DoS 対策
– 独立することによるポータビリティの確保など
• デメリット
– ネットワーク管理の煩雑化
– 監視の問題など
Reference: http://jprs.jp/tech/jp-dns-info/2003-07-10-jp-dns-operation.html
2000年問題時の推移
DNS Root Server
I-NORDUnet: Stockholm, other 28sites
E-NASA: Mt View
F-ISC: Palo Alto, other 39sites
J-VeriSign: Mt View
M-WIDE: Tokyo, Seoul,
Paris, SanFrancisco
B-ISI: Marina Del Rey
L-EPB: Marina Del Rey
K-Ripe: London, other 17sites
A-Verisign: Dulles
C-Cogent: Herndon, NY, LosAngeles, Chicago
D-UMD: College Park
G-DNIC Network: Columbus
H-ARL: Aberdeen
ROOTZONEの変更権限は誰がやるか
• DNS／ドメインツリーは開かれたシステム
– いつ何時、誰でも参加することが可能
– 自律分散的なシステムによる柔軟な拡張性が可能にし
ている
• 責任は、結局、ICANNとアメリカ政府が管理
– gTLD(Generic Top Level Domain)
• .com .net .org 等
• Verisignが運用
– ccTLD(Country Code Top Level Domain)
• .jp .to .uk 等
• 地域ドメインレジストリが運用
– JPRS(JaPan Registry Service)
ドメインの取得
• 取得申請を出せば誰でも使えます
– ccTLD
• .jp
• 他の国もそこの policy が許すなら
– .to / .ac / .tv
– gTLD
• .com / .net / .org
DNSの応用: ENUMとは
• 電話番号からサービスを検索
–
–
–
–
–
メールアドレス
Webページのアドレス
SIPアドレス
H.323
インターネットFAX 等
• 利用者は状況に応じてサービスを選択
• 標準化
IETFとITU-Tが共同で標準化を実施
ENUMの概要
(2)利用可能な
サービスを返答
電話網
GW
電話網
電話
GW
(3)サービス
の選択
電話
SIP
GW
Internet
http
server
(1)問い合わせ
http
server
ユーザ端末
ENUM
既存の機能
DNS
(4)着信
VoIP端末
ユーザ端末
FAX
server
FAX
ENUMのドメイン名
• 電話番号
– 0AB~J番号を使用
– cf.)03 – 1234 – 5678
東京
• ENUMで用いられる番号
– E.164番号を使用
– +国番号-0AB~J番号
– cf.)+81 – 3 – 1234 – 5678
• ENUMで用いられるドメイン名
– DNSの逆引きのようドメイン名になる
– cf.)8.7.6.5.4.3.2.1.3.1.8.e164.arpa
日本
ENUMドメイン
E.164番号からドメイン名の変換
– E.164番号
• +81-3-1234-5678
– 先頭の＋をのぞいて数字以外の文字を削除
• +81312345678
– 先頭の＋を削除
• 81312345678
– 数字の間に「.」をいれる
• 8.1.3.1.2.3.4.5.6.7.8
– 順番を逆にする
• 8.7.6.5.4.3.2.1.3.1.8
– .e１６４．aｒｐａを付加
• 8.7.6.5.4.3.2.1.3.1.8.e164.arpa
ENUMの現状
• 技術的には実現しつつある
– ENUMトライアルジャパンETJPの実証実験
• 最小構成ENUM DNSの構築は完了
• 実現へ向けての課題
– プライバシー
– DNSの肥大化と複雑化
ENUMの課題
• プライバシーの問題
– DNSは公開DB
• だれでもアクセスできる
– SPAM業者などによる総当たり
• 網羅的に検索可能
– 電話番号、メールアドレス、SIPアドレスなど
• DNSの肥大化・複雑化
– 管理すべきエントリの肥大化・複雑化
• 日本の電話総数1億4千万台(固定/携帯/PHS含む)#1
– 管理の難しさとパフォーマンス
• 30分に１度は更新が必要(携帯電話番号のDBは約30分)
• 毎秒5万件の問い合わせ
分散システムとセキュリティ：DNSと詐称
• 詐称
– 正当な通信相手に代わって通信を行なう
– 例：webサーバの通信を詐称して、パスワードやクレ
ジットカード番号などを不正に入手
• DNSにも詐称などの危険性はある
– UDPによる通信(TCPよりやられやすい)
DNS詐称の例
• クライアントとサーバ間の通信
クライアント
１．問い合わせ
ネームサーバ
２．問い合わせより先に
答えを返す
攻撃者（詐称者）
攻撃できるポイント
• リゾルバサーバとクライアントの間
– ピンポイントでクライアントを狙える
• ネームサーバとリゾルバサーバ間
– キャッシュされるので影響範囲が広い
ネームサーバ
リゾルバ
サーバ
クライアント
詐称による脅威(DNS)
• 名前を詐称する＝あらゆる通信を不正に入手
できる
– インターネット上のほとんどの通信は、まずＤＮＳで名
前を検索するところから始まる
– 詐称によって正当な相手とは違うIPアドレスを通信相
手にしてしまえる
脅威の例
• Amazon.co.jp を詐称してログインアカウント・クレ
ジットカード番号入手
• sfc.keio.ac.jp を詐称して、藤沢の学生に宛てた
メールを入手
• Asahi.comを詐称して嘘のニュースを流す
自律分散協調システムとセキュリティ
• データの正当性の保証
– この情報は本当に正しいのか？
– 何をもって正しいと証明するのか
• 分散しているシステムでは難しい
初対面の相手をどうやって信用するか？
• 現実社会を自律分散協調システムとして
– 相手は「私は＊＊＊のＸＸＸという者です」と言っている
– 通常は身分証明書を使う
• 学生証、免許証
• 証明書はどこが出すのか？
証明書
• ある内容が正しいことを示す
• 証明を行なう権威というものがある
– 日本の身分証明書なら日本政府
• 内容を変えるたびに更新が必要
– 学生証における進級・進学
– 自動車免許証のオートマ限定解除
公開鍵暗号方式
• それぞれ１回ずつ行なうと元に戻る不可逆演算を
する
– xφ= y, yφ’ = x (掛け算じゃないよ！)
– 剰余などを使う
– それぞれの逆演算は難しい
• xが元の情報、y が暗号化された情報
• Φおよびφ’がそれぞれ鍵
公開鍵暗号方式の使い方(1)
• 不特定多数からの暗号化した受け取り
– 例えばメールなど
– φを公開鍵、φ’を秘密鍵とする
– φは一般に公開して、他の人はそれを使って暗号化(xφ
= y)
– φ’は自分だけが持っておく
– 自分しか暗号化した内容を戻せない(yφ’ = x)
公開鍵暗号の使い方(2)
• 自分が書いたことの証明（署名）
– 同じくφを公開鍵、φ’を秘密鍵
– 書いた内容をφ’で暗号化(xφ’=y)
– 平文と暗号化した内容を一緒に送る
• つまり、x と y を送る
• この場合、y のことを「（電子）署名」という
– 他の人は公開鍵φでその内容を検証できる
• 署名を複合化して（yφ＝x）、一緒に送られてきた x と等しい
か検証
鶏と卵
• 公開鍵が正しいことをどうやって証明する？
– 公開鍵で・・・・・
• 最終的には、信用できる手段で公開鍵を手に入れ
ることが必要
– ネットワーク以外の方法
• 書籍、CD-ROM、新聞、人から聞く、などなど
• IEには最初からいくつかの公開鍵（証明書）が入っている
DNSのセキュリティ(dnssec)
• DNSのデータを署名し、クライアントが検証する
– 誰が署名するか
• 例によって、たったひとつの秘密鍵で全部を署名することは
不可能
自律分散的な署名
• それぞれのゾーンが公開鍵と秘密鍵（鍵対）を持つ
• それぞれの公開鍵はゾーンが配布
– DNSのレコードとして取得可能
• その公開鍵を他の秘密鍵で署名
– DNSでは親と子しかわからないので、自分のゾーンの公開鍵は
親に署名してもらう
• 最終的にクライアントはルートの公開鍵を持っていれば検
証可能
検証の流れ
Rootの証明書でjpの証明書を検証
Jp
jpの証明書でac.jpの証明書を検証
ac.jp
ac.jpの証明書でkeio.ac.jpの証明書を検証
検証側
keio.ac.jp
keio.ac.jpの証明書でsfc.keio.ac.jpの証明書を検証
sfc.keio.ac.jp
最後に、得たデータをsfc.keio.ac.jpの証明書で検証
DNSSECのデメリット
• データが膨大になる
– 鍵と署名のデータ
– もともといっぱいいっぱいのところに入れるのは大変(Root など)
• 手順が面倒
– 更新のたびに署名が必要
– 鍵を変更するたびに親に再署名してもらう
• jp や com などの負担は高い
• データの鍵と鍵を署名する鍵を別にすることである程度対処可能
• 親との結びつきが強くなって、自律性が薄くなる
DNSSECの現状
• 実はあまり使われていない
– Root/TLDではどこも使っていません
– 各TLDの Registry が試験的に行なっている程度
• dnssec.jp 等
• ここを基点として公開鍵を発行
• 原因は？
– デメリットが大きい
– DNS詐称による危険性があまり知られていない
– そもそもメカニズムに問題があるのでは？
• 自律分散協調的な信用メカニズムが世界中で動いている例はまだ
ない
Appendix
Anycast DNS
ルートネームサーバの選択
• ローカルネームサーバは、１３個のサーバを入れ替わり
使う
• 応答にかかった時間が短いサーバを優先的に使い、結
果的に効率の良いサーバを頻繁に使うことになる
• 選択確率（BINDでの実装)
– 使用頻度をy、
平均応答時間をxとすると、
平均7.7%
10
Y = log(0.98 *
)
7+3x
– 測定した結果、日本の場合約６割強の問い合わせが1つの
サーバに寄せられる
DNSサーバのAnycast化への契機
• DNSサーバへのDDoS攻撃
– 2002年10月22日
– ICMPリクエストの大量送出による
– ISCのDNSサーバでは一時的に80Mbpsまでトラフィッ
クが増加
• 13のルートサーバのうち動作を続けたのは4つ
• この攻撃によるDNS機能への影響はなかった
– 長時間の攻撃が続いたとすると状況は分からなかった
Anycast
• IPv6から提供されているアドレス割当手法
– Anycastを利用しない場合
• IPアドレス＝一意のホストという関係
– Anycastを利用する場合
• IPアドレス＝一意のサービスという関係
203.178.138.99
203.178.138.99
www.soi.wide.ad.jp
www.soi.wide.ad.jp(JP)
www.soi.wide.ad.jp(CA)
www.soi.wide.ad.jp(US)
同じサービスを提供しているホスト
BGP Anycast
• RFC3258に定義
– 独立した専用の AS および IP ア
ドレスブロックを複数の拠点から
BGP 的に広報
– 同一の IP アドレスを多拠点から
サービスすることを可能とする
AS-F
AS-A
AS-B
• BGPの経路選択によって「最も
近い」サーバを選択
AS-C
AS-D
AS-E
AS-F
• ただし必ずしも最も近いとは限
らない
Anycast Solution
San Jose
London
192.168.100.0/24
192.168.101.0/24
192.168.102.0/24
192.168.100.0/24
192.168.101.0/24
192.168.102.0/24
ISP
San Jose
Hong Kong
192.168.100.0/24
192.168.101.0/24
192.168.102.0/24
Hong Kong
London
Anycast化のポイント
• メリット
– DNSサーバ複製によりサーバ最大数に縛りがなくなる
– 地理的な問題が解決される
– 可用性の向上
– DoS 対策
– 独立することによるポータビリティの確保など
• デメリット
– ネットワーク管理の煩雑化
– 監視の問題など
Reference: http://jprs.jp/tech/jp-dns-info/2003-07-10-jp-dns-operation.html

Download Report