rndc serve-stale status output can be slightly confusing

The confusion is over what components of the serve-stale feature are active (or not) based on the output.

I don't think we document anywhere in the ARM how to interpret what is output.

Here are examples of what is currently output by rndc status from BIND 9.11.32-S1, and what should be understood from each:

1. Default (nothing explicitly configured)

$ rndc serve-stale status
my-default: off (stale-answer-ttl=1 max-stale-ttl=43200)
_bind: off (stale-answer-ttl=1 max-stale-ttl=43200)

Both views have stale-cache-enable yes; (by default) - otherwise we would not see values for stale-answer-ttl and max-stale-ttl. Those values are the default and have not been explicitly configured. stale-answer-enable no; is also the default.

The off means that stale-answer-enable is no and stale answers have not been enabled using rndc.

Commentary: This is confusing when you see it for the first time, because 'off' is ambiguous and could easily be misinterpreted as meaning that both stale cache and serving of stale answers are disabled (they're not)

2. Explicitly setting stale-cache-enable no;

$ rndc serve-stale status
my-default: off (not-cached)
_bind: off (not-cached)

This is easier to understand because we don't display any other options actually say 'not-cached' (although this wasn't always the case in earlier versions of BIND, which used to say just off.

Nothing is available for serving stale. You cannot enable stale answers using rndc, and even if you added 'stale-answer-enable yes;` to named.conf, this is ignored.

3. stale-cache-enable yes; (default or explicitly configured) plus stale-answer-enable yes;

$ rndc serve-stale status
my-default: on (stale-answer-ttl=1 max-stale-ttl=43200)
_bind: on (stale-answer-ttl=1 max-stale-ttl=43200)

This is the full monty - we have stale cache enabled AND we have have stale answers enabled (notice on instead of off as compared with example 1.

====

So what is the problem? The issue is that someone using a default configuration will issue rndc serve-stale status, see the output per example 1 and be confused as to whether they have serve-stale or not. Without the special knowledge that serve-stale has two components (retention of stale RRsets and serving of retained stale RRsets in specific circumstances), the existing status output can be confusing.

My suggestion for making it clearer would be something like this:

1. Default (nothing explicitly configured = stale-cache-enable yes; and stale-answer-enable no;

$ rndc serve-stale status
my-default: stale cache enabled; stale answers disabled (stale-answer-ttl=1 max-stale-ttl=43200)
_bind: stale cache enabled; stale answers disabled (stale-answer-ttl=1 max-stale-ttl=43200)

2. Explicitly setting stale-cache-enable no; (the setting of stale-answer-enable is irrelevant, it is overridden)

$ rndc serve-stale status
my-default: stale cache disabled; (stale answers unavailable)
_bind: stale cache disabled; (stale answers unavailable)

3. stale-cache-enable yes; (default or explicitly configured) plus stale-answer-enable yes;

$ rndc serve-stale status
my-default: stale cache enabled; stale answers enabled (stale-answer-ttl=1 max-stale-ttl=43200)
_bind: stale cache enabled; stale answers enabled (stale-answer-ttl=1 max-stale-ttl=43200)0)