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

[神明達哉 <[e-mail]>]

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