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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
