dns1.example.net. IN A 1.1.1.1さらに認証用に
dns2.example.net. IN A 1.1.1.2
dns3.example.net. IN A 1.1.1.3
*.domaincheck.example.net . IN A 1.1.1.3を持っているとする。(ゾーン表記にしました)
dns1.example.net.
dns2.example.net.
に加え、ランダムに選んだホスト名abcedfを付加したabcdef.domaincheck.example.net.をdns3の替りに通知する。
IPは同じなのでDNS上問題はない。(キャッシュサーバに少しだけ迷惑だけど) （IPを登録うんぬん修正しました）
顧客はdns1, dns2に加えabcdef.dnscheck.example.net.に向けてNSレコードを設定する。
事業者はexample.com.のNSレコードが、abcdef.dnscheck.example.net.へ正しく委任元DNSに登録されたことを確認し、example.comをアカウントと紐つけ、認証完了とする。さらに、以前の顧客に同じドメインを持っている人が居るかもしれないので、example.comがすでに自社のDNSやアカウントデータベースに登録されていないかチェックし、あればそれを削除する。
これでもう登録はすんだので*.dnscheckからdns3.example.net.に変更してもらう。（負荷的な意味なので必須という程でもない。）
委任元のNSが正しく自社のdns*.example.net.を指している限り、アカウントとドメインの紐付けは正しい。
紐付けの確認が必要なときは、上位レジストラのDNSに一回クエリして確認するだけで足りる。
Out. アカウントがドメインを他に持ち出す場合
出来れば連絡が欲しいがそんなものしてくれない顧客も多いだろう。
正しく設定されたサーバは委任元DNSのNSレコードの変更に追従してくれるので、業者のdns1〜3へのアクセスはなくなりただ事業者のデータベースの中に残るだけなので、しばらくはそのままで問題ない。
次にドメインとアカウントの紐付けの確認が必要になった時、上位レジストラにNSレコードをクエリしてNSが変わっていることに気づくから、その際に除去できる。
もちろん、lameになっていることに違いはないので、定期的にチェックして除去すべきだろう。
また、正しくない設定の不味いデュアルロールDNSを立てていると、中の人が新しいNSにアクセスできなくなる
上記のような確認を怠ると、ヒトのドメインを勝手に登録できてしまう某社のような共有ホスティングが出来上がる。
委任元のNSが正しく自社のdns*.example.net.を指している限り、アカウントとドメインの紐付けは正しい。
紐付けの確認が必要なときは、上位レジストラのDNSに一回クエリして確認するだけで足りる。
出来れば連絡が欲しいがそんなものしてくれない顧客も多いだろう。
次にドメインとアカウントの紐付けの確認が必要になった時、上位レジストラにNSレコードをクエリしてNSが変わっていることに気づくから、その際に除去できる。
また、正しくない設定の不味いデュアルロールDNSを立てていると、中の人が新しいNSにアクセスできなくなる
abcdef.domaincheck.example.net
とかを追加する都度に、（レジストリによって違うかもしれないけど）
そいつのホスト情報の登録が必要ですね。
ま、登録すれば良いといえば良いのですが、、、、
ここ心許ないです。
「正しく設定されたサーバは委任元DNSのNSレコードの変更に追従してくれるので、業者のdns1〜3へのアクセスはなくなりただ事業者のデータベースの中に残るだけなので、しばらくはそのままで問題ない」
TTLが切れた時点でドメイン名でのアクセスができなくなり、IP直打ちのアクセスになります。万一それが問題になるなら、それはドメインと関係なくIPレベルで対策しなければならないのでナンセンスです。