1. 対策

DNS健全性チェッカー http://www.e-ontap.com/dns/health/

ほとんど行われていない。(業界全体の怠慢)

• 登録者の責任だという。 レジストラ･レジストリによる検査くらいはやるべきことです。

DNSサービス提供者もできることはある。

1.1. リゾルバー

リゾルバー側での対策は危険なドメインの一覧を持つことくらいか。

• キャッシュ毒盛と違って、権威サーバーの乗取りは事後では対応はむずかしい。

1.2. 作らないための注意(利用者)

ドメイン名の権利確認をしていないDNS(ゾーン)サービスを利用する/やめるときには、

• lame delegation を発生させないように、よく注意しましょう。

1.2.1. 利用開始時

委譲を設定する前にゾーンを作成できるか、確認しよう。

1.2.2. 利用中止時

委譲をやめるときには、ゾーンを残したまま、委譲だけを変更しよう。

• 委譲を残して、ゾーンを削除してはならない。

1.3. サービス提供側での対策

ゾーン作成時には｢委譲されていない状態｣であることを確認する。

さくらでは部分的に実施されている対策だ。(不十分) 全面的に実施することで、lame delegationを狙ったドメイン乗取りはできなくなる。

• Cloudflareやawsdnsでやって欲しい対策だ。

何年も前に分かっているのに、いまだに実施されていない。なぜか。

-- ToshinoriMaeno 2020-05-16 05:06:52

1.4. レジストリ･レジストラによる対策

JPRSでの対応

• JP下のホストを指す場合、存在しているドメイン内であることを確認しているが、これでは不十分である。

6. LAME DELEGATION Policy (lacnic) https://www.lacnic.net/686/2/lacnic/6-lame-delegation-policy

1.4.1. さくらでの制約

2012年にサブドメイン乗取可能な脆弱性が発覚して、不十分な対策をしている。

• 今年サービスを停止したdzndnsなども同様の弱点を抱えていた。

ドメインを利用する際の仕様と制限 https://help.sakura.ad.jp/hc/ja/articles/206226041-%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E9%9A%9B%E3%81%AE%E4%BB%95%E6%A7%98%E3%81%A8%E5%88%B6%E9%99%90

だが、この文書を読み取れるひとがどれだけいるだろう。-- ToshinoriMaeno 2019-09-28 22:18:00

Trace DNS Delegation http://www.simpledns.com/lookup-dg.aspx

1.5. 確認ツール

https://ns1.com/blog/using-dig-trace

Trace DNS Delegation http://www.simpledns.com/lookup-dg.aspx

確認の道具: DNSSECは余計だが、

• https://dnsviz.net/

• https://simpledns.plus/lookup-dg

• http://www.knossos.net.nz/checkdomain.cgi

• https://www.dynu.com/en-US/NetworkTools/Delegation

これらを使いこなすにもDNSの基礎知識は欠かせない。