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