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なども同様の弱点を抱えていた。
だが、この文書を読み取れるひとがどれだけいるだろう。-- 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は余計だが、
これらを使いこなすにもDNSの基礎知識は欠かせない。