Subject: Re: [DNSOP] comments on draft-tale-dnsop-serve-stale-00

From: 神明達哉 <[email-masked]>
Date: Tue, 11 Jul 2017 11:01:18 -0700

At Tue, 27 Jun 2017 13:15:52 -0400,
Dave Lawrence <[email-masked]> wrote:

> >   Also, it's not clear to me why the TTL is set to 1 second.  Since
> >   it's actually expired, a zero TTL seems to be a more sensible choice
> >   here (a similar feature of unbound uses a zero TTL).  If there's a
> >   specific reason to avoid 0, it would be better to explain it
> >   explicitly.
>
> Added to document:
>
> "1 second was chosen because historically 0 second TTLs have been
> problematic for some implementations.  It not only sidesteps those
> potential problems with no practical negative consequence, it would
> also rate limit further queries from any client that is honoring the
> TTL, such as a forwarding resolver."

Okay.

> > - Section 4
> >
> >> Canonical Name (CNAME) records mingled in the expired cache with
> >> other records at the same owner name can cause surprising results.
> [...]
> >   I suspect this is quite specific to internal implementation details
> >   of BIND, [...] it's probably better to clarify it's specific to a
> >   particular implementation architecture.
>
> I struggled with how to incorporate this feedback, because I felt like
> it was already pretty clear that I was discussing BIND specifically.
> In the end the only change I made specifically about this was to say
> "The version of BIND" instead of just "BIND", because I'm not even
> sure whether it would be an issue in the latest versions.  I also
> swapped the sequence of events around to match the real incident that
> happened (A was received first, then later CNAME, versus the original
> doc saying CNAME then A).

My memory on this topic is already quite vague, but I guess I had this
impression since this paragraph begins with a generic sentence without
mentioning a particular implementation.  I'm not necessarily opposed
to the current text, but if I were to suggest something, I might say:

   This was observed with an initial implementation in BIND when a
   hostname changed from having an IPv4 Address (A) record to a CNAME,
   and could happen for other implementations depending on how they
   manage cached data.

In this suggested text I've made two unrelated changes:

- s/, where a hostname changed/when a hostname changed/
  sine the original phrase was a bit confusing to me (it could read as
  if it talked about something about the BIND implementation, but it's
  actually talking about in which case the problem happens).
- fixing typo: s/record.to/record to/
  You'll at least need to fix this one even if the other part of the
  suggestion is rejected.

--
JINMEI, Tatuya

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 11 Jul 2017 14:37:17 -0400

>   You'll at least need to fix this one even if the other part of the

Both done in the pending draft, which I hope to post after a call for
adoption.  (I'd caught the latter right after submitting.  Isn't that
the way it always is?)