= DNS/課題 = <> ---- <> [[DNS/Camel]] 整理できないままだが、はっきり言えるのはDNSを信用すると危険だということだ。 　DNSでなにを信用するかは自己責任だと言ってもよい。 　　つまりwebを見てもどこに連れていかれるかも常に注意していなければならないということだ。 -- ToshinoriMaeno <> 最大の問題は [[/運用]] である。 すべてが「運用」に任されている。その運用を支えるのは人だが、その「人」が育っていない。 　育てる方法もなさそう。 -- ToshinoriMaeno <> qname minimisation, minimal-responses, DNS over TCP/HTTP など多少の光も見えてはいる。 == ドメイン名利権 == ドメイン名という集中型の構造は利権と直結している。 　ICANNを始めとする原野商法が見える。 レジストラonamae.com の越権行為を黙認するJPRSレジストリ == 実装の脆弱性 == [[../脅威]] [[../脆弱性]] [[/Barwood]] のまとめ [[DNS/JPRS/未熟なDNS]] 2014年の話 (NS毒盛の再発見） [[/ひとが足りない]] JPRSが公表している内容にもいろいろ間違いがあるし、おかしな方向に誘導しようとしている記述もある。 　誤りを指摘しても、ほとんど無視されてきた。 なにを信用するかを含めて、自分で考えて判断することが重要だ。 === 複数ゾーンを抱えるゾーンサーバ === 特に系列にあるゾーンを抱えていると、いろいろ問題が発生する。-- ToshinoriMaeno <> さくらでの発覚; === DNSSECに依らない毒盛対策 === Kaminsky流の攻撃には[[/否定返答]]を利用した対策(2016年)ができるのに、実装したものは見当たらない。-- ToshinoriMaeno <> [[/キャッシュサーバにおけるNSレコードの取扱い]] == DNS/TCP == やっと、認知された。（UDPの使用をやめればいいのに） 　 性能の問題があるからと、パケット偽造しやすいUDPにこだわる。（安全性は？） UDP --> curvecp, dnscurve 毒盛対策 DNSの構造的問題 管理者の勝手な設定に警告する仕組みが必要だ。 [[/a.gtld-servers.net]] A レコードを得るには。com/net の相互参照