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

[Dave Lawrence <[e-mail]>]

Tony Finch writes:
> This sounds like it will lead to stale answers being given instead of
> re-trying other potentially working servers.

The document is explicit that you need to keep trying to get an
answer, so if an implementation is not retrying other potentially
working servers that is its own defect.

> I think serve-stale should only cover cases where servers are
> unreachable or unresponsive.

You are of course free to write your own implementation that way.
Having worked for operations where the authorities were concerned
about the possibility of accidental ServFails, I know that their
preference is that resolvers would serve-stale then too and enhance
the overall resiliency of the system.

If you think it would help, I can add some text to Implementation
Considerations about this, something like:

   Consider whether serve-stale should kick in for only the case of
   all servers being unresponsive, or whether authoritative servers
   responding with DNS RCODEs other than NoError and NXDomain also
   trigger it.  Some authoritative servers operators would prefer
   stale answers to be used in the event of their server failures,
   while other implementers see any answer from the authoritative
   server as being sufficient indication that any previously available
   answer for the question is superseded.

The implications of that are a transition from good answers to
failure answers to unavailable means that the stale answers will never
be available when they otherwise could have been, but so be it.

> If all a zone's servers start to reply REFUSED, that's a deliberate
> decision to disable the zone, and resolvers should not try to keep it
> alive beyond its TTL.

You cannot know that it is a deliberate decision to disable the zone.
In fact, I have direct operational experience of why it's a terrible
way to disable a zone.

One of my own servers was slammed for queries in a zone I was not
authoritative for.  (It was a well-known zone, too, and one which is
not DNSSEC-signed.)  My server was dutifully returning Refused to the
queries, and yet they kept coming very frequently, maxing the
link. Arguably the clients should have applied the techniques of RFC
2308 for negative caching of those Refused answers, but it was not
until I added the zone in question to send back an authoritative
answer with a proper caching signal that the queries really went away.

While it is obviously the best approach for a takedown to update the
delegation, in the situation where you have a delegation pointing to
server(s) that cannot be updated but you have control over the
servers, it is far better to provide an affirmative answer to the
question than to send Refused.  Positive caching is much better
understood than negative caching by the wide variety of DNS
implementations out there.