MoinQ: DNS/リゾルバー/動作

1. 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/リゾルバーでの対処

2. メッセージ

• DNS/1/messages DNS/RFC/1035

3. query

どこになにを問い合わせるか。それが問題だ。 qname minimisation

• /dnscache

3.1. 受け入れ

基本はどんな問い合わせ(query)も受け入れる。(open resolverでなければ）

3.2. 送出

受け取った問い合わせに対して、返答するのに必要な情報はなにか。

• 場合によっては、問い合わせを送りだす。

/サーバへの問い合わせ 毒盛を困難にするための工夫も検討されている。

3.3. 返答

/サーバからの返答の受け入れ　検査するのはtransaction ID　だけではない。

3.4. キャッシュ

/サーバからの返答のキャッシュ　原則は answer section のRRsetだけ, TTLの扱い

• 委譲返答を受け取ると、

  /NSレコードが重要

否定返答なども記録される。

3.5. 返答

/返答　キャッシュサーバが返すもの

/yatzの扱い

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

6. 実装例

/実装例