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

Mukund Sivaraman <muks@isc.org> Tue, 04 July 2017 08:36 UTC

Return-Path: <muks@isc.org>
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 D4F39131B1B for <dnsop@ietfa.amsl.com>; Tue, 4 Jul 2017 01:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 0QtwKhHwvDLw for <dnsop@ietfa.amsl.com>; Tue, 4 Jul 2017 01:36:02 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 2940B131B10 for <dnsop@ietf.org>; Tue, 4 Jul 2017 01:36:02 -0700 (PDT)
Received: from jurassic (unknown [115.117.162.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 4BF0456A0054; Tue, 4 Jul 2017 08:35:57 +0000 (GMT)
Date: Tue, 4 Jul 2017 14:05:50 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Matthijs Mekking <matthijs@pletterpet.nl>
Cc: dnsop@ietf.org
Message-ID: <20170704083550.GA17654@jurassic>
References: <149885530587.4596.14298730912579200188.idtracker@ietfa.amsl.com> <185af195-dac6-1438-916f-c9b6d73df644@isc.org> <83761c92-b5c4-7927-8897-718741fe1c6b@pletterpet.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <83761c92-b5c4-7927-8897-718741fe1c6b@pletterpet.nl>
User-Agent: Mutt/1.8.0 (2017-02-23)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9phdr4eApazXCQ-O1n009gxoRsE>
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: Tue, 04 Jul 2017 08:36:04 -0000

Hi Matthijs

On Tue, Jul 04, 2017 at 09:30:55AM +0200, Matthijs Mekking wrote:
> Hi,
> 
> I already said this in private, but will also mention it here: I like
> this idea.
> 
> Some initial comments:
> 
> 
> 1. Why actually define a new option for this. Since the option only uses
> one bit to request/acknowledge opportunistic refresh, can't we use one
> bit from the Z field from the OPT Record TTL Field?
> 
> 
> 2. The draft says:
> 
>   If Client Subnet [RFC7871] is enabled, resource records in the
>   cache may be associated with a subnet.  In these cases, the
>   resolver MUST ensure that the zone serial number associated with
>   such records is obtained from an SOA record associated with the
>   identical subnet.
> 
> But a SOA record is not associated with a subnet, and most likely will
> return with a SCOPE of 0 since the option is not actually used to
> generate the response. Typically with Client Subnet only address records
> (A, AAAA) will result in a tailored response. Also, an authoritative
> name server may generate a different response for QTYPE=AAAA while the
> SOA record has not changed.
> 
> It would be tricky to make opportunistic refresh work with Client
> Subnet. It would definitely require more thought, but I would also be
> fine with just specifying it does not work with ECS.

You're right that ECS makes things a bit tricky.

RFC7871 doesn't say anything about caching SOA, only that the address
prefix in the CLIENT-SUBNET option applies to just things that are
returned in the answer section. SOA can be returned in the answer
section when querying for type SOA.

The SOA serial field is so far only assumed to be defined for zone
transfers, and currently has no use with QUERY. Zone transfers with
address prefixed RRs are not specified by RFC7871.

BIND's resolver ECS does not cache SOA against an address prefix, but on
the authoritative side, note that there is no master file or zone
representation for zones with ECS. It is quite possible that if the auth
side is using different zone sources for different address prefixes,
they may well have different SOA serials. The problem is that none of
these is defined.

What the draft suggests is that on the resolver side, the SOA serial is
maintained for that scope subnet corresponding to the answer. With this,
it will handle cases when there are per-prefix zone sources with
differing SOA serials, albeit at a slight reduction in efficiency of
this scheme because all address prefixes cannot be refreshed at once.

In your example, the QTYPE=AAAA answer will be cached against its
specific scope prefix, and when looking for whether it needs to be
refreshed, the resolver will go looking for the SOA serial associated
with that prefix.

		Mukund