[書き起こし]親の心子知らず？委任にまつわる諸問題について考える 〜ランチのおともにDNS〜 (5)

ここからの3つの特徴(5-7)は...

と、ここまでは、こんなものかなぁと思うのですが、ここから三つが大きなポイントとなります。

(5)から(7)は、場合によっては設計や仕様をミスってしまったのかなとか、こういう風にすることなかったのにな、ということをやってしまったので、複雑に"なってしまった"特徴です。

上手く設計すれば、みんな苦労しなくて済んだかも知れないですね。 で、DNSが生まれながらに背負ってしまった業といいますか、カルマということなのかなということです。

特徴(5):NSレコードで名前を指定

まず、特徴(5)ですが、これはもう私は200回ぐらい言っていることです（笑。 「NSレコードで名前を指定」というものです。

DNSでは、名前で委任先を指定しています。 名前で指定して、グルーレコードというのを貼付けるということになっているわけです。

で、これのために、委任の仕組みが複雑になってしまったわけです。 内部名のチェックをしなければなりませんし、そもそもグルーレコードをつけなければなりません。 外部名の場合は依存関係が他のドメイン名にも波及してしまって、状況によってはマズいことがおきます。 このように、委任の部分がトラブルや脆弱性を誘発する弱点になってしまったわけです。 NSで指定しているドメイン名を強制停止されてしまって、その事業者が管理しているドメイン名が全部使えなくなってしまう事件が今年ありました。 2005年には、visa.co.jpがドメイン名ハイジャック可能となってしまっていた問題がありました。

このことは、キャッシュポイズニングするときの標的にもなっています。 90年代にKashpureffという人が、アディショナルレコードをキャッシュポイズニングすることで、alternicというところにみんなを誘導するということをやったことがありました。 あと、カミンスキー型攻撃というのも、やはりこのNSレコードで委任している部分を狙って何かしようとするものです。

で、名前の委任先を名前で指定するというのは、そもそも不自然なんですね。 普通こういうのを解決しようとする人は、下のレイヤーで解決しようとするので、こういう設計をしないと思うんですよね。 で、かつ、外部名も指定可能にしてしまったので、このような禍根を産んでしまったんですね。

禍根というのは、災いの元になるわけですが、ただ、この設計の採用には深ーい理由があったわけなんですね。 でも、これに関しては、これだけで20分ぐらいかかるので、省略とさせて頂きまして、どうすれば良かったのかなと思うわけです。 たとえば、NSIPとかNSIP6とかのようにIPアドレスで指定すれば、こういうことは起きなかった気もしています。

特徴(6):委任情報と権威情報を同種のリソースレコードで指定

次は特徴(6)です。 委任情報と権威情報をNSで指定しているということで、同じリソースレコードを使っているんですね。 そうすると、子供のNSがどうして必要なのかとか、親と子のNSが違っているときはどうするのかとか、そもそもどちらを優先すべきなのかなど、そういった誤解や混乱を招きやすいわけです。

それから、幽霊ドメイン名脆弱性のような弱点が生まれる原因になってしまったりもするわけです。 ということで、やっぱり、これも、親が「子のNS」ということで「CNS(Child NS)のようなNSとは別の専用のレコードを作って委任を示して、子供側は権威をNSでやるとしていれば、どっちがどっちであるのかということがレコードで明確になるので、良かったのかも知れないと思います。