DNSについて。

2013/04/04 18:38:24

[技術系メモ] https://wp.kaz.bz/tech

前の記事

次の記事

目次

はじめに

ここでは動作原理や概要を説明し、例えばBINDでの設定方法などは書きません。
個別の記事としてそのうち書くこともあるかもしれません。

いわゆる「インターネット」におけるDNSについての個人的な理解をまとめていってみます。
表現が厳密性にかける傾向があります（例えば１つのIPアドレスが示す機器は1つとは限りませんが、そういう表現をすることがあります）。
※さらに、面倒なので IPv4 前提の表現をします。

DNSの前に、DNSに至る経緯概略（大雑把）（リンク）

長くなるので DNSに至る経緯概略（大雑把）。 に分けました。

DNSの動作

DNSはDNSクライアント（＝リゾルバ）がDNSサーバに問い合わせることで、DNSサーバが返答をする仕組みです。
DNSはルートサーバを根としたツリー構造の分散方法をとっています。

[note]
例）www.example.com の探し方。

  1. .com を管理しているDNSサーバ（＝ルートサーバ）に対し問い合わせると example.com を管理しているDNSサーバを教えてくれます。
  2. 上で教わったサーバに対し問い合わせると、www.example.com の情報が取得できます（その情報があれば）。

[/note]

単純化のため階層が浅い例ですが、実際はもっと深い階層でも同様に探されていきます。

リゾルバ・DNSサーバ

DNSクライアントのことをリゾルバと言います。
DNSサーバには主にコンテンツサーバとキャッシュサーバの2種類があります。

リゾルバ

DNSサーバに対し名前解決を要求する側（クライアント側）のことです。
一般的なLinuxでいう /etc/resolv.conf はリゾルバがどのサーバに対し名前解決の問い合わせをしにいくかの設定です。
nslookup や dig で特に指定しない場合に問い合わせにいくサーバは /etc/resolv.conf で指定されているサーバです。

コンテンツサーバ

自分に登録されているデータについて答えるサーバです。
BINDで言うゾーンファイルに書き込むデータが回答の対象です。
問い合わせられたデータをコンテンツサーバが持っていない場合、「ない」（NXDOMAIN）と言う回答をします。

通信の度に毎回コンテンツサーバに対して名前解決をするとコンテンツサーバ（およびその上位サーバ、ルートサーバを含む）にたいし過大な負荷がかかるため、一度回答したレコードにはTTL（Time To Live）を設定し、その時間内であればキャッシュして構わないことを宣言します。
NXDOMAINの場合はそのゾーンに設定されているminimum値の時間をキャッシュ時間の上限とします（ネガティブキャッシュ）。

レジストラへのドメイン登録の際にネームサーバとして登録するのはコンテンツサーバであり、登録されているコンテンツサーバを「権威サーバ」と言います。
[note]
権威サーバ
≒ レジストラで登録するネームサーバ
≒ レジストリが管理する上位のDNSサーバにそのゾーン（≒ドメイン）のNSレコード（およびそのAレコード）として登録されているコンテンツサーバ

レジストラはレジストリが管理する上位のDNSサーバに対しそのゾーン（≒ドメイン）のNSレコード（およびそのAレコード）を登録します。
それによって、同じルートサーバを根にもつDNSサーバ群（要するにインターネット）からそのゾーンの名前解決の際に参照してもらえるようになります。
[/note]

[warning]
マスタ・スレイブといった用語がありますが、これは本来BIND用語であり、DNS用語ではありません。
データレプリケーションの方向を差しているだけの用語です。
DNSにとってはどちらもコンテンツサーバであるだけです。

プライマリ・セカンダリといった用語はプライマリ側が最初に問い合わせがあるようなイメージにつながりますが、これもまた誤解でDNSにとってはどちらもコンテンツサーバにすぎません。
強いて言うと、ネームサーバ登録の際の順序です。

また、プライマリ＝マスタ、スレイブ＝セカンダリと考えてるような説明もありますが、それもまた誤解です。
ネームサーバ登録の1台目も2台目もスレイブで構成することもよくあることです。
→マスタは特に公開せずファイアウォールなどで接続制限した場所で管理し、複数のスレイブを公開用に設定する。

と言うように、意外と巷で公開されている説明ページには間違いがあります。
（このサイト自体にもあるに違いありませんが。）
[/warning]

キャッシュサーバ

前述のとおり、通信の度にコンテンツサーバに問い合わせるのでは効率が悪いため、DNSではキャッシュの利用が想定されています。
リゾルバが問い合わせた際にキャッシュするのですが、個々の通信機器でキャッシュした場合そのキャッシュはその機器でしか利用できません。
複数の機器でキャッシュを利用することができるように用意されているのがキャッシュサーバです。

キャッシュサーバは、

  1. 問い合わせのあったものに対する回答が自分のキャッシュ内にある場合、キャッシュから回答する
  2. キャッシュ内に回答がなかった場合、キャッシュサーバがリゾルバとなり代わりに検索し、それで得た回答を回答する

と言う動作をします。
そのため、一般的に個々の機器のリゾルバが問い合わせる先はキャッシュサーバです。

再帰検索

キャッシュサーバの2.の動作を「再帰検索」と言います。
再帰検索をしに行く先はキャッシュサーバの設定によりますが、

  • 別のキャッシュサーバ
  • ルートサーバ

のどちらかであることが普通です。

オープンリゾルバについて

オープンリゾルバとは、誰でも利用できるように設定したキャッシュサーバです。
Google Public DNS（いわゆる 8.8.8.8 / 8.8.4.4）はオープンリゾルバの例です。

つまり、誰かが1度問い合わせたデータを有効に使いましょう、と言う仕組みなのですが、例えばDNSキャッシュポイズニング（いわゆる毒入れ）と合わせて考えるととてもリスキーな使い方であることが分かります。
※ DNSキャッシュポイズニングについてはこちら https://www.nic.ad.jp/ja/newsletter/No40/0800.html

例えば8.8.8.8に対し毒入れが成功すると、世界中の利用者がその影響を受けることになります。
そして攻撃手法上、利用者が多く問い合わせが多いほど毒入れの成功率は高いわけで。

設置するのも使うのもやめましょう。

※こちらのページがとても参考になります http://d.hatena.ne.jp/WK6/20111108/1320761351

[note]
最近はこんな攻撃もあります。
DNS Amp http://jprs.jp/related-info/guide/003.pdf
[/note]

共有コンテンツサーバについて

参考） https://moin.qmail.jp/DNS/脅威/共用ゾーンサービス/さくら

プロバイダなどが提供している共有コンテンツサーバですが、これに対するドメインの追加の際に充分なチェック機能が働いていない場合、ドメインの乗っ取りが可能になります。

例えば既に稼働しているドメイン example.com のコンテンツサーバに対し、www.example.com ドメインが追加できてしまう場合、www.example.com の乗っ取りが可能になります。
（既に稼働しているためネームサーバ登録はこのサーバを向いているため、www.example.com と言う問い合わせはこのサーバにきます。）

これもできるだけ避けましょう。

共有コンテンツサーバ兼オープンリゾルバ

上記の理由によって、最悪な状態な可能性があります。

BINDについて

BINDは、コンテンツサーバとキャッシュサーバどちらとしての動作もします。
（そのため、設定が複雑になります。）

つまり上記の 共有コンテンツサーバ兼オープンリゾルバ が容易に設定できる状態になっています。

named.conf で設定するゾーンデータ（zone example.com { } の形式で書くもの）はコンテンツサーバの設定、recursion 、allow-recursion あたりの設定がキャッシュサーバの設定です。

一見便利そうですが、リゾルバが問い合わせた際の回答がコンテンツサーバとしてのものかキャッシュサーバとしてのものか混在します。
コンテンツサーバであれば自分が管理していないゾーンについては答えるべきではありません。
キャッシュサーバであれば再帰検索を行うのは妥当ですが、それはルートサーバからたどるべき検索です。

BINDで再帰検索を有効にしている場合、例えばゾーン情報として google.com についてのゾーンを（勝手に）登録したとします。
その状態でこのサーバに対してwww.google.com についての名前解決を要求すると、コンテンツサーバに登録されているデータが返されます。
それによって起こることについては、こちらをご覧ください http://www.e-ontap.com/dns/weirdra/

コンテンツサーバでの再帰検索はやめましょう

ということで、コンテンツサーバでの再帰検索はやめましょう。

PR:重要

DNSは聞かれたことに答える仕組みであってどこかに書き込みにいく仕組みではありません。

[warning]
（PR）DNSは「浸透」するような仕組みではありません。
浸透いうな! http://www.e-ontap.com/dns/propagation/
[/warning]

あるドメインの権威サーバ（後述：の予定）となりたい場合、世の中の通信機器から見にきてもらう必要があります。
しつこいようですが、能動的に教えにいく仕組みではありません。

見にきてもらうための作業がレジストラでのネームサーバ登録であり、それによってそのドメインの上位に当たるDNSサーバにNSレコードおよびAレコード（Glue Record）としてそのサーバが登録されます（移譲）。
※お名前.com用語で言うと、Aレコード登録が「ホスト登録」、NSレコード登録が「ネームサーバ登録」。
※BINDのレコード表記で言うと

@example.com.
     IN NS  ns01
ns01 IN A   xxx.xxx.xxx.xxx

登録されてから、実際に見にきてもらえるまでの時間（これが世に言う「浸透」時間）は、実際にはその通信機器の環境でキャッシュ（後述：予定）が切れるまでの時間です。
キャッシュされる最大時間は（本来は）TTLで設定した時間です。

レジストラが登録ドメインを、停止ではなくNSを書き換える（そしてレジストリがそれを許可している）、ということ。

DNS界隈で起こっている、インターネットを使えなくなりかねない事象もぜひ知ってください。
→ レジストラが登録ドメインを、停止ではなくNSを書き換える（そしてレジストリがそれを許可している）、ということ。

おわりに

初めに述べたとおり、自分なりの理解であり不正確な部分も多々あると思います。
ご了承ください。

コメント