Subject: [DNSOP] comments on draft-jabley-dnsop-refuse-any-01

From: 神明達哉 <[email-masked]>
Date: Mon, 2 Nov 2015 15:21:52 +0900

I've read draft-jabley-dnsop-refuse-any-01.  I have a few comments:

- Section 3

   ANY queries are sometimes used to help mine authoritative-only DNS
   servers for zone data, since they return all RRSets for a particular
   owner name.  A DNS zone maintainer might prefer not to send full ANY
   responses to reduce the potential for such information leaks.

  I'm not opposed to the idea of reducing ANY responses per se, but
  this rationale doesn't sound very strong to me.  There are at most
  64K types of records for a particular of name (of the same class),
  and for a signed zone it's quite easy to get all existing types for
  a particular name (the number of which would usually be much smaller
  than 64K in practice).  It may be true that sending an ANY query is
  an easy and cheap way to get all types of records of a particular
  name today, if you really worry about this type of mining, tweaking
  ANY response won't help much anyway.

- Section 4

   1.  A DNS responder may choose to search for an owner name that
       matches the QNAME and, if that name owns multiple RRs, return
       just one of them.

  If the choice of the "one" is not deterministic and especially if a
  zone uses different authoritative server implementations, then it's
  more likely that they return "inconsistent" responses.  This may not
  be a problem, but we may want to encourage consistent behavior,
  e.g., by suggesting the choice of smallest (not just 'a small') one
  in Section 5.

- In terms of using ANY query for debugging purposes, and if our main
  goal is to prevent abuses like amplification attacks rather than
  mining, I wonder whether we want to allow the original behavior
  under some conditions, e.g., queries authorized by TSIG or sent over
  TCP.

- I wonder whether we want to use a new type of RR rather than HINFO
  for synthesized responses. (I've not closely followed discussions on
  this draft, so perhaps it was already considered and rejected?).

--
JINMEI, Tatuya

---

From: Bob Harold <[email-masked]>
Date: Mon, 2 Nov 2015 10:50:52 -0500

On Mon, Nov 2, 2015 at 1:21 AM, 神明達哉 <[email-masked]> wrote:

> Even a 3 to 1 reduction in queries is a significant bonus to using ANY,
and since most zones are not signed, ANY is very useful.  (But
unfortunately also abusable.)

> +1

> Strong +1 here.

> Do most resolvers cache RR types that they do not recognize?

-- 
Bob Harold

---

From: "Joe Abley" <[email-masked]>
Date: Mon, 02 Nov 2015 11:47:26 -0500

Hi Jinmei,

Many thanks, as usual, for the thoughtful review.

On 2 Nov 2015, at 1:21, 神明達哉 wrote:

> this rationale doesn't sound very strong to me.

I agree. I think that none of the motivations listed for suppressing ANY 
responses are, individually, globally convincing; some will resonate 
strongly with some operators with their own particular set of concerns, 
and others will better resonate elsewhere. The goal was to provide some 
illustrations, not to describe a smoking gun.

Do you think more text is needed to make this clear?

> e.g., by suggesting the choice of smallest (not just 'a small') one

My inclination was to leave this decision up to the implementation, or 
the operator; it wasn't obvious to me that prescribing a single approach 
was likely to result in the best approach in different situations.

We could certainly add some text with the observation that you made, as 
guidance to both implementations and operators -- i.e. advice that a 
particular server or set of servers acting together as a cluster SHOULD 
make a predictable choice in this case, on the basis that predictability 
has operational value.

> under some conditions, e.g., queries authorized by TSIG or sent over

I think we described the whole mechanism as a big giant MAY, and the 
inference we intended was that you don't have to do this at all if you 
don't want to. Choosing not to do it for particular clients or in 
response to particular transport protocols, the presence or absence of 
TSIG or SIG(0) is consistent with the advice in the text, I think -- but 
if you think this needs to be called out explicitly, I am not opposed.

> this draft, so perhaps it was already considered and rejected?).

This suggestion was raised (well, there was angry shouting about how 
wrong HINFO was) by Ed Lewis, and I talked to him briefly about it in 
person in Dublin. Paraphrasing, Ed's strong opinion is that we are 
sending a new kind of information using an RRType that was not defined 
for this purpose, and that doing so is lazy and inconsistent with the 
advice that we gave (e.g.) around SPF vs. TXT.

A counter-argument to that is that this is new behaviour, and that there 
is operational value in being able to send a test query with QTYPE=ANY 
and get a response that is human-readable using existing tools. We 
observe that many systems, even those with bleeding edge versions of 
BIND9/knot/NSD/whatever, often have fairly ancient versions of dig 
installed, and an operator at the command line is best served with a 
response she can read.

I know I have already received multiple questions from people 
troubleshooting ANY queries against cloudflare servers based on the fact 
that the HINFO RDATA contains the token "jabley". Which I am grateful 
for, because I don't get nearly enough e-mail. :-)

HINFO was intended to convey information about a host, and our use of 
HINFO is conveying that kind of information, loosely speaking. Given the 
specific desire to use an RRType that is already understood by deployed 
troubleshooting tools, and mindful of the fact that HINFO is rarely used 
otherwise (I believe there is no example of it being used in the 
portfolio of domains that Cloudflare hosts, and I believe that's also 
true for Dyn), it seemed like a reasonable choice.

Joe

---

From: Tony Finch <[email-masked]>
Date: Mon, 2 Nov 2015 17:12:49 +0000

Joe Abley <[email-masked]> wrote:
> and get a response that is human-readable using existing tools.

On the gripping hand, if you get a TYPE69 answer (say), a web search would
soon explain it is a special abbreviated ANY response.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Westerly or southwesterly 5 to 7. Rough or very rough.
Showers. Moderate or good.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 17 Nov 2015 13:44:52 -0800

At Mon, 02 Nov 2015 11:47:26 -0500,

> Do you think more text is needed to make this clear?

I don't have a particular opinion on the "more text" itself (I'd leave
it to you).  As for this particular "motivation", however, how to deal
with it would affect my other point (allowing ANY query for debugging
purposes), so we'll need to handle these points at the same time, in a
consistent manner.  See below.

> make a predictable choice in this case, on the basis that predictability

I'm fine with that.

> if you think this needs to be called out explicitly, I am not opposed.

Hmm, maybe I have to re-read the whole text again, but my impression
at the time of writing the comment was that many future
implementations will support the mechanism, perhaps with a binary
enable/disable configuration switch whose default is "enable".  If
that's the case, it's quite unlikely that we keep the debugging
capability with ANY since very few users will be willing to disable
the whole feature unconditionally.  So I think it helps if we mention
it explicitly.

And, there's a relationship between this point and about "mining"
motivation (see above): allowing the original ANY behavior for queries
over TCP makes sense if the concern is to be abused for amplification
DoS, but not if it's about "mining".  But "allow it over TCP" will be
more convenient than requiring a stronger authentication like TSIG
since it doesn't require a setup at the client side.

So, if we generally agree that the motivation about "mining" is weak,
it's more consistent if we just don't include it in the motivation
while we mention the possibility of allowing ANY over TCP for
debugging purposes.  Another option is to still mention "mining" in
motivation but we note "ANY over TCP for debugging" will undermine it.

> advice that we gave (e.g.) around SPF vs. TXT.

I, for one, totally agree with this paraphrased argument.  The logic
of the counter-argument in the next paragraph looks to me like a
variant of the typical excuse used by many TXT "abusers".  Allowing
such an argument for ourselves while acting as the RR-type police for
others (dnsop people are the usual suspects as the police in my
understanding) seems to be hypocrisy to me.  Also, the argument that
this is an intended use of HINFO (the last paragraph) sounds arbitrary
and is not very convincing, at least to me.

On the understanding of how HINFO is chosen, I'd now more positively
suggest using a new RR type.

--
JINMEI, Tatuya