DNS/毒盛/対策/RFC2181-5.4

http://dnsdoc.qmail.jp/rfc2181/s5.html　からの抜粋(編集）

• 英文はRFC2181からのコピーであるが、翻訳の正しさは保証しない。

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 [RFC2065] 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)である。

[コメント] ”glue"の用語法に混乱が見られる。-- ToshinoriMaeno 2009-09-06 08:56:06