Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-05.txt

[Dave Lawrence <[e-mail]>]

Davey Song writes:
> Normally end user have more than one configured resolvers. If only
> one resolver experience the outage and serve the stale data, could
> the user tell which resolver have more refreshed data ?

Not in the usual resolution process, no.  Whether the user's system
will fall back to the second resolver in a "reasonable" amount of time
depends on local policy.  Of course, it's entirely possible that the
second resolver won't have any better answer anyway, either because
the answer hasn't changed, it has changed but provides essentially the
same service level, or the second resolver is experiencing the
same network path problems as well.

Even if it were communicated from the recursive resolver to the stub,
then there is a further matter of communicating that to the end user.
The complexity of this led to a clear sentiment in dnsop against
including mechanisms to mark an answer that used stale data.

So yes, serving stale data is not always the best result, but
operational experience has shown that on balance the observed
benefit has outweighed the possible negative by far.

> 2) I notice it is proposed as a stand track document. If more people
> here think its benefit outweighs its impacts, I prefer it published
> as informational document

This was discussed early on, and the rationale for standards track is
that it is well within the scope of a standard to clear define
acceptable data lifetime.  While the details of each implementation
are indeed informational, being clear that data can legitimately be
used in an error condition beyond the time the TTL says it is normally
valid is properly part of the definition of a TTL.

> 3) A minor concern: in an thread in dns-operation mailing list last
> week, it is said that the behavior of serve stale in some ISPs is
> abused for reason of traffic hijack/tampering/spoofing. I'm afraid
> it will be encouraged by this document.

Two things are of note here:  they're already doing it even without an
RFC blessing it, and the document lays out pretty clearly that this is
not the condition for which serve-stale should be used.