DNS/毒盛/対策/wijngaardsについて、ここに記述してください。
3.3. Obtain Authoritative Data
- o 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. Care must be taken
to avoid DoSing parent nameservers, and not break resolution in
common cases where the NS RRsets in parent and child differ.
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
answer for qtype NS at all, or servers that are offline, because
the referral is cached when making the qtype NS query. This is
why the qtype NS query has to be made in such a way that it
elicits a fresh referral from the parent server. This gives a
once per TTL opportunity for spoofing the referral.
The NS RRset answered from the child side of the zone cut
overrides the NS RRset picked up from the referral. This causes
the same data to be used as today, where the authority section NS
set sent along by the child server overrides the NS set seen from
the referral.
Additional queries are sent for this solution. This increases
resolver and authority server load and bandwith usage.- o Authority queries for nameserver addresses, A and AAAA.
Same idea, like NS query above. You ask for A or AAAA records
directly at the authoritative server. It is not necessary to
elicit the referral again, the query can be directed at the best
server.
Additional queries are sent for this solution. This increases
resolver and authority server load and bandwith usage.- A bonus when using the above methods to obtain authoritative data is that when using DNSSEC, the data can be validated, and thus spoofed infrastructure data can be detected and handled appropriately. This protects DNSSEC, where the referral contains unsigned NS, A and AAAA records from spoofed infrastructure data. Of course, DNSSEC is designed to protect end-user data anyway, whether or not the referral data was poisoned. It simply adds the opportunity to add another layer of defense.