Hi,
today I wanted to try the ta sentinel functionality.
Unfortunately do I not get the expected results.
Maybe somebody could show me some example querries?
I tried:
dig +dnssec kskroll-sentinel-is-ta-20326.iis.se
dig +dnssec kskroll-sentinel-not-ta-20326.iis.se
dig +dnssec kskroll-sentinel-is-ta-19036.iis.se
dig +dnssec kskroll-sentinel-not-ta-19036.iis.se
All with the same result. No answer section.
dig +dnssec iis.se
iis.se. 60 IN A 91.226.37.214
iis.se. 60 IN RRSIG A 5 2 60 20180615103001 20180605103001 6150 iis.se.
XAbt3nM5DmpsDsvZN6gRW94mGwTsCYpAQxurTJYp4FHZXaXt82o+3SMD
ZEZjWsDswy3WsYp087Wx7Y4sH6HbuP0VYuwg1yLsBegrj6xNlcd5JarN
wi8ZGbTytnDBG5rvpqwUp8fat3ZZ6kko4t7BtsD4cFzdL2xpw4MPbBKz p0s=
What am I doing wrong?
/Ulrich
--
Ulrich Wisser
ulrich(a)wisser.se
Hi,
over the last weekend I did configure knot resolver on Turris Omnia to
write statistics to my influxdb instance.
Now that I have statistics, I am not entirely sure what all the data means.
Everything under answer is easy to understand.
But all data under cache is only 0, although answer.cached is not 0.
Please find some stats below. I would be very grateful for some explanation
what the data means.
My next step would be to try to use RPZ funtionality. is there statistics
for RPZ too?
/Ulrich
> stats.list()
[answer.nxdomain] => 360546
[answer.100ms] => 64682
[answer.1500ms] => 2740
[answer.slow] => 12137
[answer.servfail] => 204137
[answer.250ms] => 84208
[answer.cached] => 430091
[answer.nodata] => 1533
[answer.1ms] => 462921
[answer.total] => 922236
[answer.10ms] => 58963
[answer.noerror] => 356015
[answer.50ms] => 195917
[answer.500ms] => 29794
[answer.1000ms] => 7525
[predict.learned] => 54
[predict.epoch] => 19
[predict.queue] => 520
[query.edns] => 152223
[query.dnssec] => 211
> cache.stats()
[hit] => 0
[delete] => 0
[miss] => 0
[insert] => 0
--
Ulrich Wisser
ulrich(a)wisser.se
Hello knot-resolver users,
I have a question about design of systemd service for knot-resolver. I
installed knot from repository OpenSuse repository
<https://software.opensuse.org//download.html?project=home%3ACZ-NIC%3Aknot-r…>
on Ubuntu 16 and 18.
The systemd service uses user *knot-resolver*. But this user cannot bind to
unprivileged ports, so when I have configuration like below where I bind to
network interface on privileged port and change user context, it fails with
"*[system] bind to '10.20.30.118@853' Permission denied*":
```
net.listen({'10.20.30.118'}, 853, { tls = true })
user('knot-resolver', 'knot-resolver')
```
To fix this I changed User *knot-resolver* to *root* in systemd service.
Now service starts to run as root, binds to network interface and then
changes context.
My question is, is this solution security wise fine? Why is the systemd
service designed to run as user knot-resolver, when I guess many people
will need to override this in order to use knot-resolver properly? What is
the main idea? Or is there a different approach to overcome this (Such as
linux capabilities)?
Thank you for responses and please correct me in anything if I am wrong.
Ondrej Vaško
