= DNS/リゾルバー/機能 = <> RFCに準拠した実装を目指すのが重要 既存のリゾルバーを論拠にするのでは不十分です。 返答の選択が最重要 1. 返答中の項目 2. 毒返答の破棄 == 機能 == 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 <> 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 ---- == 毒盛防衛機能 == 　最近の話題ではフラグメント化された返答を破棄するとか。 　NXDOMAIN返答を活用した毒の排除(偽委譲返答など) キャッシュ内のレコードを優先するという原則の重要性を強調しておこう。-- ToshinoriMaeno <> リゾルバーだけでは偽情報を排除できない。-- ToshinoriMaeno <> 　ゾーンサーバー側でウソの情報を返すのだから。(共用DNSサービスの闇) ==　周辺の設定 == IPアドレス、port、MTU == 雑感 == いまなお生きている：　毒排除には無益 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日