Tim,

You said you received some operational feedback.  I wonder if it would be 
appropriate to add this operational (or implementation?) feedback to the 
(currently empty) Implementation Status section that Peter van Dijk suggested 
we add, in his DNS directorate review?

I’m not necessarily opposed to reducing the minimum caching time from 5 to 1, 
especially if we can document valid reasons for doing so.  However, I do think 
it is going a bit to far to weaken both the minimum caching time and the 
requirement level for exponential backoff.  So I would really argue to keep the 
SHOULD in the second paragraph.

Alternatively, we might consider something like 5 seconds without an 
exponential backoff implementation OR an initial 1 second cache time with an 
exponential backoff.

DW


 
> On Jul 23, 2023, at 9:00 PM, Tim Wicinski <tjw.i...@gmail.com> wrote:
> 
> 
> 
> All,
> 
> We had a discussion this morning during the hackathon about a value with 
> the document caching-resolution-failures.  The current text in 3.2 says:
> 
>     Resolvers MUST cache resolution failures for at least 5 seconds.  The
>     value of 5 seconds is chosen as a reasonable amount of time that an
>     end user could be expected to wait.
> 
>     Resolvers SHOULD employ an exponential backoff algorithm to increase
>     the amount of time for subsequent resolution failures.  For example,
>     the initial time for negatively caching a resolution failure is set
>     to 5 seconds.  The time is doubled after each retry that results in
>     another resolution failure.  Consistent with [RFC2308], resolution
>     failures MUST NOT be cached for longer than 5 minutes.
> 
> 
> There was some operational feedback that suggests 1 second is also 
> a very reasonable value here.  With some discussion, here is some 
> suggested text:
> 
>     Resolvers MUST cache resolution failures for at least 1 second.
>     The initial duration SHOULD be configurable by the operator.  A
>     longer cache duration for resolution failures will reduce the
>     processing burden from repeated queries, but will also lengthen
>     the recovery period from transitory issues.
> 
>     Resolvers MAY* employ an exponential backoff algorithm to increase
>     the cache duration when resolution failures are persistent.  For
>     example, the initial time for negatively caching a resolution
>     failure could be set to 5 seconds, and doubled after each retry
>     that results in another resolution failure, up to a configurable
>     maximum.
> 
>     Consistent with [RFC2308], resolution failures MUST NOT be cached
>     for longer than 5 minutes.
> ---
> 
> * Note that the original text has this as SHOULD. I've heard reasons for both 
> SHOULD and MAY. 
> 
> We'd like to hear from the working group on this value, and what the working 
> group thinks of this change
> 
> thanks
> tim
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/1EOBeLhMBEWg1uxqfTYxtUCMTcEb3F3FEA2EO7c3JOioTtVNfCLJH16XnnbuotVr49ldBsx_KxI4Vx5CjDqNuYdQ17vtalwP-jShq2peErxec4rVO5LJ33FG2rYySJ-hZugq-0SR7DVGxYLZEl-uJBfoRv8Zktrm5CSMGpC4jjfksy9itIXwMXbnVKRQ8qOV2E-xDb5PqUtQMLBambGxjnlXoTHtQl2dqFRx1kA7Tyg6-9vnpU5kAoRVbl_5ghCwqXM4Go0HV4s-Z-P0vPvWnuXP40ATm_rhOsymJUvwkppy58V9UrsCxC81vA7ic1gIe/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to