Contenu connexe
Similaire à 20111029 part2-dnsトリビア(出張版)-事後資料 (20)
20111029 part2-dnsトリビア(出張版)-事後資料
- 3. 「DNSトリビア」とは
• 最初のツイートは2011年06⽉20⽇
– twilogさんに感謝
• 現在までに20項⽬をツイート
• 50項⽬ぐらいまではツイートしたい
• 100ツイートできたら書籍にでも(無理w)
• 今⽇はそのうちのいくつかのご紹介と、番外編
として「なぜ浸透と⾔うとえらい先⽣に怒られ
るのか」についてお話します
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 3
- 5. その2:CNAMEは
別名ではなく正式名
• CNAMEはある別名の正式名を指定するための
RRである。別名に対する正式名は常に1つであ
り、2つ以上存在することはない。そのため、1
つの名前に対し、CNAMEを同時に2つ以上指定
することはできない。
• 指定されるのは別名ではなく「正式名」
– CNAME = Canonical Name
• 「正式」というぐらいで、常に1つに定まる
– ある名前に対するCNAMEが同時に2つ以上指定され
ることは、定義上あり得ない
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 5
- 6. その3:プライミング
• 最近のキャッシュDNSサーバーの実装の多くは、
最初にルートサーバーに“.”のNSを問い合わせ、
以降の検索にはその結果を使う。これを「プラ
イミング(priming)」と呼ぶ。これらの
キャッシュDNSサーバーでは、ルートヒントは
最初しか使われない。
• このことは意外に知られていない
• プライミングについて解説した⽇本語の書籍や
ドキュメントはほとんど⾒たことがない
• 「実践DNS」には書きませんでした…
– 校了後に「あぁ、書いたほうがよかった」と思った
のが、このツイートのきっかけ
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 6
- 7. その5:最初のTLD
• 1984年に最初のTLDとして移⾏⽤のARPA、組
織⽤のGOV/EDU/COM/MIL/ORG、国⽤のISO
3166の2⽂字、及び「複合組織」⽤が計画され
た(RFC 920)。条件付きながら「⼤きな複合
組織はTLDとなりうる」旨が既に含まれていた。
• 1984年の時点で現在のccTLDに相当するものが
既に含まれていた
• 「⼤きな複合組織」として、.CSNETという例が
書かれていた
– ただし、各例⽰はあくまでも架空のものである(実
在のものではない)と書かれている
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 7
- 8. その6:ルートサーバーの歴史
• A〜MまでのルートサーバーのうちIまでの
9つは、1990年代初頭には既に存在して
いた。その後、1995年にホスト名が
X.root-servers.netに統⼀、さらに1997
年にIANAによりJ〜Mまでの4つが追加さ
れ、現在の13体制になった。
• 名前の統⼀:応答を圧縮するため
• 13:「512の壁」を踏まえた台数
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 8
- 9. その7:⽇本の歴史
(ネームサーバー3系列)
• かつて⽇本のネームサーバーにはA、B、Cの3系列が存
在していた。系列Aで海外と接続可能な、系列Bで国内
すべてのJPドメイン名をそれぞれ管理し、系列Cで海外
に接続可能な国内組織向けに、通常のDNSツリーと系列
Bを参照(マージ)する形で運⽤されていた。
• (事後資料で修正)系列Aは国内からは参照されない
• (事後資料で修正)系列Cはjp以外は通常通りで、jpの
下だけが系列Bに差し替わる
• 国全体で今で⾔う「Split DNS」を運⽤
• 海外に到達できないネットワークの存在
– AUPによるフィルタリング
• ⽇本―⽶国―⽇本、という通信経路を避けたかった、と
いう事情もあった
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 9
- 10. その9: .ukはISO 3166ではない
• 英国のccTLDは.ukであるが、これは
ccTLDの定義であるISO 3166の2⽂字
コードからは外れている。ISO 3166で定
義されている.gbも存在しているが、
IANAにより予約されている。
• 英国はccTLDがISO 3166であるというし
くみが運⽤される前から.ukを使っていた
• .uk→.gbへの移⾏が計画されていたが、
実施されなかった
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 10
- 11. その10:AS112で実験された
IP Anycast
• DNSサービスにおけるIP Anycastの利⽤は
AS112プロジェクトにおいて実験され、その嚆
⽮(こうし)となった。それにより得られた運
⽤経験はルートサーバーをはじめとする、その
後の広域DNSサービスへのIP Anycast導⼊に役
⽴てられた。
• AS112:プライベートアドレスの逆引きゾーン
• トラブっても致命傷にならない(はず)
• それで困った⼈がいても「そもそもそんな問い
合わせをインターネットに出すんじゃない」と
⾔うことができた
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 11
- 12. その11:逆順だった.uk
• 1980年代、英国は既に独⾃の名前解決サービス
(NRS)を使っており、⾃国はUKでかつ
user@UK.AC.SITEのように、表記がDNSとは逆であっ
た。DNSへの移⾏時に.gbへの切り替えが併せて計画さ
れたが実施されず、.ukが継続使⽤された。
• 英国のゲートウェイサーバーで外国(から|へ)電⼦
メールアドレスを書き換え、相互変換していた
– (事後資料で追加)⽇本から英国に出すのは通常どおり、
user@ukc.ac.ukという記述で基本的にはOKだった
– (事後資料で追加)英国から⽇本に出す場合、使うゲートウェ
イの仕様により指定するアドレスが異なる場合があった
• user%u-tokyo.ac.jp@uk.ac.ucl.cs.nss
• user%jp.ac.u-tokyo@uk.ac.earn-relay
– 詳細は調査中、年代や各サイトの設定変更により状況は変化
• DNSプリフェッチのことを考えると、実は逆順のほうが
よかったのかもしれない
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 12
- 14. その14:PTRレコードは
複数記述可能
• 1つのIPアドレスに対し複数個のPTRレコードを
記述することは、DNSの規格に違反していない
(RFC 2181)。違反であるという記述をしば
しば⾒かけるが、誤りである。
• ただし、複数記述した場合にgethostbyaddr()
がどのような動作をするのかは実装により異
なっている
• FreeBSDとLinux(glibc)では動作が違う
– FreeBSD: 全部返す、どれが最初かは毎回変わる
– Linux(glibc): ⼀つだけ返す、返すものは毎回変わる
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 14
- 15. その15:国際化ドメイン名(IDN)
の接頭辞は株の出来⾼で決まった
• 国際化ドメイン名の接頭辞「XN」はRFC 2777
のアルゴリズムに従い、選定⽇(2003年2⽉11
⽇)のNYSEとNASDAQの6銘柄ずつ(計12銘
柄)の出来⾼をベースとした、所定の演算によ
り決定された。
• 選定の公正さを技術的に確認可能な⼿法
– Publicly Verifiable Nomcom Random Selection
(RFC 2777)
• スクワッティングやインサイダー取引を防⽌
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 15
- 16. その17:BIND 10はBIND 9と
根本的に構造が違う
• 現在開発中のBIND 10ではネームサーバーのプ
ロセス名はnamedという名前ではなく、デフォ
ルトの設定ファイル名はnamed.confという名
前ではない。
• 権威DNSサーバーとキャッシュDNSサーバーは、
b10-authとb10-recurse
• 名前の通り、権威DNSサーバーとキャッシュ
DNSサーバーは完全に分離されている
• 他に、b10-xfrout、b10-msgq、b10-cfgmgr、
b10-auth、b10-xfrin、b10-zonemgr、b10-
stats、b10-cmdctlなどがある
– qmailやPostfixの構造をイメージするとわかりやすい
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 16
- 17. その18/19:実装依存シリーズ
• CNAMEの連鎖(CNAMEの先がまたCNAME)は
たどられるべきであるとRFC 1034には記述さ
れている。ただし、CNAMEの連鎖を何段まで許
すのかは決められておらず、実装依存である。
– 8.8.8.8は連鎖が数⼗段あっても名前を引けるらしい
• 名前解決において、あるドメイン名の権威DNS
サーバーのうちのどれが選ばれるかは決められ
ておらず、実装依存である。現在の実装では何
らかの形で「ネットワーク的に近い」サーバー
を優先的に選択するものが多い。
– 例えばBIND 9ではバージョンによって異なっている
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 17
- 20. 私はえらい先⽣ではないですが…
• DNSデータについて「浸透」や「伝播」という
⾔葉を使うことには、私も違和感を持っている
• 権威DNSサーバーからキャッシュDNSサーバー
へのDNSデータの伝わり⽅は「浸透」や「伝
播」という形式ではない
• つまり、少なくともそれについて「浸透」や
「伝播」を使うのは、技術的におかしいと思う
• ただし、更新時にプライマリサーバーからセカ
ンダリサーバー群にデータが伝わることは「伝
播」で正しい
– DNS NOTIFYのRFC(RFC 1996)にも
「propagation」(伝播)という⾔葉が使われている
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 20
- 21. (ご注意)
• 以降のページは、発表会場で当⽇いただ
いたご質問やコメント、 twitter上で「え
らい先⽣」をはじめとする多くの⽅々か
らいただいたご意⾒やコメントなどを参
考にしながら、発表時に使⽤したものか
ら内容を⼤幅に加筆訂正してあります。
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 21
- 22. 経路制御(BGP)では
「伝播」「浸透」で正しい
• データを更新すると、その情報をユーザーが参照しない
場合でも、情報が系全体に伝播する
• 更新元に直接接続しているピアから情報が系全体に徐々
に⾏き渡り、浸透していく
模式図を使って説明します
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 22
- 29. 1)最初の状態
• 真ん中の□は変更対象の情報を管理する権威DNS
サーバー、その他の○はキャッシュDNSサーバー
を表すものとする
• 最初の状態で、すべてのキャッシュDNSサー
バーが変更対象の情報を持っているわけではない
ことに注⽬(緑と⽩の○がある)
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 29
- 30. 2)情報を変更
• 1)から2)の間に起こったこと
– 権威DNSサーバーでDNS情報を変更(緑→⾚)
• 例えば、www.example.jpのIPアドレスを
192.0.2.1から192.0.2.10に変更
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 30
- 31. 3)それからしばらく後
• 2)から3)の間に起こったこと
– 3)-Aのサーバーを使っているユーザーが、変更後の
DNS情報を検索(⽩→⾚)
– 3)-Bのサーバーの変更前のDNS情報が消滅した後、
そのサーバーを使っているユーザーが変更後のDNS
情報を検索(緑→⾚)
3)-A
3)-B
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 31
- 32. 4)さらにしばらく後
• 3)から4)の間に起こったこと
– 4)-Aのサーバーの変更前のDNS情報が消滅
(緑→⽩)
– 4)-Bのサーバーを使っているユーザーが、変
更後のDNS情報を検索(⽩→⾚)
4)-B
4)-A
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 32
- 33. 5)さらにしばらく後
• 4)から5)の間に起こったこと
– 5)-Aのサーバーの変更前のDNS情報が消滅し
た後、そのサーバーを使っているユーザーが
変更後のDNS情報を検索(緑→⾚)
5)-A
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 33
- 34. 6)さらにしばらく後
• 5)から6)の間に起こったこと
– 6)-Aサーバーの変更前のDNS情報が消滅(緑→⽩)
– これによりすべてのキャッシュDNSサーバーから変更前の情報が
消滅し、変更が完了
• 重要なポイント: 全部の○が⾚くならなくても、緑の○が
すべて消滅した時点で完了
6)-A
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 34
- 35. とりあえず、ここまでのまとめ
• DNSデータは経路制御(BGP)などと異なり、⽔が染み
とおる(=浸透する)ように、近いところから順にじわ
じわと⾏き渡っていくわけではない
• かつ、BGPにおける経路情報などとは異なり、全ての
キャッシュDNSサーバーにDNSデータが⾏き渡る(=伝
播する)わけでもない
• つまり、権威DNSサーバーからキャッシュDNSサーバー
へのDNSデータの伝わり⽅について「浸透」や「伝播」
という⽤語を使うことは、技術的に正しくない
• ただし、ゾーン転送によるプライマリサーバーからセカ
ンダリサーバーへの伝播については、浸透と⾔っても問
題ない
しかし、このことはいわゆる「浸透問題」に
おける、問題の本質ではない!
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 35
- 36. 続きはInternet Week 2011の
ランチセミナーL1にて
• 2011年11⽉30⽇ 11:45〜13:00
– DNS浸透の都市伝説を斬る
〜ランチのおともにDNS〜
• 多くの⽅々のご来場をお待ちしております
• 当⽇はランチセミナーに引き続き、DNS
DAY、dnsops.jp BOFも併せて開催され、
「午後は○○DNS漬け(古い)」となって
おります
• 併せてお楽しみいただければ幸いです
乞うご期待!
Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 36