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
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
