Re: [DNSOP] Suggestion for "any" - TCP only

[Hugo Maxwell Connery <[e-mail]>]

+1

(privacy response is with all, and this specific issue is not an amplification one)

Hugo Connery,
Technical University of Denmark
________________________________________
From: DNSOP [[e-mail]] on behalf of Paul Vixie [[e-mail]]
Sent: Tuesday, 10 March 2015 01:35
To: Paul Wouters
Cc: dnsop; Brian Dickson
Subject: Re: [DNSOP] Suggestion for "any" - TCP only

[cid:[e-mail]]
Paul Wouters<mailto:[e-mail]>
Monday, March 09, 2015 10:02 PM
On Sun, 8 Mar 2015, Paul Vixie wrote:

So why are we proposing to ACL the ANY queries again?

because people like me with dig-based diagnostic tools want to be able
to run ANY queries against our own servers, from our NOC/SOC.

Fair enough.

Cloudfare is not doing this for privacy reasons. So let's not kid
ourselves.

cloudflare's motives are their own affair. our motives, as a community,
for getting behind the cloudflare proposal, are what should concern us.

But all the text you want to remove from the -00 points to why people in
real life will deploy this, and you are stating that is wrong use of the
draft. Your suggestion of removing the text won't change what people
will actually use this draft for, which is to fight amplification
attacks (and avoid needing to implement "difficult ANY code")

anyone who uses this draft to defend against amplification or reflection is a fool, or else, was misled by some assertion made in the draft or on this mailing list that blocking ANY (or other meta-queries) is an effective defense against reflection/amplification. we have to stick a pitchfork in the neck of that idea. or, if you prefer: that idea is a criminal whose head should be on a pike outside the city wall.

Another argument I've heard is about the privacy of a cache. If that's
the goal of the draft, perhaps we should move it to dprive and make
that explicit?

we don't have to move something to dprive just because it touches on privacy. limiting surveillance opportunities by intermediaries is no one working group's sole charge -- it's something all working groups must do.

If we specifically want to address the ANY amplification,

we don't. this is not an amplification issue.

... If we look at the core issue, amplification based on
spoofed source IPs,

amplification based on spoofed source IP's is not the core issue.

but we can go back and forth beating that dead meme another few dozen times if you want.

--
Paul Vixie