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

["Joe Abley" <[e-mail]>]

Hi Jinmei,

Many thanks, as usual, for the thoughtful review.

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

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

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?

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

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

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

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