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

From: Brian Dickson <[email-masked]>
Date: Sun, 8 Mar 2015 14:55:37 -0700

Hey, everyone,

Given the diagnostic value of "any" (and similarly "RRSIG" et al), I would
prefer deprecation of only the UDP version, via mechanisms that are
"dig"-friendly.

E.g. return TC=1 (and minimal response) instead, to trigger TCP retry.

It throws out the bath water, but keeps the baby.

I am guessing here, but would this be easy enough to implement?

Brian

---

From: Ralf Weber <[email-masked]>
Date: Sun, 8 Mar 2015 15:42:31 -0700

Moin!

> prefer deprecation of only the UDP version, via mechanisms that are
I still fail to see the diagnostic value of it. IMHO there are better ways
to debug  a server, but not all vendors have implemented them. Also what 
do you think is the diagnostic value of RRSIG?

> I am guessing here, but would this be easy enough to implement?
I personally think it is harder to implement as you have to behave
differently depending on the protocol. I don't think we should make
it that complicate.

Deprecate both  and if some vendors still think they need them they can
implement them with a mechanism to limit access.

So long
-Ralf

---

From: Paul Vixie <[email-masked]>
Date: Sun, 08 Mar 2015 17:39:11 -0700

> Brian Dickson <mailto:[email-masked]>
> Sunday, March 08, 2015 2:55 PM
> Hey, everyone,
>
> Given the diagnostic value of "any" (and similarly "RRSIG" et al), I
> would prefer deprecation of only the UDP version, via mechanisms that
> are "dig"-friendly.

alas, in a post-snowden world, that's just not going to be enough.
> I am guessing here, but would this be easy enough to implement?

your preference for leaving TCP open implies that maybe you think
restricting or deprecating meta-data queries has something to do with
reflection/amplification defense. it does not, and any language to that
effect will be removed from the next revision of olafur's draft.

moreover, the problem of metadata queries is that anything usable for
diagnostics is also useful, in the same way and to the same degree, for
surveillance. queries for meta-data are overt information leaks. the
default MUST be that they are not answered, though the default SHOULD be
override-able by TSIG or client-ip or similar access control mechanisms.

-- 
Paul Vixie

---

From: Paul Wouters <[email-masked]>
Date: Sun, 8 Mar 2015 21:19:01 -0400 (EDT)

On Sun, 8 Mar 2015, Brian Dickson wrote:

> Given the diagnostic value of "any" (and similarly "RRSIG" et al), I would prefer deprecation of only the UDP version, via mechanisms
> that are "dig"-friendly.

A better description would be to require "source IP verification",
so that eastlake-cookies are also an accepted method.

Of course, it won't really help amplifications via open resolvers that
will just actually switch to source IP verification transport.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Sun, 08 Mar 2015 20:54:17 -0700

Paul Wouters wrote:
>> would prefer deprecation of only the UDP version, via mechanisms
>> that are "dig"-friendly.
>

that wouldn't help. the reason for restricting meta-data queries is
completely unrelated to source ip verification either by tcp 3-way
handshake, cookies, or any other method.

> will just actually switch to source IP verification transport.

again, the next revision of olafur's document will remove all mention of
amplification/reflection. that meme is dead.

-- 
Paul Vixie

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Mar 2015 00:03:00 -0400 (EDT)

On Sun, 8 Mar 2015, Paul Vixie wrote:

> again, the next revision of olafur's document will remove all mention of amplification/reflection. that meme is dead.

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

If you put ANY queries under an ACL, it means you are limiting the ANY
query diagnostics to those who can already read the logfiles to find
out what went wrong. It's basically the same as killing ANY queries.

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

Paul

---

From: Paul Vixie <[email-masked]>
Date: Sun, 08 Mar 2015 22:27:11 -0700

> Paul Wouters <mailto:[email-masked]>
> Sunday, March 08, 2015 9:03 PM

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.
> out what went wrong. It's basically the same as killing ANY queries.

if your diagnostic tools are not dig-based, then i wish you only the
best possible results from them. please do not criticize my use of
dig-based tools to find out things my log files won't tell me, nor my
laziness in preferring to use dig-based tools rather than developing a
multi-vendor dns server diagnostic protocol and patching it into every
kind of name server i might run.
> Cloudfare is not doing this for privacy reasons. So let's not kid

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

-- 
Paul Vixie

---

From: Oliver Peter <[email-masked]>
Date: Mon, 9 Mar 2015 11:55:59 +0000

> to run ANY queries against our own servers, from our NOC/SOC.

For a domain registrar who hosts a massive amount of slave zones on
serveral exernal nameservers (customers own Master, no way to access log
files) it's important to have good diagnostic tools.
I.e. a knob between allow-axfr-from and the ANY ACL would be nice.

Otherwise I'm with Paul Wouters that ACL will kill ANY queries.

-- 
Oliver PETER       [email-masked]       0x456D688F

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Mar 2015 10:02:22 -0400 (EDT)

> to run ANY queries against our own servers, from our NOC/SOC.

Fair enough.

> 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")

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?

If we specifically want to address the ANY amplification, there are other
methods to do so. If we look at the core issue, amplification based on
spoofed source IPs, then the solution seems obvious. For ANY queries
over UDP without eastlake cookies, require that the query packet will be
larger than the answer packet. So require padding in the ANY query packet.
Modify the dig command to add some 1400 bytes padding to the query
packet.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Tue, 10 Mar 2015 08:35:02 +0800

> Monday, March 09, 2015 10:02 PM

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.
> the goal of the draft, perhaps we should move it to dprive and make

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

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Tue, 10 Mar 2015 03:09:56 +0000

+1

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

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

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

Fair enough.

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.

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.

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

--
Paul Vixie