Re: Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd)

On Fri, 18 Oct 2013,  wrote:

> I have some comments on the draft.  I've noticed some of them were
> covered in the followup discussion in this thread, but I thought it's
> more handy to summarize mine in a single message.

Thanks for your feedback,

> Overall, the motivation and approach of the proposal seem to make
> sense to me.  I have some comments and questions on details.
>
> - The definition of "timeout" isn't clear to me.  In Section 3.1 it
>  only states "a timeout value for the TCP connection".  Section 3.3.2
>  explains it as: "the TIMEOUT value that is currently associated with
>  the TCP session", which is not really clear to me.  Is that the
>  (maximum) duration while the server is waiting for more DNS messages
>  from the client (and it would close the connection if there's no
>  message during the period)?  Maybe this is obvious for some, but I
>  think it's helpful to define it more clearly and specifically.

We will clarify. What was meant was the timeout value for idle TCP
sessions. servers can use this if they are behind a load balancer which
terminates these connections irrespective of the DNS software
implementation.

> - In Abstract, it says: "However, clients are currently limited in
>  their use of the TCP transport as most implementations limit the TCP
>  session to a single DNS query and answer".  Does this
>  "implementations" mean clients or servers?  According to the general
>  sense of the draft, I guess it means servers, but it's not super
>  clear.

What is a client? If you mean gethostbyname() or getaddrinfo(), those
functions don't really have an API to support more then one query. So
a client in this context is a recursive resolver acting as a forwarder.

>  If it means servers, is this true?  And, whether or not it is, I
>  think what should matter more is what the deployed servers instances
>  do, rather than how many implementations do this out of all existing
>  implementations that would include many non-compliant ones.  In that
>  sense, IIRC ISC BIND 9, which I believe is still the majority in
>  terms of deployment base, supports multiple queries/responses on a
>  single TCP connection.

That's good to know.

> - In my understanding of the draft, clients and servers send this
>  option independently, and, in particular, the server may or may not
>  send it whether or not the client includes it in the request.

no, the server never sends the option to the client if they client did
not ask for it. I see that is unclear in 3.3.2 and will fix the text.

> - I don't understand this part of Section 4:
>
>   The edns-tcp-keep-alive option can potentially be abused to request
>   large numbers of sessions in a quick burst.
>
>  Could you (or the next version of the draft) be more specific about
>  it?

Will do.

What we meant was the client could "stuff" the tcp pipe with query after
query without waiting for any answers with the sole purpose to make the
upstream resolver work really hard and use up all its resources.

This becomes more important if combined with edns-tcp-chain-query

http://tools.ietf.org/html/draft-wouters-edns-tcp-chain-query-01

Paul
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext