RFC 7873: Domain Name System (DNS) Cookies (Part 2)
こんにちは、まれいんです。
この記事は ひとりRFCの旅 Advent Calender 13日目の記事です。
やっと折り返しですね。正直つらくなってきたのですが、なるだけ頑張ります。
今回も前回に引き続きDNSのトランザクションのセキュリティを強化する、DNS Cookiesを読んでいきます。
RFC 7873 - Domain Name System (DNS) Cookies
今回はDNS Cookies対応のServer, Clientがそれぞれどのような処理をするかについてみていきます。
Server側
Cookieオプションの状況を以下の5パターンに分けます。
- OPTRRがない or cookie optionがない
- cookie optionのformatが不正
- client cookieはあるが、server cookieはない
- client cookieとserver cookieがあるが、server cookieが不正
- client cookieと正しいserver cookieがある
1. OPTRRがない or cookie optionがない
通常のクエリと同様の対応をします。
2. cookie optionが不正
FORMERRを返します。
(余談ですが、FORM ERROR でFORMERRというのに今頃気付きました)
3. client cookieはあるが、server cookieはない
サーバー側は以下の3通りの選択肢から応答を選ぶことができます。
2, 3の場合は応答にserver cookieを付け加えて返すことになっています。(SHALL) つけなくてもよいのですが、たまにはserver cookieを入れてクライアントに正しいcookieを通知しなくてはいけません。(MUST)
1はrate limitとかに引っかかった場合を想定しているようなので、基本的な応答は2 or 3と考えて良いはずです。
server cookieがない、ということはトランザクションを張れていないということなので、この状態でも名前解決を許容するかどうか、というのがサーバー側のポリシーを決めるポイントになるのかなと思いました。
4. client cookieとserver cookieがあるが、server cookieが不正
server cookieがなかったかのように扱います。(つまり3と同様)
ちなみにこのパターンになってしまう経緯としては以下のようなものがあります。
5. client cookieと正しいserver cookieがある
client cookieをコピー + server cookieもコピー or 再生成して、通常通り名前解決をして返します。
Client側
こちらも以下のnパターンに分けます。↑のもの優先です。
1. cookie optionがない
レスポンスを捨てます。
これを受け取ってしまうと、攻撃者がDNS Cookiesに対応していないふりをして毒を入れ放題になってしまうので意味がありません。
2. cookie optionのformatが不正
レスポンスを捨てます。
3. client cookieが自分が送ったものと異なる
レスポンスを捨てます。
4. Extended RCODEがBADCOOKIE
Server側で正しくないserver cookieを受け取ったなどで処理を途中でやめたということなので、リトライします。
もらったばかりのserver cookieを使ってもBADCOOKIEが返ってくる場合は、TCP志向のサーバなのでTCPでリトライします。
- それ以外
正しく処理できたと判断して、Server Cookieをキャッシュします。
その他
client側がトランザクションが張れてない状態で名前解決をしたくない場合のために、Question sectionなしのクエリを発行してもよいことになりました。
Server cookieを得るためだけでなく、自分のキャッシュしているserver cookieがただし以下の確認などに使ってもOKです。
