1. co.jp への TXT 追加の謎
RFC 5155 をふらふらと読み解く
@goto_ipv6

2. 最初に
• 実は、「co.jpにTXTリソースレコードが追加されたこと」については、
直接の理由はわかりませんでした
• 「多分これだろうという理由」は、既にわかっています
• ここでは、私がどのような道をたどり、どんな答えに行き着いたのか
をまとめてみようと思います
• なお、この資料は「私がRFC 5155をこのように解釈しました」という内容に
なっていますので、内容の正確性はRFC 5155原本にてご確認ください

3. 一通のメール
• あるとき、dnsops MLに一通のメールが流れました
Subject: [DNSOPS dnsops 1339] Re: キャッシュポイズニング攻撃の危険性増加に関
する緊急の注意喚起の掲載について
From: "T.Suzuki" <tss@e-ontap.com>
To: dnsops@dnsops.jp
Date: Tue, 15 Apr 2014 15:03:41 +0900
<snip>
それから、co.jp などにいつの間にか入っている不思議な TXT レコードについて、
本件との関連性の説明をしてもらえたりできませんか?

4. co.jpにTXTレコード？
• なぜそんなものが？
• また、JPRSさんによる「キャッシュポイズニング攻撃対策：キャッシュ
DNSサーバー運用者向け―基本対策編」との関連もわかりません
• キャッシュへの毒入れなら、私も擬似環境を作り、攻撃ツールを自作して、
毒入れに成功していました
• co.jpドメインも乗っ取ることができました
• example.co.jpなど、まるごとごっそり
• すぐに思いついたのはDNSSECでした
• 「信頼の連鎖」をつなぐためなのでしょうか？
• でも、すでに「信頼の連鎖」は構築済みだったのでは？

5. co.jpってどんなドメイン名？
• 実は、TXT RRが入る前は、リソースレコードが何も存在しないドメイン
名でした
• jpゾーンから直接、example.co.jpが委任されています
• DNSSECでも、example.co.jpのDSは、jpゾーンに登録されています
• 「example.co.jp」は、例です
• co.jpにTXT RRが入ると、DNSSECとしては、状況が変わります
• TXT RRに対する署名が行われ、RRSIG RRが生成されます
• “drill -D -o rd co.jp. any @a.dns.jp” と入力してみましょう
• これで、既に署名されていた jpゾーンと、example.co.jpとの間にあるco.jpも、
署名されることになります
• つながった！何がつながった？

6. とりあえず乗っ取りを試してみる
• 擬似環境でDNSSECを有効にし、署名してみます
• 結果、co.jpへのTXT RRがあっても毒は入りました
• あれ？
• しかし、想定していなかった、別の動作も観測しました
• co.jpのDSを偽権威DNSサーバーに問い合わせてしまうのです
• 結果、validationに失敗してSERVFAILになりました
• DoSとしては成功！！
• でも、なぜキャッシュDNSサーバーは、DSを偽権威DNSサーバーに問い合わ
せるのでしょうか？
• しかも、DSを問い合わせる現象は、TXT RRの有無に依存しません

7. RFC 5155
• ここで出てくるのがRFC 5155です
• JPRSさんによる日本語訳はこちらです
• 日本語タイトルは「DNSSECにおけるハッシュを使用した不在証明」です
• これがまた、難解で…
• 特に、「用語」を理解するのが大変
• ハッシュ化所有者名？ハッシュ整列順？空の非終端？証明可能な最近接名？カバー
する？
• co.jpは「空の非終端」（Empty non-terminal）になります

8. 混乱
• 「ハッシュ整列順」と「カバーする」が、私を混乱させました
• RFC 5155では、「ゾーン列挙」によりゾーンの全内容を読み取ることができて
しまう問題を解消しています
• ドメイン名にハッシュ関数を適用し、それを権威DNSサーバーが返すことで、
ドメイン名自体は返らなくなるのです
• ある範囲にはドメイン名は存在しないことも、複数のハッシュ化所有者名を
返すことで示すことができます
• 「カバーする」ということは、例えばco.jpについて「なにもないよ」を示すには、
その両側のハッシュ化所有者名で挟めばよいのかな？
• aa.jpとzz.jpを作ったりしました…失敗…

9. NSEC3リソースレコード
• RFC 5155ではNSEC3 RRが導入されます
• NSEC3 RRは、NSEC3 RRのオリジナル所有者名について、これに存在
するRRタイプを列挙します
• 「タイプビットマップ」フィールドにエンコードされます
• 例えば、jpドメインの場合、NSやSOA, RRRIG, DNSKEY, NSEC3PARAMが存在す
ることを、NSEC3 RRを用いてバリデーターに知らせることができます
• 「フラグ」フィールド内の「Opt-Outフラグ」により、NSEC3 RRが未署名
委任をカバーしているかがわかります
• ん？カバー？

10. カバーする
• RFC 5155に登場する「カバーする」を理解するには、以下のことも理
解しなければなりません（以下、JPRSさんの日本語訳より抜粋）
• 最近接名（Closest Encloser）： ある名前に最長一致する実在の名前で、先
祖（親、親の親など）にあたるもの
• 証明可能な最近接名（Closest Provable Encloser）： さらに、存在証明が可能なもの
• 次近接名（Next Closer Name）： ある名前の証明可能な最近接名より1ラベ
ル長い名前
• カバーする： ある名前もしくは次近接名のハッシュが、NSEC3の所有者名と
次ハッシュ化所有者名の間にあるとき、そのNSEC3 RRはその名前を"カバー
する"という
• んー、わからん…

11. カバーする（続き）
• 続けて、NSEC3 RDATAのワイヤフォーマットを見てみます（3章）
• 「次ハッシュ化所有者名」フィールドがあります
• 次ハッシュ化所有者名（Next hashed owner name）： 全ハッシュ化所有者名を整列した
集合がある場合に、あるNSEC3 RRの「次ハッシュ化所有者名」フィールドは、そのNSEC3
RRの所有者名の直後にくる所有者名のハッシュを含む
• 各NSEC3 RRにおいて、ハッシュ整列順にしたがった次のNSEC3 RRの値を、次ハッシュ化
所有者名として挿入する（7.1章）
• ハッシュ整列順（Hash order）： ハッシュ化所有者名がその数値に応じて配列される順
序
• ハッシュ化所有者名（Hashed owner name）： 所有者名にハッシュ関数を適用した後に
生成される所有者名
• 何か、見えてきました

12. カバーする（続き）
• もう一度考えてみる
• 例えばexample.co.jpの「最近接名」はco.jpです
• しかし署名されているのはjpですので、jpが「証明可能な最近接名」です
• すると「次近接名」はco.jpになります
• ここで、co.jpの「次ハッシュ化所有者名」のドメイン名はexample.jpとします
• NSEC3 RRの所有者名をco.jpとすると、ある名前co.jpのハッシュが自分自身
（所有者自身）となり、さらに「次ハッシュ化所有者名」フィールドにexample.jp
のハッシュを入れておけば、co.jpのNSEC3 RRはco.jpを「カバー」する、という
ことになります

13. "Insecure"な委任
• co.jpについては、委任先のドメイン名ではDNSSECを導入していない
組織が多くあります
• RFC 5155ではこれを「“Insecure”な委任」と呼んでいます
• が、6章を読んで、また混乱しました…
• しかし、6章の最初の一文に、「なぜDSを問い合わせるのか」の答え（の一
部）があります
• 同様に、8.9章にはバリデーターとして動作した場合の「未署名サブゾーンへ
の参照の検証」についての記載があります
• このco.jpに毒入れしてみると、DS問い合わせが発生するのです
• この動き、どこに書いてあるの？

14. Opt-Out
• NSEC3 RRの「フラグ」フィールドにはOpt-Out bitがあります
• このNSEC3 RRが未署名委任を「カバー」しているかを示しています
• つまり、ここが1の場合、未署名の委任が存在してもよい、ということです
• jpのNSEC3 RRは、ここが1になっています
• example.co.jpが未署名（DNSSECを導入していない）でも構わないことを示しています
• 署名は、ゾーンファイルに対して行います
• dnssec-signzone（BIND9に同梱）やldns-signzone（NLnet Labsの独自作成ツー
ルでありldnsライブラリのサンプルプログラム）といったツールがあります
• オプションで、Opt-Outを有効にして署名することができます

15. 実装の違い
• dnssec-signzoneでは、すべてが“Insecure”な委任の場合にはNSEC3
RRを生成しません
• RFC 5155の当初の目的の1つでもある、委任が主たる仕事となる大規模ゾー
ンの場合の、署名のコストを減らすために、このような実装になっています
• “Secure”な委任がco.jpの配下に1個もないと、co.jpのNSEC3 RRも生成されず、
co.jpの乗っ取りが可能となります
• co.jpの配下にex1.co.jpとex2.co.jpがあったとして、どちらもjpから委任されており、しか
しDNSSECは導入していなかった場合、DSがjpには登録されていないために、署名の際
に、co.jpのNSEC3 RRは生成されません
• jpのNSEC3 RRにはOpt-Outがあるため、バリデーターはco.jp以下についてバリデーショ
ンを行いません

16. 実装の違い（続き）
• ldns-signzoneでは、ゾーンファイルに記載されたすべての委任につ
いて、NSEC3 RRを生成します
• さらには、「空の非終端」のNSEC3 RRも生成してしまいます
• ゾーンファイルにjpとexample.co.jpが記載されていた場合、署名後のファイルにはco.jp
のNSEC3 RRが自動生成されます
• example.co.jpが”Secure”か、”Insecure”かどうかは関係ありません
• RFC 5155にはErrataが出ており、この中では、ldns-signzoneのような処理をし
なければならない、とあります（Errata ID: 3441）
• OpenDNSSECでも、この動作をするように変更されています

17. そしてDSを問い合わせる理由は？
• どちらのツールでも、 “Secure”な委任がある場合は「空の非終端」に
ついてもNSEC3 RRが生成されます
• 例えばexample.co.jpはjpから委任されているとすると、co.jpから委任されて
いるわけではないために、co.jpのNSEC3 RRにおける「タイプビットマップ」に
はNSは記録されません（というか空になります）
• co.jp NS RRを毒入れされるとバリデーターは、しかしco.jpにはNSが存在しな
いことを知っているために、「おかしいぞ」と気が付きます
• ここでUnboundもBIND9も、jpの権威DNSサーバーが言っていることよりかは
co.jpの（偽）権威DNSサーバーが言っていることを信じてみようということで、
偽権威DNSサーバーにDSがあるか問い合わせ、「信頼の連鎖」が守られて
いるかを確認しようとします（これについてのRFCが見つからない…）
• そもそも、本来なら委任元に問い合わせるべきだし

18. というわけで
• RFC 5155に、「少しだけ」詳しくなることができました
• いや、ほんの少しだけ、ですね…
• なぜco.jpにTXT RRをつけたのかという理由は、わかりませんでした
• TXT RRの有無で、キャッシュDNSサーバー（バリデーター）の動作に変わりは
ありませんでした
• どうやら、co.jpにつけたかったのではなくて、aichi.jpなどの都道府県型JPドメ
イン名を守るためでは？というお話を、ある方（某h氏）から聞きました
• なるほど納得です
• aichi.jpなどは、もしかするとDNSSECさえも知らない人・組織が使っている可能性
• なので、「一律」に入れたと、ある方（某O氏）がおっしゃっていました
• 結果、co.jpにもTXT RRがつきました

19. gouv.fr の謎
• JPRSさんは、co.jpやaichi.jpなどにTXTレコードを入れました
• drill -D co.jp any
• TXTと、TXTに関するRRSIGがありますね
• 同じく「空の非終端」となりうるgouv.frはどうでしょうか？
• drill -D gouv.fr any
• なぜ、このようにして（なって）いるのでしょうか？

20. その後
• 2014年7月17日、18日に、香川県高松市にてJANOG34 Meetingが開
催されました
• その中に、「Security Issuesへの取り組みと対応―「ちゃんと」「きちんと」伝え
るためにできること～キャッシュポイズニングの手法を題材に～」というプロ
グラムがあり、co.jpなどにTXT RRがついた理由が明かされました
• また、別途、JPRSにて6月9日ころに「DNS.JPゾーンの収容変更につい
て」という操作も行われました
• dns.jpゾーンが作成（jpゾーンから分離）されました