Hi Erik,
Yes the hashlittle reads beyond bounds (read up on that in lookup3.c around line 375). It does so on purpose for speed reasons; but won't actually use the bad data or cause a segmentation error.
There is an #ifdef there to make purifiers happy, if you want that.
So it seems to be false positive. Thank you for the report!
Best regards, Wouter

I'm ok with this specific issue found using AddressSantizier being a WONTFIX, but i also think that if you are not using AddressSanitizer as part of your normal development process, you will end up with bugs.
The fact that you suggest defining VALGRIND to disable this warning shows that you currently don't use ASAN, which in my experience finds far more bugs than Valgrind and has a smaller impact on performance.
For instance if I compile with:
CFLAGS="-fsanitize=address -g -DVALGRIND" CXXFLAGS=$CFLAGS ./configure
I now get ASAN reporting numerous memory leaks in `unittest`:
```
=================================================================
==18423==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 80 byte(s) in 1 object(s) allocated from:
#0 0x7f18bf794ed0 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1ed0)
#1 0x562bca538b40 in views_create services/view.c:59
#2 0x562bca5e0004 in respip_view_conf_actions_test testcode/unitmain.c:683
#3 0x562bca5e18e8 in respip_test testcode/unitmain.c:824
#4 0x562bca5e19ea in main testcode/unitmain.c:875
#5 0x7f18bea382b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
Direct leak of 80 byte(s) in 1 object(s) allocated from:
#0 0x7f18bf794ed0 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1ed0)
#1 0x562bca538b40 in views_create services/view.c:59
#2 0x562bca5e141d in respip_view_conf_data_test testcode/unitmain.c:801
#3 0x562bca5e18de in respip_test testcode/unitmain.c:822
#4 0x562bca5e19ea in main testcode/unitmain.c:875
#5 0x7f18bea382b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x7f18bf794ed0 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1ed0)
#1 0x562bca5e123a in respip_view_conf_data_test testcode/unitmain.c:795
#2 0x562bca5e18de in respip_test testcode/unitmain.c:822
#3 0x562bca5e19ea in main testcode/unitmain.c:875
#4 0x7f18bea382b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
```
Those are almost certainly leaks from the test program rather than the actual unbound library, but their existence makes it harder to validate unbound using tools like the sanitizers because the un-important/irrelevant warnings here make testing with ASAN (and tools like fuzzers) difficult.