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

神明達哉 <jinmei@wide.ad.jp> Tue, 11 July 2017 18:01 UTC

MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
In-Reply-To: <22866.37576.448814.454933@gro.dd.org>
References: <CAJE_bqebjKFEvWEQbHM49sr_BgFEf8PtrnFWWPphSttFU+aQ8A@mail.gmail.com> <22866.37576.448814.454933@gro.dd.org>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Tue, 11 Jul 2017 11:01:18 -0700
Message-ID: <CAJE_bqeaYsoPD=-4o0tdkKnyPXAY5iVPpUxJLOX6njMwzivrjg@mail.gmail.com>
To: Dave Lawrence <tale@dd.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pBOBwITMA49aekSyD6whkFj18kA>
Subject: Re: [DNSOP] comments on draft-tale-dnsop-serve-stale-00
Precedence: list

At Tue, 27 Jun 2017 13:15:52 -0400,
Dave Lawrence <tale@dd.org> 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

[DNSOP] comments on draft-tale-dnsop-serve-stale-… 神明達哉
Re: [DNSOP] comments on draft-tale-dnsop-serve-st… Dave Lawrence
Re: [DNSOP] comments on draft-tale-dnsop-serve-st… 神明達哉
Re: [DNSOP] comments on draft-tale-dnsop-serve-st… Dave Lawrence