Subject: [DNSOP] comments on draft-muks-dnsop-dns-opportunistic-refresh-00

From: 神明達哉 <[email-masked]>
Date: Fri, 14 Jul 2017 10:43:08 -0700

I've read draft-muks-dnsop-dns-opportunistic-refresh-00.  In short my
current impression is: "interesting but not yet very convincing idea".

High-level comments:

It's an interesting idea.  However, depending on its main motivation
I'm not sure how effective it is.  As it's listed in the dnsop agenda
https://datatracker.ietf.org/meeting/99/agenda/dnsop/ with
draft-tale-dnsop-serve-stale, it may mainly intend to be a mitigation
in case the authoritative server of a popular name becomes
unreachable.  But, for this proposal to be effective in that case, the
resolver would have to query other names in the same zone
periodically.  I'm not sure if we can generally assume that in cases
where it matters (for example, for the "twitter.com" zone the resolver
may only query for "twitter.com").

Also, the target zone needs to be generally stable, so for example
it's not very effective if the zone is quite frequently updated.  I
can imagine some popular zones are frequently updated, e.g., for load
balancing purposes.  For example, in my quick experiments the SOA
serial of the facebook.com zone changes quite rapidly.

On the other hand I wonder some other popular zones may not rely on
SOA serials to keep its authoritative servers up to date (i.e., they
may not use the standard zone transfer mechanism to distribute the
latest version of zones to secondaries).

I can also think of a corner case where this approach doesn't work
well: assume a zone that changes very frequently and its serial can
wrap quite quickly.  unlike secondary authoritative servers that are
supposed to be notified reasonably timely via NOTIFY, a resolver may
not be able to notice intermediate changes quickly enough and
incorrectly assumes the zone hasn't changed when the serial has
actually wrapped around.  It's easy to dismiss such a case as
unrealistic, but as a formal protocol I don't think we should ignore
these cases too casually.

Given these observations, I'd first like to understand specifically
for what purpose under which assumptions this proposal is deemed to be
useful.  At this moment it's not very convincing to me.

Some specific comments on the draft text follow:

- Section 4.3

   Upon receiving a positive response containing an SOA RR and a valid
   ZONESERIAL EDNS0 option, the resolver SHOULD associate the zone's
   serial number with the RRs in the answer.

  I believe the resolver should also associate the zone name.  Perhaps
  that's the intent, but it's not very clear from this description.
  So it would be better to say so more explicitly.

- Section 4.3: what if the response contains a ZONESERIAL option but
  there's no SOA in the additional (or authority) section?

- Section 4.5

   o  An authoritative server receiving a misconfigured ZONESERIAL
      option in a query SHOULD return a FORMERR response.

   o  A resolver receiving a misconfigured ZONESERIAL option in a
      response MUST NOT interpret the serial number in any SOA RR in
      that response as an indication of zone freshness.

  It's not clear what "misconfigured" means.  It would help if this
  could be more specific.

- Section 5

  I'd suggest revising the format diagram as follows:

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-------------------------------+-------------------------------+
     !         OPTION-CODE           !         OPTION-LENGTH         !
     +-------------+-+---------------+-------------------------------+
     |   Reserved  |R|
     +-------------+-+

  with the following description:

      Reserved       A 7-bit unused field.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.

      R              1-bit request/acknowledge flag.  This bit MUST be
                     clear in requests [...same as the original text]

  The main motivation for this suggestion is that "Bit 7 of this
  field" in the original text might sound a bit ambiguous.  Even if
  it can be considered reasonably clear per common sense, I think it'd
  still be helpful if we specify the position in the diagram.  Also,
  in the suggested text the reserved area is just called "reserved"
  instead of calling the entire 8 bits "flags".  Not a strong opinion,
  but I think it's better as we might want to use some of the reserved
  area for non-flag type of data.

--
JINMEI, Tatuya

---

From: Mukund Sivaraman <[email-masked]>
Date: Sat, 15 Jul 2017 21:17:23 +0530

Hi Jinmei

Thank you for the review. Some replies are below.

> latest version of zones to secondaries).

I don't know how it got clubbed together with
draft-tale-dnsop-serve-stale as serving a similar purpose. It seems to
be a misunderstanding.

The scheme was considered to reduce queries from a resolver, when
possible for a zone that has a last-modified timestamp or serial as an
identifier following an ordered sequence that identifies a whole zone at
a particular time.

To avoid implementation and operational complexity, we decided to use
the SOA serial as this identifier. This will not suit every operator
case (esp. if the SOA serial is not maintained at all by custom
nameservers that generate answers on-the-fly), so the scheme is optional
on the server-side (auth). However, e.g., for a BIND master and slaves
using the regular RBTDB, it can be configured on by default.

That it might sometimes help the case where auth service is
non-functional may be a side effect, but this is not the goal.

> these cases too casually.

On the master, if an SOA serial is updated very frequently, overflows,
wraps around and counts upward to exactly match the previous serial,
would the slave notice it during a refresh?  It wouldn't, and so even
regular queries to the slave may result in old stale data being served.

In the case of this scheme, as it is optional, it would be up to the
operator to decide based on the risk of quick wraparound.

I agree that the corner cases should be explored thoroughly.

> useful.  At this moment it's not very convincing to me.

I'm including some comments from previous discussion among the authors
from several weeks ago:

--------

> 1. A delegation-centric zone.  Queries to such a zone would not benefit
> from this scheme, as we explicitly rule out its use for NS records.

For zones such as TLDs, the update rate would also be too high for this
draft to be useful.

> 2. A tiny zone, comprising little more than an A/AAAA record for www,
> an MX record, and NS records.  Under these circumstances, a resolver
> is only going to do a minimal number of lookups to the zone, so is
> unlikely to get a lot of benefit by extending TTLs.

There are other categories of zones that lie between these two.

Even in the above case, in a validating resolver, every A/AAAA fetch
would require a corresponding DNSKEY fetch to validate RRSIGs, so this
draft would save at least one fetch when the previously cached DNSKEY's
TTL had expired.

There are several popular zones like facebook.com, apple.com,
google.com, etc. where people/apps lookup more than one name's address
within that zone. At an ISP's resolver, such lookups are continuous.

Then, there are small-to-medium sized businesses such as isc.org which
have address lookups for www, mail, git, jabber, asterisk, etc. where
the zone content is mostly static.

Almost every business that runs its own services such as email, web
apps, etc. would include multiple names having address records at the
least. Then there are service-specific records.

I'm sure it can be demonstrated with a zone such as isc.org as an
example, at an office with multiple people and machines such as ISC's
950 Charter Street office address, how a single lookup by one
person/machine would help follow-up lookups for other names+records by
other people/machines.

--------

>   there's no SOA in the additional (or authority) section?

In this case, it would be broken behavior and one can assume FORMERR
parsing the reply message. This should be documented.

>   It's not clear what "misconfigured" means.  It would help if this

Yes it should be rephrased as it would not be a configuration mistake.

>   I'd suggest revising the format diagram as follows:

+1. I'm also used to LSB being 0 and MSB being 7, so the current text is
confusing.

		Mukund