Subject: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

From: [email-masked]
Date: Wed, 08 Feb 2017 21:56:36 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY
        Authors         : Joe Abley
                          Olafur Gudmundsson
                          Marek Majkowski
	Filename        : draft-ietf-dnsop-refuse-any-04.txt
	Pages           : 10
	Date            : 2017-02-08

Abstract:
   The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
   The operator of an authoritative DNS server might choose not to
   respond to such queries for reasons of local policy, motivated by
   security, performance or other reasons.

   The DNS specification does not include specific guidance for the
   behaviour of DNS servers or clients in this situation.  This document
   aims to provide such guidance.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 8 Feb 2017 21:58:03 -0800

This version addresses all the comments that the chair's determined needed
addressing.

Olafur

On Wed, Feb 8, 2017 at 9:56 PM, <[email-masked]> wrote:

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

---

From: "Woodworth, John R" <[email-masked]>
Date: Thu, 9 Feb 2017 08:53:22 +0000

Olafur,

This is my first draft review so apologies if it seems harsh, I
really like the concept of this draft.

Comments:

--
Section 4.1 "Select one RRSet mode" -

The section including "...choose a small one(s) to..." seems
confusing, a single RRSet is expected why the possibility of
multiple RRsets?

--
Section 4.2 "Synthesised HINFO RRset" -

I do not follow the section including "...query includes DO=1...".
Should the implementation fall back to the one-RRSet-mode?  If the
only RRSet returned is a synthesized HINFO one, what does the
returned RRSIG correspond to?

--
General -

I would personally like to see more direction for implementers
provided in the draft, e.g. expected configurable features.
I realize this is a matter of personal taste.

Thanks and good luck,
John

-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 9 Feb 2017 07:29:50 -0800

John,

Thanks for the review
you are spot on, I should not edit while watching a soccer game :-(

I will post an updated version in the next few days.

how about for section 4.1:
I was trying to cover the case where the RRSET selected has Multiple
RRSIG's not

About 4.2.
Implementation may choose this when it can, if it can not for a zone then
fall back on 4.1

as for the guidance, I tried, but there are strong opinions out there and
.....

Olafur

On Thu, Feb 9, 2017 at 12:53 AM, Woodworth, John R <
[email-masked]> wrote:

> This communication is the property of CenturyLink and may contain
> confidential or privileged information. Unauthorized use of this
> communication is strictly prohibited and may be unlawful. If you have
> received this communication in error, please immediately notify the sender
> by reply e-mail and destroy all copies of the communication and any
> attachments.
>

---

From: Richard Gibson <[email-masked]>
Date: Thu, 9 Feb 2017 23:47:35 -0500

With full realization that this is coming very late in the game, we had a
great deal of internal conversation within Dyn about implementing
refuse-any, and came away unsatisfied with both the "subset" and "HINFO"
approaches—the latter because of reasons that have already been covered,
and the former for lacking in-band signaling of non-"conventional"
incompleteness to aid legitimate use.

I believe there is sufficient cause to reserve a new OPT record EDNS header
flag bit
<http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-13>
for indicating "partial response" (as distinct from "truncation"). It will
be safely ignored by current clients, but convey the desired information to
those in the know.

P.S. Our discussion also raised some more minor points:

   - Insisting that the HINFO OS field SHOULD be empty ("set to the null
   string") seems a little too strong; there's room in it for (and value
   from) a short explanation (e.g., cloudflare.com. 3789 IN HINFO "Please
   stop asking for ANY" "See draft-ietf-dnsop-refuse-any"). I'd prefer text
   like "The OS field of the HINFO RDATA SHOULD be short to minimize the size
   of the response, and MAY be empty or MAY include a summarized
   description of local policy."
   - "Conventional [ANY] response" is used but not defined.
   - "ANY does not mean ALL" is misleading—RFC 1035
   <https://tools.ietf.org/html/rfc1035#section-3.2.3> is clear about
   QTYPE=255 being "a request for *all* records" (emphasis mine). That
   said, the proposed *response* behavior is consistent with that RFC.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Fri, 10 Feb 2017 10:44:16 -0800

Thank you for your comments

Q: why do you think it is useful to complicate things with a EDNS0 flag ?

Olafur

On Thu, Feb 9, 2017 at 8:47 PM, Richard Gibson <[email-masked]> wrote:

> I believe there is sufficient cause to reserve a new OPT record EDNS
> header flag bit
>    stop asking for ANY" "See draft-ietf-dnsop-refuse-any"). I'd prefer
>    text like "The OS field of the HINFO RDATA SHOULD be short to minimize
>    the size of the response, and MAY be empty or MAY include a summarized

---

From: Richard Gibson <[email-masked]>
Date: Fri, 10 Feb 2017 15:01:57 -0500

Because without such a signal, humans using ANY for legitimate diagnostic
purposes have no means of differentiating section 4.1/4.3 "subset"
responses from conventional responses where there just happen to be only a
small number of RRSets at the queried name, encouraging (or at least doing
nothing to dissuade) a conclusion that the response is in fact conventional
and complete.

On Fri, Feb 10, 2017 at 1:44 PM, Ólafur Guðmundsson <[email-masked]>
wrote:

>>    text like "The OS field of the HINFO RDATA SHOULD be short to
>>    minimize the size of the response, and MAY be empty or MAY include a
>>    summarized description of local policy."

---

From: "Woodworth, John R" <[email-masked]>
Date: Fri, 10 Feb 2017 20:43:11 +0000

Richard, Olafur;

Just reread your draft and had a question.

Would it be worthwhile to formalize a default result-set for an ANY query in your draft?  Seems like there is a great disparity among implementations and as pointed out in your draft clients looking to save calories with a single query still require fallback logic “just in case” they don’t get what is expected.

Since this draft defines 3 alternate methods for determining responses, a 4th could formally define “normal”.  Just a thought.

BTW: like the idea of a the flag to better control intent.

Thanks,
John

From: DNSOP [mailto:[email-masked]] On Behalf Of Richard Gibson

Because without such a signal, humans using ANY for legitimate diagnostic purposes have no means of differentiating section 4.1/4.3 "subset" responses from conventional responses where there just happen to be only a small number of RRSets at the queried name, encouraging (or at least doing nothing to dissuade) a conclusion that the response is in fact conventional and complete.

On Fri, Feb 10, 2017 at 1:44 PM, Ólafur Guðmundsson <[email-masked]<mailto:[email-masked]>> wrote:
Thank you for your comments

Olafur

---

From: Tony Finch <[email-masked]>
Date: Mon, 13 Feb 2017 13:03:18 +0000

> nothing to dissuade) a conclusion that the response is in fact conventional

There are several ways to avoid this pitfall:

Use TCP

Look for an NSEC(3) record

Query for the specific types you want to know about

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: East 7 to severe gale 9, occasionally storm 10 at first near welsh
coast, veering southeast 5 to 7. Moderate or rough. Mainly fair. Moderate or
good.

---

From: Richard Gibson <[email-masked]>
Date: Mon, 13 Feb 2017 09:33:35 -0500

> Query for the specific types you want to know about

The pitfall comes from unexamined muscle-memory assumptions when inspecting
a DNS response, so none of those methods avoid it. They're expecting people
to remember that longstanding behavior has changed without providing any
clue about it.

---

From: Tony Finch <[email-masked]>
Date: Mon, 13 Feb 2017 16:46:03 +0000

> to remember that longstanding behavior has changed without providing any

OK. But does an EDNS flag help? What if you are using old tools?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey: Southeasterly 5 to 7, occasionally gale 8 in south. Rough,
becoming very rough for a time in south. Fair. Good.

---

From: Richard Gibson <[email-masked]>
Date: Mon, 13 Feb 2017 12:06:14 -0500

> OK. But does an EDNS flag help? What if you are using old tools?

If you are using old tools, then you don't get new conveniences (the same
is true of using OPT class to specify a maximum payload size exceeding 512
bytes, using the DO bit to request DNSSEC records, and using the COOKIE
option for authentication). But a flag would still be there, conveying
information even if any given client or tool isn't looking for it.

---

From: Robert Edmonds <[email-masked]>
Date: Mon, 13 Feb 2017 12:38:01 -0500

> information even if any given client or tool isn't looking for it.

It looks like dig does display unknown EDNS flags -- as a masked hex
value:

https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=lib/dns/message.c;h=45bd0ba9ea31be49ffa5bca2aebb77ebc2f3b95c;hb=4801fbccaa431ca6a72753150cbb58e5d4627cc4#l3408

You think this would actually provide any sort of useful information? No
operator would understand what "MBZ: 0xNNNN" means without re-training,
and if you're re-training operators you may as well point them to this
document.

-- 
Robert Edmonds

---

From: Richard Gibson <[email-masked]>
Date: Mon, 13 Feb 2017 12:50:16 -0500

> and if you're re-training operators you may as well point them to this

I think it would be _very_ useful. People easily forget new information,
but seeing unexpected data like that would provide the necessary trigger
for remembering this document and e.g. retrying with +tcp.

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 13 Feb 2017 18:02:56 +0000

> On Feb 13, 2017, at 9:50 AM, Richard Gibson <[email-masked]> wrote:
> 
> I think it would be _very_ useful. People easily forget new information, but seeing unexpected data like that would provide the necessary trigger for remembering this document and e.g. retrying with +tcp.

I dislike the idea of a EDNS "partial response" flag.

Tools like dig, when asked to issue an ANY query over UDP can:

1) fail with "ANY over UDP is deprecated", or
2) warn with "ANY over UDP might give partial results", or
3) automatically use TCP

DW

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 13 Feb 2017 10:05:53 -0800

> for remembering this document and e.g. retrying with +tcp.

Richard,

HINIFO is such a signal :-)
thus your request applies only to Send-one and Send-useful responses.
I do not think adding complexity will help at all.

 ... you want an overhead cost forever just because of "muscle memory"
learning curve for few people.

Olafur

---

From: Richard Gibson <[email-masked]>
Date: Mon, 13 Feb 2017 13:15:25 -0500

> 1) fail with "ANY over UDP is deprecated", or

That's not true, though, and tools have no way of knowing whether or not
such a failure is appropriate without the very signal I'm requesting.

> 3) automatically use TCP

Regardless of anything else, those are both reasonable.

---

From: Richard Gibson <[email-masked]>
Date: Mon, 13 Feb 2017 13:15:28 -0500

> thus your request applies only to Send-one and Send-useful responses.

Correct, as I covered in my initial message.

> learning curve for few people.

The overhead is already proposed by this document for name servers to apply
special QTYPE=ANY processing; I'm just advocating for its communication to
clients.

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 13 Feb 2017 18:31:48 +0000

> On Feb 13, 2017, at 10:15 AM, Richard Gibson <[email-masked]> wrote:
> 
> On Mon, Feb 13, 2017 at 1:02 PM, Wessels, Duane <[email-masked]> wrote:
> That's not true, though, and tools have no way of knowing whether or not such a failure is appropriate without the very signal I'm requesting.

Deprecated may not be the best choice of wording, even though it was in the title of the original draft and got my hopes up.

However, the authors of dig and other tools, having read this new RFC, can decide that they will no longer support ANY over UDP and exit with an error message saying so and provide hints ("use +tcp") for how to make it work.

DW

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Feb 2017 09:21:50 +1100

We don't need any new signalling.  If the answer is truncated you
set tc=1.  This works with all existing clients.

If there is only a single RRset + RRSIGs then you don't get tc=1
except for traditional space reasons.

Mark
-- 
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: Mon, 13 Feb 2017 22:29:58 +0000

Mark Andrews <[email-masked]> wrote:

> set tc=1.  This works with all existing clients.

One of the points of minimal-any is that the answer is not truncated
because you do not want clients to automatically retry over TCP. This is
to handle situations where many third-party recursive servers are under
attack using one of your names, so the recursive servers are hitting
your authoritative servers hard. RRL does not work in this case, because
the clients are legitimate recursive servers. You want to give them an
answer asap, that they can cache without hitting TCP.

Tony.

--

f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--
  zr8h punycode

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 13 Feb 2017 22:43:23 GMT

> From: Tony Finch <[email-masked]>

> answer asap, that they can cache without hitting TCP.

On the contrary, as that case is described, RRL works fine, and
this minimal-any mechanism won't help the obvious attack situation
in that might be intended.

Each legitimate recursive server will ask once per some TTL and
cache the rrsets that it gets.  No single legitimate recursive
server will make a lot of ANY requests per unit time.

An attack that might be intended involves many open recursive servers
(perhaps open only local infected eyeball stubs) being hit for only a
few requests each (or at least passing on only a few each request) for
your names but many all together.

However, in that case how many legitimate recursive servers will
send ANY requests to authorities?

Vernon Schryver    [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Feb 2017 10:07:04 +1100

> send ANY requests to authorities?

Any with a empty cache for name when the query comes in and a qtype
255 in the request.

The hard part of a 255 request is just having cached negative
responses for individual types doesn't result in useful response
to the request.  You still need to recurse with qtype 255 to get
some data to return including NODATA for a ENT.

Mark

---

From: Tony Finch <[email-masked]>
Date: Mon, 13 Feb 2017 23:29:41 +0000

> cache the rrsets that it gets. 

Not if the authoritative server is overloaded and has run out of TCP
sockets and is unable to answer the question. The recursive servers will
all then be perpetually retrying while the attack continues, so the
authoritative servers will never recover from overload.

> send ANY requests to authorities?

In the case of this attack it was thousands.

Tony.

--