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

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

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

DNS周辺技術勉強会 #dnstudy 022011年10⽉29⽇

森下泰宏


「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でかつ[email protected]のように、表記がDNSとは逆であった。DNSへの移⾏時に.gbへの切り替えが併せて計画されたが実施されず、.ukが継続使⽤された。

• 英国のゲートウェイサーバーで外国（から|へ）電⼦メールアドレスを書き換え、相互変換していた– （事後資料で追加）⽇本から英国に出すのは通常どおり、

[email protected]という記述で基本的にはOKだった– （事後資料で追加）英国から⽇本に出す場合、使うゲートウェ

イの仕様により指定するアドレスが異なる場合があった• user%[email protected]• user%[email protected]

– 詳細は調査中、年代や各サイトの設定変更により状況は変化• 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）それからしばらく後• 2）から3）の間に起こったこと

– 3)-Aのサーバーを使っているユーザーが、変更後のDNS情報を検索（⽩→⾚）

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

3)-A

3)-B


4）さらにしばらく後• 3）から4）の間に起こったこと

– 4)-Aのサーバーの変更前のDNS情報が消滅（緑→⽩）

– 4)-Bのサーバーを使っているユーザーが、変更後のDNS情報を検索（⽩→⾚）

4)-A

4)-B



– 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トリビア（出張版）-事後資料

Documents