1. DNS/リゾルバー/動作
リゾルバーの動作はバラバラ: /dnscache
/cf1111.tcpreplay.net /tkix.net
ひとつのリゾルバーの動作を理解(それも無理かと思うが)したところでDNSを分かったつもりになっても、 別のリゾルバーを使ってみれば別の動作をすることのに気付くだろう。
例えば、どういうNSがキャッシュされるか、など。
RFC 1035 7章 http://dnsdoc.qmail.jp/rfc1035/chapter7.html
- RFC 2181 疑問を部分的には解消したが、新たな問題も。
/qname-minimisation により、リゾルバーの動作は変わる。
DNS/gTLD/sharp/jp.sharp をどう扱うのがいいか。
Route53 のように乗取が実行しやすいサービスは注意が必要だ。
2. メッセージ
3. query
どこになにを問い合わせるか。それが問題だ。 qname minimisation
3.1. 受け入れ
基本はどんな問い合わせ(query)も受け入れる。(open resolverでなければ）
3.2. 送出
受け取った問い合わせに対して、返答するのに必要な情報はなにか。
- 場合によっては、問い合わせを送りだす。
/サーバへの問い合わせ 毒盛を困難にするための工夫も検討されている。
3.3. 返答
/サーバからの返答の受け入れ 検査するのはtransaction ID だけではない。
3.4. キャッシュ
/サーバからの返答のキャッシュ 原則は answer section のRRsetだけ, TTLの扱い
- 委譲返答を受け取ると、
/NSレコードが重要
否定返答なども記録される。
3.5. 返答
/返答 キャッシュサーバが返すもの
4. 基礎になる概念
/RRSetsの扱い 資源レコード集合
/RRSet中の資源レコードのTTL RFC2181 5.2.
5. 毒盛対策
現在に実装は以下の原則を守っていない。
キャッシュにあるレコードを優先する。 /移転インジェクション 排除
TTLはdelegateされている期限を守る。(rootから引き継ぐ）/GhostDomainNames 排除
NXDomain/NoData返答中のSOAレコードから得られるzone cuts不在情報を使う。/委譲毒 排除
delegation返答を除いて、Authority/Additionl Sectionは信用しない。/移転毒 排除
- これによる不利益は多少の余分なquery(NSレコードに設定されたTTL時間に一度）発生だが、大したことはない。
- このことを示す必要があるが。 あるいは攻撃を監視しておき、攻撃が行われていることが分かった時点で、警戒モードに移るとかも可能だ。
delegation返答を得た場合には、Nonce付きの問い合わせ直しを行って、確認する。
- 確認できたら、本来のゾーンサーバからNS/Aを取り込みなおす。
-- ToshinoriMaeno 2017-02-08 19:40:08