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

From: Stephen Morris <[email-masked]>
Date: Mon, 3 Jul 2017 12:36:55 +0100

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

-------- Forwarded Message --------
Subject: New Version Notification for
draft-muks-dnsop-dns-opportunistic-refresh-00.txt
Date: Fri, 30 Jun 2017 13:41:45 -0700
From: [email-masked]
To: Mukund Sivaraman <[email-masked]>, Shane Kerr
<[email-masked]>, Stephen Morris <[email-masked]>

A new version of I-D, draft-muks-dnsop-dns-opportunistic-refresh-00.txt
has been successfully submitted by Mukund Sivaraman and posted to the
IETF repository.

Name:		draft-muks-dnsop-dns-opportunistic-refresh
Revision:	00
Title:		DNS Opportunistic Refresh for Resolvers
Document date:	2017-06-29
Group:		Individual Submission
Pages:		9
URL:
https://www.ietf.org/internet-drafts/draft-muks-dnsop-dns-opportunistic-refresh-00.txt
Status:
https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-opportunistic-refresh/
Htmlized:
https://tools.ietf.org/html/draft-muks-dnsop-dns-opportunistic-refresh-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dns-opportunistic-refresh-00

Abstract:
   This document describes a mechanism whereby a DNS resolver can
   opportunistically refresh the TTLs of cached records of a zone using
   serial number information carried in responses from the zone's
   nameservers.  As well as improving resolver response time by reducing
   the need to make upstream queries, the mechanism can also reduce the
   workload of authoritative servers.

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: Robert Edmonds <[email-masked]>
Date: Mon, 3 Jul 2017 12:50:51 -0400

> Please send comments and feedback to the list.

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

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 4 Jul 2017 09:30:55 +0200

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.

3. Security Considerations

I think this could use some words on the risk that an adversary tries to
make a record stick in the cache for longer than it is allowed, by
spoofing a response with an additional SOA record (this can be stopped
with DNSSEC obviously).

Best regards,
  Matthijs

On 03-07-17 13:36, Stephen Morris wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 4 Jul 2017 14:05:50 +0530

Hi Matthijs

> 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

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 4 Jul 2017 13:11:18 +0200

> they may well have different SOA serials. The problem is that none of

Which makes it hard to rely on it.