On Thu, Oct 01, 2015 at 09:02:09AM -0700, Ólafur Guðmundsson wrote: > Only validating resolver will send follow up query,
Correct, but it would send them to every name server until it got a non-bogus reply. This is unnecessary collateral damage. > 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. I see five categories. Malicious queries can come in directly, or through a resolver, or from a spoofed source. Legitmate queries can come in directly or through a resolver. - With spoofed source queries it doesn't matter what we answer. Setting TC=1 or dropping would be fine. - With a direct query (from dig, for example) it doesn't matter what we answer. REFUSED would be fine. - With a query from a resolver, we have to send an answer that the resolver will accept, so it doesn't keep trying; we also have to send an answer that will *not* impair the resolver's ability to resolve other names later. The problem is, we can't perfectly distinguish between these categories. DNS COOKIE will help to weed out the spoofed sources when it's deployed widely enough to rely on, and DNS RRL will mitigate the damage, but things will always get through. I see no choice but to assume the least convenient case: that a query for type ANY is coming from a resolver which is passing along a query from a legitimate client. In order to avoid doing any harm to that presumptive resolver, we *must* perform a database lookup to find out whether the qname exists and whether it's below a zone cut, so we'll know whether to return NXDOMAIN, a delegation, or a minimized response. And if the zone is signed and we're sending a minimized response, then it *must* include a valid signature. > 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. It doesn't look like an incomplete answer; it looks like a *bogus* answer. A validating resolver will react by sending the same query to every other auth server for the zone until it gets something that validates. Eventually it'll SERVFAIL, and at that point perhaps the application will do something sensible, but we're wasting resolver resources in the meantime. > 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. You've got to search the database for zone cuts, or you'll end up with a resolver thnking example.com is authoritative for www.child-zone.example.com. You've got to search down to see if there's a leaf node above the qname, or the resolver won't be able to use a cached NXDOMAIN as a signal to stop sending queries for descendant nodes in the future. > In our proposal you are optimizing for c) without knowing if the type you > return is of value to the originator of the query, I don't care whether the response is of value to the originator; I'd return no answer at all if I could. (Unfortunately, NODATA for type ANY is interpreted by some caches to mean "no data of any type", and REFUSED wouldn't stop a resolver from asking.) > furthermore your answer is likely to be larger. Admittedly true. Still an improvement over conventional ANY responses. > If we agree that both are acceptable and each server only needs to support > one of the two then that is fine with me. Both are acceptable as long as we don't break the DNS. I cannot support a proposal that does break the DNS. If we do what's necessary to avoid breaking the DNS, then I don't believe there's any practical advantage to the HINFO approach, but I wouldn't oppose. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
