20111029 part2-dnsトリビア（出張版）-事後資料

DNSトリビア（出張版）
+ IW2011ランチセミナーのネタをチラ⾒せ

DNS周辺技術勉強会 #dnstudy 02
2011年10⽉29⽇
森下泰宏

Copyright © 2011 Yasuhiro Orange Morishita, all rights reserved. 1

「DNSトリビア」とは
• 私がtwitterで勝⼿にやっている企画
• DNSについて意外に知られていなさそう
なことや、知っていると得する（かも知
れない?）ことを不定期にツイート
• 気分転換したい時の頭の体操と⾃⼰満⾜
– 140⽂字以内にまとめる
– 最初は⼤抵はみ出している


「DNSトリビア」とは
• 最初のツイートは2011年06⽉20⽇
– twilogさんに感謝
• 現在までに20項⽬をツイート
• 50項⽬ぐらいまではツイートしたい
• 100ツイートできたら書籍にでも（無理ｗ）

• 今⽇はそのうちのいくつかのご紹介と、番外編
として「なぜ浸透と⾔うとえらい先⽣に怒られ
るのか」についてお話します


その1:RRのTTL値は
「キャッシュしてもよい時間」
• RRのTTL値は「キャッシュしなければな
らない時間」ではなく、「キャッシュし
てもよい時間」を表している。
• RFC 1034 / 1035的にはキャッシュは必
須ではない（should、もちろん実運⽤で
はキャッシュすべき）
• TTL値を超えてキャッシュを保持してはな
らない（これが重要）


その2:CNAMEは
別名ではなく正式名
• CNAMEはある別名の正式名を指定するための
RRである。別名に対する正式名は常に1つであ
り、2つ以上存在することはない。そのため、1
つの名前に対し、CNAMEを同時に2つ以上指定
することはできない。
• 指定されるのは別名ではなく「正式名」
– CNAME = Canonical Name
• 「正式」というぐらいで、常に1つに定まる
– ある名前に対するCNAMEが同時に2つ以上指定され
ることは、定義上あり得ない


その3:プライミング
• 最近のキャッシュDNSサーバーの実装の多くは、
最初にルートサーバーに“.”のNSを問い合わせ、
以降の検索にはその結果を使う。これを「プラ
イミング（priming）」と呼ぶ。これらの
キャッシュDNSサーバーでは、ルートヒントは
最初しか使われない。
• このことは意外に知られていない
• プライミングについて解説した⽇本語の書籍や
ドキュメントはほとんど⾒たことがない
• 「実践DNS」には書きませんでした…
– 校了後に「あぁ、書いたほうがよかった」と思った
のが、このツイートのきっかけ

その5:最初のTLD
• 1984年に最初のTLDとして移⾏⽤のARPA、組
織⽤のGOV/EDU/COM/MIL/ORG、国⽤のISO
3166の2⽂字、及び「複合組織」⽤が計画され
た（RFC 920）。条件付きながら「⼤きな複合
組織はTLDとなりうる」旨が既に含まれていた。
• 1984年の時点で現在のccTLDに相当するものが
既に含まれていた
• 「⼤きな複合組織」として、.CSNETという例が
書かれていた
– ただし、各例⽰はあくまでも架空のものである（実
在のものではない）と書かれている

その6:ルートサーバーの歴史
• A〜MまでのルートサーバーのうちIまでの
9つは、1990年代初頭には既に存在して
いた。その後、1995年にホスト名が
X.root-servers.netに統⼀、さらに1997
年にIANAによりJ〜Mまでの4つが追加さ
れ、現在の13体制になった。
• 名前の統⼀:応答を圧縮するため
• 13:「512の壁」を踏まえた台数


その7:⽇本の歴史
（ネームサーバー3系列）
• かつて⽇本のネームサーバーにはA、B、Cの3系列が存
在していた。系列Aで海外と接続可能な、系列Bで国内
すべてのJPドメイン名をそれぞれ管理し、系列Cで海外
に接続可能な国内組織向けに、通常のDNSツリーと系列
Bを参照（マージ）する形で運⽤されていた。
• （事後資料で修正）系列Aは国内からは参照されない
• （事後資料で修正）系列Cはjp以外は通常通りで、jpの
下だけが系列Bに差し替わる
• 国全体で今で⾔う「Split DNS」を運⽤
• 海外に到達できないネットワークの存在
– AUPによるフィルタリング
• ⽇本―⽶国―⽇本、という通信経路を避けたかった、と
いう事情もあった

その9: .ukはISO 3166ではない
• 英国のccTLDは.ukであるが、これは
ccTLDの定義であるISO 3166の2⽂字
コードからは外れている。ISO 3166で定
義されている.gbも存在しているが、
IANAにより予約されている。
• 英国はccTLDがISO 3166であるというし
くみが運⽤される前から.ukを使っていた
• .uk→.gbへの移⾏が計画されていたが、
実施されなかった


その10:AS112で実験された
IP Anycast
• DNSサービスにおけるIP Anycastの利⽤は
AS112プロジェクトにおいて実験され、その嚆
⽮（こうし）となった。それにより得られた運
⽤経験はルートサーバーをはじめとする、その
後の広域DNSサービスへのIP Anycast導⼊に役
⽴てられた。
• AS112:プライベートアドレスの逆引きゾーン
• トラブっても致命傷にならない（はず）
• それで困った⼈がいても「そもそもそんな問い
合わせをインターネットに出すんじゃない」と
⾔うことができた


その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プリフェッチのことを考えると、実は逆順のほうが
よかったのかもしれない

その13:DNSSECの署名は
有効期限ではなく「有効期間」
• DNSSECの署名（RRSIGレコード）には、開始時
刻と満了時刻の双⽅が存在する。そのため厳密に
は「有効期限」ではなく「有効期間（validity
period）」と表現される。
• 当時「クレジットカードとは違う」とツイートし
たところ、@tss_0101 さんから「ダイナースの
クレジットカードには開始も書かれている、とい
うご指摘をいただきました。感謝いたします


その14:PTRレコードは
複数記述可能
• 1つのIPアドレスに対し複数個のPTRレコードを
記述することは、DNSの規格に違反していない
（RFC 2181）。違反であるという記述をしば
しば⾒かけるが、誤りである。
• ただし、複数記述した場合にgethostbyaddr()
がどのような動作をするのかは実装により異
なっている
• FreeBSDとLinux(glibc)では動作が違う
– FreeBSD: 全部返す、どれが最初かは毎回変わる
– Linux(glibc): ⼀つだけ返す、返すものは毎回変わる


その15:国際化ドメイン名（IDN）
の接頭辞は株の出来⾼で決まった
• 国際化ドメイン名の接頭辞「XN」はRFC 2777
のアルゴリズムに従い、選定⽇（2003年2⽉11
⽇）のNYSEとNASDAQの6銘柄ずつ（計12銘
柄）の出来⾼をベースとした、所定の演算によ
り決定された。
• 選定の公正さを技術的に確認可能な⼿法
– Publicly Verifiable Nomcom Random Selection
（RFC 2777）
• スクワッティングやインサイダー取引を防⽌


その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の構造をイメージするとわかりやすい

その18/19:実装依存シリーズ
• CNAMEの連鎖（CNAMEの先がまたCNAME）は
たどられるべきであるとRFC 1034には記述さ
れている。ただし、CNAMEの連鎖を何段まで許
すのかは決められておらず、実装依存である。
– 8.8.8.8は連鎖が数⼗段あっても名前を引けるらしい
• 名前解決において、あるドメイン名の権威DNS
サーバーのうちのどれが選ばれるかは決められ
ておらず、実装依存である。現在の実装では何
らかの形で「ネットワーク的に近い」サーバー
を優先的に選択するものが多い。
– 例えばBIND 9ではバージョンによって異なっている

番外編:
なぜ浸透と⾔うと
えらい先⽣に怒られるのか


「浸透いうな！」
• twitterで「DNSが浸透しない」とか
「DNSの浸透待ち」とツイートすると、
もれなくえらい先⽣に怒られます
• その理由は何か?


私はえらい先⽣ではないですが…
• DNSデータについて「浸透」や「伝播」という
⾔葉を使うことには、私も違和感を持っている
• 権威DNSサーバーからキャッシュDNSサーバー
へのDNSデータの伝わり⽅は「浸透」や「伝
播」という形式ではない
• つまり、少なくともそれについて「浸透」や
「伝播」を使うのは、技術的におかしいと思う
• ただし、更新時にプライマリサーバーからセカ
ンダリサーバー群にデータが伝わることは「伝
播」で正しい
– DNS NOTIFYのRFC（RFC 1996）にも
「propagation」（伝播）という⾔葉が使われている

（ご注意）
• 以降のページは、発表会場で当⽇いただ
いたご質問やコメント、 twitter上で「え
らい先⽣」をはじめとする多くの⽅々か
らいただいたご意⾒やコメントなどを参
考にしながら、発表時に使⽤したものか
ら内容を⼤幅に加筆訂正してあります。


経路制御（BGP）では
「伝播」「浸透」で正しい
• データを更新すると、その情報をユーザーが参照しない
場合でも、情報が系全体に伝播する
• 更新元に直接接続しているピアから情報が系全体に徐々
に⾏き渡り、浸透していく

模式図を使って説明します


1）最初の状態
• すべてのASが古い経路情報を保持


２）経路情報を変更
• 真ん中のASで経路情報を変更
– 例えば、192.0.2.0/24という経路情報を追加


3）経路情報が伝播
• 直接BGP接続しているピアに経路情報が
伝播


4）伝播の拡⼤
• それぞれの隣のピアに経路情報が伝播
– 経路情報が徐々に浸透


5）伝播（浸透）の完了
• すべてのASに経路情報が伝播


キャッシュDNSサーバでは
古いデータが「消滅」していく
• その情報をユーザーが参照しない限り、個々の
キャッシュDNSサーバーにはロードされない
• 接続の形態はデータの伝わり⽅には関係しない

模式図を使って説明します


1）最初の状態
• 真ん中の□は変更対象の情報を管理する権威DNS
サーバー、その他の○はキャッシュDNSサーバー
を表すものとする
• 最初の状態で、すべてのキャッシュDNSサー
バーが変更対象の情報を持っているわけではない
ことに注⽬（緑と⽩の○がある）


2）情報を変更
• 1）から2）の間に起こったこと
– 権威DNSサーバーでDNS情報を変更（緑→⾚）
• 例えば、www.example.jpのIPアドレスを
192.0.2.1から192.0.2.10に変更


3）それからしばらく後
– 3)-Aのサーバーを使っているユーザーが、変更後の
DNS情報を検索（⽩→⾚）
– 3)-Bのサーバーの変更前のDNS情報が消滅した後、
そのサーバーを使っているユーザーが変更後のDNS
情報を検索（緑→⾚）

3)-A

3)-B


4）さらにしばらく後
– 4)-Aのサーバーの変更前のDNS情報が消滅
（緑→⽩）
– 4)-Bのサーバーを使っているユーザーが、変
更後のDNS情報を検索（⽩→⾚）

4)-B

4)-A


– 5)-Aのサーバーの変更前のDNS情報が消滅し
た後、そのサーバーを使っているユーザーが
変更後のDNS情報を検索（緑→⾚）

5)-A

– 6)-Aサーバーの変更前のDNS情報が消滅（緑→⽩）
– これによりすべてのキャッシュDNSサーバーから変更前の情報が
消滅し、変更が完了
• 重要なポイント: 全部の○が⾚くならなくても、緑の○が
すべて消滅した時点で完了

6)-A


とりあえず、ここまでのまとめ
• DNSデータは経路制御（BGP）などと異なり、⽔が染み
とおる（＝浸透する）ように、近いところから順にじわ
じわと⾏き渡っていくわけではない
• かつ、BGPにおける経路情報などとは異なり、全ての
キャッシュDNSサーバーにDNSデータが⾏き渡る（＝伝
播する）わけでもない
• つまり、権威DNSサーバーからキャッシュDNSサーバー
へのDNSデータの伝わり⽅について「浸透」や「伝播」
という⽤語を使うことは、技術的に正しくない
• ただし、ゾーン転送によるプライマリサーバーからセカ
ンダリサーバーへの伝播については、浸透と⾔っても問
題ない

しかし、このことはいわゆる「浸透問題」に
おける、問題の本質ではない！

続きはInternet Week 2011の
ランチセミナーL1にて
• 2011年11⽉30⽇ 11:45〜13:00
– DNS浸透の都市伝説を斬る
〜ランチのおともにDNS〜
• 多くの⽅々のご来場をお待ちしております
• 当⽇はランチセミナーに引き続き、DNS
DAY、dnsops.jp BOFも併せて開催され、
「午後は○○DNS漬け（古い）」となって
おります
• 併せてお楽しみいただければ幸いです
乞うご期待！

ありがとうございました！


20111029 part2-dnsトリビア（出張版）-事後資料

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 20111029 part2-dnsトリビア（出張版）-事後資料

Similar to 20111029 part2-dnsトリビア（出張版）-事後資料 (20)

20111029 part2-dnsトリビア（出張版）-事後資料