Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

[Evan Hunt <[e-mail]>]

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-mail]
Internet Systems Consortium, Inc.