#acl ToshinoriMaeno:admin,read,write,rename,delete Known:read,write All:read #pragma section-numbers on #format wiki = DNS = DNS辞典を目指すwikiです。 [[/項目]] 右上の'''検索ボタン'''(タイトル、テキスト)を活用してください。 twitter: beyondDNS https://djbdns.qmail.jp/ https://dnsdoc.qmail.jp/ [[/基礎]] [[/入門]] [[DNS入門]] [[/ゾーン/設定]] [[/毒盛]] [[/NEWS]] [[/next_generation]] [[/歴史]] <> [[/項目一覧]] [[/難しい]] == 特長 == DNSは「ドメイン名空間(集まり)｣を「共有･統合｣するための仕組みです。 ドメイン名には属性を持たせられます。 {{{ ドメイン名空間は木構造の階層構造をしています。 ドメイン名の階層にしたがって、分割･管理されています。 とはいうものの、実態はTLD名による分割がほとんどです。 }}} [[/ドメイン名]], [[/ゾーン]], [[/ドメイン名登録]] などに分けて、説明します。 {{{ ｢分散｣、｢統合｣の仕組みが｢委任･委譲｣です。 }}} [[/分散管理]] [[/統合]] [[/委任･委譲]] {{{ それぞれの｢ゾーン｣を管理しているのが権威サーバーです。 }}} [[/ゾーン]] [[/権威サーバー]] {{{ ドメイン名空間内の検索を受け持つのがリゾルバーです。 }}} [[/リゾルバー]], ｢問い合わせ｣と｢返答｣の[[/メッセージの形式]]も重要です。 == DNSには危険がいっぱい == [[/攻撃]] されやすい仕組みになっています。[[/セキュリティ]] [[DNSの基礎]]は[[DNS/RFC/1034]]に書かれています。-- ToshinoriMaeno <> 実験的な試みのまま、今に至っています。 {{{ 運用に依存しています。 脆弱性に目をむけないまま、利用は拡大してきました。 大部分のひとはDNSの正しい知識を求めていない。目先の問題を解決する方法をさがしているだけです。 }}} == 用語: 混乱 バベル == DNSの世界ではさまざまな用語が使われています。ひとにより意味するものが違ったりします。 そこで重要なのが、各人が言葉をどういう意味で使っているか、確認することです。 そして、自分はどういう意味で使っているかを説明できるようにすることです。 == ドメイン名 == [[DNS/RFC/1034/2]] [[DNS/RFC/1034/3]] 　中国では「域名」と言われる。　DNSサーバーは服务器だが、サーバーは日本語として通じる。　[[/中国語]] 分かりやすいか: https://www.kagoya.jp/howto/webhomepage/01/ == 資源レコード == ドメイン名の属性 == 分散管理 == ドメイン名の集まりはゾーンに分けられて管理される。 [[DNS/RFC/1034/4]] ゾーン 登録あるいは委譲 === 統合・共有 === == 名前解決 == 名前解決は[[/リゾルバー]] が行います。　[[DNS/RFC/1034/5]] リゾルバーは効率化のために、[[/キャッシュ]]を持ちます。 おもに[[/ゾーン]]情報をキャッシュに保持します。 == セキュリティ == [[/セキュリティ]] == 用語 == DNS Terminology https://www.ietf.org/rfc/rfc8499.txt == RFC == ---- ドメイン名の「階層構造」と分割管理を理解すれば、DNSを少しは分かります。-- ToshinoriMaeno <> [[/運用]] が鍵になります。 　[[/セキュリティ]]がおろそかにされてきた世界、問題が山積している。 DNSSECは一部のDNSレコードの正当性だけを確認できる。運用は非常に大変だ。 「未熟」正しい説明はまだない。やさしい説明は間違いが多い。(「[[/浸透]]」など) DNSに代わるなにかが必要だが、いつになることか。それまでどうするのか。 [[DNS/architecture]] [[/実装]] [[/歴史]] [[/メモ]] [[/security]] [[/用語]] [[http://twitter.com/beyondDNS|twitter:#beyondDNS]] ---- Domain Names Are Fading From User View 19 Apr, 2017 · by Karl Auerbach [[Cavebear]] DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look? https://tools.ietf.org/html/rfc8324 {{{ DNS Cookies, TCPを使おう。 DNSSECという複雑な仕組みはいらない。 DNSはそこそこ安全に使える。 }}} https://tools.ietf.org/html/rfc7766 privacyを気にするなら、qname minimisationを使いましょう。 DNSサーバーの移転には時間がかかります。 = DNS基礎 = A warm welcome to DNS https://powerdns.org/hello-dns/ == 定義 == [[/定義]]　DNSは[[DNS/1/ドメイン名]]の集まりを統合管理する仕組みである。 {{{ 周りのものには好きな名前をつけたい。 各自が好き勝手な名前を使うのでは他人との情報交換で支障がでる。 }}} DNSは名前([[DNS/1/ドメイン名]]）の衝突を避けるための仕組みである。 DOMAIN NAMES - CONCEPTS AND FACILITIES [[DNS/RFC/1034]] === ゾーン === ぶつかりの生じない（統一された）[[DNS/1/名前空間]]を「分散管理」（共存させる）するための仕組みである。 　-> delegation [[/基礎]] [[/parameters]] それぞれの名前空間は「[[DNS/1/ゾーン]]」と呼ばれる。 ゾーンは[[DNS/1/delegation]]によって、関連づけされる。 RFC 1034 2 DNS design goals {{{ The primary goal is a consistent name space which will be used for referring to resources. In order to avoid the problems caused by ad hoc encodings, names should not be required to contain network identifiers, addresses, routes, or similar information as part of the name. }}} === 属性 === ドメイン名には属性（DNS資源レコードと呼ばれる）をもたせることができる。 必要な[[DNS/1/資源レコード]]を検索する仕組みがある。これを実装するのが、リゾルバーである。 検索と結果には[[DNS/1/messages]]という形式が使われる。 [[/ゾーンサーバー]] [[/論文]]　[[/ネームサーバー]] == 課題 == [[/課題]] https://www.slideserve.com/deon/11-dns-domain-name-system 新TLDのもたらす脅威　https://twitter.com/OrangeMorishita/status/735020472207695872?lang=ja 動くかどうかさえはっきりしていなかった。セキュリティは考慮されていない。（RFC 1034) == 運用 == [[/管理]] [[/運用]] [[/運用/調査]] [[/JPRS/未熟なDNS]]　[[/2016]] = 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サービス]]での脆弱性が指摘されました。 (2012年) 　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なら詐称は難しくなります。 == リゾルバー == [[DNS/リゾルバー]] === DNSキャッシュ毒盛 === [[DNS/毒盛再考]] : 現状でのDNSキャッシュサーバには毒盛される危険があります。[[/毒盛/入門]] 　たとえば、 [[DNS/毒盛/co.jp]] などは比較的容易な状態です。 {{{ 　2008年に公表された手法を使ってco.jp などに毒盛可能です。(2014) }}} Kaminsky型攻撃に対しては簡単で有効な対策を見つけました。実装が待たれます。 -- ToshinoriMaeno <> [[/キャッシュサーバへの毒盛]] = DNSSECは割にあわない = [[DNSSEC]]は手間がかかるわりに[[DNS/キャッシュ毒盛/対策]]としては十分な効果がのぞめません。 　https://jprs.jp/doc/dnssec/jp-dps-jpn.html DNSSEC対応したキャッシュだって毒を盛られます。共用のキャッシュサーバは特に危険です。 == DNSCurve を使ってみよう == [[DNSCurve]] は DNS query/response を暗号化することで、第三者による毒盛を防ぎます。 = DNS サーバ運用の惨状 = コンテンツサーバの設定を調べてみます。 [[/設定]] * [[/おかしな設定のプロバイダ]]-- DnsJp:nicjpTLD.html JP ドメインサーバ * http://www.cerias.purdue.edu/weblogs/pmeunier/policies-law/post-38/ 穴を指摘することの危険性 いろんな設定をする人がいるものです。真似しないでくださいね。 DNS健全化タスクフォースというのがありましたが、 成果（報告）はあったのでしょうか。　http://www.nic.ad.jp/ja/newsletter/No24/063.html visa.co.jp 乗っ取り事件やKaminsky 型攻撃などの事件がないと、 改善勧告すら無視されるのが現状のようです。 = 関連情報 = [[DNS/資源レコード]] [[http://community.citrix.com/display/ns/How+GSLB+Works|How GSLB Works]] [[/links|関連情報]] -- [[/Faq]] -- [[/RFC]] * [[/国際化ドメイン名/トラブル]] * [[/IPv6関連情報]] DNSアプライアンス http://thinkit.co.jp/article/1134/1 ----- [[GlobalSecurity:Internet]] -- http://risks.qmail.jp さまざまな危険 --