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