20111029 part2-dnsトリビア(出張版)-事後資料

3,172 views
3,086 views

Published on

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,172
On SlideShare
0
From Embeds
0
Number of Embeds
57
Actions
Shares
0
Downloads
51
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

20111029 part2-dnsトリビア(出張版)-事後資料

  1. 1. DNSトリビア(出張版)+ IW2011ランチセミナーのネタをチラ⾒せ DNS周辺技術勉強会 #dnstudy 02 2011年10⽉29⽇ 森下 泰宏 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 1
  2. 2. 「DNSトリビア」とは• 私がtwitterで勝⼿にやっている企画• DNSについて意外に知られていなさそう なことや、知っていると得する(かも知 れない?)ことを不定期にツイート• 気分転換したい時の頭の体操と⾃⼰満⾜ – 140⽂字以内にまとめる – 最初は⼤抵はみ出している Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 2
  3. 3. 「DNSトリビア」とは• 最初のツイートは2011年06⽉20⽇ – twilogさんに感謝• 現在までに20項⽬をツイート• 50項⽬ぐらいまではツイートしたい• 100ツイートできたら書籍にでも(無理w)• 今⽇はそのうちのいくつかのご紹介と、番外編 として「なぜ浸透と⾔うとえらい先⽣に怒られ るのか」についてお話します Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 3
  4. 4. その1:RRのTTL値は 「キャッシュしてもよい時間」• RRのTTL値は「キャッシュしなければな らない時間」ではなく、「キャッシュし てもよい時間」を表している。• RFC 1034 / 1035的にはキャッシュは必 須ではない(should、もちろん実運⽤で はキャッシュすべき)• TTL値を超えてキャッシュを保持してはな らない(これが重要) Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 4
  5. 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. 6. その3:プライミング• 最近のキャッシュDNSサーバーの実装の多くは、 最初にルートサーバーに“.”のNSを問い合わせ、 以降の検索にはその結果を使う。これを「プラ イミング(priming)」と呼ぶ。これらの キャッシュDNSサーバーでは、ルートヒントは 最初しか使われない。• このことは意外に知られていない• プライミングについて解説した⽇本語の書籍や ドキュメントはほとんど⾒たことがない• 「実践DNS」には書きませんでした… – 校了後に「あぁ、書いたほうがよかった」と思った のが、このツイートのきっかけ Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 6
  7. 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. 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. 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. 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. 11. その10:AS112で実験された IP Anycast• DNSサービスにおけるIP Anycastの利⽤は AS112プロジェクトにおいて実験され、その嚆 ⽮(こうし)となった。それにより得られた運 ⽤経験はルートサーバーをはじめとする、その 後の広域DNSサービスへのIP Anycast導⼊に役 ⽴てられた。• AS112:プライベートアドレスの逆引きゾーン• トラブっても致命傷にならない(はず)• それで困った⼈がいても「そもそもそんな問い 合わせをインターネットに出すんじゃない」と ⾔うことができた Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 11
  12. 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
  13. 13. その13:DNSSECの署名は 有効期限ではなく「有効期間」• DNSSECの署名(RRSIGレコード)には、開始時 刻と満了時刻の双⽅が存在する。そのため厳密に は「有効期限」ではなく「有効期間(validity period)」と表現される。• 当時「クレジットカードとは違う」とツイートし たところ、@tss_0101 さんから「ダイナースの クレジットカードには開始も書かれている、とい うご指摘をいただきました。感謝いたします Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 13
  14. 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. その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. 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. 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
  18. 18. 番外編: なぜ浸透と⾔うとえらい先⽣に怒られるのか Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 18
  19. 19. 「浸透いうな!」• twitterで「DNSが浸透しない」とか 「DNSの浸透待ち」とツイートすると 、 もれなくえらい先⽣に怒られます• その理由は何か? Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 19
  20. 20. 私はえらい先⽣ではないですが…• DNSデータについて「浸透」や「伝播」という ⾔葉を使うことには、私も違和感を持っている• 権威DNSサーバーからキャッシュDNSサーバー へのDNSデータの伝わり⽅は「浸透」や「伝 播」という形式ではない• つまり、少なくともそれについて「浸透」や 「伝播」を使うのは、技術的におかしいと思う• ただし、更新時にプライマリサーバーからセカ ンダリサーバー群にデータが伝わることは「伝 播」で正しい – DNS NOTIFYのRFC(RFC 1996)にも 「propagation」(伝播)という⾔葉が使われている Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 20
  21. 21. (ご注意)• 以降のページは、発表会場で当⽇いただ いたご質問やコメント、 twitter上で「え らい先⽣」をはじめとする多くの⽅々か らいただいたご意⾒やコメントなどを参 考にしながら、発表時に使⽤したものか ら内容を⼤幅に加筆訂正してあります。 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 21
  22. 22. 経路制御(BGP)では 「伝播」「浸透」で正しい• データを更新すると、その情報をユーザーが参照しない 場合でも、情報が系全体に伝播する• 更新元に直接接続しているピアから情報が系全体に徐々 に⾏き渡り、浸透していく 模式図を使って説明します Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 22
  23. 23. 1)最初の状態• すべてのASが古い経路情報を保持 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 23
  24. 24. 2)経路情報を変更• 真ん中のASで経路情報を変更 – 例えば、192.0.2.0/24という経路情報を追加 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 24
  25. 25. 3)経路情報が伝播• 直接BGP接続しているピアに経路情報が 伝播 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 25
  26. 26. 4)伝播の拡⼤• それぞれの隣のピアに経路情報が伝播 – 経路情報が徐々に浸透 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 26
  27. 27. 5)伝播(浸透)の完了• すべてのASに経路情報が伝播 Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 27
  28. 28. キャッシュDNSサーバでは 古いデータが「消滅」していく• その情報をユーザーが参照しない限り、個々の キャッシュDNSサーバーにはロードされない• 接続の形態はデータの伝わり⽅には関係しない 模式図を使って説明します Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 28
  29. 29. 1)最初の状態• 真ん中の□は変更対象の情報を管理する権威DNS サーバー、その他の○はキャッシュDNSサーバー を表すものとする• 最初の状態で、すべてのキャッシュDNSサー バーが変更対象の情報を持っているわけではない ことに注⽬(緑と⽩の○がある) Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 29
  30. 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. 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. 32. 4)さらにしばらく後• 3)から4)の間に起こったこと – 4)-Aのサーバーの変更前のDNS情報が消滅 (緑→⽩) – 4)-Bのサーバーを使っているユーザーが、変 更後のDNS情報を検索(⽩→⾚) 4)-B4)-A Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 32
  33. 33. 5)さらにしばらく後• 4)から5)の間に起こったこと – 5)-Aのサーバーの変更前のDNS情報が消滅し た後、そのサーバーを使っているユーザーが 変更後のDNS情報を検索(緑→⾚) 5)-A Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 33
  34. 34. 6)さらにしばらく後• 5)から6)の間に起こったこと – 6)-Aサーバーの変更前のDNS情報が消滅(緑→⽩) – これによりすべてのキャッシュDNSサーバーから変更前の情報が 消滅し、変更が完了• 重要なポイント: 全部の○が⾚くならなくても、緑の○が すべて消滅した時点で完了 6)-A Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 34
  35. 35. とりあえず、ここまでのまとめ• DNSデータは経路制御(BGP)などと異なり、⽔が染み とおる(=浸透する)ように、近いところから順にじわ じわと⾏き渡っていくわけではない• かつ、BGPにおける経路情報などとは異なり、全ての キャッシュDNSサーバーにDNSデータが⾏き渡る(=伝 播する)わけでもない• つまり、権威DNSサーバーからキャッシュDNSサーバー へのDNSデータの伝わり⽅について「浸透」や「伝播」 という⽤語を使うことは、技術的に正しくない• ただし、ゾーン転送によるプライマリサーバーからセカ ンダリサーバーへの伝播については、浸透と⾔っても問 題ないしかし、このことはいわゆる「浸透問題」に おける、問題の本質ではない! Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 35
  36. 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
  37. 37. ありがとうございました! Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 37

×