Subject: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd)

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Oct 2013 16:21:34 -0400 (EDT)

As discussed, I separated the EDNS TCP keep-alive option from the EDNS
chain-query document, and Joe Abley kindly offered his assistance in
(re)writing this document.

Paul

-------- Original Message --------
From: [email-masked]
To: Paul Wouters <[email-masked]>, Joe Abley <[email-masked]>
Subject: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt
Date: Tue, 15 Oct 2013 09:39:54 -0700

A new version of I-D, draft-wouters-edns-tcp-keepalive-00.txt
has been successfully submitted by Paul Wouters and posted to the
IETF repository.

Filename:	 draft-wouters-edns-tcp-keepalive
Revision:	 00
Title:		 The edns-tcp-keepalive EDNS0 Option
Creation date:	 2013-10-15
Group:		 Individual Submission
Number of pages: 9
URL:             http://www.ietf.org/internet-drafts/draft-wouters-edns-tcp-keepalive-00.txt
Status:          http://datatracker.ietf.org/doc/draft-wouters-edns-tcp-keepalive
Htmlized:        http://tools.ietf.org/html/draft-wouters-edns-tcp-keepalive-00

Abstract:
    DNS messages between clients and servers may be received over either
    UDP or TCP.  UDP transport involves keeping less state on a busy
    server, but can cause truncation and retries over TCP.  Additionally,
    UDP can be exploited for reflection attacks.  Using TCP would reduce
    retransmits and amplification.  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, making use of
    TCP only suitable as a fallback protocol for UDP.

    This document defines an EDNS0 option ("edns-tcp-keepalive") that
    allows DNS clients and servers to signal their respective readiness
    to conduct multiple DNS transactions over individual TCP sessions.
    This signalling facilitates a better balance of UDP and TCP transport
    between individual clients and servers, reducing the impact of
    problems associated with UDP transport and allowing the state
    associated with TCP transport to be managed effectively with minimal
    impact on the DNS transaction time.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tony Finch <[email-masked]>
Date: Wed, 16 Oct 2013 12:40:28 +0100

I think it should be made clear that it is fine for clients to use TCP
keepalive without this spec, and servers must support that. (This is
particularly handy for asynchronous bulk DNS lookups with software like
adns which uses at most two sockets.) My understanding is what this spec
is supposed to do is to (1) allow servers to close TCP connections more
aggressively than RFC 1035 says, and (2) signal to clients how long they
can expect idle connections to last. I think (1) should be allowed
regardless of any explicit signalling.

Section 3.2.2: Use by DNS Clients - Receiving Responses

   A DNS client that receives a response using TCP transport that
   includes the edns-tcp-keepalive option MAY keep the existing TCP
   session open.

I would prefer this to say:

   A DNS client that receives a response using TCP transport MAY
   keep the existing TCP session open whether or not the response
   includes the edns-tcp-keepalive option.

   A DNS client that receives a response using TCP transport that
   includes the edns-tcp-keepalive option SHOULD close an idle
   connection within the period given in the TIMEOUT value.

The idea in this second paragraph is to encourage clients to take care of
the connection's FIN-WAIT-2 state.

Section 3.3.2: Use by DNS Servers - Sending Responses

This section is problematic. Absence of a edns-tcp-keepalive option should
not imply that keepalive is not allowed, since that is an incompatible
change to existing requirements. I think it would be better if no
keepalive were signalled with a edns-tcp-keepalive timeout of zero, and
indefinite keepalive by omitting the option (since this is an undefined
timeout not an infinite one, because infinite is impossible).

Even if the timeout is zero this should still be an *idle* timeout, and we
should keep the RFC 1035 requirement that the server "should delay closing
its end of the connection until all outstanding client requests have been
satisfied." Perhaps there is an opportunity to allow servers to kill
active connections: a TIMEOUT value of zero could mean "this is the last
response on this connection; gotta close it. if you were expecting any
more responses they have been discarded, sorry!". But my guess is that
aggressively closing active TCP connections will lead to increased load
because of connection thrashing.

So I suggest deleting the last paragraph of section 3.2.2, which describes
how clients should interpret a zero timeout, and I suggest the following
text to replace the whole of section 3.3.2:

   The existing DNS specifications state that DNS servers MUST support
   multiple DNS transactions on a single TCP connection. They MAY close
   idle connections, but they SHOULD NOT close the connection until all
   client requests have been satisfied.

   DNS servers MAY include the edns-tcp-keepalive option in responses
   sent using UDP transport to indicate to the client the TIMEOUT value
   it might expect if it was to open a TCP session with the server and
   receive a response with the edns-tcp-keepalive option present.

   DNS servers MAY include the edns-tcp-keepalive option in responses
   sent using TCP transport to signal how long they are willing to keep
   idle connections open. Servers MUST specify the TIMEOUT value that is
   currently associated with the TCP session. It is reasonable for this
   value to change according to local resource constraints.  The DNS
   server can set the TIMEOUT value to zero to indicate that it intends to
   close the connection as soon as there are no more outstanding requests.

Section 3.6: Anycast Considerations

This seems excessively pessimistic about the stability of anycast routing.
It works OK for HTTP, so why not DNS over TCP? A short TIMEOUT should be
fine.

Section 4: Security Considerations

This is nonsense! The edns-tcp-keepalive option makes no difference to the
ability of clients to make large numbers of concurrent requests.

I think this section could discuss points like:

* Good: this spec explicitly allows servers to close connections more
aggressively in order to avoid resource exhaustion, which improves the
availability of servers in overload situations.

* Risk: servers and clients must not treat timeout values as strong
commitments - the server is always allowed to close connections early to
reclaim resources.

* Risk: closing connections too early may lead to connection thrashing
which may increase load

* Risk: servers that close connections have to keep a TCP control block in
memory to keep track of the FIN-WAIT-2 period, so it is generally
preferable for the client to close the connection and handle FIN-WAIT-2.
Good: this spec gives clients a clear indication of when they should close
connections.

* Advice: perhaps there should be something about the extra memory
resources used by tcp connection buffers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Oct 2013 11:05:37 -0400 (EDT)

> regardless of any explicit signalling.

Historically, DNS transactions over TCP only handle 1 query/answer.

That's not what the specification was supposed to mean, but that's what
it has become in practise. Joe and I therefor thought it would be best
to leave that existing deployment as-is, and use a new option to clearly
unambiguously indicate that yes we will actually allow more than one
query and actively encourage it. That was our number one goal.

So while we don't disagree with you that implementators could fix that,
we thought it would be error prone to change that. It would be
impossible to distinguish between old unpatched DNS software and new
patched DNS software. This new option makes it abundantly clear. It
avoids mismatched expectations between DNS clients and DNS servers.

And while doing so, allows us to warn DNS clients about idle TCP
connections, as we expect that a lot of load balances would interfere
with long outstanding TCP sessions that would require a special signal
to the DNS clients not to linger too long.

We will look at your proposed changes, especially the security section
ones, and merge in what seems appropriate. But unless I hear more people
who would favour making the new option more "optional" I think we should
stick to this more clear cut of the undefined past behaviour.

Paul

---

From: Tony Finch <[email-masked]>
Date: Thu, 17 Oct 2013 11:00:47 +0100

> Historically, DNS transactions over TCP only handle 1 query/answer.

Really? I was using persistent TCP connections back in the 1990s. They
work really nicely.

Note also that RFC 5966 says that servers MUST support TCP and support
multiple queries per connection. I think edns-tcp-keepalive should be
compatible with that requirement.

Tony.

---

From: Joe Abley <[email-masked]>
Date: Thu, 17 Oct 2013 07:17:49 -0400

> Really? I was using persistent TCP connections back in the 1990s. They

I think the problem is not necessarily that serious authority server implementations don't implement TCP; the problem is more that TCP support is provided as a fallback mechanism with short server-side timeouts and a small capacity for active sessions, and TCP from clients is generally treated as the exception rather than the rule (we hope they'll use it if we set TC=1, but otherwise we don't really expect it).

The goal of this option is to define a signalling mechanism whereby a client and server can both be confident that the other side has set these expectations aside, and instead might well prefer to do TCP over UDP. This has implications for both the server and the client with respect to the assumptions in the previous paragraph, the most obvious of which is for a server to reign in any aggressive close-after-response.

The protocol elements in this -00 could surely use improvement. However, the basic idea, as described above, is necessary if we want to find a way to use pools of TCP connections between busy endpoints as an alternative to the usual source-spoofed UDP spray.

> compatible with that requirement.

No argument there.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Oct 2013 09:00:31 -0400

> query and actively encourage it. That was our number one goal.

I very strongly agree with this, and I like the overall approach this
document takes.  

The problem with the STD13 specification is that neither side of the
connection has any guidance as to how the other side will behave.  The
most prudent thing to do in that case is to use a connection one time
and then tear down as soon as possible, even though that's not by any
means the best thing for either side.

This option gives a way for both sides to co-ordinate their behaviour;
it's a good example of the sort of interoperability enhancement that
we should like to see.  It provides an incentive to keep connections
up.  Clever implementations could even use different timeouts for
different connections, based in part on things like recent rate of
queries, the reputation of the connecting IP, and so on.

I thank Paul and Joe for writing this up.  I think it's something we need.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 17 Oct 2013 09:51:35 -0400

Paul Wouters writes:
> But unless I hear more people who would favour making the new option
> more "optional" I think we should stick to this more clear cut of
> the undefined past behaviour.

Just for the record, to balance out any comments for changing course,
I support this approach.  I do not speak for my employer, but I expect
that we would implement it in our nameserver.

---

From: Tony Finch <[email-masked]>
Date: Thu, 17 Oct 2013 18:16:37 +0100

Dave Lawrence <[email-masked]> wrote:
> I support this approach.

I am worried that this will make edns-tcp-keepalive clients perform
unnecessarily badly when talking to RFC 5966 servers, so developers are
going to have to add a configuration switch to make the client do
persistent TCP even in the absence of edns-tcp-keepalive. This is ugly: it
should be handled automatically by the protocol not by system integrators
debugging performance problems.

Tony.

---

From: Joe Abley <[email-masked]>
Date: Thu, 17 Oct 2013 13:30:17 -0400

On 2013-10-17, at 13:16, Tony Finch <[email-masked]> wrote:

> unnecessarily badly when talking to RFC 5966 servers,

could you explain how?

Joe

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Oct 2013 09:39:55 +1100

In message <[email-masked]>, Joe Abley writes
> > unnecessarily badly when talking to RFC 5966 servers,

Yes please explain.

For DNSSEC you just send the requests then look for the responses.
You can even send the multiple requests in one write operation.
Even a RFC 5966 server which has the timers turned down to a couple
of seconds will see the multiple requests.  RFC 5966 servers are
still expected to handle multiple requests over a single TCP
connection.

RFC 5966 changes RFC 1035 by dropping the "two minutes" down to
"a couple of seconds".

Several connection management policies are recommended:

   - The server should not block other activities waiting for TCP
     data.

   - The server should support multiple connections.

   - The server should assume that the client will initiate
     connection closing, and should delay closing its end of the
     connection until all outstanding client requests have been
     satisfied.

   - If the server needs to close a dormant connection to reclaim
     resources, it should wait until the connection has been idle
     for a period on the order of two minutes.  In particular, the
     server should allow the SOA and AXFR request sequence (which
     begins a refresh operation) to be made on a single connection.
     Since the server would be unable to answer queries anyway, a
     unilateral close or reset may be used instead of a graceful
     close.

No where does RFC 5966 say "read a single request then close the socket".
No where does RFC 1035 say "read a single request then close the socket".
No where does RFC 5966 say "read a single request then close the socket
			    unless it is a SOA query".
No where does RFC 1035 say "read a single request then close the socket
			    unless it is a SOA query".

Nameservers that "read a single request then close the socket" with
or without "unless it is a SOA query" are not following RFC 1035.
The forth recommendation is about choosing which socket to close
if you are FORCED to close a socket.  It is not a invitation to
always close the socket if the first request is not a SOA request.

Now I am not saying that telling the server that you intend to send
more requests over this socket is a bad thing but it shouldn't be
necessary to be able to pipeline multiple DNSSEC requests over a
single socket.

A nameserver that does not attempt to read a second request on a
TCP socket is *broken*.  If you are the vendor of such a product
fix it and issue a update notice.

Mark

> Joe
> 
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Oct 2013 20:17:45 -0400 (EDT)

> fix it and issue a update notice.

Do you still see value in the edns-tcp-keepalive and timeout value,
or do you think dns clients can already assume they can sent multiple
queries and keep the tcp connection open for a reasonably time as per
RFC 5966?

Is there any measurement data out there to see how well multiple queries
over TCP works?

Paul

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Oct 2013 11:57:27 +1100

In message <[email-masked]>, Paul Wouters w
> queries and keep the tcp connection open for a reasonably time as per

It will either work (the server is conformant and not over loaded)
or it won't (the server is over loaded or broken).  Sending multiple
queries over TCP is a optimisation.

If there is more than one broken vendor then writing a RFC saying
this is a common problem may be useful.

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 Oct 2013 11:40:25 +0100

> > unnecessarily badly when talking to RFC 5966 servers,

An RFC 5966 server supports persistent TCP but does not advertise this
fact. An edns-tcp-keepalive client interprets this lack of advertisement
as lack of support, so it will send only one query per TCP connection.
This increases latency and means it can't make concurrent queries over TCP
without multiple TCP connections, and for high query volumes it risks port
exhaustion from all the FIN-WAIT-2 states. If you run the client in RFC
5966 mode then it will try persistent TCP regardless of what the server
says and avoid these problems.

Tony.

---

From: Ray Bellis <[email-masked]>
Date: Fri, 18 Oct 2013 11:04:06 +0000

On 18 Oct 2013, at 11:40, Tony Finch <[email-masked]> wrote:

> fact.

It shouldn't have to - every DNS server should already support persistent TCP.  Mostly, all that 5966 did was clarify the requirements to support TCP *at all* and drop the minimum idle time.

The use of an individual TCP session per query is client habit, and in no way mandated by anything in the earlier DNS documents.

Ray

---

From: Joe Abley <[email-masked]>
Date: Fri, 18 Oct 2013 07:32:24 -0400

> An RFC 5966 server supports persistent TCP but does not advertise this

I think we all agree on this.

> An edns-tcp-keepalive client interprets this lack of advertisement

What we're trying to optimise is

(a) the ability for a server to manage a finite resource (a TCP connection pool) in a way that is most likely to result in those sockets being well-used;

(b) the ability for a client who desires multiple exchanges over the same TCP socket to know what the timeout on the server is, so that it knows when to fall back to UDP.

In the case of a busy resolver (Google, OpenDNS, Comcast, whatever) sending regular and frequent queries to a busy server (one of the CO.UK servers, say) perhaps the "few seconds" timeout on the server is not an issue. But if the server has the resources to keep a TCP socket open to receive 0.3 queries per second from a particular resolver, the ability to use this signalling to extend the timeout on the server side allows multiple exchanges where normal behaviour (absent signalling) would not.

In the case of a mobile device sending less frequent queries to a resolver, the default TCP timeout on the server might well be a problem. A busy resolver might not be able to spare the resources to keep the socket open for such a client today, but the idea here is to think ahead to a world where TCP is not the exception to the rule and perhaps some of the scaling techniques used by web servers that can support orders of magnitude more concurrent TCP connections than most DNS servers do today.

Keeping the socket open on the server for a relatively low query rate from a resolver avoids the overhead of closing and reopening a TCP socket, and provides source address validation of the client, protecting it from collateral damage that might result from (e.g.) RRL.

I think the potential advantages are non-imaginary.

> says and avoid these problems.

So the key observation here, if I'm reading it correctly, is that clients might reasonably try to re-use an open socket even if the edns-tcp-keepalive option is not present, anticipating a short (but not impossible) timeout on the server side.

Joe

---

From: Dave Lawrence <[email-masked]>
Date: Fri, 18 Oct 2013 09:24:04 -0400

> as lack of support, so it will send only one query per TCP connection.

So your concern is about as-yet-unwritten software being written
badly?

This can't be reasonably addressed by references in the proposed RFC
along the lines of "The DNS standard has always been to support
multiple requests over TCP (ref: 1035 and 5966), therefore a client
that does not receive the keepalive option from the server SHOULD
assume that multiple requests are supported until demonstrated
otherwise."

People will still write bad software, but it's not like they weren't
informed.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 18 Oct 2013 09:27:45 -0400 (EDT)

> An RFC 5966 server supports persistent TCP but does not advertise this

I hope to have some measurements done in time for Vancouver to see what
the percentage of queries/servers is where this is a problem. That could
help assess whether or not we still need a special indication via edns
or not.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Sat, 19 Oct 2013 01:11:43 +1100

In message <[email-masked]>, Paul Wouters w
> help assess whether or not we still need a special indication via edns

Why?  Clients should be able to handle the connection being closed
unexpectedly and retry any uncompleted queries.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 18 Oct 2013 10:21:54 -0400 (EDT)

> unexpectedly and retry any uncompleted queries.

I'm trying to reduce dns(sec) latency, not adding more repeating tcp
failures. If it turns out that most obtained DNS resolvers are useless
for TCP than there is a need to give a clear indication to a client
that a resolver does work well.

The question is how pervasive are rfc 5966 compliant resolvers out
there, and whether there is a need to advertise those who are.

Paul

---

From: Ray Bellis <[email-masked]>
Date: Fri, 18 Oct 2013 14:31:47 +0000

> there, and whether there is a need to advertise those who are.

As the author of RFC 5966, I'm confused by your use of "5966 compliant".

AFAICR (and assuming a server that already supports TCP) the only significant normative change in RFC 5966 was the recommendation to drop the idle timeout from two minutes down to being "of the order of seconds".

Everything else was just clarification of stuff from previous RFCs that most people took as read, but wasn't necessarily written down as clearly as it might have been.

Any enterprise grade DNS server that does already support TCP should handle multiple queries over the same socket without complaint.

kind regards,

Ray

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 Oct 2013 18:05:35 +0100

> So your concern is about as-yet-unwritten software being written

No, the above is what edns-tcp-keepalive specifies. It says:

                 The DNS server MAY omit including the edns-tcp-
   keepalive option if it deems its local resources are too low to
   service more TCP keepalive sessions.

So a correctly written client that follows this spec will interpret the
absence of the option as lack of support for persistent TCP.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 Oct 2013 18:36:30 +0100

Joe Abley <[email-masked]> wrote:
>
> So the key observation here, if I'm reading it correctly, is that
> clients might reasonably try to re-use an open socket even if the
> edns-tcp-keepalive option is not present, anticipating a short (but not
> impossible) timeout on the server side.

Right.

There are (basically) three kinds of server:

Working edns-tcp-keepalive servers support persistent TCP and advertise
this fact. RFC 5966 clients and edns-tcp-keepalive clients will both use
persistent TCP connections and everyone is happy.

Working RFC 5966 servers support persistent TCP but do not advertise this.
RFC 5966 clients will use persistent TCP connections, but
edns-tcp-keepalive clients will think the server is in overload and will
not use persistent TCP even though they could. Sadface.

Broken servers may or may not advertise support for persistent TCP. An
edns-tcp-keepalive server may be broken because there is a nasty middlebox
in the way, or perhaps it got overloaded without being able to signal this
to the client. So clients have to detect broken servers based on their
ability to keep a TCP connection open to the server, and in any case they
have to be able to recover gracefully from an abruptly closed connection.
I'm a bit doubtful that there is any benefit in an explicit "I'm broken"
signal from the server using the edns-tcp-keepalive option.

I like the aims of the draft and I think it is useful for the server to be
able to say to the client, please use TCP, and please close idle
connections within N seconds. But the current version is a wee bit buggy.

Tony.

---

From: Joe Abley <[email-masked]>
Date: Fri, 18 Oct 2013 13:39:25 -0400

> connections within N seconds. But the current version is a wee bit buggy.

Absolutely. It's a 00. Your bug reports are helpful!

Joe

---

From: 神明達哉 <[email-masked]>
Date: Fri, 18 Oct 2013 12:07:31 -0700

At Tue, 15 Oct 2013 16:21:34 -0400 (EDT),

> (re)writing this document.

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.

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.

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

  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.

- 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.  (That
  is, unlike (e.g.) NSID, including this option in a request doesn't
  mean the client requests the server to include it in the response).
  Is this correct?  Maybe obvious, but I think it's helpful to clarify
  that more explicitly.

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

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 18 Oct 2013 12:11:45 -0700

At Wed, 16 Oct 2013 11:05:37 -0400 (EDT),

> stick to this more clear cut of the undefined past behaviour.

I'm not really sure what 'more "optiona"' specifically means here, but
I think it makes sense to introduce a "timeout" value indicating the
server will close the connection immediately.

--
JINMEI, Tatuya

---

From: Paul Wouters <[email-masked]>
Date: Fri, 18 Oct 2013 15:20:13 -0400 (EDT)

> more handy to summarize mine in a single message.

Thanks for your feedback,

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

>  sense of the draft, I guess it means servers, but it's not super

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.

>  terms of deployment base, supports multiple queries/responses on a

That's good to know.

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

>  Could you (or the next version of the draft) be more specific about

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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 19 Oct 2013 07:44:32 +1100

In message <[email-masked]>, Paul Wouters w
> there, and whether there is a need to advertise those who are.

All DNS servers should already handle multiple questions over a TCP
socket.  This is *basic* RFC 1035.  Just send the queries and deal
with the fact that you may have broken servers. 

Adding a new option often the worst thing you can do to fix a failure
to follow specification.  It is definitely not needed to fix this
problem.

Just write a RFC with a title like "Common DNS server errors in
handling queries over TCP" which points out that DNS servers are
expected to handle multiple queries over TCP.  Then a user has a
second clue bat to go beat the vendor over the head with.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Sat, 19 Oct 2013 08:28:09 +1100

> second clue bat to go beat the vendor over the head with.

Just so you can have a something to test with I hacked dig to keep
the tcp socket open.  It needs more work to be production quality.

	dig @server +tcp -f querylist

Now I know named handles multiple queries over a socket.
Perhaps others can report what works for them.

Mark

diff --git a/bin/dig/dighost.c b/bin/dig/dighost.c
index 79b11d0..a10742a 100644
--- a/bin/dig/dighost.c
+++ b/bin/dig/dighost.c
@@ -120,7 +120,8 @@ isc_boolean_t
 	usesearch = ISC_FALSE,
 	showsearch = ISC_FALSE,
 	qr = ISC_FALSE,
-	is_dst_up = ISC_FALSE;
+	is_dst_up = ISC_FALSE,
+	keep_open = ISC_TRUE;
 in_port_t port = 53;
 unsigned int timeout = 0;
 unsigned int extrabytes;
@@ -151,6 +152,8 @@ static void		idn_check_result(idn_result_t r, const char *msg);
 int  idnoptions	= 0;
 #endif
 
+isc_socket_t *keep = NULL;
+
 /*%
  * Exit Codes:
  *
@@ -2339,6 +2342,16 @@ send_tcp_connect(dig_query_t *query) {
 	}
 
 	INSIST(query->sock == NULL);
+
+	if (keep != NULL) {
+fprintf(stderr, "REUSING socket\n");
+		sockcount++;
+		isc_socket_attach(keep, &query->sock);
+		query->waiting_connect = ISC_FALSE;
+		launch_next_query(query, ISC_TRUE);
+		goto search;
+	}
+	
 	result = isc_socket_create(socketmgr,
 				   isc_sockaddr_pf(&query->sockaddr),
 				   isc_sockettype_tcp, &query->sock);
@@ -2361,6 +2374,7 @@ send_tcp_connect(dig_query_t *query) {
 	result = isc_socket_connect(query->sock, &query->sockaddr,
 				    global_task, connect_done, query);
 	check_result(result, "isc_socket_connect");
+ search:
 	/*
 	 * If we're at the endgame of a nameserver search, we need to
 	 * immediately bring up all the queries.  Do it here.
@@ -2725,6 +2739,12 @@ connect_done(isc_task_t *task, isc_event_t *event) {
 		UNLOCK_LOOKUP;
 		return;
 	}
+	if (keep_open) {
+fprintf(stderr, "SAVING socket\n");
+		if (keep != NULL)
+			isc_socket_detach(&keep);
+		isc_socket_attach(query->sock, &keep);
+	}
 	launch_next_query(query, ISC_TRUE);
 	isc_event_free(&event);
 	UNLOCK_LOOKUP;
@@ -3541,6 +3561,9 @@ destroy_libs(void) {
 	isc_result_t result;
 #endif
 
+	fprintf(stderr, "CLOSING socket\n");
+	if (keep != 0)
+		isc_socket_detach(&keep);
 	debug("destroy_libs()");
 	if (global_task != NULL) {
 		debug("freeing task");
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Fri, 18 Oct 2013 15:54:38 -0700

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

> > - The definition of "timeout" isn't clear to me.
>

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

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

> 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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 18 Oct 2013 23:10:06 -0400 (EDT)

> the tcp socket open.  It needs more work to be production quality.

Thanks! I've used the patch to test some servers

> Perhaps others can report what works for them.

I've tested against:
- unbound
- dnsmasq
- powerdns-recursor
- bind9.7

All of these returned pipelined queries that I threw at them (upto a
few hundred)

OpenDNS worked as well.

Google DNS worked but puts a limit of 64 queries on a TCP connection.

I have not yet tested how long these servers and services keep idle
connections open.

Paul

---

From: Tony Finch <[email-masked]>
Date: Sat, 19 Oct 2013 16:20:36 +0100

Right.

I have been thinking about what changes this draft implies relative to RFC
5966. There's a general encouragement to use TCP, but that doesn't require
protocol changes.

I don't think it implies any changes to server connection management.
There are quality-of-implementation questions, but they doesn't need
protocol changes.

The only difference it makes to the client is it can close connections
based on the server's idle timeout, instead of keeping them open
indefinitely.

This is beneficial to the server, since it offloads FIN-WAIT-2 to the
client. It is not beneficial to the client since it implies extra timeout
handling and extra bandwidth usage - think radio power.

Perhaps the server should only send the option when its timeout is less
than indefinite, or if it changes in the lifetime of the connection. Then
in most cases the client will not have to bear the extra costs.

Tony.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 21 Oct 2013 09:22:23 +0000

> second clue bat to go beat the vendor over the head with.

It's already implicit in 5966, where there's text clarifying that responses on a TCP connection may arrive in a different order to requests.

kind regards,

Ray

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 21 Oct 2013 19:52:11 +0530

> Perhaps others can report what works for them.

I remember seeing a config option in the NSD configuration for the
number of queries it's allowed to serve on a TCP connection. So I guess
other DNS servers also implement it.

		Mukund

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Oct 2013 09:49:05 +1100

In message <[email-masked]>, Ray Bellis writes:
> It's already implicit in 5966, where there's text clarifying that
> responses on a TCP connection may arrive in a different order to requests.
>
> kind regards,
>
> Ray

Sometimes it is just better to says things explicitly.
Sometimes it is just better to not mix a correction with
a extension.

Mark

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 23 Oct 2013 21:45:59 +0530

Hi Paul

> Htmlized:        http://tools.ietf.org/html/draft-wouters-edns-tcp-keepalive-00

This document does not cite RFC 5966. Have you read and considered
everything in RFC 5966 in full when preparing this draft?

		Mukund