Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

[John Heidemann <[e-mail]>]

On Thu, 15 Dec 2016 10:09:16 +0100, Stephane Bortzmeyer wrote: 
>On Wed, Dec 14, 2016 at 08:57:56AM -0800,
> John Heidemann <[e-mail]> wrote 
> a message of 49 lines which said:
>
>> There's a bunch of possible trade-offs: client latency, server
>> memory, client memory, novelty vs. maturity of design, maturity of
>> libraries, support by other groups, design complexity, ...
>
>Added to the future next version of the draft
><https://github.com/bortzmeyer/ietf-dprive-step-2/commit/5779cbf94605fbcd174bd5d57544150fc636e620>

If you're updating, you might also add out protocol agility, something else that has
come up in this thread and before.

>> You suggested earlier in the thread that rfc7858 was weaker than
>> some alternatives for recurisive-to-auth traffic, so I was trying to
>> figure out for which metrics you think it is weaker.
>
>The point was raised by Mukund Sivaraman at the Seoul meeting. If I
>remember correctly, his main concern was the state to keep in the
>client, because a resolver will talk to hundreds, even thousands of
>authoritative name servers.

Thank you---state for outgoing connections on a recursive resolver
could be an issue, and to my knowledge it has not been studied yet.

My initial guess is it's not much different from state for incoming
connections on a large authoritative, and that resource limits can be
handled the same way (start closing when you're low on resources).  But
a careful study here would be useful.

And of course, there is still state on the recursive resolver if queries
are sent over DTLS or IPsec, it's just different state in a slightly
different place in the stack.

   -John Heidemann