DNS/脆弱性/未整理について、ここに記述してください。 [[DNS]] の部分コピー <> = DNSは脆弱である = [[/脆弱性]]を知ることが重要です。　[[/脆弱性入門]] [[/歴史]] UDPを使うことによる脆弱性を知る必要があります。 [[/キャッシュ毒盛]] [[DNS/返答]] を分類してみます。 Kaminsky手法を使ったキャッシュ[[/毒盛]]には十分な対策があります。 ただし、対策はあるのに、ほとんど使われていません。 　　なぜかはわかりません。DNSSECを広めたいからか、関心がないからでしょう。 30年以上使われているDNSを[[/JPRS/未熟なDNS]]と言っていていいのでしょうか。 [[/砂上の楼閣]] あるいは成長の望めない代物ではないでしょうか。 脆弱性をすべて仕様のせいにしてしまっていいのでしょうか。 DNSに深入りしてもいいことはないのですが、 深入りせずに問題点を理解するのも難しいと思います。 　きちんと説明できるほどのDNSに詳しいひとがいないのでしょう。 　　時間をかければかけるほど、抜けづらくなるでしょう。 すぐには代わりがないというのも状況を悪くしています。 -- ToshinoriMaeno <> 重要項目の一覧は[[/索引]]を見てください。 [[/JP-DNS]] == Verisign 管理の不良 == [[/Verisign]] は root-servers の運用まで任されている企業ですが、その運用はお粗末です。 * UDP check sum 0 問題 2016-01 から * [[/netとcomの相互依存]] 2016-01 から 　glue ではないAdditionalを受け入れないと動作しない。[[/glueなし運用]] 日本での規制 : https://www.nic.ad.jp/ja/materials/after/20160318/20160318-kanesaka.pdf == レジストリ == DNSゾーンサーバーを移転するときに、いわゆる「浸透待ち」時間が発生するのは、 委譲・委任情報(NS)のTTLを短く設定できないように制約しているレジストリの責任が大きいと考える。 ---- [[/基礎知識]] [[/用語]] [[/実装]][[/未来はあるのか]] [[/JPRS/未熟なDNS]] ([[/用語/JPRS用語]]） [[DNS入門]] もどうぞ。[[/delagation-attack]] 議論 https://www.ietf.org/mail-archive/web/dnsop/current/maillist.html [[/draft]] [[/DNSCrypto]] [[/2015]] == レジストラ == JPドメインでは[[/レジストラ]]は「指定事業者」と言い換えられています。 　顧客の所有するドメインの管理情報を変更する権限をもつ業者です。 DNSサーバを提供する業者（DNSプロバイダ)とは概念的には別ものです。 　同じであるかのような説明をしている業者は信用してはなりません。 　レジストラを兼ねているとしても、分けて説明している業者を選びましょう。 レジストラの移転についてはまずはレジストリ(JPRS)の説明から読んでください。 レジストラによるDNS情報の書き換えという事件もありました。（権利者の同意なし） レジストラに侵入されて、DNS情報を書き換える事件も度々起きています。 　[[/レジストリ]]にも侵入されたような報道もありましたが、詳しい説明はありません。（それがDNSという業界） -- ToshinoriMaeno <> == DNS プロバイダ == [[DNS/プロバイダ]]のサーバの振る舞いをまとめてみました。 [[DNS/旧サーバが古い返事を返す]] あらためて、[[DNS/管理者への警告とお願い]]を書きます。-- ToshinoriMaeno <> [[レンタルサーバ/DNSサーバ引越]]手順をまとめてみました。 　「浸透遅延」という都市伝説をさけるための手順を作成中です。 [[DNS/引越]]もどうぞ。　 [[/非協力的事業者]] には注意が必要です。 == 共用DNSゾーンサービスは危険 == [[DNS/脅威/共用ゾーンサービス/さくら]] などの[[DNS/サービス|共用DNSサービス]]での脆弱性が指摘されました。 　JPRSからも注意喚起が出ています。(6/22, 7/04) さくらは修正すると言っていましたが、部分的な対応でしかありません。 その他の業者については対応するかどうかも広報されてしません。 -- ToshinoriMaeno <> [[DNS/ホスティング]] とも呼ばれる。 == DNS/TCPはmust == あなたのDNSは[[DNS/TCP|TCP]]をサポートしていますか。https://tools.ietf.org/html/rfc7766 [[DNS/RFC/RFC5966]]によって、DNSでTCPを使えるようにしなければならないとなっています。 キャッシュサーバへの毒盛はUDPの送信アドレス詐称を利用しています。TCPなら詐称は難しくなります。 = DNSSECは割にあわない = [[DNSSEC]]は手間がかかるわりに[[DNS/キャッシュ毒盛/対策]]としては十分な効果がのぞめません。 　https://jprs.jp/doc/dnssec/jp-dps-jpn.html DNSSEC対応したキャッシュだって毒を盛られます。共用のキャッシュサーバは特に危険です。 == DNSCurve を使ってみよう == [[DNSCurve]] は DNS query/response を暗号化することで、第三者による毒盛を防ぎます。 = リゾルバー = [[DNS/リゾルバー]] == DNSキャッシュ毒盛 == [[DNS/毒盛再考]] : 現状でのDNSキャッシュサーバには毒盛される危険があります。[[/毒盛/入門]] 　たとえば、 [[DNS/毒盛/co.jp]] などは比較的容易な状態です。 {{{ 　2008年に公表された手法を使ってco.jp などに毒盛可能です。(2014) }}} Kaminsky型攻撃に対しては簡単で有効な対策を見つけました。実装が待たれます。 -- ToshinoriMaeno <> [[/キャッシュサーバへの毒盛]]