1. DNS/リゾルバー

DNSの概要(仕組み)の理解にはDNS/リゾルバー/動作の理解が欠かせない。 (リゾルバーの実装がバラバラというのを棚上げにしても、いくつかのRFCの解説が必要か)

どういう動作をするリゾルバーを使うかは、利用する側が決定するもの。 (でも、大多数はISPの提供するリゾルバーを使っているだろう。)

/blog.apnic

Public DNSを標榜するリゾルバーは動作内容(方針)を公表すべきだと思います。(iijがやっているといいが。)

「仕様」というよりも「保証された動作」があるとしたら、 「それぞれのリゾルバーにより異なる」と言うことでしょう。

「なにが保証されているか」は環境を定義してもらわないと、なんとも言えない。

送り出すquery, responseの処理、キャッシュへの保存、保存したデータの利用 などが鍵です。


1.1. 内部のリゾルバー

組織の規模によってはリゾルバーを持つのが適当だ。

1.2. 外部リゾルバー

外部のリゾルバーを使うとしたら、以下のふたつから選ぶことになるだろう。

恐ろしいtweetを見かけた。

というわけで長年に及んだ権威DNSサーバとキャッシュDNSサーバの分離オペ完了です。
達成感はあるのに人に誇れないのが残念ね。むしろ内緒にしておくべき事か。
16:23 - 2019年4月12日 

2. リゾルバー

DNS入門/レコードの探しかた にあることをやってくれるのがリゾルバーです。

同じ名前を繰り返し検索することを省略するために/キャッシュを持ちます。

名前解決のためには、必要なレコードに責任のあるDNS/1/ゾーンサーバー を見つけることから始めます。

DNS/ブロッキングが違法だというひとたちは、リゾルバーの仕事がどういうものか、を理解しているのだろうか。

DNS/実装/リゾルバー

2.1. リゾルバーの動作

リゾルバーがどういう振る舞いをすべきかの全般的規定はRFCにはありません。

ニセでない本物の返答をなるべく速く入手するのがよいとされてきましたが、 それも最近はprivacy尊重ということで風向きが変わっています。-- ToshinoriMaeno 2018-08-25 09:46:04

2.2. 必要な仕事

検索対象のドメイン名が属するゾーンを確定して、そのゾーンのサーバーに問合せを送るのが必要な仕事です。

共用の公開リゾルバーでも毒盛されないような動作をするリゾルバーモデルを構築したいものです。-- ToshinoriMaeno 2018-08-23 05:35:37

DNS/RFC/1035/2#A2.2._.2BMIgwTzBCMItpy2IQ_Common_configurations

しかし、ここで説明するものはDNS/RFC/1034/5RFC1035の動作例などとは異なります。

現存する実装(BIND, Unbound, Knot resolver, PowerDNS resolver, djbdns, Deadwood) などを使ってみれば分かります。

/com-net問題

2.3. 要件

リゾルバーの/要件の要点

  1. 答えるべきqueryかどうかの判定をする。(リゾルバーはすべての問い合わせに答えるべきか)
    • ローカルに保持している情報かどうか。
  2. query DNS情報(レコード)を保持していそうなゾーンサーバーを探しだす。(/zone cut検出、NSレコードquery)

    • rootサーバーからのdelegationをたどって、より近いゾーンサーバへ。目的のゾーンサーバが見つかるまで。
      • 期限切れのdelegationが途中にないかを確認する意味もある。(Ghost Domain Names)
      • 必要に応じて、NSレコードのA/AAAAのqueryを発生する。
  3. 目的のゾーンサーバーにDNS/1/queriesを送って、DNS資源レコードを取り出す。

  4. 得られた情報は再利用するために、/キャッシュに保持する。(TTLの管理)

    • NS(delegation)が返ってきたら、毒の可能性が高い。
    • DNS/毒盛 対策 (おまけ情報は破棄)

    • /NXDomain返答の処理 DNS/毒盛/対策/NXDOMAIN返答活用

    • /CNAME返答なら、1 へ戻って繰り返すのか?

      • qtypeがMXであったなら繰り返さない。To_tss/2017-03-19 (アクセス制限つきリンク)

      • その他のqtypeであっても、CNAMEを追いかけるのはclient側の責任ではないだろうか。
        • 現実には試したリゾルバーはCNAMEの追跡をして、Answer Sectionに付けてくる。余計なお世話だ。
  5. すでにキャッシュにあるデータとの整合性
    • RRSet単位でなら置き換えることもある (RFC 1912; 2181 ranking)
    • qname-minimisation時のNS queryに対するCNAME返答はどう扱うのか。
  6. 返答を作成する。(/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

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を使うのでもいいが。

2.6. 警告

自分用のリゾルバーを公開設定していると乱用される危険もあります。

2.7. 解説

キャッシュにある情報をいつまで再利用していいか、 を判断するために使われるのが資源レコードにあるTTLというフィールドです。

DNS入門/TTL

DNS/用語/キャッシュサーバ 例: キャッシュサーバ

/RFC2181ランキング再考

2.8. fujiwara

Updating Resolver Algorithm

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

2.10. 判別

多段CNAMEの処理とか、ttl min, max などで判別できるかも。-- ToshinoriMaeno 2018-08-26 07:21:04

qname minimisation, minimal-responses など、リゾルバーの動作を特徴づける項目の方が重要です。

Moin2Qmail: DNS/リゾルバー (last edited 2021-11-22 23:09:28 by ToshinoriMaeno)