Subject: [DNSOP] I-D Action: draft-ietf-dnsop-edns-tcp-keepalive-06.txt

From: [email-masked]
Date: Mon, 22 Feb 2016 04:08:23 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : The edns-tcp-keepalive EDNS0 Option
        Authors         : Paul Wouters
                          Joe Abley
                          Sara Dickinson
                          Ray Bellis
	Filename        : draft-ietf-dnsop-edns-tcp-keepalive-06.txt
	Pages           : 14
	Date            : 2016-02-22

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 commonly use TCP
   only for retries and servers typically use idle timeouts on the order
   of seconds.

   This document defines an EDNS0 option ("edns-tcp-keepalive") that
   allows DNS servers to signal a variable idle timeout.  This
   signalling encourages the use of long-lived TCP connections by
   allowing the state associated with TCP transport to be managed
   effectively with minimal impact on the DNS transaction time.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-edns-tcp-keepalive-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-tcp-keepalive-06

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 22 Feb 2016 12:21:55 +0000

All, 

This update addresses all of the outstanding comments from the IESG review of this document, apart from a decision on the question about DNS-over-DTLS.

Joel/Tim - is there an update on that decision?

Regards

Sara. 

> On 22 Feb 2016, at 12:08, [email-masked] wrote:
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Bob Harold <[email-masked]>
Date: Mon, 22 Feb 2016 13:41:02 -0500

On Mon, Feb 22, 2016 at 7:21 AM, Sara Dickinson <[email-masked]> wrote:

> All,
>
> This update addresses all of the outstanding comments from the IESG review
> of this document, apart from a decision on the question about DNS-over-DTLS.
>

I am not understanding one thing.

 3.3.2.  Sending Responses

Says that a server "that receives a query ... without the
edns-tcp-keepalive option ... MAY include the edns-tcp-keepalive option in
the response"

But

3.4.  TCP Session Management

Indicates that a server can only send the edns-tcp-keepalive option in an
answer if the client includes it in the request.

-- 
Bob Harold

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 22 Feb 2016 18:53:32 +0000

> On 22 Feb 2016, at 18:41, Bob Harold <[email-masked]> wrote:
> 
> Says that a server "that receives a query ... without the edns-tcp-keepalive option ... MAY include the edns-tcp-keepalive option in the response"
> 
> But
> 
> Indicates that a server can only send the edns-tcp-keepalive option in an answer if the client includes it in the request.

It is subtle, but is the difference between an EDNS0 OPT RR and a specific EDNS0 option:

- yes, the server can only send an EDNS0 OPT RR if the client includes one in the request but…
- as long as there was an EDNS0 OPT RR in the request, the server can send back the edns-tcp-keepalive option even there wasn’t one in the OPT RR in the request. 

Sara.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Feb 2016 10:24:01 +1100

In message <[email-masked]>, Sara Dickinson w
rites:
> > edns-tcp-keepalive option ... MAY include the edns-tcp-keepalive option
> > in the response"
> >
> > But
> >
> > Indicates that a server can only send the edns-tcp-keepalive option in
> > an answer if the client includes it in the request.
>
>
> - yes, the server can only send an EDNS0 OPT RR if the client includes
> one in the request but
> - as long as there was an EDNS0 OPT RR in the request, the server can
> send back the edns-tcp-keepalive option even there wasnt one in the OPT
> RR in the request.

Strictly speaking the additional section can have anything the
server feels is relevent including a OPT record (this in RFC 1034).
Clients are expected to cope with anything added to the additional
section.

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.

That said it is pointless to add a OPT record unless you know the
client understands OPT.  Using a extended rcode would also be
problematic as they require that the client understand OPT records
which can't be determined unless you have see a OPT in the request.

Unknown EDNS options are expected to be ignored in both requests
and replies so it is safe to add a unknown EDNS option to either.

This actually means you can add this option to any response but I
would limit it to responses where there was a OPT record in the
request.

Mark

-- 
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: Mon, 22 Feb 2016 20:51:38 -0500 (EST)

> would limit it to responses where there was a OPT record in the

I'm fine with that change. It makes sense to me.

Paul

---

From: joel jaeggli <[email-masked]>
Date: Mon, 22 Feb 2016 21:40:56 -0800

We're good,

We hold the token at his point so we can push it over to the rfc editor.

Thanks for the effort
joel

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 23 Feb 2016 12:59:44 +0000

> On 22 Feb 2016, at 23:24, Mark Andrews <[email-masked]> wrote:
> 
> 

Just to clarify, the draft already specifies that restriction, based on this text from RFC6891 (https://tools.ietf.org/html/rfc6891#section-7 <https://tools.ietf.org/html/rfc6891#section-7>) :

  “Lack of presence of an OPT record in a request MUST be taken as an
   indication that the requestor does not implement any part of this
   specification and that the responder MUST NOT include an OPT record
   in its response.“

Sara.