A followup to my own post. It appears to work as expected, but it definitely works better when pointed to the RIGHT master with actually up-do-date data ;)
Please excuse me for the false alarm. /mjt Michael Tokarev wrote:
Is it just me or is unbound actually not doing flush* operations? # unbound-control flush_zone tls.msk.ru ok removed 50 rrsets, 83 messages and 0 key entries # unbound-control flush_zone tls.msk.ru ok removed 50 rrsets, 83 messages and 0 key entries # unbound-control flush_zone tls.msk.ru ok removed 50 rrsets, 83 messages and 0 key entries # unbound-control flush_zone tls.msk.ru ok removed 50 rrsets, 83 messages and 0 key entries so on each invocation (i did that one right after another), it reports that it removed the same amount of records. But actual reports are not being removed, since querying it for an RR which changed on master (it's a forward zone) returns the same, old data. flush and flush_type does not appear to work the same way as flush_zone above - both reports a name were flushed but in reality it is not. Also, unbound-control help says that argument for 'flush' is optional, but it returns syntax error if no argument is given to it: # unbound-control flush error cannot parse name Restarting the cache clears up the stale data and it starts returning new data as it should. But no flush* magic appears to help. This is unbound 1.3.4-1, a Debian package. Thanks! /mjt
_______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
