Duane

On Sun, Jul 23, 2023 at 9:20 PM Wessels, Duane <dwess...@verisign.com>
wrote:

> 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?
>

This seems very reasonable.  I'll work with them on this.


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

My first opinion is to keep the SHOULD, and let folks speak up if they feel
this is wrong.

I liked the way you worded the timeout range in section 3.1.

I do think/feel the value should be configurable by the operator.

thanks
tim



> 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