秋深まりぼちぼち温泉につかりたいシーズンになってまいりましたが、皆様如何おすごしでしょうか。お久しぶりの酔っ払い系ツチノコです。
温泉といえば、
越後のんべえ温泉グループ。
— Fuminori Toyama (@ftoyama) 2013, 1月 16
で有名な ENOG という新潟のネットワーク系のグループが存在しますが、そちらで DNS に関する話題をお話して来ましたのでそちらの話でもさせて頂きたいとおもいます。
(あ、本当は Echigo Network Operators’ Group の略で ENOG らしいです。)
唐突ですが、皆さんはDNSってお好きですか？
大概の管理者の方は
ってな感じではないでしょうか。
そんななんとなく動いているからなんとなく理解した様になりがちな DNS の振舞いの中でも特に誤解されている DNS の名前解決の動作に関するトピックです。
DNS には
- ドメイン名とIPアドレス等のリソースレコード を紐付けるデータを持つ権威DNSサーバ
- 端末から名前解決の要求を受け、権威DNSサーバに問合せを行うキャッシュDNSサーバ
のふたつが存在する事は皆さんご存知かとおもいます。
ここで皆さんに質問です。
端末が “酔っ払い.jp” というサイトに接続を行いたいとします。そこで下図の (2)(3) でキャッシュDNSサーバは “.” の権威DNSサーバ (root の権威DNS サーバ) に対してどういったクエリを送り、”.” の権威DNSサーバはどういう返答を返すでしょうか。
よくある答えは、”.” の権威DNSサーバには “.jp” の権威DNSサーバを尋ね (NSレコードを聞き) 、それらを返答として受け取る、というものでした。以下、一階層ずつ下の権威DNSサーバを尋ねるクエリを送っていき、最後の階層でIPアドレスを尋ねる (A/AAAAレコードを聞き)、という形ですね。
これらの答えは、実際の挙動とは異なります。
というわけで、答えはこちら。
ちょっと分かりづらいですね。
キャッシュDNSサーバは常に “酔っ払い.jp のIPアドレスは何?( Aレコード)” を常に問合せ続けます。”.” の権威DNSサーバにも、”.jp” の権威DNSサーバにも、実際に紐付けるデータを持つ “酔っ払い.jp” の権威DNSサーバにもです。常に “クライアントから要求された名前解決のクエリ” を送ります。
わざわざ、”.” の権威DNSサーバに次の階層である “.jp” の NSレコードを聞いたりは、しないんですね。
で、”酔っ払い.jp” の A レコードを直接知らない “.” の権威DNSサーバは “.jp” の権威DNSサーバなら知ってるんじゃない、という意味で Authority Section に NS レコードの一覧をいれて教えてあげます。
あとは、実際に紐付けるデータを持っている権威DNSサーバに辿りつくまで繰り返し、です。
ところが、現在 IETF の dnsop で提案されている DNS query name minimisation to improve privacy というインターネットドラフトで状況が変わるかも知れません。
上記のドラフトによると、現在の “クライアントが知りたいドメイン名のリソースレコードを root の権威DNSサーバから順番に引いていく” というやり方は、実はプロトコル上の要求ではなく、歴史的にそうやっているだけだ、というのです。
そしてこの従来の振舞いですと、より上位の権威DNSサーバやそれらに到達するDNSクエリのパケットを覗き見できるネットワークの管理者は、ある程度エンドユーザの活動が推測できる、という事になります。
こりゃいけねぇ、ってなことで QNAME Minimisation という提案がなされているのですが、こいつの内容って、
- “.” から問合せを始める際、一階層下の権威DNSサーバを尋ねる ( NS レコードを聞く )
- 一番下の階層に辿りついたら実際に聞きたいリソースレコードを尋ねる
というものなのです。これって、さっきのよくある間違いと同じ事ですよね。
現在、Experimental RFC になる予定になっていますが、従来の挙動から変更しても特に互換性がない為、メジャーな実装で機能が入るとあっさり普通の動作になったりするかも知れません。
というわけで、今日は DNS についてよく誤解されている振舞いと、将来的にそれが本当の動作になっちゃうかも、ってなお話をさせて頂きました。
詳細はこちらのスライドの中身もご覧頂ければとおもいます。