1. DNS/毒盛/AncillaryDataAttacks
Contents
付帯的なデータと言える。
https://tools.ietf.org/id/draft-weaver-dnsext-comprehensive-resolver-00.html September 30, 2008
- 補助データとか付随データとか呼ぶのがいいでしょうか。（余計なお世話のことが多いのですが）
これらを無視するresolver実装はDeadwood(MaraDNS)とKnot DNS resolverです。
私はdnscache(djbdns)に手を入れて使っています。-- ToshinoriMaeno 2015-12-13 07:15:41
最近、対策が不十分だと知りました。-- ToshinoriMaeno 2017-10-10 12:11:27
Unboundもharden-referral-pathオプションを指定すると、より安全になります。
参考： http://conferences.sigcomm.org/hotnets/2014/papers/hotnets-XIII-final127.pdf
逆に｢外部名に対するAdditional｣を受け入れるあぶないリゾルバーが見つかりました。/1.1.1.1 など。
2. Knot DNS での扱い
[knot-dns-users] minimal responses Marek Vavruša marek.vavrusa at http://nic.cz Mon Sep 14 08:50:11 CEST 2015
https://lists.nic.cz/pipermail/knot-dns-users/2015-September/000704.html
NS in the authority section is really extra data and shouldn't be cached, as it gives the attacker a tool to joust valid NSs out of cache with spoofed ones much more easily.
整形してあります。
コメントしたいことは多々あるのですが、当面はもとのまま載せておきます。 /コメント は別に書く予定。 -- ToshinoriMaeno 2015-10-18 12:34:23
https://tools.ietf.org/id/draft-weaver-dnsext-comprehensive-resolver-00.html
3. 10章
10. Cache Policy, Scoping, and Ancillary Data Attacks
RFC 2181 section 5.4.1 [RFC2181] is the current specification for how to accept ancillatory data.
It allows ancillatory data, if "in bailywick" (from a server which should be an authority for this name), to be cached for subsequent use, although it should not be returned as an answer. It is this caching of ancillatory data that enables the "race-until-win" Kaminski blind cache attack.
Likewise, before bailywick-checking was deployed, ancillatory data was used for classic glue poisoning.
The ancillatory data includes all the data beyond the direct answer to the query (including the NS RRSet, A records associated with the NS RRSet, A records associated with a CNAME for the direct answer, or any other data).
This data serves four purposes:
- The NS RRSet and associated A records needed to resolve the current request.
- Items, such as an A record for a CNAME alias, which if accepted will speed the current request's processing
- by removing the need to fetch additional records.
- Items which if placed in the cache will speed subsequent lookups.
- An indication that an item in the cache is now obsolete.
This suggests that items have a different role in two scopes, analogous to how programming languages view scope:
- the local scope of the current recursive query and the global scope of the cache.
Within the local scope, for purposes of resolving the direct question, ancillary data often must be trusted: otherwise authoritative nameservers may not be reachable when they exist within the domain being queried or in other cases where domains host each-others nameservers.
Yet for the purposes of resolving a query, if an authority lies about the ancillatory data, it could just as easily lie about the direct answer, making this data no less trustworthy for processing this answer.
Yet for purposes of inclusion into the global scope, or for returning as the response to a query, ancillary data must not be trusted.
It is, by definition, unsolicited information and not an authoritative response, and lies at the heart of the Kaminski attack. If a recursive resolver never accepts ancillary data into the cache, it becomes impossible to target a single name with a race-until-win blind attack.
However, a resolver may safely perform an independent fetch for any piece of ancillary data.
This second fetch must not reuse the local scope of the previous fetch, but instead be fetched using a new local context. This enables both the use of ancillary data in responses (such as A records involved in CNAMES) and to speed subsequent responses (such as obtaining the NS RRSet for subsequent lookups).
As an example, suppose the query for 'www.example.com' returns
www.example.com CNAME server.example.com, example.com NS ns.example.com, ns.example.com A 12.34.56.78, server.example.com A 12.34.56.90'.
The resolver can succesfully cache and return 'www.example.com CNAME server.example.com', but must perform independent queries to fetch the NS RRSet and the A records for ns.example.com and server.example.com, and it can't return 'www.example.com CNAME server.example.com, server.example.com A 12.34.56.90' to the final client until the lookup for server.example.com completes.
As a result, all information which is either placed in the global scope or returned to the final client will be validated directly by querying the proper authoritative server. There are no race-until-win attacks possible for including a name into the cache, as inserting a name only would take place if it doesn't exist in the cache which limits any attempt to once every TTL.
This is more restrictive than the policy in RFC 2181 section 5.4.1 [RFC2181]. The RFC policy allows ancillary data to be accepted into the global scope (cache) for purposes of subsequent query processing, which enables race-until-win attacks.
Although the RFC states that the final client should also not accept these authority or additional records, it is unclear whether the stub resolver follow the RFC. Thus a well structured recursive resolver should return results which are safe even if the client does cache additional records in violation of the RFC.
The simplest mechanism for validation is to perform an explicit fetch, a policy being implemented in Unbound [unbound]:
For CNAMEs and A records that are not the direct answer to the query, such records are not accepted directly but are instead fetched independently.
For the NS record and associated A records, the separate global and local scope is approximated by validating the NS RRSet and all elements within it using subsequent separate fetches.
There is some minor uncertanty if this is a close-enough approximation for the NS RRSet. There exists a short-term time window where the NS RRSet and A records would be in the cache but unvalidated, which may provide a narrow opportunity for abuse. However, this policy does not require new data structures to maintain the local scope of a recursive query, and the abuse window is probably sufficiently small.
Note that if an explicit local scope is maintained, such a policy of fetching all ancillary data rather than including it subsumes bailiwick checking for accepting data into the cache, as no data is included into the cache for any use that was not explicitly requested from an authoritative server.