DNSのRFCの問題点いくつか

RFC1034当時の記述を見ると、当時の想定と現在の実情の差異でセキュリティ上問題になる点がいくつかある。

権威のあるレコードに加え、権威を持たないレコードも追加で返すことを許容し、推奨してしまった。
当時は、あるゾーンについて権威のあるサーバは、暗黙に完全に信頼できると考えられていて、権威サーバへのリゾルバ・キャッシュ機能を信用して負荷分散してしまえる、と考えられていたようだ。推奨されるリゾルバの挙動には、単に権威のあるサーバや、ヒントとして設定されているリゾルバなりから返答を受け取ったら、（文法・リクエストID一致のセキュリティチェックをせず、）ユーザに返しキャッシュに入れる。と書いてある。

現在では、権威のあるサーバが（乗っ取りやポイズニングを含め）悪意を含んだ時に、委任元がそれを検知して排除するまでの時間差が十分ある。権威のあるレコード以外を破棄するか何らかの信頼性評価の後に返答し、リゾルバもそれをチェックすべきと定義するべきだった。

信頼済みサーバと権威の階層化を明確に定義しなかった

信頼出来るサーバ、例えば（程度によるが）DHCPの指定DNSサーバや、ISPのDNSサーバーや、ルートサーバは信頼して良いはずだ。
もしリゾルバのアルゴリズムに、信頼済みサーバを切り分けるポリシーが最初から定義されていれば、それらから返ってくる回答はそれがAdditionalであっても信頼してキャッシュしてしまって良く、それ以外は破棄する実装の指標が明示できた。
そうすればキャッシュの挙動がバージョンごとに変わるなんてこともなかったのではないか？

また、権威サーバはよりルートに近いほうがより高い権威があると定義されていれば、2つの異なるゾーンが権威を持ちうるNSレコード・グルーレコードの優先順が明示でき、浸透言うな（3）のようなNSレコードキャッシュの不用意な更新はRFC由来でなくただの実装ミスのバグと言えた。