RFC2308 要約メモ

Updated by: 4035, 4033, 4034, 6604, 8020               PROPOSED STANDARD
                                                            Errata Exist

Network Working Group                                          M. Andrews
Request for Comments: 2308                                          CSIRO
Updates: 1034, 1035                                            March 1998
Category: Standards Track

              Negative Caching of DNS Queries (DNS NCACHE)

1.用語

QNAME とは

"QNAME" - the name in the query section of an answer, or where this resolves to a CNAME, or CNAME chain, the data field of the last CNAME. The last CNAME in this sense is that which contains a value which does not resolve to another CNAME. Implementations should note that including CNAME records in responses in order, so that the first has the label from the query section, and then each in sequence has the label from the data section of the previous (where more than one CNAME is needed) allows the sequence to be processed in one pass, and considerably eases the task of the receiver. Other relevant records (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
(あえて翻訳しない)

QNAME に関するこの Errata の議論は重要

Status: Reported (1)
RFC 2308, "Negative Caching of DNS Queries (DNS NCACHE)", March 1998
Source of RFC: dnsind (int)

Errata ID: 4983

Status: Reported
Type: Editorial

Reported By: Stéphane Bortzmeyer
Date Reported: 2017-03-28

Section 1 says:

   "QNAME" - the name in the query section of an answer, or where this
	   resolves to a CNAME, or CNAME chain, the data field of the last
		   CNAME.

It should say:

   "QNAME" - the name in the query section (RFC 1034, section 3.7.1).
https://www.rfc-editor.org/errata_search.php?rfc=2308&eid=4983

FORWARDER とは

RFC2308

"FORWARDER" - a nameserver used to resolve queries instead of directly using the authoritative nameserver chain. The forwarder typically either has better access to the internet, or maintains a bigger cache which may be shared amongst many resolvers. How a server is identified as a FORWARDER, or knows it is a FORWARDER is outside the scope of this document. However if you are being used as a forwarder the query will have the recursion desired flag set.

RFC7719

Forwarder: Section 1 of [RFC2308] describes a forwarder as "a nameserver used to resolve queries instead of directly using the authoritative nameserver chain". [RFC2308] further says "The forwarder typically either has better access to the internet, or maintains a bigger cache which may be shared amongst many resolvers." That definition appears to suggest that forwarders normally only query authoritative servers. In current use, however, forwarders often stand between stub resolvers and recursive servers. [RFC2308] is silent on whether a forwarder is iterative-only or can be a full-service resolver.



否定応答












2.1 Name Error

Authority Section の NS や SOA レコードの存在に関わらず、RCODE の回答コード "Name Error (NXDOMAIN)" で Referral と NXDOMAIN を区別できる。

NXDOMAIN 4つのタイプ

NXDOMAIN RESPONSE: TYPE 1.

           Header:
               RDCODE=NXDOMAIN
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
               XX. NS NS1.XX.
               XX. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3
(なぜ XX の SOA や NS を知っているのか?)
NXDOMAIN RESPONSE: TYPE 2.

           Header:
               RDCODE=NXDOMAIN
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
           Additional:
               <empty>
(なぜ XX の SOA を知っているのか?)
NXDOMAIN RESPONSE: TYPE 3.

           Header:
               RDCODE=NXDOMAIN
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               <empty>
           Additional:
               <empty>
(なぜ TRIPPLE.XX の不存在を知っているのか?)
NXDOMAIN RESPONSE: TYPE 4

           Header:
               RDCODE=NXDOMAIN
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               XX. NS NS1.XX.
               XX. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3
  
REFERRAL RESPONSE.

           Header:
               RDCODE=NOERROR
           Query:
               ANOTHER.EXAMPLE. A
           Answer:
               <empty>
           Authority:
               EXAMPLE. NS NS1.XX.
               EXAMPLE. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3

2.1 についての考察

以上の例は EXAMPLE と XX が同居していると思われるろくでもない代物なので初学者は無視したほうがよい。(キャッシュの同居も扱っているのでなおさらろくでもない)

2.2 No DATA

NODATA is indicated by an answer with the RCODE set to NOERROR and no relevant answers in the answer section. The authority section will contain an SOA record, or there will be no NS records there.

NODATA は RCODE が NOERROR で Answer Section に妥当な Answer がないことで示される。(NODATA という RCODE はない) Authority Section には SOA があったり、NS がなかったりする。(それにより NODATA と Referral を区別できる)

NODATA RESPONSE: TYPE 1.

           Header:
               RDCODE=NOERROR
           Query:
               ANOTHER.EXAMPLE. A
           Answer:
               <:empty>
           Authority:
               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
               EXAMPLE. NS NS1.XX.
               EXAMPLE. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3
NO DATA RESPONSE: TYPE 2.

           Header:
               RDCODE=NOERROR
           Query:
               ANOTHER.EXAMPLE. A
           Answer:
               <:empty>
           Authority:
               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
           Additional:
               <:empty>
NO DATA RESPONSE: TYPE 3.

           Header:
               RDCODE=NOERROR
           Query:
               ANOTHER.EXAMPLE. A
           Answer:
               <:empty>
           Authority:
               <:empty>
           Additional:
               <:empty>
REFERRAL RESPONSE.

           Header:
               RDCODE=NOERROR
           Query:
               ANOTHER.EXAMPLE. A
           Answer:
               <:empty>
           Authority:
               EXAMPLE. NS NS1.XX.
               EXAMPLE. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3

NXDOMAIN の例と違い CNAME を扱っていないが CNAME も扱いうる。NODATA が示すのは CNAME 連鎖の最後の値についてである。

3. 権威サーバからの否定回答

そのゾーンに権威のあるネームサーバは NXDOMAIN や要求されたタイプが NODATA であることを報告する応答の Authority Section にそのゾーンの SOA レコードを含めなくてはいけない。応答がキャッシュできるようにするためだ。キャッシュの TTL は SOA の MINIMUM フィールドと SOA 自身の TTL の小さい方にセットされ、否定回答をどれくらいキャッシュしていてよいかを示す。

4. SOA Minimum フィールド

過去3つの定義

2つめはマスターゾーンファイルの中でだけ意味がある。セカンダリへ転送されたデータは明示的な TTL が生成される。別な方法が使われるべきであり RFC 1035 ではマスターファイルフォーマットがディレクティブとして
$TTL <:TTL> [comment]
を含むよう拡張された。
このディレクティブ以降に現れる明示的な TTL を持たない RR には $TTL の TTL が設定される。

残った現在の意味は否定応答の TTL であり、SOA minimum フィールドの新しい定義だ。

5. 否定回答のキャッシング

権威サーバが否定回答を作成するとき TTL を指定しなければいけない。
Authority Section に SOA レコードをいれる。その TTL は SOA の minimum フィールドと SOA レコードの TTL の小さい方が選ばれる。キャッシュの TTL は減算されて 0 になったら回答に使用してはいけない。

SOA レコードのない否定応答はキャッシュされるべきではない。(否定応答の TTL を渡してカウントダウンしないフォワーダが相互参照されるとキャッシュが永遠に残る可能性がある)

キャッシュ時間には制限を設けるべきだ。1 - 3 時間をデフォルトとするのが賢明だ。1日を越えると問題が多いことがわかっている。

6. キャッシュからの否定回答

否定回答のキャッシュを答える際に、減算された TTL を持つ SOA を Authority Section に付加しなければいけない。(NXDOMAIN や NODATA が正しく timeout するように) (注: 本文書には否定回答は暗黙の Referral を持つべきだと書かれているがそれに従うのは好ましくないだろう)

7. 他の否定応答

(TTL を示せない) 他の否定応答のキャッシングをカバーする RFC はない。ループ回避の必要あり。

7.1 Server Failure (オプション)

Server Failure は 2 つに分類される。

  1. ゾーン設定にミスがあることを検出できた場合: サーバに指定されているのにゾーンが設定されていないかゾーンデータが取得できなくなっている
  2. そのサーバが他のサーバからデータを取得しなくてはいけないがそのサーバがデータを提供できなくなっている

いずれの場合もリゾルバは server failure 応答をキャッシュしてもよい。その場合、5 分を超えてキャッシュしてはいけない (MUST NOT)。<query name, type, class, server IP address> の組みでキャッシュしなければいけない(MUST)。

7.2 Dead / Unreachable Server (オプション)

120秒以内にサーバが応答しなかったらそれをキャッシュしても良い(MAY)。

例: ICMP unreachable, TCP resets, その他 IP スタックのエラー

5 分以上停止とみなしてはいけない (MUST NOT)。

トランスポート層でサーバ停止が検出されたときは IP アドレスで、それ以外の場合は <query name, type, class, server IP address> の組みでキャッシュしなければいけない(MUST)。

8 - Changes from RFC 1034

Negative caching はもはやオプショナルではない。

権威のない negative answers もキャッシュしてもよい。

Authority Section の SOA はキャッシュしなければいけない

Name error indications must be cached against <query name, QCLASS>の組に対する Name error はキャッシュしないといけない。(must be cached)

<query name, QTYPE, QCLASS> の組に対する No Data はキャッシュしないといけない。

キャッシュされた SOA レコードは応答に付加しないといけない。

This was explicitly not allowed because previously the distinction between a normal cached SOA record, and the SOA cached as a result of a negative response was not made, and simply extracting a normal cached SOA and adding that to a cached negative response causes problems.
The $TTL TTL directive was added to the master file format.

残りのセクションは省略