Apologies in advance for iPad MIME-crime. See below for crimes committed by workman rather than tools.
> On Sep 7, 2017, at 21:37, Paul Vixie <p...@redbarn.org> wrote: > > note, there's a proposal contained here. > > Jared Mauch wrote: >>> On Thu, Sep 07, 2017 at 01:29:47PM -0700, Paul Vixie wrote: >>> if the draft being considered was clear on two points, i'd support adoption. >>> >>> ... >> >> Would you see the querying application informing you of intent via >> option code saying "If I'm unable to talk to you once TTL expires, I may >> serve >> your last known good answer"? > > i don't think so. if it was "may i serve your last good answer?" then yes. > but with it as "i may" and the ? outside the quotes as shown above, then no. There's a recursive operator with whom Jared and tale may be familiar that some time ago had a feature called "pinning" whereby particular names that were known to be availability-sensitive (their non-availability caused great disturbance in the helpdesk) could be "pinned" -- that is, in the recursive server, they were configured never to expire from the cache. They could be refreshed, but they would not expire. When I remember learning about this I remember a certain personal conflict. The goal in the implementation I referred to was edge-centric, in the sense that the goal was to reduce the opportunity for end-users to see breakage due to DNS resolution failure. The recursive operator (and, by proxy, the access provider that was fielding the support calls) could probably find out in short order whether this was a safe thing to do for particular domains, and they chose the domains that should be pinned, but I thought and still think that that was a less desirable workflow than the zone manager signalling what the behaviour should be in the event that authoritative servers couldn't be reached. The implementation was pragmatically good, but I thought it could be better. The conversation I have seen so far is edge-centric; a recursive operator might serve stale data because it believes that a stale answer is better than no answer in all cases. A more granular approach might allow a recursive server to cache a record with multiple TTLs, indicating (for example) that ideally you would refresh this response after N seconds, but if you can't do that then perhaps M seconds would be fine. A large M would reasonably approximate "quite stale". Telling recursive servers what to do in the event of authority servers being unreachable seems better as an authority server operator than having to deal with a variety of behaviours between you and the end-user. This is different from a mechanism whereby a stub or downstream recursive resolver would signal tolerance for stale data in responses. This could be implemented maybe as an EDNS option used in the request and corresponding response between a recursive server and an authority server. Queries within zones that were not served by their authority servers configured to supply the option or which were not requested by recursive servers prepared to do the necessary would be handled conventionally. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
