
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hello folks.<div class=""><br class=""></div><div class="">I noticed a behaviour with prefetch that is a bit counter-intuitive, unless I’m not reading the code correctly. It seems to me that prefetch, via “reply_and_prefetch()” returns immediately a response to the client but blacklists the cache, preventing this record from being returned to future clients until the prefetch finishes.</div><div class=""><br class=""></div><div class="">While this may make sense for usual prefetch scenarios to deal with slow upstreams, since <a href="https://github.com/NLnetLabs/unbound/commit/a8db52120b3d3ac078601ed875e8eac92bbbae65" class="">https://github.com/NLnetLabs/unbound/commit/a8db52120b3d3ac078601ed875e8eac92bbbae65</a> this is also being used with the serve expired functionality. Serve expired can also be a way to deal with slow upstreams but a major scenario where it can be used is to deal with availability issues with the upstream. If you blacklist the cache, and unbound takes a while to deal with a non-responding upstream, you loose the ability to serve the expired entry. Am I correct here?</div><div class=""><br class=""></div><div class="">I think it would be great if the prefetch logic did not blacklist the cache entry while it is doing its work. It seems to me that it returns a response to the client and then fakes another request with no listening client and the cache blacklisted to force it to use the network. Maybe there is another way to signal unbound not to use the cache? Can we use the fact that there is no listening client for this request? I tried this route but in “answer_from_cache()” cinfo is frequently NULL.</div><div class=""><br class=""></div><div class="">What are your thoughts on this issue?</div><div class=""><br class=""></div><div class="">Best regards,</div><div class="">André Cruz</div></body></html>