## page was renamed from DNS/実装/リゾルバー計画 == DNS/リゾルバー/計画 == <> <> [[DNS/リゾルバー]]にある要件を実施する。 [[DNS/実装/python/dnslib/リゾルバー]] python/dnslibの存在を知ったおかげで、ゾーンサーバーの骨格ができてきた。 　毒入の返答を返すのが簡単にできる。ｗ そこで、そろそろリゾルバーを作り始める。（目的は毒盛対策だ） 　　DNSSECは扱わない。 [[DNS/dnscache]] [[http://djbdns.qmail.jp/djbdns/dnscache.html]] https://github.com/paulchakravarti/dnslib/blob/master/dnslib/server.py {{{ >>> resolver = BaseResolver() >>> logger = DNSLogger(prefix=False) >>> server = DNSServer(resolver,port=8053,address="localhost",logger=logger) >>> server.start_thread() >>> q = DNSRecord.question("abc.def") >>> a = q.send("localhost",8053) }}} {{{ class BaseResolver(object): """ Base resolver implementation. Provides 'resolve' method which is called by DNSHandler with the decode request (DNSRecord instance) and returns a DNSRecord instance as reply. In most cases you should be able to create a custom resolver by just replacing the resolve method with appropriate resolver code for application (see fixedresolver/zoneresolver/shellresolver for examples) Note that a single instance is used by all DNSHandler instances so need to consider blocking & thread safety. """ }}} == 実装項目 == 優先 1. [[/毒盛対策]] 1. [[/qname_minimisation]] RFC 後回しか。 2. qname randomization 0x20 ひとつの問い合わせを回答するまでは次の問い合わせは受け付けない。 ローカルに解決すべき対象 　private addressの逆引き [[/rfc要請]] == データ構造 == [[/data-structure]] RRSet キャッシュ 　zone毎に分けるべきかも; 階層を反映させるのか。 　　リゾルバーの目標はドメイン名空間の再現だと思う。 TTLの管理 　ヒットしたときに期限内かどうかを検査するだけですめばいいのだが。 Ghost Domain Names脆弱性で明らかにされたにも拘らず、 消滅したドメインのレコードを残すリゾルバーがありそうだ。 　根本的にはゾーンサーバーの返すTTLを見直す必要があるが、 　　当面は委譲する権限のあるサーバからのTTLを超えたTTLは認めないという方針でいく。 zone cuts キャッシュ 否定返答キャッシュ * レコード不在のキャッシュ * ゾーン不在のキャッシュ Knot resolverはpacketキャッシュを持っているが、必要か。 == query生成 == [[/query]] どこになにを問い合わせるか。 root-serverから順に問い合わせドメイン名に到達するまでのゾーンをたどる。 　　いきなりレコード(キャッシュ）を探すことはしない。 　これにより、上位からの委譲が期限切れになった場合、 　　下部のレコードも期限切れ扱いすることができる。（ゾーン単位の管理を前提に） 　 dnscacheに倣うもの： {{{ 内部的にlocalhostを処理します。 127.0.0.1 という A レコードがあったものとします。 内部的に1.0.0.127.in-addr.arpaを処理します。 localhost という PTR レコードがあったものとします。 ドットつき 10進表記のドメイン名を内部処理します。 例えば、ドメイン名 192.48.96.2 には 192.48.96.2 という A レコードを与えます。 }}} qname minimisationの原則： 　よくある実装のようになんでもroot-serversに投げて、 　delegation chainをたどるということはしない。 zone cutsの存在を調べながら、降下していくことにする。（qname minimisation) 　zone cuts 確認方法 　　上位ドメインから末端へ; TTLを確認しながら降下 　上位のNSがキャッシュになかった場合、下位のNSがキャッシュにあったとしても使わない。　　 　　このときにキャッシュの上書きが行われるか。 　　　 zone cutsを別管理していれば、zone cutsの削除で対応するのがよさそう。 　つまり、zone cutsは集合ではなく、ドメイン名の木構造を反映するものがよい。 == response 処理 == [[/respense]] 　delegation返答を疑え。 毒盛対策を中心に考える。特にゾーンサーバからの不正なデータを除去する。 　Kaminsky流の攻撃でも、NS毒盛やCNAME毒盛が排除できることを目標とする。 == cache overwrite == RFC2181にあるような判断を避けるための原則 　キャッシュになにを置くの判断が問題だ。 特に(権威のない）delegation返答はキャッシュしないというのが大事だと思う。 　nonceつきの再問い合わせのあと、権威サーバに問い合わせしたものをキャッシュにいれる。 　問題はTTLだ。Ghost Domain Names を発生させないための工夫が必要になる。 -- ToshinoriMaeno <>