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

[神明達哉 <[e-mail]>]

At Mon, 02 Nov 2015 11:47:26 -0500,
"Joe Abley" <[e-mail]> wrote:

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

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.

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

I'm fine with that.

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

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.

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

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.

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

--
JINMEI, Tatuya