Subject: [DNSOP] another way to minimize ANY responses

From: Evan Hunt <[email-masked]>
Date: Wed, 25 Mar 2015 20:50:00 +0000

Last night the dumb-idea fairy visited me as I was falling asleep, and
suggested that another way to reduce the impact of ANY queries would be
to pick *one* rrset and return just that. (Probably the numerically
smallest rrtype present at the node, plus RRSIGs if any.)

This avoids poisoning caches with false NODATA, it works for both DNSSEC
and non-DNSSEC zones, meets djb's requirements, makes ANY responses small,
and we don't need to argue about what rrtype to use for synthesized
responses in non-DNSSEC answers.  Still leaks some data (which admittedly
undermines the motivation of Olafur's draft) but not as much and what gets
leaked would be trivial to acquire by other means anyway.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Tony Finch <[email-masked]>
Date: Wed, 25 Mar 2015 21:56:55 +0000

> On 25 Mar 2015, at 20:50, Evan Hunt <[email-masked]> wrote:
> 
> to pick *one* rrset and return just that.

Very nice :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Wed, 25 Mar 2015 22:11:55 +0000

Intriguing. I think there might be a temptation to take this idea one step further and say that preference should be given to the *smallest* RRset possible -- to reduce the degree of amplification. But that would be a mistake. It would, for instance, discriminate IPv4 over IPv6 (since A records are smaller than AAAA records) and certain services over others (SRV records are larger than MX records are larger than A records). When the client doesn't get the RRset it wants from the QTYPE=* query, it'll follow up with one or more subsequent queries for the type(s) it cares about. Not very efficient, and the end result is more "amplification" than was hoped for.

Ideally, the QTYPE=* responder should *learn* what is most *useful* to the client, e.g. if the client usually follows up a QTYPE=* query with a QTYPE=MX query, whenever it doesn't get MX as the chosen QTYPE of the response, then try picking MX as a response to the QTYPE=* more often and see if the client is happier, i.e. the number of followup queries goes down.

Alas, this level of adaptive behavior would require holding more per-client state information in the server than is comfortable, and in any case, is probably beyond the algorithmic capabilities of most DNS implementers...

											- Kevin

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of Tony Finch
Sent: Wednesday, March 25, 2015 5:57 PM
To: Evan Hunt
Cc: [email-masked]
Subject: Re: [DNSOP] another way to minimize ANY responses

> suggested that another way to reduce the impact of ANY queries would 
> be to pick *one* rrset and return just that.

Very nice :-)

Tony.

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Mar 2015 18:20:35 -0400 (EDT)

On Wed, 25 Mar 2015, Darcy Kevin (FCA) wrote:

> When the client doesn't get the RRset it wants from the QTYPE=* query, it'll follow up with one or more subsequent queries for the type(s) it cares about.

First of all, let me re-iterate that this client is broken and not a
valid client implementation of the DNS.

The initial reply could include an NSEC(3) record in the additional
section which lists which RRTYPE's are present in the zone, so the querier
could figure out without a new query if the MX or other type it really
wants, exists.

But as I said, this is improper use of the ANY query and the DNS
protocol.

Paul

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 25 Mar 2015 17:28:41 -0500

All,

First of all, I really like Evan's idea. It's nice and simple to implement.

Also, I think we can just pick any one RRset. In amplification it is no 
worse than querying for the corresponding QNAME/QTYPE. And adding search 
behaviour or learning capabilities adds unnecessary complexity that 
costs additional processing.

Best regards,
  Matthijs

On 03/25/2015 05:11 PM, Darcy Kevin (FCA) wrote:
> Intriguing. I think there might be a temptation to take this idea one
> step further and say that preference should be given to the
> *smallest* RRset possible -- to reduce the degree of amplification.
> But that would be a mistake. It would, for instance, discriminate
> IPv4 over IPv6 (since A records are smaller than AAAA records) and
> certain services over others (SRV records are larger than MX records
> are larger than A records). When the client doesn't get the RRset it
> wants from the QTYPE=* query, it'll follow up with one or more
> subsequent queries for the type(s) it cares about. Not very
> efficient, and the end result is more "amplification" than was hoped
> for.
>
> Ideally, the QTYPE=* responder should *learn* what is most *useful*
> to the client, e.g. if the client usually follows up a QTYPE=* query
> with a QTYPE=MX query, whenever it doesn't get MX as the chosen QTYPE
> of the response, then try picking MX as a response to the QTYPE=*
> more often and see if the client is happier, i.e. the number of
> followup queries goes down.
>
> Alas, this level of adaptive behavior would require holding more
> per-client state information in the server than is comfortable, and
> in any case, is probably beyond the algorithmic capabilities of most
> DNS implementers...
>
> - Kevin
>
> -----Original Message----- From: DNSOP
> [mailto:[email-masked]] On Behalf Of Tony Finch Sent:
> Wednesday, March 25, 2015 5:57 PM To: Evan Hunt Cc: [email-masked]
>> Last night the dumb-idea fairy visited me as I was falling asleep,
>> and suggested that another way to reduce the impact of ANY queries
>> would be to pick *one* rrset and return just that.
>
> Very nice :-)
>
> Tony. -- f.anthony.n.finch  <[email-masked]>  http://dotat.at
>
> _______________________________________________ DNSOP mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________ DNSOP mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 25 Mar 2015 17:37:23 -0500

Speaking for myself, I love Evan's idea with picking one rrset. It is 
simple.  Would the simplest be to grab the first rrset it finds?

tim

---

From: Michael Sinatra <[email-masked]>
Date: Wed, 25 Mar 2015 16:04:24 -0700

> simple.  Would the simplest be to grab the first rrset it finds?

I think that's the simplest solution.  If you instead pick a record to
return beforehard, (e.g. A), then what if the QNAME doesn't have an A
record?  Do you then pick CNAME?  MX?  If you just pick the first
record, it's "fair" (doesn't privilege one RRTYPE over another) and easy
to implement.

I am also okay with including the RRSIG for the first record, if available.

michael

---

From: Ralf Weber <[email-masked]>
Date: Wed, 25 Mar 2015 18:53:50 -0500

Moin!

On Wed, Mar 25, 2015 at 10:11:55PM +0000, Darcy Kevin (FCA) wrote:
> Intriguing. I think there might be a temptation to take this idea one step
> further and say that preference should be given to the *smallest* RRset
> possible -- to reduce the degree of amplification.  But that would be a
> mistake.  It would, for instance, discriminate IPv4 over IPv6 (since A
> records are smaller than AAAA records) and certain services over others
> (SRV records are larger than MX records are larger than A records).
You can make an A record response that is a lot larger than an AAAA
response, as you reply with an RRSET that can hold a lot of A records.
That is the currently very popular with attackers that create purpose
build amplification domains.

>  When
> the client doesn't get the RRset it wants from the QTYPE=* query, it'll
> follow up with one or more subsequent queries for the type(s) it cares
> about.  Not very efficient, and the end result is more "amplification"
> than was hoped for.
I think we agreed long ago somewhere in this threat that all of this will
not help with reducing amplification attacks.

Other than that I think it could work, as ANY != ALL ;-).

So long
-Ralf

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Mar 2015 17:24:32 -0700

> Tim Wicinski <mailto:[email-masked]>
> Wednesday, March 25, 2015 3:37 PM
>
> Speaking for myself, I love Evan's idea with picking one rrset.

i didn't want to be the first to say so, since a lot of the ideas i like
are ugly ducklings. but since others have chimed in positively, i'll add
my voice: this is a beautiful swan.

> It is simple.  Would the simplest be to grab the first rrset it finds?

that would be an overspecification. the spec should simply say "any
RRset, where the choice of which RRset is implementation-dependent".
some might go for oldest; some for smallest; some for first. we should
not say, other than perhaps to say "if an implementation always chooses
its RRset according to static preferences, then AAAA should have a
higher priority than A."

-- 
Paul Vixie

---

From: Evan Hunt <[email-masked]>
Date: Thu, 26 Mar 2015 06:20:55 +0000

> my voice: this is a beautiful swan.

Thanks. :)

> some might go for oldest; some for smallest; some for first.

My one suggestion is that it not be random; for any given set of
two more more types at a node, a succession of ANY queries should
all get back the same response. (Otherwise there's an unnecessary
increase in leaked information, and RRL might not count the responses
as duplicates.)  That's why I initially suggested "numerically smallest
rrtype present", but any repeatable selection criteria would be fine.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Mar 2015 23:26:51 -0700

Evan Hunt wrote:
> ...

you make an excellent point. so, the spec might ask for repeatability,
but not specify how that's to be achieved. it's still an information
leak since the preferred type may have timed out of the cache, in which
case an rdns would have to return the next thing on its priority list.
(refetching should NOT be done!)

-- 
Paul Vixie

---

From: Florian Weimer <[email-masked]>
Date: Thu, 26 Mar 2015 10:48:28 +0100

> smallest rrtype present at the node, plus RRSIGs if any.)

Yes, this looks quite reasonable.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Mar 2015 06:36:38 -0500

> (refetching should NOT be done!)

I don't think you need a priority list--any deterministic mechanism will do.   I'd suggest using the numerical RRtype code, and choosing the highest number.   This will not always return the smallest RR, but it has the virtue of preferring AAAA to A, but quite possibly sending neither (which I think is even better).

---

From: Tony Finch <[email-masked]>
Date: Thu, 26 Mar 2015 11:52:14 +0000

A further thought...

My too-clever (not clever enough?) hack can cause problems downstream,
if you have

1. auth (DNSSEC) -> 2. cache (DNSSEC) -> 3. cache (insecure) -> 4. resolver

3 sends a DO=0 ANY query to 2

2 sends a DO=1 version of the query to 1

1 does ANY minimization and responds with a signed NSEC (and nothing else)

2 does not know about ANY minimization

What does 2 return to 3? It can't send a signed NSEC because DO=0.

If 2 returns noerror/nodata then 3 will cache this (for all RRtypes) and
will fail to forward subsequent queries from 4 for other RRtypes.

If 1 uses Evan's ANY minimization then 2 will be able to safely drop any
DNSSEC rubric when passing the response to 3, without implying there are
no records at the QNAME. So 3's cache entry will not suppress queries for
other RRtypes.

To summarize: one constraint on a minimal ANY response is that if there
are non-DNSSEC records at the QNAME then the answer must include at least
one of them, that is, it must not look like a NODATA response.

Another way of saying this is that you can't just translate an ANY query
into a query for a fixed RRtype: as Evan said, you have to look at the
data at the QNAME so you can pick one of the existing RRsets and return
that.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle, Faeroes: Southeast becoming cyclonic 6 to gale 8, occasionally
severe gale 9 in Faeroes, becoming west 4 or 5 later. Moderate or rough,
becoming very rough for a time. Rain or showers. Good, occasionally poor.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 26 Mar 2015 16:20:29 +0100

> What does 2 return to 3? It can't send a signed NSEC because DO=0.

ANY is special, you can get NSEC and RRSIG in responces with DO=0
(some implementations do that).  With suitably aligned TTLs, I suppose
you can even end up with just a NSEC/RRSIG RRset pair.

NSEC3 is different because of the QNAME mismatch.  There, the problem
you describe actually exists, I think.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 26 Mar 2015 14:28:46 -0700

Ted Lemon wrote:
>> you make an excellent point. so, the spec might ask for repeatability, but not specify how that's to be achieved. it's still an information leak since the preferred type may have timed out of the cache, in which case an rdns would have to return the next thing on its priority list. (refetching should NOT be done!)
>

priority list is an example of determinative. so is sorting by numeric
rr type value. but in either case, as those rrsets expire, others will
be exposed -- an information leak. or if a certain type is preferred,
then when that rrset expires, re-fetching will occur -- another
information leak.

what we should say in the spec is "determinative, and non-information-leaking", and let implementers scratch their heads about how to do that. we should not try to invent it here, or specify it in an ietf document.

-- 
Paul Vixie

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Mar 2015 18:33:18 -0500

> what we should say in the spec is "determinative, and non-information-leaking", and let implementers scratch their heads about how to do that. we should not try to invent it here, or specify it in…

I don't see how you can do that without maintaining state.   So this may be a nice general thing to specify, but is it a _good_ thing to specify?

---

From: Evan Hunt <[email-masked]>
Date: Fri, 27 Mar 2015 01:10:38 +0000

On Thu, Mar 26, 2015 at 06:33:18PM -0500, Ted Lemon wrote:
> > what we should say in the spec is "determinative, and
> > non-information-leaking", and let implementers scratch their heads
> > about how to do that. we should not try to invent it here, or specify
> > it in an ietf document.
>
> I don't see how you can do that without maintaining state.   So this may
> be a nice general thing to specify, but is it a _good_ thing to specify?

"Determinate" is necessary, for reasons stated earlier. As long as the
authority doesn't change the content of a node, the ANY response should
stay the same.  But if the node content does change (e.g., there's an A
rrset that wasn't there before), then the ANY response may change, and I
don't think we need to contort ourselves to prevent that.  So IMHO it's not
necessary to emphasize "non-information-leaking" with the same level of
urgency, though it's desirable.

It *might* be kinda vaguely desirable to offer guidance on the selection
method to use, so that people get the same predictable ANY answers from
BIND, NSD, etc.  Otherwise, you could characterize it as an information
leak if someone were running multiple implementations on different servers,
and one of them returns AAAA and another one MX, etc.  However, it can't
possibly be any worse of a leak than merely running an old server that
doesn't implement ANY minimization, so on balance I agree with Paul that
it would be an overspecification.

---

From: Jan Včelák <[email-masked]>
Date: Sat, 28 Mar 2015 20:55:59 +0100

On 26.3.2015 07:26, Paul Vixie wrote:
> but not specify how that's to be achieved.

I think the repeatable selection criteria should be specified exactly,
so that all authoritative servers for one zone would return the same
result regardless the server implementation.

This also means, that the selection criteria should be RR type/content
based. Some information (e.g., RR creation or age) is not preserved on
zone transfers.

Jan