https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7335

--- Comment #6 from Reindl Harald <[email protected]> ---
yes, i will try to find debug-infos but need to do that on a different machine

on the production server i can trigger the test result also when i restart
unbound (meaning some of the first tests don't return URIBL_BLACK) when i
restart unbound before and so the cache is empty

the main difference here is the 872 ms response

looks like it's not a matter of "showing SA is not sending the query" but the
asynchron responses are somewhere handeled racy and i guess the same happens
when the TTL expired which may explain the differences 

on the other hand it does not really explain the changing results within a
short timeframe while that's absoluetly not predictable to trigger

at tleat the dig results are showing that the unbound cache *is* answering
after a restart / expire
_________________________________________________________

[root@mail-gw:/scripts/spamfilter/development]$ dig
finewatch2016.ru.black.uribl.com.

;; ANSWER SECTION:
finewatch2016.ru.black.uribl.com. 294 IN A      127.0.0.2

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mi Jul 06 12:58:51 CEST 2016
;; MSG SIZE  rcvd: 77

[root@mail-gw:/scripts/spamfilter/development]$ systemctl restart unbound
_________________________________________________________

[root@mail-gw:/scripts/spamfilter/development]$ dig
finewatch2016.ru.black.uribl.com.

;; ANSWER SECTION:
finewatch2016.ru.black.uribl.com. 300 IN A      127.0.0.2

;; Query time: 872 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mi Jul 06 12:58:58 CEST 2016
;; MSG SIZE  rcvd: 77

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to