1. DNS/リゾルバー/計画
| /qname_minimisation /response /rfc要請 /毒盛対策 |
Contents
DNS/リゾルバーにある要件を実施する。
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.
"""
2. 実装項目
優先
後回しか。
- qname randomization 0x20
ひとつの問い合わせを回答するまでは次の問い合わせは受け付けない。
ローカルに解決すべき対象
- private addressの逆引き
3. データ構造
/data-structure RRSet キャッシュ
- zone毎に分けるべきかも; 階層を反映させるのか。
- リゾルバーの目標はドメイン名空間の再現だと思う。
TTLの管理
- ヒットしたときに期限内かどうかを検査するだけですめばいいのだが。
Ghost Domain Names脆弱性で明らかにされたにも拘らず、 消滅したドメインのレコードを残すリゾルバーがありそうだ。
- 根本的にはゾーンサーバーの返すTTLを見直す必要があるが、
- 当面は委譲する権限のあるサーバからのTTLを超えたTTLは認めないという方針でいく。
zone cuts キャッシュ
否定返答キャッシュ
- レコード不在のキャッシュ
- ゾーン不在のキャッシュ
Knot resolverはpacketキャッシュを持っているが、必要か。
4. 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を確認しながら降下
- このときにキャッシュの上書きが行われるか。
- zone cutsを別管理していれば、zone cutsの削除で対応するのがよさそう。
5. response 処理
- delegation返答を疑え。
毒盛対策を中心に考える。特にゾーンサーバからの不正なデータを除去する。
- Kaminsky流の攻撃でも、NS毒盛やCNAME毒盛が排除できることを目標とする。
6. cache overwrite
RFC2181にあるような判断を避けるための原則
- キャッシュになにを置くの判断が問題だ。
特に(権威のない）delegation返答はキャッシュしないというのが大事だと思う。
- nonceつきの再問い合わせのあと、権威サーバに問い合わせしたものをキャッシュにいれる。 問題はTTLだ。Ghost Domain Names を発生させないための工夫が必要になる。
-- ToshinoriMaeno 2016-10-16 11:37:45