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
Hi,
I would like to run Knot Resolver with DNS-over-TLS on my laptop, but I
need to configure 'policy.FORWARD' whenever I connect to our corporate
network. The information about new connection is provided by the Network
Manager, that is not a problem, but then I need to configure the
resolver somehow. I was thinking about creating a new configuration file
and simply restarting the server, but it fails with "Start request
repeated too quickly".
Is there a way to add/remove policy rules "on the fly"?
The HTTP/2 module seems like a good candidate for doing this. Can this
module be used to accomplish this task?
Best regards,
Martin Sehnoutka
PS: If there is anyone using dnssec-trigger, this would be similar, but
less complicated.
--
Martin Sehnoutka | Associate Software Engineer
PGP: 5FD64AF5
UTC+1 (CET)
RED HAT | TRIED. TESTED. TRUSTED.
Hi, Folks!
I want to use GoogleDNS 8.8.x.x as fallback forwarder when domain's NS'es
are down or inaccessible (for example, when network connectivity between me
and NS is broken).
Is it possible?
policy.add(policy.all(policy.FORWARD({ '8.8.8.8', '8.8.4.4' }))) works
well, but disables recursion at all. How to call it only after/when
recursion is failed?
WBR, Ilya
Dear Knot Resolver users,
Knot Resolver 2.3.0 has been released. This is a security release that
fixes CVE-2018-1110.
We're also introducing a new mailing list, knot-resolver-announce. Only
notifications about new releases or important announcements will be
posted there.
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-announce
Security
--------
- fix CVE-2018-1110: denial of service triggered by malformed DNS
messages (!550, !558, security!2, security!4)
- increase resilience against slow lorris attack (security!5)
Bugfixes
--------
- validation: fix SERVFAIL in case of CNAME to NXDOMAIN in a single
zone (!538)
- validation: fix SERVFAIL for DS . query (!544)
- lib/resolve: don't send unecessary queries to parent zone (!513)
- iterate: fix validation for zones where parent and child share
NS (!543)
- TLS: improve error handling and documentation (!536, !555, !559)
Improvements
------------
- prefill: new module to periodically import root zone into cache
(replacement for RFC 7706, !511)
- network_listen_fd: always create end point for supervisor supplied
file descriptor
- use CPPFLAGS build environment variable if set (!547)
Full changelog:
https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.3.0/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-2.3.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-2.3.0.tar.xz.asc
Documentation:
https://knot-resolver.readthedocs.io/en/v2.3.0/
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Hi,
I have a fresh installation of the Knot Resolver on my Fedora 27:
*Package version*:
$ rpm -q knot-resolver
knot-resolver-2.2.0-1.fc27.x86_64
but it does not work out of the box. The problem is, that the user
"knot-resolver" cannot bind to a privileged port. Why is the systemd
service file using knot-resolver user? It works just fine, when I remove
the "User=" option from service file and add this line into the
kres.conf file:
user('knot-resolver', 'knot-resolver')
The resulting process runs as knot-resolver and it binds successfully.
Best regards,
--
Martin Sehnoutka | Associate Software Engineer
PGP: 5FD64AF5
UTC+1 (CET)
RED HAT | TRIED. TESTED. TRUSTED.
Hello,
There is a website I need to use in a daily basis that uses DNSSEC,
however their keys have expired which causes validation to fail. I have
contacted their support but they failed to resolve the issue so far.
Since I can resolve the name when using `dig +cd`, I was hoping I could
configure `kresd` to skip validation when resolving that specific
domain. It seems that I should be able to do so by using the `policies`
module and the `FLAGS` action:
https://knot-resolver.readthedocs.io/en/stable/modules.html#actions
I am not sure with flag/flags to use. I inspected the source and tried
the following:
policy.add(policy.suffix(policy.FLAGS('DNSSEC_CD'),{todname('example.org.')}))
But this apparently had no effect. I also tried without the trailing dot
and played with other flags, but no success.
Does anybody know which flag I could set to bypass DNSSEC validation for
the specified domain? Or, if the policy module is not the way to achieve
that goal, is there any other way?
# kresd --version
Knot DNS Resolver, version 1.5.1
Any help will be greatly appreciated,
// Leonardo.
Greetings. I want to build Knot 2.1 on a Ubuntu 16.04.4 LTS. However, the
libknot from the packages is too old:
Makefile:87: *** libknot >= 2.6.4 required. Stop.
As compared to:
libknot-dev/xenial,now 2.1.1-1build1 amd64 [installed]
Is it possible to get the libknot package on Ubuntu 16.04.4 LTS updated
soon? If not, how do I install the latest libknot by hand?
--Paul Hoffman
Greetings. My kresd config file is:
net.listen('192.241.207.161', 5364)
trust_anchors.file = 'root.keys'
modules.load('ta_sentinel')
I wanted to test this with a zone I set up at this-is-signed.com. However,
I'm getting a positive result back for both the is-ta and the not-ta
records (it is properly giving me the SERVFAIL for the bogus record).
Have I configured Knot Resolver incorrectly? For Knot 2.2.1, do I need a
different form for the names in order to get the kskroll-sentinel effect to
kick in? From the DNSOP WG mailing list traffic, I thought I needed the
4f66 tag, but could have misinterpreted that.
--Paul Hoffman
# dig @192.241.207.161 -p 5364
kskroll-sentinel-is-ta-4f66.this-is-signed.com a
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.241.207.161 -p 5364
kskroll-sentinel-is-ta-4f66.this-is-signed.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36153
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;kskroll-sentinel-is-ta-4f66.this-is-signed.com. IN A
;; ANSWER SECTION:
kskroll-sentinel-is-ta-4f66.this-is-signed.com. 60 IN CNAME
this-is-signed.com.
this-is-signed.com. 60 IN A 192.241.207.161
;; Query time: 283 msec
;; SERVER: 192.241.207.161#5364(192.241.207.161)
;; WHEN: Sun Feb 25 00:09:54 UTC 2018
;; MSG SIZE rcvd: 105
# dig @192.241.207.161 -p 5364
kskroll-sentinel-not-ta-4f66.this-is-signed.com a
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.241.207.161 -p 5364
kskroll-sentinel-not-ta-4f66.this-is-signed.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14466
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;kskroll-sentinel-not-ta-4f66.this-is-signed.com. IN A
;; ANSWER SECTION:
kskroll-sentinel-not-ta-4f66.this-is-signed.com. 60 IN CNAME
this-is-signed.com.
this-is-signed.com. 54 IN A 192.241.207.161
;; Query time: 5 msec
;; SERVER: 192.241.207.161#5364(192.241.207.161)
;; WHEN: Sun Feb 25 00:10:00 UTC 2018
;; MSG SIZE rcvd: 106
# dig @192.241.207.161 -p 5364 bogus.this-is-signed.com a
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.241.207.161 -p 5364
bogus.this-is-signed.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20810
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;bogus.this-is-signed.com. IN A
;; Query time: 9 msec
;; SERVER: 192.241.207.161#5364(192.241.207.161)
;; WHEN: Sun Feb 25 00:10:08 UTC 2018
;; MSG SIZE rcvd: 42
