On Wed, Sep 30, 2015 at 10:08 PM, Evan Hunt <e...@isc.org> wrote: > On Wed, Sep 30, 2015 at 11:28:45PM -0400, Joe Abley wrote: > > 1. Return an unsigned response. This will be marked as bogus, and > > trigger a QTYPE=HINFO re-query that will either return an actual signed > > HINFO from the zone or a signed proof of non-existence. We think. I > > haven't actually tested that a re-query will happen, but Olafur is > > confident. :-) > > I haven't tested it either, but that is not what I would expect. >
Only validating resolver will send follow up query, > > If the resolver gets a bogus response to a query of type ANY, I > would expect it to try the same query at another name server, > until it had exhausted all authoritative name servers, and then > reply with SERVFAIL. > Here is the deal there are 3 sources of ANY queries to authoritative servers a) Malicious ones both direct or reflected flood via open resolvers b) Someone debugging or trying to zone walk c) Resolver forwarding a ANY query because the cache for that name was EMPTY. We need to look at each one and for a) what we return does not matter but it should be small as it is just noise for b) we need them to comprehend the answer for c) we need the resolver to accept the answer and not send followup queries when a) or b) is the reason they got the query HINFO meets all the goals for a) and b). This leaves us with c) in the case when query source is a legitimate application, but in this case the HINFO is a useless information and the application should realize that this attempt at getting something for free failed and fall back on queries for what it wants i.e. MX and A + AAAA records. I used to be in the camp for TC bit but that was before I realized that open resolvers/forwarders are quite happy to do TCP, meaning you get a flood of TCP connections. TC only addresses the issue of direct forged floods. > > 2. Sign the HINFO RR as it is synthesised (or pre-sign one, to avoid the > > edge authority servers needing access to a signing key). > > Pre-signing essentially reduces to adding an empty HINFO to every node in > every zone, then using the pick-one-RRset method, but ensuring that HINFO > is always selected first. > > > That is true. However, one of the use-cases for this approach is a > > nameserver for which a search for records present at a particular owner > > name (as would normally be performed when responding to an ANY query) is > > expensive. > > It's not at all obvious to me that this is cheaper. > There is NO need to sign, unsigned HINFO returned for ANY query looks to an validating resolver just like an incomplete answer thus it can either return the HINFO or ask the followup question for the HINFO and get a signed denial that the HINFO exists ==> which looks like the HINFO was just deleted from the zone i.e. temporal inconsistency. The draft optimizes against a) and b) the the cost of the possible extra queries for c) when there is a validating resolver, which most of the time might be a be answering out of cache thus it is not forwarding ANY query. The goal of the draft is to give resolvers something to cache. thus getting help from the resolvers in deflecting the flood. We wanted to optimize defending against the misuse of ANY query in attacks. It is up to each operator to decide what to do and when. Not having a well documented way to deal with this is the main problem. For off-line signed zones the auth server can copy this behavior of "forging" unsigned HINFO and then dealing with the verification triggered extra queries. > > With either method, you have to search down through the zone to find out > whether the node exists (otherwise you'd be returning NXDOMAIN, rather than > a minimized response). Since you're doing that search anyway, choosing an > RRset to return is pretty cheap. And actually, you really *should* also > look through the RRsets at the node to make sure there isn't a non-empty > HINFO record before you synthesize an empty one, and if you're doing *that* > anyway, choosing an RRset wouldn't cost any more and could well cost less. > Given the assumption that we are optimizing for defense there is no need for an authoritative resolver to know if it is authoritative for the zone the query was for, it can just return HINFO as an negative answer to the ANY query type. The whole question is around the following equation "ANY == ALL" I say ANY != ALL, your proposal was so say stop after first RRset found so we agree on the core question the only difference is on what to return. In our proposal you are optimizing for c) without knowing if the type you return is of value to the originator of the query, furthermore your answer is likely to be larger. For me answering few hundred ANY queries a second is not a problem (steady state) , answering few millions a second is a problem (regular events) is. Simple forwarders will keep asking thus what is returned does not matter, > Assuming we aren't considering the possibility of native HINFO records, > I agree that synthesizing an unsigned HINFO would be little quicker > than pulling an RRset out of the node, but not *so* much quicker as > to seem obviously worthwhile. > Depends on how auth server looks up records, not all auth servers have full zones in memory, thus the lookup might be significantly more expensive. > > And for signed zones, synthesizing a signed HINFO would almost > certainly be slower, while returning a pre-signed HINFO would be > no faster than choosing an RRset. > See above about the need to for signing the answer and see if you agree. > > The disadvantages of pick-one-RRset that I can see are 1) more > information leaked (but nothing that couldn't be obtained by sending > queries for individual qtypes anyway), and 2) modestly larger response > size (but still a lot better than unminimized ANY responses). > > Perhaps both approaches should be described in the draft. > If we agree that both are acceptable and each server only needs to support one of the two then that is fine with me. Olafur
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
