DNSによる名前解決の動作フロー。

2014/05/01 20:57:10

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

前の記事

次の記事

DNS用語整理 も合わせてご覧ください。

目次

関連する要素

IPv4 の範囲での例です。
仮に www.example.co.jp（以降 (www)） の Aレコード の名前解決を行う場合。
（dig で言えば dig a www.example.co.jp ）

名前解決をする対象
www.example.co.jp、 以降 (www) の Aレコード
（スタブ)リゾルバ
名前解決を要求するクライアント。 以降 (R)
キャッシュサーバ
以降 (C)
example.co.jp ドメインのネームサーバ（権威コンテンツサーバ） [1] [2]
以降 (A)
jp ドメインのネームサーバ（権威コンテンツサーバ:TLDのネームサーバ）[2]
以降 (JP)
ルートサーバ
以降 (ROOT)

なお、それぞれの特定のレコードを (www:A) のように表記します。
※上記は「www.example.co.jp の Aレコード」の意味

[warning]
単純化のため、問い合わせた名前に対応するレコードはすべて綺麗に設定されている場合でまとめています。
実際は問い合せた際に対応するレコードがないことによるネガティブキャッシュや、不適切なNSレコードの設定（外部名のNSレコードで相互に循環しているなど）、権威サーバが応答しないなど、様々な要因での異常が発生する可能性があり、それごとの動作が発生します。

また、(R) 自身がキャッシュを持つ場合もありますが、ここでは(R)のキャッシュがない場合でまとめます。
[/warning]

[note]
(A:NS) は同じドメイン名下のホスト名（内部名）でなくとも設定できるが（外部名)、外部名である場合上記手順 7. で得る（A:A) を取得するために別途名前解決が必要となること、その外部名のドメインのネームサーバ二全てを委ねることになること、外部名のドメインでさらに外部名のNSが使われている場合さらに別途名前解決が必要となること、などリスクが大きくなります。
[/note]
参考資料） http://www.slideshare.net/OrangeMorishita/20111029-part1dnsdis

キャッシュサーバにキャッシュがない状態での検索

  1. (R) が (C) に (www:A) を問い合わせる
  2. (C) が自身のキャッシュに該当レコードがないことを確認する。＝＞ない
  3. (C) が (ROOT) に (www:A) を問い合わせる。
  4. (ROOT) は (www:A) を知らないので、自身の知っている (www) の最上位ドメインJP のネームサーバ (JP:NS) と、(JP:A) (＝グルー)を(C)に返す。[3]
  5. (C) が (JP:NS) と (JP:A) をキャッシュする。
    (JP:A) は ADDITIONALの回答であるためキャッシュしない実装もある。以下同様。
  6. (C) が (JP) に (www:A) を問い合わせる。
  7. (JP) は (www:A) を知らないので、自身の知っている (www) の最上位ドメインEXAMPLE.CO.JP のネームサーバ (A:NS) と (A:A) (＝グルー)を(C)に返す。
  8. (C) が (A:NS) と (A:A) をキャッシュする。
  9. (C) が (A) に (www;A) を問い合わせる。
  10. (A) は (www:A) を持っているので、自身の知っている (www:A) を(C)に返す。
  11. (C) が (www:A) をキャッシュする。
  12. (C) が (R) に上記で得られた (www:A) を返す。

[note]
実際は各 NSレコード、Aレコードは複数の応答があるのでそのうちのどのレコードが使われるかは実装依存。
[/note]

この手順をdig で表すと下記のようになる。

  1. (R): dig a (www) @(C)
  2. (C):
  3. (C): dig a (www) @(ROOT)
  4. (ROOT)からの応答: (JP:NS) / (JP:A)
  5. (C):
  6. (C): dig a (www) @(JP)
  7. (JP)からの応答: (A:NS) / (A:A)
  8. (C):
  9. (C): dig a (www) @(A)
  10. (A)からの応答: (www:A)
  11. (C):
  12. (C)からの応答: (www:A)

なお、この一連の名前解決（反復問い合わせ）でキャッシュサーバにキャッシュされる可能性があるレコードは以下のとおり。
実装次第でキャッシュされないものもありえる。

  • (JP:NS)
  • (JP:A)
  • (A:NS)
  • (A:A)
  • (www:A)

[note]
つまり「権威」と言っているのは

(ROOT) から順次たどってたどり着けるNSレコードで示された名前に対応するAレコードのIPアドレスのネームサーバ

であり、ネームサーバ側でそのゾーンのデータを持っているかどうかではありません。
権威サーバとコンテンツサーバはイコールではありません。

「レジストラが登録ドメインを、停止ではなくNSを書き換える（そしてレジストリがそれを許可している）、ということ。」 の件はこの「権威」の流れを断ち切る（NSレコードの削除)のではなく別の方向に向けたもので、それは乗っ取りである、ということが主題です。
[/note]

キャッシュサーバにキャッシュがある状態での名前解決

以下、キャッシュの内容は上記のものとする。

(www:A) を名前解決した場合

  1. (R) が (C) に (www:A) を問い合わせる
  2. (C) が自身のキャッシュに該当レコードがありTTLを過ぎていないことを確認する。=> 有効なキャッシュにヒット
  3. (C) が (R) に上記で得られた (www:A) を返す。

www2.example.co.jp のAレコード（以降 (www2:A)） を名前解決した場合

  1. (R) が (C) に (www2:A) を問い合わせる
  2. (C) が自身のキャッシュに該当レコードがないことを確認する。＝＞ない。ただし (A:NS) / (A:A) は有効なキャッシュにヒット
  3. (C) が (A) に (www2:A) を問い合わせる。
  4. (A) は (www2:A) を持っているので、自身の知っている (www2:A) を(C)に返す。
  5. (C) が (www2:A) をキャッシュする。
  6. (C) が (R) に上記で得られた (www2:A) を返す。

www3.example2.co.jp のAレコード（以降 (www3:A)） を名前解決した場合

  1. (R) が (C) に (www3:A) を問い合わせる
  2. (C) が自身のキャッシュに該当レコードがないことを確認する。＝＞ない。ただし (JP:NS) / (JP:A) は有効なキャッシュにヒット
  3. (C) が (JP) に (www3:A) を問い合わせる。
  4. (JP) は (www3:A) を知らないので、自身の知っている (www3) の最上位ドメインEXAMPLE2.CO.JP のネームサーバ (A2:NS) と (A2:A) (＝グルー)を(C)に返す。
  5. (C) が (A2:NS) と (A2:A) をキャッシュする。
  6. (C) が (A2) に (www3;A) を問い合わせる。
  7. (A) は (www3:A) を持っているので、自身の知っている (www3:A) を(C)に返す。
  8. (C) が (www3:A) をキャッシュする。
  9. (C) が (R) に上記で得られた (www3:A) を返す。

[note]
つまりキャッシュされているレコードのうち、名前解決の対象にしているドメイン名の直上のスーパードメイン（親ドメイン)、言い方を変えて正規表現のように言うと後方最長マッチのドメイン名のレコードをキャッシュから探して利用します。
[/note]

[note]
(A) で (www:A) を書き換えた場合（IPアドレスを変更した場合)に、新しい (www:A) を (R) で利用するようになるには (C) の (www:A) のキャッシュがヒットしなくなり再度名前検索を行った後になります。
(A) から (C) や (R) に変更を通知する方法はありません（「浸透」というのにふさわしいような動作はどこにもありません）。
[/note]

キャッシュがヒットしなくなるタイミング

大きく以下の3つが考えられます。

  • 各レコードに設定されているTTLを過ぎた場合
  • キャッシュサーバの設定でキャッシュの有効期限の上限が定められている場合でTTLがそれ以上に設定されている場合、その上限にたっした場合
  • キャッシュサーバの再起動などでキャッシュを消した場合

(A) の管理者側である程度コントロールできるのは各レコードに設定するTTLのみであり、それ以外でキャッシュサーバ内のきゃっしゅをコントロールする術はありません。

この動作フローから推察されるリスク

[warning]
CO.JP の NSレコードが実在しないので正規にはキャッシュされることはありませんが、仮にキャッシュポイズニングによって CO.JP のNSレコードをキャッシュサーバにキャッシュさせることに成功した場合、キャッシュされていない CO.JP のサブドメイン（つまり～.co.jp） は偽の CO.JP のNSレコードに従い名前解決を行うため、偽の応答を元に以降の通信（例えばWebサイトの閲覧）を続けることになります。

複合的な攻撃として、例えばOpenSSLの脆弱性（Heartbleed）によって仮にSSL証明書が奪われていた場合、アクセスしているURLとSSL証明書のコモンネームを一致させることが出きるため、ブラウザの警告を出さずに偽サイトにアクセスさせることができ、それを偽サイトだと見分けるのは非常に困難です。
[/warning]

続きはこちらをご覧ください。
キャッシュポイズニングの開いたパンドラの箱 -1- http://www.e-ontap.com/dns/endofdns.html
キャッシュポイズニングの開いたパンドラの箱 -2- http://www.e-ontap.com/dns/endofdns2.html
長年放置されてきた DNS の恐るべき欠陥が明らかに http://www.e-ontap.com/blog/20140415.html

  1. レジストラの管理画面などで登録している「ホスト登録」などと表現されている項目は (A:A) を指定する設定であり、「ネームサーバ登録」などと表現されている項目は (A:NS) の登録に対応する。 ↩
  2. 階層的と言う意味では、TLDであるJPのネームサーバがexample.co.jp に対して答えるのは CO.JP のNSレコードであるように考えられるが、実際は CO.JP はゾーンとなっていない（JPゾーンに含まれる)ため、JPのネームサーバが答えるのは直接 example.co.jp のNSレコードになる。 ↩ ↩
  3. 実際は
    - 回答（ANSWER）:該当なし
    - 知っている権威（委任先：AUTHORITY）： (JP:NS)
    - おまけ（ADDITIONAL）：(JP:A）
    として応答が返る。
    ADDITIONALはない場合もあるし、キャッシュサーバ（リゾルバ）側が利用しないこともある。
    ADDITIONALがない場合、リゾルバ側が (JP:NS) で与えられた名前を改めて解決しにいく。
    以下 NS + A の応答はすべて同様。 ↩

コメント