1. DNS
DNS辞典を目指すwikiです。 /項目 右上の検索ボタン(タイトル、テキスト)を活用してください。
twitter: beyondDNS https://djbdns.qmail.jp/ https://dnsdoc.qmail.jp/
Contents
1.1. 特長
DNSは「ドメイン名空間(集まり)｣を「共有･統合｣するための仕組みです。
- ドメイン名には属性を持たせられます。
ドメイン名空間は木構造の階層構造をしています。 ドメイン名の階層にしたがって、分割･管理されています。 とはいうものの、実態はTLD名による分割がほとんどです。
/ドメイン名, /ゾーン, /ドメイン名登録 などに分けて、説明します。
｢分散｣、｢統合｣の仕組みが｢委任･委譲｣です。
それぞれの｢ゾーン｣を管理しているのが権威サーバーです。
ドメイン名空間内の検索を受け持つのがリゾルバーです。
/リゾルバー, ｢問い合わせ｣と｢返答｣の/メッセージの形式も重要です。
1.2. DNSには危険がいっぱい
DNSの基礎はDNS/RFC/1034に書かれています。-- ToshinoriMaeno 2019-07-28 02:40:07
- 実験的な試みのまま、今に至っています。
運用に依存しています。 脆弱性に目をむけないまま、利用は拡大してきました。 大部分のひとはDNSの正しい知識を求めていない。目先の問題を解決する方法をさがしているだけです。
1.3. 用語: 混乱 バベル
DNSの世界ではさまざまな用語が使われています。ひとにより意味するものが違ったりします。
- そこで重要なのが、各人が言葉をどういう意味で使っているか、確認することです。
そして、自分はどういう意味で使っているかを説明できるようにすることです。
1.4. ドメイン名
中国では「域名」と言われる。 DNSサーバーは服务器だが、サーバーは日本語として通じる。 /中国語
分かりやすいか: https://www.kagoya.jp/howto/webhomepage/01/
1.5. 資源レコード
ドメイン名の属性
1.6. 分散管理
ドメイン名の集まりはゾーンに分けられて管理される。
DNS/RFC/1034/4 ゾーン 登録あるいは委譲
1.6.1. 統合・共有
1.7. 名前解決
名前解決は/リゾルバー が行います。 DNS/RFC/1034/5
1.8. セキュリティ
1.9. 用語
DNS Terminology https://www.ietf.org/rfc/rfc8499.txt
1.10. RFC
ドメイン名の「階層構造」と分割管理を理解すれば、DNSを少しは分かります。-- ToshinoriMaeno 2019-05-28 23:39:06
/運用 が鍵になります。
/セキュリティがおろそかにされてきた世界、問題が山積している。
DNSSECは一部のDNSレコードの正当性だけを確認できる。運用は非常に大変だ。
「未熟」正しい説明はまだない。やさしい説明は間違いが多い。(「/浸透」など)
DNSに代わるなにかが必要だが、いつになることか。それまでどうするのか。
DNS/architecture /実装 /歴史 /メモ /security /用語
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サーバーの移転には時間がかかります。
2. DNS基礎
A warm welcome to DNS https://powerdns.org/hello-dns/
2.1. 定義
/定義 DNSはDNS/1/ドメイン名の集まりを統合管理する仕組みである。
周りのものには好きな名前をつけたい。 各自が好き勝手な名前を使うのでは他人との情報交換で支障がでる。
DNSは名前(DNS/1/ドメイン名）の衝突を避けるための仕組みである。
DOMAIN NAMES - CONCEPTS AND FACILITIES DNS/RFC/1034
2.1.1. ゾーン
ぶつかりの生じない（統一された）DNS/1/名前空間を「分散管理」（共存させる）するための仕組みである。
-> delegation
それぞれの名前空間は「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.
2.1.2. 属性
ドメイン名には属性（DNS資源レコードと呼ばれる）をもたせることができる。
必要なDNS/1/資源レコードを検索する仕組みがある。これを実装するのが、リゾルバーである。
検索と結果にはDNS/1/messagesという形式が使われる。
2.2. 課題
https://www.slideserve.com/deon/11-dns-domain-name-system
新TLDのもたらす脅威 https://twitter.com/OrangeMorishita/status/735020472207695872?lang=ja
動くかどうかさえはっきりしていなかった。セキュリティは考慮されていない。（RFC 1034)
2.3. 運用
3. DNSは脆弱である
- UDPを使うことによる脆弱性を知る必要があります。
DNS/返答 を分類してみます。
Kaminsky手法を使ったキャッシュ/毒盛には十分な対策があります。
- ただし、対策はあるのに、ほとんど使われていません。 なぜかはわかりません。DNSSECを広めたいからか、関心がないからでしょう。
30年以上使われているDNSを/JPRS/未熟なDNSと言っていていいのでしょうか。
/砂上の楼閣 あるいは成長の望めない代物ではないでしょうか。
脆弱性をすべて仕様のせいにしてしまっていいのでしょうか。
DNSに深入りしてもいいことはないのですが、 深入りせずに問題点を理解するのも難しいと思います。
- きちんと説明できるほどのDNSに詳しいひとがいないのでしょう。
- 時間をかければかけるほど、抜けづらくなるでしょう。
すぐには代わりがないというのも状況を悪くしています。
-- ToshinoriMaeno 2016-02-09 11:17:01
重要項目の一覧は/索引を見てください。
3.1. 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
3.2. レジストリ
DNSゾーンサーバーを移転するときに、いわゆる「浸透待ち」時間が発生するのは、
- 委譲・委任情報(NS)のTTLを短く設定できないように制約しているレジストリの責任が大きいと考える。
/基礎知識 /用語 /実装/未来はあるのか /JPRS/未熟なDNS (/用語/JPRS用語）
DNS入門 もどうぞ。/delagation-attack
議論 https://www.ietf.org/mail-archive/web/dnsop/current/maillist.html
3.3. レジストラ
JPドメインでは/レジストラは「指定事業者」と言い換えられています。
- 顧客の所有するドメインの管理情報を変更する権限をもつ業者です。
DNSサーバを提供する業者（DNSプロバイダ)とは概念的には別ものです。
- 同じであるかのような説明をしている業者は信用してはなりません。 レジストラを兼ねているとしても、分けて説明している業者を選びましょう。
レジストラの移転についてはまずはレジストリ(JPRS)の説明から読んでください。
レジストラによるDNS情報の書き換えという事件もありました。（権利者の同意なし）
レジストラに侵入されて、DNS情報を書き換える事件も度々起きています。
/レジストリにも侵入されたような報道もありましたが、詳しい説明はありません。（それがDNSという業界）
-- ToshinoriMaeno 2015-07-06 01:33:26
3.4. DNS プロバイダ
DNS/プロバイダのサーバの振る舞いをまとめてみました。 DNS/旧サーバが古い返事を返す
あらためて、DNS/管理者への警告とお願いを書きます。-- ToshinoriMaeno 2010-09-12 01:49:10
レンタルサーバ/DNSサーバ引越手順をまとめてみました。
- 「浸透遅延」という都市伝説をさけるための手順を作成中です。
DNS/引越もどうぞ。 /非協力的事業者 には注意が必要です。
3.5. 共用DNSゾーンサービスは危険
DNS/脅威/共用ゾーンサービス/さくら などの共用DNSサービスでの脆弱性が指摘されました。 (2012年)
- JPRSからも注意喚起が出ています。(6/22, 7/04)
さくらは修正すると言っていましたが、部分的な対応でしかありません。
- その他の業者については対応するかどうかも広報されてしません。
-- ToshinoriMaeno 2012-12-13 23:49:46
DNS/ホスティング とも呼ばれる。
3.6. DNS/TCPはmust
あなたのDNSはTCPをサポートしていますか。https://tools.ietf.org/html/rfc7766 DNS/RFC/RFC5966によって、DNSでTCPを使えるようにしなければならないとなっています。
- キャッシュサーバへの毒盛はUDPの送信アドレス詐称を利用しています。TCPなら詐称は難しくなります。
3.7. リゾルバー
3.7.1. DNSキャッシュ毒盛
DNS/毒盛再考 : 現状でのDNSキャッシュサーバには毒盛される危険があります。/毒盛/入門
たとえば、 DNS/毒盛/co.jp などは比較的容易な状態です。
2008年に公表された手法を使ってco.jp などに毒盛可能です。(2014)
Kaminsky型攻撃に対しては簡単で有効な対策を見つけました。実装が待たれます。 -- ToshinoriMaeno 2016-05-14 23:54:20
4. DNSSECは割にあわない
DNSSECは手間がかかるわりにDNS/キャッシュ毒盛/対策としては十分な効果がのぞめません。
DNSSEC対応したキャッシュだって毒を盛られます。共用のキャッシュサーバは特に危険です。
4.1. DNSCurve を使ってみよう
DNSCurve は DNS query/response を暗号化することで、第三者による毒盛を防ぎます。
5. DNS サーバ運用の惨状
コンテンツサーバの設定を調べてみます。 /設定
/おかしな設定のプロバイダ-- 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 型攻撃などの事件がないと、 改善勧告すら無視されるのが現状のようです。
6. 関連情報
DNSアプライアンス http://thinkit.co.jp/article/1134/1
Internet -- http://risks.qmail.jp さまざまな危険 --