IETF-draft/wijngaards/3.3について、ここに記述してください。

3.3 Obtain Authoritative Data

これが毒盛対策になっているのだろうか、私にはわからない。 -- ToshinoriMaeno 2014-11-27 11:51:34

referral 返答の場合に、別の形で問合せしなおすという対策はここには書かれているようには読めない。

1. Authority query for NS after referral

The idea is to obtain authoritative data for the NS RRset instead of using data tacked along on another message.

On a referral, the data from the referral may be used to continue answering the current query, but it is not stored in the cache.

If the question equals the referred zone name and has qtype NS, then the NS RRset from the referral does get stored in the cache.

   ???

If the question is not that already, a new lookup is performed for the referred zone name with qtype NS. The results from that lookup are cached normally. The lookup has to start at a parent of the referred zone, so that a new referral is obtained.

The upshot is that RFC2181 adherence pins the NS RRset data in the cache because it is seen in the answer section, and tacked on data from other messages is ignored until the TTL expires. It should be noted that most infrastructure TTLs for NS records are very large.

It does not break existing disjoint RRsets, or servers that do not

The NS RRset answered from the child side of the zone cut

Additional queries are sent for this solution. This increases

2. Authority queries for nameserver addresses, A and AAAA.

Same idea, like NS query above. You ask for A or AAAA records

Additional queries are sent for this solution. This increases

3. おまけ

A bonus when using the above methods to obtain authoritative data is


Unbound 1.5.0