Deprecation notice for BIND 9: "resolver-nonbackoff-tries", "resolver-retry-interval"

[Fred Morris]

They don't seem well documented. Even in the ARM for 9.12 they're listed 
as options but no explanation is provided. It's easy to suspect that 
nobody is going to use an option which isn't documented (unless they're of 
a mind to browse sourcecode). This could be a self-fulfilling assumption.

On Wed, 6 Dec 2023, Evan Hunt wrote:
>
> In line with ISC's deprecation policy, I am notifying the mailing list
> of our intent to deprecate the "resolver-nonbackoff-tries" and
> "resolver-retry-interval" options in named.
>
> [...] They are not thought to be useful in a production environment,
> and we know of no operators using them. (Please let us know if this is
> incorrect!)

Exactly who is the "user", anyway? Am I to assume that "operator" is 
supposed to mean "somebody administering a naming service in conjunction 
with internet resources (addresses) to be located with said naming 
service? The default aggressive retry profile suggests that it's all about 
addresses and "happy eyeballs".

However as an example email doesn't need that level of aggression, either 
for locating SMTP servers or for filtering done with such as SPF or DANE. 
And how about all of the PYLM TXT records (and all of those SPF includes)?

The behavior of qname minimization in an environment with a lot of empty 
non-terminals strongly suggests that things are increasingly optimized 
towards namespaces which don't have a lot of them; and is there any 
problem domain addressed by the DNS where that is more the case than name 
to address mapping? (Counterexample: PTR records, now more than ever.)

I say go ahead, if nothing else consider it a "scream test". But can you 
take a moment and tell us which stakeholder group(s) you think you're 
optimizing for, why, and how?

Thanks...

--

Fred Morris