1. DNS/脅威/共用ゾーンサービス/同居の問題

Contents

DNS/脅威/共用ゾーンサービス/同居の問題
委譲が行われていても問題がある（森下）
さくらDNS脆弱性の背景
脆弱性発覚現象の分析
対策
問題

現時点での対策：同居は避ける。

いつ、どこまで解明できるかは見えない。脆弱である可能性も。

../同居を許さない

これが作られた理由は「さくら」での事件である。 http://dnsops.jp/event/20120901/20120901-DNS_Summer_Days_2012-the-delegation-v1.4-after.pdf

2. 委譲が行われていても問題がある（森下）

それがなにかはまだ示されていない。-- ToshinoriMaeno 2012-06-26 22:32:42

親子間での矛盾か。
- これは委譲とはなにかを考え直すべきで、ロンゲストマッチなどを持ち出す話ではない。

・基本的には「NSが混ざる」問題です（下記）。これについては、BIND 8とBIND 9で動作が変化しました。以下、引用します。

・なお、内部データベースの構造が「BIND 8 was unable to properly distinguish between these two sets of NS records and would "leak" the child's NS records into the parent」であることから、BIND 8ではいわゆる「スーパードメインハイジャック問題」を引き起こすと推測されます（未確認）。

BIND 9に付属のドキュメントから引用します。

No Information Leakage between Zones

BIND 9 stores the authoritative data for each zone in a separate data structure, as recommended in RFC1035 and as required by DNSSEC and IXFR. When a BIND 9 server is authoritative for both a child zone and its parent, it will have two distinct sets of NS records at the delegation point: the authoritative NS records at the child's apex, and a set of glue NS records in the parent.

BIND 8 was unable to properly distinguish between these two sets of NS records and would "leak" the child's NS records into the parent, effectively causing the parent zone to be silently modified: responses and zone transfers from the parent contained the child's NS records rather than the glue configured into the parent (if any). In the case of children of type "stub", this behavior was documented as a feature, allowing the glue NS records to be omitted from the parent configuration.

Sites that were relying on this BIND 8 behavior need to add any omitted glue NS records, and any necessary glue A records, to the parent zone.

Although stub zones can no longer be used as a mechanism for injecting NS records into their parent zones, they are still useful as a way of directing queries for a given domain to a particular set of name servers.

・ゾーン転送についても注意が必要。ゾーン転送をclarifyするRFCに書かれていた気がします。

・DNSSECの観点では、DSレコードの取り扱いや、NSEC3にした時のことにも配慮（RFCでの記述）があった気がします。

以上、-- OrangeMorishita 2012-06-27 13:28:42

3. さくらDNS脆弱性の背景

DNSサーバの動作が影響している。

DNSの仕様の欠陥が表面化した。

ゾーン分割、委譲の表現、ドメインの管理（データowner)

森下さんも言っていたように、親が委譲するためのNSと子が自分のサーバを宣言するNSとが同じタイプ名という欠陥

ゾーンcutしたときにNSレコードは上位に管理権限を渡すべきだったのに、下位に渡してしまったことなど。

ロンゲストマッチは現在の脆弱性に直接影響はしていないが、

クライアントが委譲のチェーンを辿らないというのは問題を大きくしている。

浸透しない、Ghost Domain Names, オレオレゾーン

4. 脆弱性発覚現象の分析

以下の二つは分けて論じるべき

（１）きちんと委譲されているが同居している場合
（２）委譲関係がないのに親ドメイン、サブドメインが同居している場合

委譲関係がないのに同居しているケースも

親だけが所有者
子だけが所有者
親子とも所有者
どちらも所有者でない

というケースがありえる。これらも区別する必要がある。

（親、子というのは祖先、子孫に置き換えて読んでください。）
- ただし、3,4 の場合は現在は脆弱性にはならない。

サブドメインハイジャックだけが問題ではないことを読み取っていただけるだろう。

5. 対策

あるゾーンのサービスを受け持つサーバはあとから来た親＊（先祖）は受け入れてはならない。

[親の方が本物だと確認できて受け入れるなら、子は本物でなければ排除すべき ] くらいか。

そのサーバーだけで局所的に見た場合、実はオレオレ親であるという判定のほうが難しい

ロンゲストマッチなんてのはすくなくとも今の乗っ取り問題には関係ない。そして、正しく委譲されている場合も関係ない。ということで、まったく関係のない話題です。（おそらく、問い合わせの手間を省こうとしたために入った）

6. 問題

委譲関係にない場合に子ドメインに属すると解釈できる名前の問い合わせを行うとどういう返事が返ってくるか。（１）さくら風（２）VD風　（３）その他（本来あるべき姿）

MoinQ: DNS/脅威/共用ゾーンサービス/同居の問題