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

[Dave Lawrence <[e-mail]>]

Thank you for the feedback, Jinmei!  Now that Akamai finally posted
its IPR notice we can work on moving it forward.  We plan on asking
for WG adoption now that -01 is up.

https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/

Jinmei wrote:
> - I suspect it should include 'Updates: 1035 (if approved)' in the
> top boilerplate.

Done.  1034 too.

>   The recommended value of the client response timer is 1.8 seconds,
>   so end clients will see this amount of delay for queries for which
>   this technique is needed (most notably while the corresponding
>   authoritative servers are under a DoS attack and unreachable).  I
>   wonder whether this is really acceptable in terms of user
>   experience.  According to the draft this implementation has been
>   actually used in the field (correct?).  If so, were the end users
>   okay with the delay?

It's hard for me to address directly what "okay" is.  I can only say
that they got service when otherwise there would have been done.

We're certainly open to discussing timer values.  In fact, Warren has
previously told me that he doesn't think the values are right either.
We might end up with some different recommendations based on
particular use-cases.  At any rate, they're all "SHOULD" for people to
adjust for whatever their own reasons.

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

Also, as noted with the other timers, it's still a SHOULD.

It doesn't seem worth it to me to add even more text cataloguing the
problems that some people have encountered with 0 TTL, such as
informally described in
http://mark.lindsey.name/2009/03/never-use-dns-ttl-of-zero-0.html

I am, however, still open to further discussion on whether there is a
compelling reason to use 0 instead of 1.  I realize 1035 did have a
pretty explicit definition of what it though 0 *should* mean, but then
went on to describe sending 0 TTL SOAs, which no one does.

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

If people think there is additional wording improvement still needed
here, please suggest.