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

From: Shane Kerr <[email-masked]>
Date: Thu, 1 Oct 2015 10:12:41 +0000

Joe and all,

On 2015-10-01 02:25-0400
"Joe Abley" <[email-masked]> wrote:

> On 1 Oct 2015, at 1:08, Evan Hunt wrote:
> 
> > 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.
> 
> I think I've run out of reasons why the HINFO approach is better than 
> your pick-one idea, which mainly leaves us with the HINFO approach 
> feeling a lot like a dirty hack that makes me want to shower, while 
> yours gets the job done without needing updates to 1035, assuming we 
> feel comfortable with the assertion that ANY doesn't have to mean ALL in 
> the context of an authority server. I like it quite a lot. Sorry again 
> to have missed it when you first brought it up.
> 
> Olafur had a particular code-base in mind as motivation for documenting 
> this, and he may have some perspectives that I have missed. On that 
> note, I will take a few steps away from the microphone.

In the case where people just want to reduce the damage of ANY queries
in reflection attacks, I quite like the PowerDNS option of forcing ANY
queries to TCP via truncation. I'm not sure if this has been documented
in any RFC, but if not then perhaps it bears mentioning too?

Cheers,

--
Shane

---

From: Dick Franks <[email-masked]>
Date: Thu, 1 Oct 2015 12:13:34 +0100

Dick Franks
________________________

> in any RFC, but if not then perhaps it bears mentioning too?

That rests on two assumptions:

1)  that damage limitation from reflection attacks is the primary concern
here, which appears no longer to be the case.

2) that there is some plausible reason for doing ANY queries, in which case
it would be interesting to know what that might be.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 1 Oct 2015 12:30:57 +0000

On 2015-10-01 12:13+0100

> Dick Franks

The draft documents amplification attacks:

   ANY queries are also frequently used to exploit the amplification
   potential of DNS servers using spoofed source addresses and UDP
   transport (see [RFC5358]).  Having the ability to return small
   responses to such queries makes DNS servers less attractive
   amplifiers.

Which is why I mention it.

> it would be interesting to know what that might be.

The entire draft presumes some plausible reason for doing ANY queries,
otherwise it would just say "we hereby deprecate ANY queries". :P

In fact the start of the motivations section tries to address this:

   ANY queries are legitimately used for debugging and checking the
   state of a DNS server for a particular owner name.

I'm not sure I totally agree, since I have never had occasion to use an
ANY query in anger, but some people seem really attached to it.

Cheers,

--
Shane

---

From: Paul Vixie <[email-masked]>
Date: Thu, 01 Oct 2015 07:33:10 -0700

> in any RFC, but if not then perhaps it bears mentioning too?

note that in a normal reflective ddos where a lot of ANY queries are
being received, the above proposal results in a full TCP session table,
thus denying TCP service to any non-attacker.

this is not a serious problem since virtually anyone can launch a denial
of service against TCP/53, without a distributed attack force. so, that
problem already exists.

if it's going to become a documented operational practice, then this
risk should be documented also.

-- 
Paul Vixie

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 1 Oct 2015 09:02:09 -0700

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

> 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

---

From: Evan Hunt <[email-masked]>
Date: Fri, 2 Oct 2015 03:41:01 +0000

> 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.

> c) Resolver forwarding a ANY query because the cache for that name was

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.

> 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.

> the query was for, it can just return HINFO as an negative answer to the

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.

> 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.

> 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 -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Dave Lawrence <[email-masked]>
Date: Sun, 4 Oct 2015 10:32:51 -0400

A couple of quick observations:

* The draft says that the answer in a signed zone MAY be unsigned.
  Since this will ultimately cause a SERVFAIL for validating
  resolvers, it is not really acceptable.

* The draft does not describe at all what the proper behaviour is for
  an owner name that has a CNAME record.  Since CNAMEs require special
  handling, this should be addressed.  Personally I think the CNAME
  should be returned in this case.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Sun, 4 Oct 2015 08:57:03 -0700

>   resolvers, it is not really acceptable.

You and Evan,
 are right we will update the document to reflect this, as returning
unsigned answers is only
accepted by non-validating resolvers and figuring out if resolver is
validating requires tracking resolver behavior
thus it is simpler and cheaper to sign.
Servers with Off-line signed zones have more to gain from this
functionality.

> good point, we will address it

Olafur

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Oct 2015 15:14:46 +1100

In message <CAN6NTqxTA5Zo-tFS3TkQ4V08BZq_UyRN4ZQ_=[email-masked]>
> > good point, we will address it

Given * doesn't recurse for CNAME and CNAME can only exist with
NSEC/KEY/RRSIG I would suggest that CNAME + RRSIG is returned.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]