1. DNS/リゾルバー/機能

RFCに準拠した実装を目指すのが重要

既存のリゾルバーを論拠にするのでは不十分です。

返答の選択が最重要

1. 返答中の項目
2. 毒返答の破棄

1.1. 機能

1. 問合せ元制限(アクセス)
   • TCP, DoH, QUIC, rate limiting も、query format check
2. 問合せ先制限
   • ローカルゾーン、ブロッキング、フィルタリング
3. 問合せの生成(順序)　TCP DoH
   • キャッシュの棚卸し、 qname minimisation, cookie,
     • zone cut query, nonce
4. 問合せの送出
   • なにをどこにどう問い合わせるかの決定(もっとも重要か) 、問合せ先の決定,
5. 返答の処理
   • 受け入れ項目の決定、キャッシュとの整合性、キャッシュの上書きは無用
   • キャッシュ(TTL) cache-max-ttl, cache-min-ttl
   • CNAME毒排除強化
6. キャッキュ管理、事前問合せ
7. 返答を送り出すこと
   • 委譲返答にあったNS, A などを返答に用いるか。(用いるべきではないと考える。
     • minimal response

-- ToshinoriMaeno 2019-08-23 03:25:51

https://twitter.com/search?q=%E3%83%AA%E3%82%BE%E3%83%AB%E3%83%90%E3%83%BC%E3%81%AE%E5%8B%95%E4%BD%9C&src=typed_query&f=live

1.2. 毒盛防衛機能

• 最近の話題ではフラグメント化された返答を破棄するとか。 NXDOMAIN返答を活用した毒の排除(偽委譲返答など)

キャッシュ内のレコードを優先するという原則の重要性を強調しておこう。-- ToshinoriMaeno 2019-08-24 06:43:14

リゾルバーだけでは偽情報を排除できない。-- ToshinoriMaeno 2019-08-27 13:22:45

• ゾーンサーバー側でウソの情報を返すのだから。(共用DNSサービスの闇)

1.3. 周辺の設定

IPアドレス、port、MTU

1.4. 雑感

いまなお生きている：　毒排除には無益 https://tools.ietf.org/html/rfc2181

https://twitter.com/beyondDNS/status/393051359328489472

リゾルバー（キャッシュ）がどう動作すべきかを規程する（できる）としたら、法で強制する方法しかなさそう。 （でも、現在は共用リゾルバーがどう動作すべきかの基準すらないらしい。） 午前1:28 · 2013年10月24日

すべてのリゾルバーが同じ振る舞いをするわけではない。（設定によっても異なるし、実装によっても異なる）

にもかかわらず、すべてのリゾルバーについての動作であるかのように書いてある文書がある。（まゆつば 午前10:21 · 2017年8月3日

https://twitter.com/beyondDNS/status/421464603558563840 「グルーレコード」とか「委譲（委任）」のまともな定義（説明）がない状態で、どうやって正しく動作するリゾルバーが作れようか。（なんとなく使えているからいいや、というのがDNSらしい。） 午前11:12 · 2014年1月10日

https://twitter.com/beyondDNS/status/893104637024190465 DNSは（関連）RFCを全部しっかり読んでも分からないと思う。(読んだわけではない😍) リゾルバーの動作はmanを読んでもわからない。（現実のmanというのは説明ではないから） さて、どうすればDNS、DNSSECは理解できるのでしょう。 😱 午後10:41 · 2017年8月3日