## page was renamed from DNS/1/リゾルバー ## page was renamed from DNS/基礎知識/リゾルバー ## page was renamed from = DNS/リゾルバー = <> <> DNSの概要(仕組み)の理解には[[DNS/リゾルバー/動作]]の理解が欠かせない。 (リゾルバーの実装がバラバラというのを棚上げにしても、いくつかのRFCの解説が必要か) どういう動作をするリゾルバーを使うかは、利用する側が決定するもの。 (でも、大多数はISPの提供するリゾルバーを使っているだろう。) [[/Problems]] [[/blog.apnic]] Public DNSを標榜するリゾルバーは動作内容(方針)を公表すべきだと思います。(iijがやっているといいが。) 「仕様」というよりも「保証された動作」があるとしたら、 「それぞれのリゾルバーにより異なる」と言うことでしょう。 「なにが保証されているか」は環境を定義してもらわないと、なんとも言えない。 送り出すquery, responseの処理、キャッシュへの保存、保存したデータの利用 などが鍵です。 そして、保存があると、履歴が問題になります。-- ToshinoriMaeno <> ---- [[/GhostDomain]] == 内部のリゾルバー == 組織の規模によってはリゾルバーを持つのが適当だ。 == 外部リゾルバー == 外部のリゾルバーを使うとしたら、以下のふたつから選ぶことになるだろう。 　[[/ISP]]、[[DNS/オープンリゾルバー/公開リスト]] 恐ろしいtweetを見かけた。 　　https://twitter.com/kasuga_net/status/1116602616828399616 {{{ というわけで長年に及んだ権威DNSサーバとキャッシュDNSサーバの分離オペ完了です。 達成感はあるのに人に誇れないのが残念ね。むしろ内緒にしておくべき事か。 16:23 - 2019年4月12日 }}} = リゾルバー = [[DNS入門/レコードの探しかた]] にあることをやってくれるのがリゾルバーです。 . リゾルバーは名前解決のための検索を代行しているだけです。(方便としての説明) 同じ名前を繰り返し検索することを省略するために[[/キャッシュ]]を持ちます。 　キャッシュにあるデータの有効期限を示すためにTTLが使われます。 名前解決のためには、必要なレコードに責任のある[[DNS/1/ゾーンサーバー]] を見つけることから始めます。 　古い脆弱な実装ではいきなりキャッシュ内を探したりします。 [[DNS/ブロッキング]]が違法だというひとたちは、リゾルバーの仕事がどういうものか、を理解しているのだろうか。 [[DNS/実装/リゾルバー]] == リゾルバーの動作 == {{{ リゾルバーがどういう振る舞いをすべきかの全般的規定はRFCにはありません。 }}} . RFC 1035 Section 2 に動作例はあります。(問い合わせをroot zone serverに送って、順に降下していく) ニセでない本物の返答をなるべく速く入手するのがよいとされてきましたが、 それも最近はprivacy尊重ということで風向きが変わっています。-- ToshinoriMaeno <> == 必要な仕事 == {{{ 検索対象のドメイン名が属するゾーンを確定して、そのゾーンのサーバーに問合せを送るのが必要な仕事です。 }}} 　検索対象がキャッシュにあるかどうかをいきなり調べるとGhost Domain Names脆弱性に当たる可能性がある。-- ToshinoriMaeno <> 共用の公開リゾルバーでも毒盛されないような動作をするリゾルバーモデルを構築したいものです。-- ToshinoriMaeno <> おおまかな枠組み案はありますが、まだ実用にならないレベルです。 [[DNS/RFC/1035/2#A2.2._.2BMIgwTzBCMItpy2IQ_Common_configurations]] . このあたりの図を見ると、初期に想定された構成が分かるはずです。 しかし、ここで説明するものは[[DNS/RFC/1034/5]]や[[DNS/RFC/1035/7|RFC1035の動作例]]などとは異なります。 . [[/qname minimisation]]を採用しているリゾルバーの動作であり、[[/longest match]]ではないのです。 現存する実装(BIND, Unbound, Knot resolver, PowerDNS resolver, djbdns, Deadwood) などを使ってみれば分かります。 . これらは状況により異なる動作をすることがあって、どれが正しいとも言えない。:-< [[/com-net問題]] == 要件 == リゾルバーの[[/要件]]の要点 0. 答えるべきqueryかどうかの判定をする。(リゾルバーはすべての問い合わせに答えるべきか） . ローカルに保持している情報かどうか。 0. query DNS情報(レコード)を保持していそうなゾーンサーバーを探しだす。([[/zone cut検出]]、NSレコードquery） . rootサーバーからのdelegationをたどって、より近いゾーンサーバへ。目的のゾーンサーバが見つかるまで。 . 期限切れのdelegationが途中にないかを確認する意味もある。(Ghost Domain Names) . 必要に応じて、NSレコードのA/AAAAのqueryを発生する。 0. 目的のゾーンサーバーに[[DNS/1/queries]]を送って、DNS資源レコードを取り出す。 . （[[DNS/返答/処理]]毒の排除も） 0. 得られた情報は再利用するために、[[/キャッシュ]]に保持する。(TTLの管理） * NS(delegation)が返ってきたら、毒の可能性が高い。 * [[DNS/毒盛]] 対策　(おまけ情報は破棄） * [[/NXDomain返答の処理]] [[DNS/毒盛/対策/NXDOMAIN返答活用]] * [[/CNAME返答]]なら、1 へ戻って繰り返すのか？ . qtypeがMXであったなら繰り返さない。[[To_tss/2017-03-19]] (アクセス制限つきリンク） . その他のqtypeであっても、CNAMEを追いかけるのはclient側の責任ではないだろうか。 . 現実には試したリゾルバーはCNAMEの追跡をして、Answer Sectionに付けてくる。余計なお世話だ。 0. すでにキャッシュにあるデータとの整合性 . RRSet単位でなら置き換えることもある　(RFC 1912; 2181　ranking) . qname-minimisation時のNS queryに対するCNAME返答はどう扱うのか。 0. 返答を作成する。([[/minimum responseの原則]]） [[DNS/実装/リゾルバー]], [[DNS/用語/リゾルバー]] [[/入門]] [[/patent]] https://twitter.com/beyondDNS/status/827694317363879936 リゾルバーは外部からの問い合わせに直結した問い合わせを送り出すだけでなく、 どこに問い合わせを送るべきかを決定するための問い合わせを送り出す必要もある。 （RFC1034ではルートサーバーに送ることを前提にしているようにも受け取れるが） そのあたりが複雑になる理由か。 RFC 8109 - Initializing a DNS Resolver with Priming Queries https://tools.ietf.org/html/rfc8109 == qname minimisation == QNAME minimisation (RFC 7816) RFC 7626: DNS Privacy Considerations (August 2015) http://www.rfc-editor.org/rfc/rfc7626.txt kudos to @bortzmeyer / @AFNIC == 毒盛対策 == ゾーンサーバにはTCPを使って問い合わせをするのがよい。DNS Cookieを使うのでもいいが。 . DNSSECは使わなくてすむ。 == 警告 == 自分用のリゾルバーを公開設定していると乱用される危険もあります。 . 共用の公開リゾルバーを使っているなら、TCPで問い合せするようにしましょう。 == 解説 == キャッシュにある情報をいつまで再利用していいか、 を判断するために使われるのが資源レコードにあるTTLというフィールドです。 [[DNS入門/TTL]] [[DNS/用語/キャッシュサーバ]] 例: [[キャッシュサーバ]] [[/RFC2181ランキング再考]] == 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の継続というのは提案者がまだ諦めていないというだけですね。 ---- == Misbehavior == Observed DNS Resolution Misbehavior BCP 123 RFC4697 　https://tools.ietf.org/html/rfc4697　 https://www.rfc-editor.org/rfc/rfc4697.txt Observation of query traffic received by two root name servers and the thirteen com/net Top-Level Domain (TLD) name servers has revealed that a large proportion of the total traffic often consists of "requeries". == 判別 == 多段CNAMEの処理とか、ttl min, max などで判別できるかも。-- ToshinoriMaeno <> かつてはhand shakeでBINDのversionを判別していたものもあった。 qname minimisation, minimal-responses など、リゾルバーの動作を特徴づける項目の方が重要です。