Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-opportunistic-refresh-00.txt

Robert Edmonds <edmonds@mycre.ws> Mon, 03 July 2017 16:50 UTC

Return-Path: <edmonds@mycre.ws>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E773131464 for <dnsop@ietfa.amsl.com>; Mon, 3 Jul 2017 09:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 I91jX15lu1sw for <dnsop@ietfa.amsl.com>; Mon, 3 Jul 2017 09:50:52 -0700 (PDT)
Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 736AC131443 for <dnsop@ietf.org>; Mon, 3 Jul 2017 09:50:52 -0700 (PDT)
Received: by chase.mycre.ws (Postfix, from userid 1000) id E334E12C10FC; Mon, 3 Jul 2017 12:50:51 -0400 (EDT)
Date: Mon, 3 Jul 2017 12:50:51 -0400
From: Robert Edmonds <edmonds@mycre.ws>
To: dnsop@ietf.org
Message-ID: <20170703165051.eifyac7xlgk7b6tb@mycre.ws>
References: <149885530587.4596.14298730912579200188.idtracker@ietfa.amsl.com> <185af195-dac6-1438-916f-c9b6d73df644@isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <185af195-dac6-1438-916f-c9b6d73df644@isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wQCi9UTPDVWMCZuoxizHRE7uL2E>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-opportunistic-refresh-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 03 Jul 2017 16:50:54 -0000

Stephen Morris wrote:
> Hi
> 
> We have submitted a new draft which attempts to formalize an idea that
> has been kicking around for a couple of years, namely to use serial
> number information from DNS responses to determine whether stale records
> in a cache can be refreshed without the need for an upstream query.
> 
> Please send comments and feedback to the list.
> 
> Stephen

Hi,

I noticed this draft defines an EDNS0 option that communicates a single
bit of information:

   FLAGS  Flags field.  Bit 7 of this field is the request/acknowledge
      flag.  This bit MUST be clear in requests from the resolver to the
      authoritative server and MUST be set in responses from the
      authoritative server to the resolver.  By flipping the bit in a
      response, answers from misbehaving authoritiative servers that
      just copy unknown EDNS0 options from query to response are not
      mistakenly treated as being from servers that understand
      opportunistic DNS refresh.

Just an observation: this bit indicates client-side support in queries
and server-side support in responses. This is the exact use case for the
"DNS Features" capability in draft-edmonds-dnsop-capabilities [0]. And
the capabilities option already detects and discards echoing, so no need
to flip the bit between query and response.

[0] https://tools.ietf.org/html/draft-edmonds-dnsop-capabilities-00#section-4.1

-- 
Robert Edmonds