--- Begin Message ---
i have two comments here.
Ondřej Surý wrote on 2023-07-18 11:54:
With my implementor’s hat on, I think this is wrong approach. It (again) adds a
complexity to the resolvers and yet again based (mostly) on isolated incident.
I really don’t want yet another “serve-stale” in the resolvers. I have to yet
see an evidence that serve-stale has helped anything since the original
incident, but now every resolver has to have it because people want it.
i think serve-stale is a protocol violation and should be described that
way in an RFC and that any implementation who chooses to provide it
should also emit a syslog() warning when it is enabled. so, yes. but,
also no, because gavin's suggestion is nothing like serve-stale. see below.
On 18. 7. 2023, at 20:38, Gavin McCullagh <gmccull...@gmail.com> wrote:
I'd like to reach out to NLNet about changing Unbound to do this, so I want to
make sure people have a chance to disagree. Feel free to voice your
disagreement (and reasons) here if you do.
i don't think this should be an implementation option. we should define
stale-sigs in an RFC and describe them as "like servfail or formerr",
and require in all three cases (stale sigs, servfail, formerr) that at
least one other ns.nsdname be consulted before signaling failure on the
original request.
this level of complexity is the cost of full resolving. we have to limit
the amount of work done by stubs, but we do that by migrating the work
to the recursives.
--
P Vixie
--- End Message ---
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
