Subject: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Jul 2016 10:53:10 -0400 (EDT)

The reason I hummed against this idea is that I think it is better to
teach validators to not strip dnssec signed additional data, and just
supply the data there.

The current document as explained today seemed to limit itself already
to in baliwick or subzone data.

That seems a much simpler solution to the proposed problem.

Paul

---

From: Robert Edmonds <[email-masked]>
Date: Mon, 18 Jul 2016 12:14:42 -0400

> to in baliwick or subzone data.

Hi,

I couldn't make it to IETF 96, but consider this a virtual hum against
this idea also.

> That seems a much simpler solution to the proposed problem.

If I'm not mistaken, there's also no specification work required,
either. (Besides, perhaps, specifying a RR that configures the behavior
in the nameserver.) Nameservers are allowed to add “useful” RRs to the
additional section, using local data.

-- 
Robert Edmonds

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 19 Jul 2016 08:07:03 +0200

Moin!

You were not alone, though I hummed for different reasons. I think it is
bad to blow up responses with stuff that might be helpful, but in reality
only will be helpful to people running amplification attacks.

So long
-Ralf

---

From: George Michaelson <[email-masked]>
Date: Tue, 19 Jul 2016 16:18:55 +1000

"in reality" is skewing the story. You don't foresee a usecase, but
you do foresee abuse? So deploy cookies or move to TCP, or DTLS or
some other cost space where amplify implies special knowledge, or cost
on the amplifier.

I'm not sure I understand the use-case either btw, but this rebuttal
smells like the classic 'FUD it out of existence' IETF approach.
Warren is smart. I'm sure he thought of this.

-G

PS a use case as I understand it, is people (like 8.8.8.8) who see
patterns in otherwise unrelated DNS query and could potentially short
circuit in time, and query chain sequence things which are utterly
predictable. You ask for A? we know in 2 ms you will ask for AAAA, or
DS/DNSKEY of the parent or... because.. well because we have the query
dynamics in the space, and we know what we see. So lets put things
into answers and start converting clients to understand this, and we
drop query load significantly and speed up DNS closure. This feels
like optimizations we'd expect in other protocols.

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 19 Jul 2016 08:36:02 +0200

Moin!

> some other cost space where amplify implies special knowledge, or cost
Which then introduces a deployment or scaling problem. Granted for
Google scaling DNS to TCP is not a problem, but it might be for others.

[..]
> like optimizations we'd expect in other protocols.
Except that if you have a decent size and hot Cache with refreshing
these records will be in there anyway. IMHO you gained nothing, but I
agree with Jim Reid that it would be good to have data on this.

So long
-Ralf

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 19 Jul 2016 03:00:49 -0400

> agree with Jim Reid that it would be good to have data on this.

Nothing except some DNS round trips.
How could that matter though?

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 19 Jul 2016 09:19:58 +0200

Moin!

> How could that matter though?
As said I don't believe we have additional round trips between the
recursive and the authoritative server in most of the cases. That is
what we need data for though. DNS and applications that use DNS have
unbelievable levels of caching. So while this all might apply to you
if you run your own resolver just for you, it's not the case in big
cache deployments most people use (be it their ISP or some big public
resolver).

So long
-Ralf

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 19 Jul 2016 09:37:37 +0200

On 19 July 2016 at 09:19, Ralf Weber <[email-masked]> wrote:

> While I tend to agree that the optimization gain between the recursive and
authoritative server is probably  minimal, the potential gain between the
recursive and the stub is huge.  Other than the fact that the explanation
focuses on the authoritative, I don't see any reason this needs to be
limited to recursive->authoritative conversations.  Indeed, with the OPT
signalling a recursive could obtain the EXTRA records and provide the same
optimized answers to stubs.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Jul 2016 09:46:51 +0200

I thought the proposal specifically excluded support for this sort of query
in any case other than for queries from authoritative servers.

On Jul 19, 2016 09:37, "Matthew Pounsett" <[email-masked]> wrote:

>> While I tend to agree that the optimization gain between the recursive
> and authoritative server is probably  minimal, the potential gain between
> the recursive and the stub is huge.  Other than the fact that the
> explanation focuses on the authoritative, I don't see any reason this needs
> to be limited to recursive->authoritative conversations.  Indeed, with the
> OPT signalling a recursive could obtain the EXTRA records and provide the
> same optimized answers to stubs.
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 19 Jul 2016 10:13:59 +0200

On 19 July 2016 at 09:46, Ted Lemon <[email-masked]> wrote:

> I thought the proposal specifically excluded support for this sort of
> query in any case other than for queries from authoritative servers.
>
> I'm not sure what you mean about "this sort of query".    There wouldn't
be any special query sent to recursives.  The response from recursives
could include the additional records called for by the EXTRA records cached
when the authoritative was queried.  I don't see anything about that being
prohibited in the draft... in fact I see no reason for § 6 if it was
prohibited.  There'd be no reason for recursives to ever receive the EXTRA
records themselves.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Jul 2016 10:15:32 +0200

Sorry, this sort of response to queries.