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

In message <[email protected]>, Joe Abley writes
:
> 
> On 2013-10-17, at 13:16, Tony Finch <[email protected]> wrote:
> 
> > I am worried that this will make edns-tcp-keepalive clients perform
> > unnecessarily badly when talking to RFC 5966 servers,
> 
> could you explain how?

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 protected]
> 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 protected]
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext