共用DNSでのゾーンのチェックと権威

本来、サブゾーンを作るには、たとえ同じDNSサーバであって親ゾーンに対応する委任元NSレコードを必要とするが、少なくともBIND9はこれを確認しない。
例えば、親ゾーンが同一のBINDインスタンスに設定されているにも関わらず、NSレコードでの委任が記述されていない（擬似的な）サブゾーンをゾーン設定ファイルとして受け付ける。そして、一旦登録されてしえば、RFCどおり、よりリクエストに近いサブゾーン側を優先して解答する。

したがって、共用DNSサーバ管理者がユーザーの権限をチェックせずユーザーからのゾーン追加要求を受け入れると、同じ共用DNSサーバの他のゾーンのサブゾーンを乗っ取ることが出来る。つまりさくらの共用DNS問題になる。
これ自体は、BINDのnamed-checkconfの実装が、ゾーン登録時に委任関係の矛盾をチェックするよう実装してあれば問題はなかったと思われる。

ただし根本的には、共用DNSの管理者が、要求したユーザーがそのドメインの所有者であることを確認することが必要になる。
レジストラが共用DNSを運営していて、ドメイン登録管理アカウントと連携しているなら、ユーザがドメインの所有者であることは自明だが、外部から共用DNSへ受け入れる場合、確認は非常に困難になる。

本来、悪意あるゾーンが（他の登録済みゾーンと衝突しない限り）勝手に登録されていても、自身が権威あるDNSサーバと解答するだけでだれもアクセスしないはずなので問題は無さそう（追加セクションでのポイズニング問題は別として）に見えるが、ちょうどDNSサーバを移転しようとしていたり、ゾーンの衝突を確認せず二重登録を許容していたりすると、乗っ取りが可能になる。

簡易な運用では、ユーザーの要求をチェックせずとにかく受け入れ、しばらくしても委任元のNSレコードが対照共用DNSサーバを向かない場合は不正として削除する。
これは無料の共用DNSや、共用ウェブホスティングなどに付属する（無償オプションとしての）共用DNSで使われている。
たとえばvalue-domainの無料DNSはこの運用だった。
この方法では、応答の権威セクションや追加セクションを無制限に信頼する古いリゾルバ実装にポイズニングしうる。

より安全な運用では、ユーザがドメインの（レジストラに承認された）所有者であることを確認する必要がある。
それは委任元の（tldレジストリのDNSサーバ上の）NSレコードを編集する権限があるかでチェックすることができるのは、以前書いた。
もちろん、登録済みの他のユーザーのゾーンと矛盾がないか、といったチェックは依然必要だが。

レジストリがWhoisデータベースの一括ダウンロードといった提供をすることが無い限り、このチェック以外確認のしようが無いと考えている。