Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <59B1F467.9010308@redbarn.org>
Date: Thu, 7 Sep 2017 23:08:43 -0400
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FAC87A99-5558-4369-ADC0-57E2B7BF0429@hopcount.ca>
References: <59B1F467.9010308@redbarn.org>
To: Paul Vixie <paul@redbarn.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nhPnoQajgbx8R86ShWiP4_4e7sA>
Subject: Re: [DNSOP] opportunistic semi-authoritative caching (Re: DNSOP
 Call for Adoption - draft-tale-dnsop-serve-stale)
Precedence: list

Apologies in advance for iPad MIME-crime. See below for crimes committed by w=
orkman rather than tools.

> On Sep 7, 2017, at 21:37, Paul Vixie <paul@redbarn.org> wrote:
>=20
> note, there's a proposal contained here.
>=20
> 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 adopt=
ion.
>>>=20
>>> ...
>>=20
>>   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 s=
erve
>> your last known good answer"?
>=20
> 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 s=
ome time ago had a feature called "pinning" whereby particular names that we=
re known to be availability-sensitive (their non-availability caused great d=
isturbance in the helpdesk) could be "pinned" -- that is, in the recursive s=
erver, they were configured never to expire from the cache. They could be re=
freshed, but they would not expire.

When I remember learning about this I remember a certain personal conflict. T=
he goal in the implementation I referred to was edge-centric, in the sense t=
hat 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 acces=
s provider that was fielding the support calls) could probably find out in s=
hort order whether this was a safe thing to do for particular domains, and t=
hey chose the domains that should be pinned, but I thought and still think t=
hat 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 b=
e better.

The conversation I have seen so far is edge-centric; a recursive operator mi=
ght serve stale data because it believes that a stale answer is better than n=
o answer in all cases. A more granular approach might allow a recursive serv=
er to cache a record with multiple TTLs, indicating (for example) that ideal=
ly 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 approximat=
e "quite stale". Telling recursive servers what to do in the event of author=
ity servers being unreachable seems better as an authority server operator t=
han 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 r=
esolver would signal tolerance for stale data in responses.

This could be implemented maybe as an EDNS option used in the request and co=
rresponding response between a recursive server and an authority server. Que=
ries within zones that were not served by their authority servers configured=
 to supply the option or which were not requested by recursive servers prepa=
red to do the necessary would be handled conventionally.


Joe