Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,757 views

Published on

  • Be the first to comment

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

×