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

[Mukund Sivaraman <[e-mail]>]

Hi Jinmei

Thank you for the review. Some replies are below.

On Fri, Jul 14, 2017 at 10:43:08AM -0700, 神明達哉 wrote:
> 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 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.

> 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.

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.

> 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.

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.

--------

> 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?

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

> - 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.

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

> - 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.

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

		Mukund