Contents
| /abstract /introduction /s10 /s11 /s12 /s5 /s6 /s7 /s8 /s9 |
5. 資源レコード集合 (Resource Record Sets)
Each DNS Resource Record (RR) has a label, class, type, and data. It is meaningless for two records to ever have label, class, type and data all equal - servers should suppress such duplicates if encountered. It is however possible for most record types to exist with the same label, class and type, but with different data. Such a group of records is hereby defined to be a Resource Record Set (RRSet).
各 DNS 資源レコード (RR) は 識別子 (ラベル)、クラス、型、値(データ) からなる。 これらがすべて同じであるような二つのレコードが存在することは無意味なので、 サーバはもし重複に出会ったら、重複をとり除いた返事をすべきである。 ただし、値だけが異っていて、識別子、クラスと型が同じレコードは ほとんどのレコード型について認められている。 このように、識別子、クラス、型が同じレコードの一群を 資源レコード集合 (Resource Record Set、RRSet)と定義する。
5.1. RRSet から 資源レコードを返事する (Sending RRs from an RRSet)
A query for a specific (or non-specific) label, class, and type, will
always return all records in the associated RRSet - whether that be
one or more RRs. The response must be marked as "truncated" if the
entire RRSet will not fit in the response.識別子、クラス、型を特定した、あるいは特定しない問い合わせに対しては、 見つかった資源レコード集合(RRSet)中のレコードをすべて返す。 それがひとつか、複数であるかにかかわらずである。
もし RRSetが返事(のパケット)に収まりきらないときには切りつめられた(truncated) という印をつけた返事をする。
5.2. RRSet 中の 資源レコードの TTL (TTLs of RRs in an RRSet)
Resource Records also have a time to live (TTL). It is possible for
the RRs in an RRSet to have different TTLs. No uses for this have
been found that cannot be better accomplished in other ways. This
can, however, cause partial replies (not marked "truncated") from a
caching server, where the TTLs for some but not all the RRs in the
RRSet have expired.資源レコードにも有効寿命 (TTL)がある。 ある RRSet 中の各資源レコードのTTLが異っていることはありうる。 このことには他の方法では実現できないような有効な用途がみつかっていない。 しかるに、このことはキャッシュサーバから(切りつめられていない) 部分的返事が返ってくることの原因となる。 というのは、一部の資源レコードの寿命(TTL)が尽きてしまうことがあるからである。
Consequently the use of differing TTLs in an RRSet is hereby
deprecated, the TTLs of all RRs in an RRSet must be the same.結論として、RRSet中の資源レコードはすべて同じ TTL を持つべきであり、 異なるような使い方はすべきでない。
Should a client receive a response containing RRs from an RRSet with
differing TTLs, it should treat this as an error. If the RRSet
concerned is from a non-authoritative source for this data, the
client should simply ignore the RRSet, and if the values were
required, seek to acquire them from an authoritative source. Clients
that are configured to send all queries to one, or more, particular
servers should treat those servers as authoritative for this purpose.
Should an authoritative source send such a malformed RRSet, the
client should treat the RRs for all purposes as if all TTLs in the
RRSet had been set to the value of the lowest TTL in the RRSet. In
no case may a server send an RRSet with TTLs not all equal.TTLが異なる資源レコードをもつ資源レコード集合からの 返答をクライアントが受け取ったらエラーとして扱うべきである。 当該 RRSet が権威なしの情報源からのものであれば、 単に RRSetを無視してよい。
必要な情報なら権威をもった情報源をさがすこと。 問い合わせを特定のサーバ(単数あるいは複数)に送るように設定されている クライアントの場合にはこれらのサーバを権威あるものと見なす必要がある。
権威ある情報源が上のような欠陥のあるRRSetを返してくるなら、 RRSetのすべての資源レコードがRRSet中の最小のTTLを持つものとして扱うべきである。 いかなる場合にもサーバは異なるTTLをもつようなRRSetを返してはならない。
5.3. DNSSEC Special Cases
Two of the record types added by DNS Security (DNSSEC) [<a title="Eastlake, D., Kaufman, C., "Domain Name System Security Extensions", RFC 2065, January 1997." href="chapter13.html#RFC2065">RFC2065</a>]
require special attention when considering the formation of Resource
Record Sets. Those are the SIG and NXT records. It should be noted
that DNS Security is still very new, and there is, as yet, little
experience with it. Readers should be prepared for the information
related to DNSSEC contained in this document to become outdated as
the DNS Security specification matures.
5.3.1. SIG records and RRSets
A SIG record provides signature (validation) data for another RRSet
in the DNS. Where a zone has been signed, every RRSet in the zone
will have had a SIG record associated with it. The data type of the
RRSet is included in the data of the SIG RR, to indicate with which
particular RRSet this SIG record is associated. Were the rules above
applied, whenever a SIG record was included with a response to
validate that response, the SIG records for all other RRSets
associated with the appropriate node would also need to be included.
In some cases, this could be a very large number of records, not
helped by their being rather large RRs. Thus, it is specifically permitted for the authority section to
contain only those SIG RRs with the "type covered" field equal to the
type field of an answer being returned. However, where SIG records
are being returned in the answer section, in response to a query for
SIG records, or a query for all records associated with a name
(type=ANY) the entire SIG RRSet must be included, as for any other RR
type. Servers that receive responses containing SIG records in the
authority section, or (probably incorrectly) as additional data, must
understand that the entire RRSet has almost certainly not been
included. Thus, they must not cache that SIG record in a way that
would permit it to be returned should a query for SIG records be
received at that server.
RFC 2065(-> 2535 prop) actually requires that SIG queries
be directed only to authoritative servers to avoid the problems that
could be caused here, and while servers exist that do not understand
the special properties of SIG records, this will remain necessary.
However, careful design of SIG record processing in new
implementations should permit this restriction to be relaxed in the
future, so resolvers do not need to treat SIG record queries
specially. It has been occasionally stated that a received request for a SIG
record should be forwarded to an authoritative server, rather than
being answered from data in the cache. This is not necessary - a
server that has the knowledge of SIG as a special case for processing
this way would be better to correctly cache SIG records, taking into
account their characteristics. Then the server can determine when it
is safe to reply from the cache, and when the answer is not available
and the query must be forwarded.
5.3.2. NXT RRs
Next Resource Records (NXT) are even more peculiar. There will only
ever be one NXT record in a zone for a particular label, so
superficially, the RRSet problem is trivial. However, at a zone cut,
both the parent zone, and the child zone (superzone and subzone in
RFC 2065(-> 2535 prop) terminology)
will have NXT records for the same name. Those
two NXT records do not form an RRSet, even where both zones are
housed at the same server. NXT RRSets always contain just a single
RR. Where both NXT records are visible, two RRSets exist. However,
servers are not required to treat this as a special case when
receiving NXT records in a response. They may elect to notice the
existence of two different NXT RRSets, and treat that as they would
two different RRSets of any other type. That is, cache one, and
ignore the other. Security aware servers will need to correctly
process the NXT record in the received response though.
5.4. RRSets の受け取り (Receiving RRSets)
Servers must never merge RRs from a response with RRs in their cache
to form an RRSet. If a response contains data that would form an
RRSet with data in a server's cache the server must either ignore the
RRs in the response, or discard the entire RRSet currently in the
cache, as appropriate. Consequently the issue of TTLs varying
between the cache and a response does not cause concern, one will be
ignored. That is, one of the data sets is always incorrect if the
data from an answer differs from the data in the cache.サーバは返事として得られた資源レコード(RRs) とキャッシュ中の RRs とをまぜあわせて 別の資源レコード集合(RRSet) を作成してはならない。
サーバがキャッシュしているデータと RRSetを構成するようなデータが 返答中にある場合、サーバは返答中の RRsを無視するか、現在キャッシュにある RRSetを捨てさるか、適当な方を選択する。 この結果、キャッシュと返答で TTL が異っていることは問題とはならない。
つまり、キャッシュと返答とが異なるデータ集合である場合、どちらかが 不正であるということである。
The challenge for the server is to determine which of the data sets is
correct, if one is, and retain that, while ignoring the other. Note
that if a server receives an answer containing an RRSet that is
identical to that in its cache, with the possible exception of the
TTL value, it may, optionally, update the TTL in its cache with the
TTL of the received answer. It should do this if the received answer
would be considered more authoritative (as discussed in the next
section) than the previously cached answer.サーバにとっての課題は正しいものがあるとして、 どちらのデータセットが正しいかを決定することと、 正しい方を残し、正しくない方を無視することとである。
TTL値の違いは無視するものとして、 キャッシュ中の RRSetとまったく同じ RRSetを持つ 返答を受けとったときには、キャッシュ中の TTL を受信した返答の TTL で更新してもよいことに注意せよ。(オプション)
受信した返答が現在キャッシュされているところの以前の 返答より権威がある(次の節で述べる)と考えられる場合には、 この更新を行うべきである。
5.4.1. データの順位つけ (Ranking data)
When considering whether to accept an RRSet in a reply, or retain an
RRSet already in its cache instead, a server should consider the
relative likely trustworthiness of the various data. An
authoritative answer from a reply should replace cached data that had
been obtained from additional information in an earlier reply.
However additional information from a reply will be ignored if the
cache contains data from an authoritative answer or a zone file.返答中の RRSetを受けいれるか、それともキャッシュ中にあるものを残すかを 検討するときには、サーバはデータ間の信用度を比較すべきである。 返答中の権威ある返事はキャッシュ中の以前の返答の付加情報として得られたデータ を置きかえるべきである。 しかしながら、キャッシュ中のデータが権威ある返事からの ものであるか、ゾーンファイルからのものである場合には返答中の付加情報は無視される。
The accuracy of data available is assumed from its source.
Trustworthiness shall be, in order from most to least:
* Data from a primary zone file, other than glue data,
* Data from a zone transfer, other than glue,
* The authoritative data included in the answer section of an authoritative reply.
* Data from the authority section of an authoritative answer,
* Glue from a primary zone, or glue from a zone transfer,
* Data from the answer section of a non-authoritative answer, and
non-authoritative data from the answer section of authoritative answers,
* Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers.得られるデータの正確さは情報源に依存する。 信頼できるものから、順に以下のようになる。
- プライマリゾーンファイルからのデータ (グルーデータを除く)、
- ゾーン転送で得られたデータ (グルーデータを除く)、
- 権威ある返事の answer節中にある権威あるデータ、
- 権威ある返事の authority節中にあるデータ、
- プライマリゾーンファイルのグルーデータ、または
- ゾーン転送で得られたグルーデータ
- 権威のない返事の answer節中にあるデータ、および
- 権威ある返事の answer節中にある権威のないデータ、
- 権威ある返事の付加情報、
- 権威のない返事のauthority節中のデータ、 権威のない返事の付加情報
Note that the answer section of an authoritative answer normally
contains only authoritative data. However when the name sought is an
alias (see section 10.1.1) only the record describing that alias is
necessarily authoritative. Clients should assume that other records
may have come from the server's cache. Where authoritative answers
are required, the client should query again, using the canonical name
associated with the alias.権威のある返事の answer節は通常権威あるデータだけを含むことに注意せよ。 とはいえ、検索している名前が別名(alias,10.1.1 節を参照)であるときには 別名を記述しているレコードだけが必然的に権威がある。 クライアントは他のレコードはサーバのキャッシュから来たと推定すべきである。 権威ある返事が必要なら、クライアントは 別名が指している正規名を使って再度問い合わせるべきである。
Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
without cause or excuse.受信されたりキャッシュされている資源レコードのうち、 これらのグループ分けの最低の信頼度に属する権威のない資源レコード、 つまり、付加情報節中のデータや権威のない返事のauthority節中のデータは キャッシュされることで、問い合わせに対する返事で answer として返されるような ことがあってはならない。 これらは 付加情報としてなら返事に含めてもよい。 このことを無視すれば、相対的に信頼できないデータの信頼度を 理由もなく上げていることになり、弁解する余地はない。
When DNS security [<a title="Eastlake, D., Kaufman, C., "Domain Name System Security Extensions", RFC 2065, January 1997." href="chapter13.html#RFC2065">RFC2065</a>] is in use, and an authenticated reply has
been received and verified, the data thus authenticated shall be
considered more trustworthy than unauthenticated data of the same
type. Note that throughout this document, "authoritative" means a
reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY
records to determine the authenticity of data, the AA bit is almost
irrelevant. However DNSSEC aware servers must still correctly set
the AA bit in responses to enable correct operation with servers that
are not security aware (almost all currently).
Note that, glue excluded, it is impossible for data from two
correctly configured primary zone files, two correctly configured
secondary zones (data from zone transfers) or data from correctly
configured primary and secondary zones to ever conflict. Where glue
for the same name exists in multiple zones, and differs in value, the
nameserver should select data from a primary zone file in preference
to secondary, but otherwise may choose any single set of such data.
Choosing that which appears to come from a source nearer the
authoritative data source may make sense where that can be
determined. Choosing primary data over secondary allows the source
of incorrect glue data to be discovered more readily, when a problem
with such data exists. Where a server can detect from two zone files
that one or more are incorrectly configured, so as to create
conflicts, it should refuse to load the zones determined to be
erroneous, and issue suitable diagnostics.グルーを別にすれば、正しく設定されたプライマリゾーンファイルのデータ間で、 あるいは正しく設定されたセカンダリゾーン(ゾーン転送で得たデータ)間で、 あるいは正しく設定されたプライマリとセカンダリのゾーンデータ間で データが矛盾することはない。 同じ名前に対するグルーが複数のゾーンに存在して、値が異なるとき、 ネームサーバはプライマリゾーンファイルのものをセカンダリよりも優先 すべきであるが、それ以外についてはどれか任意のひとつの集合を選んでよい。
決定可能であれば、権威あるデータ源により近い情報源からの ものを選ぶのが理にかなっている。 セカンダリよりもプライマリのデータを選ぶことは 不正なグルーデータ(もしあれば)源をより早く発見しやすくする。
二つのゾーンファイルを比べてすくなくとも一つが正しく設定されていなくて、 矛盾を引きおこすことが分った場合、サーバは間違っているゾーンは ロードしないで、適切な診断メッセージを出力する。
"Glue" above includes any record in a zone file that is not properly
part of that zone, including nameserver records of delegated sub-
zones (NS records), address records that accompany those NS records
(A, AAAA, etc), and any other stray data that might appear.上でいうグルー("Glue") には ゾーンファイルに含まれているがゾーンには属さないレコードを含む。 これらのレコードには、 委譲したサブゾーンに対するネームサーバ (NS)レコード、 これらの NS レコードに伴なっているアドレスレコード(A, AAAA, など)、 そしてその他のはぐれデータ(stray data)である。
5.5. RRSets の送り出し (reprise)
A Resource Record Set should only be included once in any DNS reply.
It may occur in any of the Answer, Authority, or Additional
Information sections, as required. However it should not be repeated
in the same, or any other, section, except where explicitly required
by a specification. For example, an AXFR response requires the SOA
record (always an RRSet containing a single RR) be both the first and
last record of the reply. Where duplicates are required this way,
the TTL transmitted in each case must be the same.ある資源レコード集合 は どの DNS 返答にもただ一度しか含めてはいけない。 それは 必要なら、Answer, Authority, Additional Information 節のどれに現われてよい。 しかし、同一での節でかどうかにかかわらず、繰返して現われてはならない。 ただし、仕様で明示的に要求されている場所を除く。 例えば、AXFR への返答は SOA レコード (always an RRSet containing a single RR) が 返答の最初と最後のレコードとしてなければならない。 このように重複が要求されている場合にも、それぞれの送られる TTL は おなじ値でなければならない。
2002-02-21 訳 前野年紀