Maintained by: NLnet Labs

[Unbound-users] bad flush "." and prefetch interaction

W.C.A. Wijngaards
Tue Jun 17 16:14:12 CEST 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

On 06/16/2014 07:02 PM, Paul Wouters wrote:
> 
> Hi,
> 
> Please see: https://bugzilla.redhat.com/show_bug.cgi?id=1109651
> 
> ExecSum: if you flush the entire cache on network-connect, when you
> have pre-fetching enabled, the entire cache is attempted to be
> pre-fetched.
> 
> It would be good if user flushed records are not marked for
> pre-fetch.

Unbound does not pre-fetch expired records.  They are fetched
normally, i.e. when a user asks for it.  So the cache flush does not
cause lookups.  It also does not cause pre-fetch.

When a record is 'near expiry' then a pre-fetch happens (if prefetch
is enabled).  This pre-fetch only happens when a user queries for that
record.  The pre-fetch does not happen if the user does not query for
the record.

For that 400 queries part of the report.  So unbound will only
generate an outbound query (except for trust-anchor updates on
schedule) when there is an inbound user query.  Also for pre-fetch.
So, those 400 queries would only happen if the user is performing 400
lookups.

I am trying to deduce what unbound would do in theory.  If in practice
this is not happening, some bug hunting is required.  Does the user
have real data or are these his estimates?  Perhaps his mobile
performs a lot of lookups when it connects to a hotspot, which is
possible, with, I don't know, a lot of apps.

Best regards,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJToE00AAoJEJ9vHC1+BF+NInQP/i2ijDGqd+BaFH6gdszTOApw
FgMnl4lDE/LB7cNuahCV85CuIVXeMCr5eYkyDKNQDb7AHEpIGZvzha18W4GsyfRu
MwhCJYZmiI19Ld64Tp2u1eA2yD1PnxyQFL7lDlXqlDFHhNydMgG3msWh1vDjFNhj
gmjk9DO0TZ6P1a+fFVbtg/4NN58fkNQ7Z6X83E1Hf5wAPdXVqNIlPwGFGsaI9W71
KtRoWUc2/192EX4wYT4GHVyFnApyPPjcpwMlEEEByeKNcExFN9krTzXwWhsNr3oS
igPptYzXkpdfvpvfYD2on08gGXCcWE1o00epe9EWjAPEO9wGZqUGryQzZWby2Mt9
dUA0jhRjNlziJ9dakc3Gx+UT/xR+D0ByZqjBcW+wWe9N+4gZAJpznyZHK9hOf4fx
yn2O6bYsxdFwvjhb8nsqTMNQ1wbUpL9qtiV1BovlYy/RM8lLpkSF5nHOTvNtAjiX
MKvSABs4DcPR2eURETFlYN4BfLLIli8DSFMf29Vn4qphex4LbGRnsrbfNboqSAWZ
21nNtA2iGNsWFG5dndmVpQ/dH5Gl89A7p8GvdYoo1b/f+VXzjFkXgbxq4MQtOnZH
nEA+BqUPCt9m6kQ/RanEonI+IMo5xBBZl8psq0lSKgjPD4cxljxqMn4RseqQrws2
kqn++Sv7fUV/fOZ8ebVw
=+FTw
-----END PGP SIGNATURE-----