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

At Fri, 18 Oct 2013 15:20:13 -0400 (EDT),
Paul Wouters <[email protected]> wrote:

> > - The definition of "timeout" isn't clear to me.
>
> 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.

Hmm, so, for example, if an administrator uses a load balancer
configured with a "TCP timeout" value would configure the backend name
server so it will include that value for this EDNS option?  I suspect
ordinary readers without much background would need a lot of
imagination to come up with this scenario just from the draft text:-)

> > - 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.

First off, I didn't think it was a client, but the text wasn't really
clear.  Secondly, if it was really about clients, "what kind of
client" would actually be my next question, as there are different
types of "clients" (stub resolver and recursive server) and it was not
really clear from the draft text.  Thirdly, since you asked, IIRC the
very basic primitive "libresolv" library supports the "stay open"
option flag.  See, e.g. lines 514-517 of
http://svnweb.freebsd.org/base/head/lib/libc/resolv/res_send.c?view=markup&pathrev=255336
although this doesn't matter much in the context of this draft anyway.

> >   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.

Okay, but this doesn't seem to be an abuse of the proposed option, but
just a possible attack on a server that accepts multiple queries on a
single connection in general (I remember it was already pointed out in
the thread).

--
JINMEI, Tatuya
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext