[dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

[Paul Vixie]

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 <gmccullagh at 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