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

[Ólafur Guðmundsson <[e-mail]>]

On Wed, Sep 30, 2015 at 10:08 PM, Evan Hunt <[e-mail]> 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