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