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

Mark Andrews <marka@isc.org> Mon, 22 February 2016 23:24 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA371B2DDE for <dnsop@ietfa.amsl.com>; Mon, 22 Feb 2016 15:24:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1flvnUVcuQBW for <dnsop@ietfa.amsl.com>; Mon, 22 Feb 2016 15:24:06 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395B41B2DB1 for <dnsop@ietf.org>; Mon, 22 Feb 2016 15:24:06 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 32333349315; Mon, 22 Feb 2016 23:24:04 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2D408160042; Mon, 22 Feb 2016 23:24:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1F192160091; Mon, 22 Feb 2016 23:24:04 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CnifGjjzq5OR; Mon, 22 Feb 2016 23:24:04 +0000 (UTC)
Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id C7231160042; Mon, 22 Feb 2016 23:24:03 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 50A6542F4E45; Tue, 23 Feb 2016 10:24:01 +1100 (EST)
To: Sara Dickinson <sara@sinodun.com>
From: Mark Andrews <marka@isc.org>
References: <20160222120823.20935.92992.idtracker@ietfa.amsl.com> <859D225D-AF1D-40A2-8CDC-1035ACC13BA2@sinodun.com> <CA+nkc8B+ffKyoFVax2M9UP0s0VgYYycG3k+Eg3DZBU2Gx_qpow@mail.gmail.com> <9FA7A153-19CB-420A-BEE2-2F0DC9C70D21@sinodun.com>
In-reply-to: Your message of "Mon, 22 Feb 2016 18:53:32 -0000." <9FA7A153-19CB-420A-BEE2-2F0DC9C70D21@sinodun.com>
Date: Tue, 23 Feb 2016 10:24:01 +1100
Message-Id: <20160222232401.50A6542F4E45@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/QGBlpdJDqwOiO1jL0BJbktnySzQ>
Cc: Bob Harold <rharolde@umich.edu>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-tcp-keepalive-06.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Feb 2016 23:24:07 -0000

In message <9FA7A153-19CB-420A-BEE2-2F0DC9C70D21@sinodun.com>, Sara Dickinson w
rites:
>
> > On 22 Feb 2016, at 18:41, Bob Harold <rharolde@umich.edu> wrote:
> >
> > 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.
>
>
> 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 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

> Sara.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org