DNS再入門

DNS の基礎

DNS の構成 (ホワイトボードで) と知っておくべき概念

• RFC1034
• RFC1035
• スタブリゾルバ、フルリゾルバ
• キャッシュサーバ、コンテンツサーバ(権威サーバ、ゾーンサーバ)
• ゾーン
• 委譲 (委任 / delegation)
• グルー
• 再帰 (recursive)、反復 (iterative)
• 浸透 ...いうな

ゾーンとは

• (ラベルの)隣接空間 (管理境界で区切られる)
• 権限のあるデータだけ置いてよい (may)
• 特殊な例外として "glue records" (他は must not)
  (RFC1033 にはそう書いてあるが後述のゾーン下部の委譲を示す NS も例外)
• ラベルの区切り(ドット)あるいはサブドメイン名といちいち対応するものではない (よくある誤解)

ゾーン分割

• 隣接するノードとノードの間にゾーンカット(境界)ができる
• (カットされず) ノードが接続されている名前空間が(区画された)ゾーン
  jp, chukyo-u.ac.jp, sist.chukyo-u.ac.jp, suzuki.sist.chukyo-u.ac.jp...
  (ac.jp はカットされておらずゾーンではない)
• ゾーンはその内部の名前全てに権威がある
• ルートに近い最上位のノードがゾーン名となる
• ドメイン名、ノードは単一のゾーンに属する (複数のゾーンに属さない)
• 区画されたゾーンは一組織が自由に制御できる
• データを変更し、木を継ぎ足し、ノードを削除し、サブゾーンの委譲ができる

ゾーンデータ

ゾーンの主たる4つの構成物

• ゾーン内のすべてのノード (名前) についての権威のあるデータ
• ゾーン頂点のノードを定義するデータ (SOA と NS のこと)
• 委譲したサブゾーンを示すデータ (下部のゾーンカット/これもまた NS)
• サブゾーンにアクセスするためのデータ (グルーと呼ばれる A や AAAA)
  (後者2つは権威をもたないデータ)

権威とは何か

• 権威はルートから順に委譲される (鈴木解釈)
• 木構造の一部についての完全な情報がゾーンとしてまとめられ管理される
• ゾーン内部の情報は全て権威ある情報 (RFC 的には委譲されている必要はない)

NS, SOA

• ゾーンの頂点ノードを示す管理上重要なデータは
  • ゾーンサーバすべてをリストアップする NS (Name Server) RRs
  • ゾーン管理パラメータを記述する一つの SOA RR
• ゾーン下部切断点 (cut) を示す RRs はサブゾーンの NS RRs
  • それら NS RRs は権威あるデータではない
  • サブゾーンの頂点を示す RRs と正確に一致しているべき (SHOULD)
• NS RRs は頂点と下部切断点にのみ現れ決して中間には現れない

グルー

• もしネームサーバの名前がサブゾーン内部にあったら、ネームサーバのアドレスを知るためには知りたいアドレスに問い合わせないといけないという状況になる
• 解決のために、権威のないサーバのアドレス RRs である "glue" RRs をゾーンに持たせる
• glue RRs はネームサーバの名前がゾーンカットの下にあるときに限り必要であり、referral 応答の一部としてのみ使われる
• 内部名という言葉で説明されることがあるが「下部名」のほうが適切 (鈴木案)

再帰

• 分散DBにおいて自力で名前解決できないサーバもある。このため2つの方法を用意する
  • Iterative: クライアントに他のサーバを紹介し、問い合わせを追跡させる
  • Recursive: 一つ目のサーバがクライアントである他のサーバからの問い合わせを追跡する
• サーバにとって一番シンプルなモードは non-recursive
  • ローカルな情報だけを用いて問い合わせに応答できる
  • 応答はエラー、回答 (answer)、最も近い他のサーバへの参照 (referral) からなる
• クライアントにとって一番シンプルなモードは recursive 　
  • このモードはネームサーバをリゾルバとして機能させる
  • 応答はエラーまたは回答で、決して参照は返さない
  • このサービスはオプショナルであり、利用するクライアントを限定してよい

以上 RFC1034 より抜粋: 実にわかりづらい。これが書かれた時代にはキャッシュとコンテンツの分離がちゃんとなされていなかったことも考慮して理解する必要がある

鈴木の解釈: recursive は iterative なサーバあるいはローカルな情報を持つサーバに辿り着くまで多段となりうるから recursive

5種類の DNS 返答

Notes on the Domain Name System (D.J.Bernstein) - The five types of DNS responses (前野訳)

• 「照会名に対して答レコードが(複数可)あった。」 (NOERROR / QNAME, QCLASS, QTYPE が一致し answer を回答)
• 「照会名が別名であったため問合せに答えは得られなかった。 照会名を変えてもう一度試みる必要がある。」 (CNAME)
• 「照会名に対して答えるべきレコードを持っていない。 また、他のいかなるタイプのレコードも存在しないことが保証されている。」 (NXDOMAIN / (否定)キャッシュ時間は 応答の authority section のSOA に依存 / DJB の警告に注意/ RFC8020 参照) 　
• 「照会名は答レコードをもたない。 しかし、別タイプのレコードはあるかもしれない。」 (NODATA / 擬似応答 / 他のTYPEはあるかもしれない / TTL は SOA に依存)
• 「サーバが答を持っていないので、問合せには答えてもらえなかった。 別のサーバにコンタクトする必要がある。」 ( Authority section に他のサーバの参照情報 (referral) / *委任にのみ使うべき)

TTL

• TTL 値はキャッシュ (の利用) が許される時間である (キャッシュし続けるべき時間ではない)
• RRset の RRs の TTL 値は一致していなくてはならない (MUST)

• キャッシュにあるのと同じ RRSet で TTL だけが異なる応答を受信した場合、オプショナルだが TTL を受信したもので更新してもよい (MAY)
• 受信した応答がより権威ある場合 (RFC 2181 ランキング参照) はキャッシュを更新すべきだ (SHOULD)
• ネガティブキャッシュの時間は否定応答に付随する SOA の minimum 値 (Negative cache TTL) あるいは SOA 自身の TTL の短い方が参照される (ゾーンサーバはこれを揃えて応答する)
  

  e-ontap.com 2560 SOA ns.e-ontap.com hostmaster.e-ontap.com (
                       1489584832 16384 2048 1048576 2560)
  

RFC 2181 講座 (ランキング)

RFC2181
5.4.1. Ranking data

優先度の高い順に、、、
     + プライマリのゾーンデータ
     + セカンダリのゾーンデータ
     + 権威ある応答の Answer セクションの権威あるデータ (AA)
     + 権威ある応答の Authority セクションのデータ
     + プライマリ・セカンダリサーバの中のグルーデータ
     + 権威のない応答の Answer セクションのデータ, および
       権威のある応答の Answer セクションの権威のないデータ
       (コンテンツ・キャッシュ兼用サーバなどでゾーン外データがつくことがある)
     + 権威ある Answer の Additional セクションの情報,
       権威のない Answer の Authority セクションのデータ,
       権威のない Answer の Additional セクションのデータ

ランキング

RFC2181
5.4.1. Ranking data
  (snip)
   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query. 

最下位ランクのデータ(権威ある Answer の Additional セクションの情報, 権威のない Answer の Authority セクションのデータ, 権威のない Answer の Additional セクションのデータ) はキャッシュしても Answer に用いてはいけない、と書いてある。

2008 年の BlackHat での Kaminsky の説明 (嘘の Additional が毒になる説明) が間違っていた所以がここに...

NS 移転において憂慮すべき点

• 委譲元の TTL に従うキャッシュサーバの存在
  (毒入れ防止の観点からは憂慮ではなく望ましい動作)
• 幽霊ドメイン名脆弱性のあるキャッシュサーバの存在
• キャッシュ兼用サーバからの移転はトラブル必至
• 非協力的な事業者が大半
• 不要になったゾーンを消せないサービスとか (契約解除後までも)

適切な NS 移転の要点

• ケースバイケースであり自分で考えないとダメ (手順は一人歩きするので指南しない)
• 基本的には新 NS を用意しておき、委譲元で NS を切り替えればそれでよい
• NS RRset (+glue) と他の RRs を同時に切り替えない (これが一番重要)
• 幽霊ドメイン名脆弱性対策、そして早期に新 NS へ誘導するために、旧サーバに新 NS を書く
  (これが効かない実装もある / 効く実装は移転インジェクションに脆弱)
• 委譲元の TTL が経過するまでは旧 NS へのアクセスを考慮 　
• 委譲元の TTL が過ぎたら旧ゾーンの設定は消す
• 緊急時には委譲元を書き換えたら旧ゾーンはすぐに消すのもあり
  (たいていのキャッシュサーバは親 (委譲元) 側から検索しなおす) 　
• 旧 NS に新 NS を書くことも、ゾーンを消すことも出来ない場合はそういうサービスを利用していた自分を罵りつつ、事業者にクレームを入れる 　
• 移転先が事前にゾーンを作らせてくれない場合、自由の効くサーバに臨時の NS を立てるケースもある

2019/4/5 追記:利用しているサービスによってはすぐにゾーンを消すのは危険なので注意してください。最悪、毒入れされます。このことに今まで気づかなかったのは迂闊でした。上記説明が不適切であったことをお詫びします。(参考:黒塗りのDNS)

「浸透」でごまかすことの弊害

• 待つ必要のない客を待たせる (客を騙す行為)
• 騙されていることに気づかない
• サービスの問題点に気づかない (キャッシュ・コンテンツ兼用など)
• 適切な設定確認を怠る (非再帰問い合わせでまず確認)
• 不適切な確認でネガティブキャッシュを入れて自爆する (いきなり再帰検索)
• 待った上でしか設定ミスや障害を疑わない
• そもそもいつまで待てばいいのかわからない (自分から見えたら浸透完了? 例えば30日待ちますか?)
• DNS の仕組みの理解が進まない
• 間違った理解の浸透に手を貸す
• 「浸透いうな!」と言われて悲しい目にあう
• etc.

(このページのパーマネントリンクはこちらをお願いします)

以上、ご理解頂けましたら、、、