DNS/リゾルバー/要件

1. DNS/リゾルバー/要件

Contents

DNS/リゾルバー/要件
1. 要件
解説
fujiwara

ここで説明するものはDNS/RFC/1034/5やRFC1035の動作例などとは異なる。

qname minimisationを採用しているリゾルバーの動作であり、/longest matchではない。

1.1. 要件

答えるべきqueryかどうかの判定をする。(リゾルバーはすべての問い合わせに答えるべきか）
- ローカル(ゾーン)に保持している情報かどうか。キャッシュにある情報か。あれば、5へ。
query DNS情報(レコード)を保持していそうなゾーンサーバーを探しだす。(../zone cut検出、NSレコードquery）
- rootサーバーからのdelegationをたどって、より近いゾーンサーバへ。目的のゾーンサーバが見つかるまで。
  - 期限切れのdelegationが途中にないかを確認する意味もある。(Ghost Domain Names)
  - 必要に応じて、NSレコードのA/AAAAのqueryを発生する。
目的のゾーンサーバーにDNS/1/queriesを送って、DNS資源レコードを取り出す。
- （DNS/返答/処理 /毒見も）
得られた情報は再利用するために、../キャッシュに保持する。(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返答はどう扱うのか。
返答を作成する。(/minimum responseの原則）

DNS/実装/リゾルバー, DNS/用語/リゾルバー /入門

/patent

https://twitter.com/beyondDNS/status/827694317363879936

リゾルバーは外部からの問い合わせに直結した問い合わせを送り出すだけでなく、どこに問い合わせを送るべきかを決定するための問い合わせを送り出す必要もある。（RFC1034ではルートサーバーに送ることを前提にしているようにも受け取れるが）そのあたりが複雑になる理由か。

2. 解説

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

3. 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

MoinQ: DNS/リゾルバー/要件

1. DNS/リゾルバー/要件

1.1. 要件

2. 解説

3. fujiwara