1. DNS/毒盛/BIND-trust-level

キャッシュ毒盛を許す理由がRFC2181 だという根拠を調べている。

RFC2181-Sec5 RRSets の受け取り

サーバは返事として得られた資源レコード(RRs) とキャッシュ中の RRs とをまぜあわせて 別の資源レコード集合(RRSet) を作成してはならない。
...
キャッシュと返答とが異なるデータ集合である場合、どちらかが 不正であるということである。  

DNS/RFC/2181/s5#A5.4.1._.2BMMcw.2FDC.2FMG6YBk9NMGQwUQ_.28Ranking_data.29

2. Hitchhiker's Guide

Guideより (BIND 9.4.1 の上書きルールとある)

Define symbol

Trust level

Description

ultimate

8

This server is authoritative

secure

7

Successfully DNSSEC validated

authanswer

6

Answer from an authoritative server

authauthority

5

Received in the auth section as an authority response

answer

4

Answer from a non-authoritative server

glue

3

Received in a referral response

additional

2

Received in the add section of a resp

authoritative (level 8)というのはローカルにゾーンファイルを持っているという意味です。(権威・ゾーンサーバ)

level 6 はゾーンサーバからの返事でAnswer section にあるもの(だが、CNAMEにおまけのA は除かれるはず)

level 5 には委譲返答は含まれない。(問題のある)

level 4

level 3 が委譲返答(どこからの返答かが重要だし、ここがDNSの根幹)

BIND and Unbound. In BIND, a cached RRset is overwritten if the trust level of
the received RRset is higher or equal to the cached one and its TTL is longer.

NS-type RRsets received in a referral are an exception:
they have the trust level 8 for the purposes of overwriting 
(i.e., they always overwrite the records already present in the cache),
but are stored with the trust level 3.

「レベルが同等以上」で、TTLが短かくなるのでなければ、新しく受け取ったものをキャッシュに入れ直す。 (Ghost Domain Names 脆弱性の原因)

例外は"referral"であり、「常に上書きする」。ただし、キャッシュされたものはレベル3となる。 (これを信じられるか。いつの話だろうか。)

[注] 「常に上書きする」というような記述はRFC2181には見当たらない。 BIND実装の話か。 最近の調査ではreferral による上書きは起きないケースもあるらしい。 -- ToshinoriMaeno 2014-04-12 14:53:50

static const char *trustnames[] = {
        "none",

        "pending-answer",
        "additional",
        "glue",
        "answer",
        "authauthority",
        "authanswer",
        "secure",
        "local" /* aka ultimate */
};

BINDなどが RFC 2181 に従った動作をしているという主張の根拠が分からない。

MaraDNS. MaraDNS does not use trust levels.
A new record contained in the response simply overwrites the existing record.
In practice, however, only NS records can be overwritten by forged responses.
Because MaraDNS does not cache the additional section of responses,
in order to overwrite an A or CNAME record the forged response
should contain the replacement mapping in the answer section and
its label must be exactly the same as the label of the record to be overwritten.

Such a forgery would only be accepted in response to a query with the same label.
Observe, however, that since a record with this label is already present in the cache,
a MaraDNS resolver would never initiate a recursive query for this label.
Therefore, there is no query that would give the attacker an opportunity to overwrite an existing A or CNAME record.

RFC2181 を見ても、上位からの委譲返答は上位ゾーンのデータではないということでしかない。