co.jp への TXT 追加の謎

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

最初に • 実は、「co.jpにTXTリソースレコードが追加されたこと」については、直接の理由はわかりませんでした • もちろん、「多分これだろうという理由」は、既にわかっています • ここでは、私がどのような道をたどり、答えに行き着いたのかをまとめてみようと思います

一通のメール • あるとき、dnsops MLに一通のメールが流れました From: "T.Suzuki" <tss@e-ontap.com> To: dnsops@dnsops.jp Date: Tue, 15 Apr 2014 15:03:41 +0900 <snip> それから、co.jp などにいつの間にか入っている不思議な TXT レコードについて、本件との関連性の説明をしてもらえたりできませんか?

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

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

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

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

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

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

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

実装の違い • 実は、BIND9に付属のdnssec-signzoneと、NSD4に付属のldns- signzoneでは、動作に違いがあることがわかりました • ldns-signzoneでは、ゾーンファイルに記載されたすべての委任について、 NSEC3 RRを生成してしまう • RFC 5155にはErrataがあり、この中ではldns-signzoneのような動きとすべき、とあります • dnssec-signzoneでは、“Insecure”な委任の場合にはNSEC3 RRを生成しない • RFC 5155の当初の目的の1つでもある、委任が主たる仕事となる大規模ゾーンの場合の署名のコストを減らすために、このような実装になっている • “Secure”な委任が1つもないと、co.jpの乗っ取りが可能

というわけで • RFC 5155に、「少しだけ」詳しくなることができました • いや、ほんの少しだけ、ですね • DNSSEC難しい… • なぜco.jpにTXT RRをつけたのかという理由は、わかりませんでした • TXT RRの有無で、キャッシュDNSサーバー（バリデーター）の動作に変わりはありませんでした • どうやら、co.jpにつけたかったのではなくて、aichi.jpなどの地域型JPドメイン名を守るためでは？というお話を、ある方から聞きました • 納得です

co.jp への TXT 追加の謎

by goto_ipv6

on Jun 24, 2014

Statistics

Views

Actions

1 Embed 37

Accessibility

Categories

Upload Details

Usage Rights

Report content

co.jp への TXT 追加の謎 Presentation Transcript