Subject: [DNSOP] draft-ietf-dnsop-refuse-any and QTYPE=RRSIG

From: Tony Finch <[email-masked]>
Date: Fri, 5 Feb 2016 22:10:08 +0000

Last weekend one of our authoritative name servers
(authdns1.csx.cam.ac.uk) suffered a series of DoS attacks which made it
rather unhappy. Over the last week I have developed a patch for BIND to
implement draft-ietf-dnsop-refuse-any which should allow us to handle
ANY flood attacks better. http://fanf.livejournal.com/140566.html

I still have a potential problem with RRSIG queries, which work a lot like
ANY queries. Cloudflare's approach is to simply refuse them, which makes a
lot of sense because RRSIG queries don't have the same interop concerns as
ANY queries. However, in an attack like the ones we had last weekend where
the queries arrived at our authoritative servers from lots of real
recursive servers, a refusal will cause retries and make the attack worse.

Would it be reasonable as an alternative to follow the refuse-any approach
and just return the RRSIG(s) for one RRset? If so, I think this suggestion
should be included in the draft.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Thames, Dover: Southwest 5 to 7, occasionally gale 8 later, perhaps severe
gale 9 later. Moderate, occasionally rough later. Occasional rain or drizzle.
Moderate or good, occasionally poor.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 06 Feb 2016 09:42:14 +1100

In message <[email-masked]>, Tony Fi
> should be included in the draft.
 
Yes, for both SIG and RRSIG.  They are not useful queries on their
own.  I am discounting the corner case of a non DNSSEC aware recursive
server in front of a validating client as that does not work reliably
with DNS loose coherency.

Mark

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Fri, 5 Feb 2016 22:48:51 +0000

Mark Andrews <[email-masked]> wrote:
> > Would it be reasonable as an alternative to follow the refuse-any
> > approach and just return the RRSIG(s) for one RRset? If so, I think
> > this suggestion should be included in the draft.
>
> Yes, for both SIG and RRSIG.

Thanks :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Biscay: Southerly veering southwesterly 5 to 7, occasionally gale 8.
Moderate or rough, occasionally very rough later in northwest. Rain later.
Good, occasionally poor later.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Sat, 6 Feb 2016 00:56:14 +0000

> should be included in the draft.
For all you care you an even return a forged RRSIG/SIG i.e. one that is
made up on the fly
just make sure it covers a non existing TYPE :-)

   Olafur

---

From: Tony Finch <[email-masked]>
Date: Sun, 7 Feb 2016 14:16:15 +0000

Another question:

In order to minimize responses even further, I have made my code omit or
include signature records depending on whether DO=0 or DO=1. That is, and
ANY query with DO=0 gets one arbitrary unsigned RRset in response, and an
ANY query with DO=1 gets one arbitrary signed RRset.

Is this sensible, and if do should it be suggested by the draft?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle: Southerly becoming cyclonic 5 to 7, occasionally gale 8 at first in
east. Rough or very rough. Rain or showers. Good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Sun, 7 Feb 2016 14:20:11 +0000

Ólafur Guðmundsson <[email-masked]> wrote:
> made up on the fly just make sure it covers a non existing TYPE :-)

Make it an RRSIG covering an RRSIG with a private algorithm and you don't
even need to do any crypto :-) (Not entirely serious suggestion.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire, Forties, Cromarty, Forth: Southerly or
southwesterly 6 to gale 8, occasionally severe gale 9 at first, decreasing 5
at times later. Rough or very rough, becoming high for a time except in
Cromarty and Forth. Rain or showers. Moderate or good, occasionally poor.

---

From: Evan Hunt <[email-masked]>
Date: Sun, 7 Feb 2016 20:04:49 +0000

> Is this sensible, and if do should it be suggested by the draft?

Yes. I haven't looked in the draft recently, but I thought I mentioned that
when I originally described this trick.  Choose an arbitrary (preferably
determinate) rrset to return, and include its covering signature if it
exists and DO=1 so the response can validate.

                                        eh

---

From: Tony Finch <[email-masked]>
Date: Mon, 8 Feb 2016 15:33:07 +0000

Evan Hunt <[email-masked]> wrote:
>
> Choose an arbitrary (preferably determinate) rrset to return, and
> include its covering signature if it exists and DO=1 so the response can
> validate.

Right.

My code currently just picks the first RRtype it gets from the backend
data store (or the type covered if the first RRtype is a signature type).
This is stable on a single server but different servers can return the
data in a different order.

Doing anything more determinate would require an extra loop over the data
to choose, before the loop that builds the response. (Actually I can
probably avoid two loops if I'm clever.) I didn't think I cared enough to
do that. However some answers from my zones (e.g. DNSKEY) are bigger than
512 bytes and so can cause truncation and TCP, so maybe I do care after
all.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole, Lundy, Fastnet: West gale 8 to storm 10, decreasing 6 to gale 8,
occasionally 11 at first except in Sole. Very high or phenomenal, becoming
very rough or high. Squally showers. Moderate or poor.

---

From: Jared Mauch <[email-masked]>
Date: Mon, 8 Feb 2016 10:37:09 -0500

> On Feb 8, 2016, at 10:33 AM, Tony Finch <[email-masked]> wrote:
> 

Or just having the TCP implementation in BIND get improved as it’s clear there
are some more people pushing in this direction.  I’m looking at just putting
something like DNSDIST on my hosts to process TCP and balance it across
multiple daemons to do the query scale.

- Jared

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 8 Feb 2016 16:46:36 +0000

> Is this sensible, and if do should it be suggested by the draft?
Tony: the draft says right now:

A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, and MAY instead send a response with a single
   RRSet in the answer section.

   The RRSet returned in the answer section of the response MAY be a
   single RRSet owned by the name specified in the QNAME.  Where
   multiple RRSets exist, the responder MAY choose a small one to reduce

   its amplification potential.

Is that not sufficient ?

Olafur

---

From: Tony Finch <[email-masked]>
Date: Mon, 8 Feb 2016 16:58:07 +0000

Ólafur Guðmundsson <[email-masked]> wrote:

> Tony: the draft says right now: [...]
>
> Is that not sufficient ?

The most relevant bit in the current draft is:

   If the DNS query includes DO=1 and the QNAME corresponds to a zone
   that is known by the responder to be signed, a valid RRSIG for the
   RRSets in the answer section MUST be returned.

which does in fact imply that you can leave the RRSIGs out when DO=0
if you read it properly (which I evidently failed to do!) but it's
probably worth saying so explicitly.

Tony.

---

From: bert hubert <[email-masked]>
Date: Mon, 8 Feb 2016 22:38:13 +0100

> multiple daemons to do the query scale.

With a liiiitle work btw dnsdist could proxy TCP/IP questions over UDP with
gigantic packet sizes. This would get you TCP/IP to the unwashed BCP38-free
masses but UDP in your home network.

Might that be a good idea?

	Bert