[dns-operations] Full-service resolver - Pending Upstream Query behaviour

Paul Vixie paul at redbarn.org
Tue Oct 5 18:04:14 UTC 2021

Frederico A C Neves wrote on 2021-10-05 09:01:
> ...
> Anyway I think that even though the incident was not DNS related "We",
> as the DNS community, could probably do better in future events.
> I would like to start a discussion or to hear implenters and operators
> of Full-service resolvers on what would be the best software
> architecture or best current configuration practice to handle a
> traffic pattern when a very popular name enters a scenario were all
> the auth-servers are timing-out or network unreachable.

was cache miss deduplication by q-tuple ever standardized? it is a nec'y 
part of kaminsky resistance and so ought to be part of whatever BCP 
corpus comes about. pending upstream query behaviour would be an 
expansion on cache miss dedup by q-tuple, such that a rising tide of 
timeouts would yield probabilistic prediction of servfail for cache 
misses aimed at the affected <zone,auth>.

in 2003, i implemented this as a form of negative caching, where the 
negativity spectrum included timeouts, refuseds, and servfails -- not 
just nxdomain. this worked well but needed refinement and the 
implementation was not open-source. so, you and i with rodney joffe 
published "resimprove" containing some of these ideas, but it has taken 
some decades to get these accepted.

i hope you succeed in this rekindling, and i would join any such effort. 
when it comes to authority dns responses to cache miss transactions, 
recent nonperformance is an excellent reason to predictively fail rather 
than packing good on top of bad. distributed state can be treated as a 
mass-like quantity, so that its inertia can be conserved at design time.


Sent from Postbox <https://www.postbox-inc.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20211005/cff480c3/attachment.html>

More information about the dns-operations mailing list