http://netsec.ccert.edu.cn/duanhx/files/2010/12/ghostdomain-2012-02-08-export-with-build.pdf
example.jp.ゾーンにsub.exmaple.jp.のNSレコードがあった
不法行為が判明しsub.exmaple.jp.のNSレコードは削除されたユーザーがsub.example.jp.をクエリする
一方、
sub.example.jp.の（元）権威サーバは、自身を指すNSレコードのレスポンスを権威有りで返すだろう。当然権威は持っている。
RFCを文字通り読むと、推奨は先にキャッシュに入っていた方、ということになる。
元権威サーバのキャッシュがあると、そのキャッシュは権威ある用に見える古い権威サーバの情報で更新され続ける。つまり、幽霊ドメインになる。
http://jprs.jp/tech/notice/2012-02-17-ghost-domain-names.html
幽霊ドメインをなるべく速く排除するために、BINDほかリゾルバ実装では、サブゾーンルートのNSレコードがサブゾーンのDNSから得たときは、キャッシュのTTLだけ更新しない（ゾーンのルートに対応する"@ IN NS *" なレコードはTTL延長しない）ことで対処しているようだ。
http://dnsops.jp/bof/20120425/20120425-DNSOPS.jp-BoF_Ghost_Domain_Names_v02.pdf
確かに、その時点でNSレコードの内容を利用することは権威がある以上どうしようもないが、キャッシュすることは強制ではないので、RFCを逸脱せず親ゾーンのTTLを上限にドメインを削除できる。
sub.example.jpを消すのではなく、他のDNSサーバに委任する場合、example.jp.の権威サーバは、新しいレスポンスを権威なしで返す。
もし、古い権威サーバの制御ができなくなったら、sub.example.jpの古い権威サーバは古い権威サーバ自身をさす古いNSレコードを権威アリで返す。
同じくRFC推奨に従うと、リゾルバはsub.example.jpの古いDNSからの返答でキャッシュを更新してしまうので、何らかの理由でsub.example.jpにアクセスがあると、何時まで経っても更新されない。＝
浸透いうな不浸透問題。
同様に、サブゾーンから返ってくるNSレコードは無視されるので、TTL切れすると親ゾーンの新しいNSれこーどが読み込める。
親ゾーンを優先するようにRFCが書かれていればこんな問題は起きなかった。ただ論文のスライドの最後にもあるけれど、オーバーヘッドは避けられない。当時はサーバーの処理能力的にそんな事やってられなかった、というのが主要因なんだろう。
ネームサーバ移転は本人のミスで片付くが、幽霊DNSは不法なドメインを削除できないというセキュリティ上の問題として扱われているので、対応が進んでいる、はずなんだけれど実体はだいぶ違うらしい。
もし、古い権威サーバの制御ができなくなったら、sub.example.jpの古い権威サーバは古い権威サーバ自身をさす古いNSレコードを権威アリで返す。
浸透いうな不浸透問題。
同様に、サブゾーンから返ってくるNSレコードは無視されるので、TTL切れすると親ゾーンの新しいNSれこーどが読み込める。
NSの移転問題を”浸透いうな不浸透問題”にしてみました。
