---- <> ---- == DNS/リゾルバー/要件 == <> <> ここで説明するものは[[DNS/RFC/1034/5]]や[[DNS/RFC/1035/7|RFC1035の動作例]]などとは異なる。 qname minimisationを採用しているリゾルバーの動作であり、[[/longest match]]ではない。 === 要件 === 0. 答えるべきqueryかどうかの判定をする。(リゾルバーはすべての問い合わせに答えるべきか） 　　　ローカル(ゾーン)に保持している情報かどうか。キャッシュにある情報か。あれば、5へ。 1. query DNS情報(レコード)を保持していそうなゾーンサーバーを探しだす。([[../zone cut検出]]、NSレコードquery） 　　　rootサーバーからのdelegationをたどって、より近いゾーンサーバへ。目的のゾーンサーバが見つかるまで。 期限切れのdelegationが途中にないかを確認する意味もある。(Ghost Domain Names) 　　　　必要に応じて、NSレコードのA/AAAAのqueryを発生する。 2. 目的のゾーンサーバーに[[DNS/1/queries]]を送って、DNS資源レコードを取り出す。 　　（[[DNS/返答/処理]] [[/毒見]] も） 3. 得られた情報は再利用するために、[[../キャッシュ]]に保持する。(TTLの管理） キャッシュを上書きしないという原則を提案しているが、実装では見当たらない。 * NS(delegation)が返ってきたら、毒の可能性がある。[[/NS毒見]] したら、2 に戻る。 * [[DNS/毒盛]] 対策　([[/おまけ情報は破棄]]） * [[../NXDomain返答]] [[DNS/毒盛/対策/NXDOMAIN返答活用]] * [[/Answer Sectionから分かること]] 　　 * [[../CNAME返答]]なら、1 へ戻って繰り返すのか？　 qtypeがMXであったなら繰り返さない。[[To_tss/2017-03-19]] (アクセス制限つきリンク） 　　　　その他のqtypeであっても、CNAMEを追いかけるのはclient側の責任ではないだろうか。 現実には試したリゾルバーはCNAMEの追跡をして、Answer Sectionに付けてくる。余計なお世話だ。 qname-minimisation時のNS queryに対するCNAME返答はどう扱うのか。 4. 返答を作成する。([[/minimum responseの原則]]） [[DNS/実装/リゾルバー]], [[DNS/用語/リゾルバー]] [[/入門]] [[/patent]] https://twitter.com/beyondDNS/status/827694317363879936 リゾルバーは外部からの問い合わせに直結した問い合わせを送り出すだけでなく、 どこに問い合わせを送るべきかを決定するための問い合わせを送り出す必要もある。 （RFC1034ではルートサーバーに送ることを前提にしているようにも受け取れるが） そのあたりが複雑になる理由か。 == 解説 == キャッシュにある情報をいつまで再利用していいか、 を判断するために使われるのが資源レコードにあるTTLというフィールドです。 == fujiwara == Updating Resolver Algorithm draft-fujiwara-dnsop-resolver-update-00 https://www.ietf.org/id/draft-fujiwara-dnsop-resolver-update-00.txt RFC 2181 Ranking data and referrals/glue importance --- new resolver algorithm proposal --- https://indico.dns-oarc.net/event/25/session/6/contribution/19/material/slides/2.pdf https://twitter.com/mad_p/status/809657578930065408 {{{ 既存の名前解決アルゴリズムはおかしいという指摘。 親側NS・グルーの扱いに関してRFC1034と2181に矛盾 → 提案は特許があると指摘。 親側NS、グルーだけを使う案は否決。議論継続 }}} draftの継続というのは提案者がまだ諦めていないというだけですね。 ---- Observed DNS Resolution Misbehavior BCP 123 RFC4697 https://www.rfc-editor.org/rfc/rfc4697.txt