Subject: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-00.txt

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Sep 2013 21:15:46 -0400 (EDT)

FYI,

Let's make DNSSEC on mobile phones possible without hacking dnssec into
X.509 blobs (or JSON or XML)

Paul

-------- Original Message --------
Subject: New Version Notification for draft-wouters-edns-tcp-chain-query-00.txt
Date: Tue, 10 Sep 2013 18:11:35 -0700
From: [email-masked]
To: Paul Wouters <[email-masked]>

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

Filename:	 draft-wouters-edns-tcp-chain-query
Revision:	 00
Title:		 TCP chain query requests in DNS
Creation date:	 2013-09-10
Group:		 Individual Submission
Number of pages: 13
URL: http://www.ietf.org/internet-drafts/draft-wouters-edns-tcp-chain-query-00.txt
Status: http://datatracker.ietf.org/doc/draft-wouters-edns-tcp-chain-query
Htmlized: http://tools.ietf.org/html/draft-wouters-edns-tcp-chain-query-00

Abstract:
    This document defines an EDNS0 extension that can be used by a DNSSEC
    enabled Recursive Nameserver configured as a forwarder to send a
    single query over TCP requesting to receive a complete validation
    path along with the regular query answer.  Additionally, use of this
    option is considered a request to keep the TCP connection open to
    serve additional DNS requests.  Use of this option significantly
    reduces DNS latency for hosts deploying DNSSEC.

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: Evan Hunt <[email-masked]>
Date: Wed, 11 Sep 2013 03:44:55 +0000

>    reduces DNS latency for hosts deploying DNSSEC.

I'm not certain "request DNSSEC chain" and "keep the TCP connection open"
should be combined in a single option, but I support both.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 11 Sep 2013 09:29:27 +0200

>    reduces DNS latency for hosts deploying DNSSEC.

Want!

Some thoughts after a very quick read:

- It should probably mention what to do with CNAMES (my guess would be
return data until cname and let client requery with chain option for that)
- Depending on above, I don't think *infinite* chains are possible
(though prohibitively long ones are)
- Should there be a considerations section about timeouts?

BTW, I have a sneaking suspicion there also might be a bit of trickery
regarding keys of multiple where some chains are valid and some are not,
but I haven't got a specific example in my head yet.

Jelte

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Sep 2013 08:13:57 -0400

> should be combined in a single option, but I support both.

Isn't "keep the TCP connection open" superfluous, since in DNS the responsibility for closing the socket lies with the client, not the server?

A client expecting to receive a multi-message reply will presumably know to keep the socket open. A server capable of sending a multi-message reply would also know.

RFC 1035:

4.2.2. TCP usage

Messages sent over TCP connections use server port 53 (decimal).  The
message is prefixed with a two byte length field which gives the message
length, excluding the two byte length field.  This length field allows
the low-level processing to assemble a complete message before beginning
to parse it.

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.

Joe

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 11 Sep 2013 10:48:55 -0400

Joe Abley writes:
> Isn't "keep the TCP connection open" superfluous, since in DNS the
> responsibility for closing the socket lies with the client, not the
> server? 

Yes, and no.  This is definitely what the spec says,.  For years many
operators have believed it to be a misfeature of the original spec and
have subverted it in various ways, including short timeouts before the
server kills the connection if a client EOF is not forthcoming.

It would be useful to have a way to negotiate the TCP connection
behavior, including options like signalling that the server may close
the connection as soon as the response is sent, or that the client
wants to send more than one request.  I don't think this meaning
should be bundled into the DNSSEC chain query option, however.

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Sep 2013 11:31:14 -0400

> should be bundled into the DNSSEC chain query option, however.

So, perhaps an EDNS0 option that allows some degree of capabilities negotiation (client says I can do { x, y, z }, server may provide responses with similar options, client issues test query over first message sent on newly-opened TCP socket to catalogue capabilities).

This might also be a way to signal the availability of other transports like SCTP or HTTP.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Sep 2013 11:54:35 -0400 (EDT)

> should be bundled into the DNSSEC chain query option, however.

I've heard several people tell me this now and I agree. The question is:

1) do we want to clarify in a separate draft that the TCP connection
    can remain open for re-use?

2) do we want to use another edns0 option to ask the server to keep the
    TCP connection, which the server indicates by returning this option
    in its TCP reply?

It seems to be 2) is probably a better idea, and I'm happy to write that
up in a separate document.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Sep 2013 11:56:19 -0400 (EDT)

> This might also be a way to signal the availability of other transports like SCTP or HTTP.

I'd prefer an option for just TCP so this doesn't end up getting
bikeshedded. The client is (presumbly) already using TCP to connect.

(also dns over http is just a bad hack that should not be needed. Let's
not multiplex the entire internet over port 80/443)

Paul

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Sep 2013 11:58:48 -0400

> bikeshedded. The client is (presumbly) already using TCP to connect.

I'd prefer a more general option that would allow more connection parameters to be advertised in future, if/when they become interesting. Assigning one code point to "persistent TCP connection capable" could leave the door open in future for bikeshedding, but since that seems inevitable anyway, what's the harm?

I'm keen/able to contribute text to such a document (separate from edns-tcp-chain-query), if you'd like a co-author.

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Sep 2013 13:00:06 -0400

Hey,

Having now spent more than 15 seconds thinking about this...

>   can remain open for re-use?

Given that this apparently breaks assumptions already present in widely-deployed software, that sounds like an uphill battle.

>   TCP connection, which the server indicates by returning this option

I think yes, and upon >15 seconds of reflection I can't think of a reason why you'd want such an option to be more general than this specific functionality. Other transport-related signalling can use different edns0 options.

> up in a separate document.

Agree.

Joe

---

From: "Dickson, Brian" <[email-masked]>
Date: Wed, 11 Sep 2013 17:36:31 +0000

Top-reply (sorry) - agree, sounds great, willing to review and/or
contribute ideas/text.

BTW - suggestion: include (from the server) info about maximum idle time
of an open connection.
E.g. no guarantees if you try to use this without keepalives and after 5
minutes has passed.
This will often correspond to reaping state on state-ful load balancers.
Knowing $REAP_TIME may make operational improvements on implementations
where the option has been negotiated.
Unusual values of $REAP_TIME may even suggest altering the keep-alive
interval on the TCP socket, per server.

Brian

On 9/11/13 1:00 PM, "Joe Abley" <[email-masked]> wrote:

>Given that this apparently breaks assumptions already present in
>widely-deployed software, that sounds like an uphill battle.
>
>I think yes, and upon >15 seconds of reflection I can't think of a reason
>why you'd want such an option to be more general than this specific
>functionality. Other transport-related signalling can use different edns0
>options.
>
>_______________________________________________
>dnsext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Sep 2013 14:29:59 -0400 (EDT)

>> up in a separate document.

Okay. I'll draft it up. The only real choice I see is the relaying a
time period, but that seems silly. Either party might change it mind
depending on work and load, so I think it should just be a binary
on/off.

However, I think we should allow the option to be queried/advertised
over UDP. It would actually allow the client to know about the TCP
capability without actually wasting a TCP session.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Sep 2013 14:36:42 -0400 (EDT)

> interval on the TCP socket, per server.

I was leaning towards not signaling the time period, but I see no harm
in passing along the information from the server to the client.

Paul

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Sep 2013 15:57:34 -0400

> capability without actually wasting a TCP session.

I agree. Regardless of the fact that the transport capability being signalled is TCP-specific, the capability advertisement should be transport-agnostic.

Joe