At Tue, 27 Jun 2017 13:15:52 -0400, Dave Lawrence <t...@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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
