On Wed, 18 Mar 2015, Paul Vixie wrote:
Paul Wouters wrote:
On Tue, 17 Mar 2015, Yunhong Gu wrote:
The reason that this response can be used for an amplification
attack is its size, not the ANY type.
A responses with 200 A records can be used for the same purpose.
The (even deeper) root cause is the
use of UDP in DNS protocol. I just do not think banning ANY touches
any of these fundamental issues.
Right, so require tcp or eastlake cookies,
that would protect third parties, but not the server itself.
It offers some protection, but it is not perfect.
or allow padding the ANY
request so the request/response ratio is close to 1 before allowing
the answer.
that would not prevent the unfortunate information leak that allows third
parties to scan our caches.
So there are two clear distinct use cases. ANY against authoritative and
ANY against caches. I agree that one could limit ANY queries of caches
to a sysadmin only ACL. We lose some remote debugging capability but
gain some privacy. Putting an ACL in on the authoritative server is
much more complex - it could backfire as a long discussion in the last
week on how to refuse those queries show.
Make the dig command default to tcp. That should cover
the vast majority of valid ANY queries.
my proposal is, limit ANY to a selected set of source-ip addresses, as is
commonly done with AXFR/IXFR.
Which I answered before by saying that is basically killing the ANY
query. The proposed solution merely pretends to not kill it by saying
"acl". But let me clarify that I think putting an ACL on the recursive
is fine - legitimate applications should not use use ANY queries and
this is a fine mechanism to ensure the qmail's and firefoxes of the
future won't make the same mistake.
The trick of requiring ANY comes via verified sourc IP or a question
packet bigger than the response ensures this query type will cease to
be used for amplification. If we want to do this we should start changing
our legitimate tools to do this so at some point in the future we
could enforce this without breaking our own toolbox.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
