Apologies if this has been asked before, but I was unable to find
informative resources about this topic except this[1].
What are the downsides of having a recursive DNS server in front of an
authoritative DNS Server? I'm wondering if all the points listed in the
linked article are relevant for small scale installations.
Is anyone running such a setup and can share some advice with regards to
rate limiting?
[1]: https://www.whalebone.io/separate-dns-servers/
--
Alex JOST
Hey list,
new here. Could someone please try explain to me, what's better about the
new algorithm for choosing nameservers? I feel like it totally broke my use
case.
I use knot-resolver as local resolver and have configured this:
acme = policy.todnames({'acme.cz', 'acme2.cz'})
policy.add(policy.suffix(policy.FLAGS({'NO_CACHE'}), acme))
policy.add(policy.suffix(policy.STUB({'172.16.21.93','172.16.21.94','8.8.8.8'}),
acme))
Until the "better" algo, it worked exactly as I wanted it to. When I was in
the network where the 172.16.21.9{3,4} DNS servers were available, they
were selected. And when they were not available, google DNS was used to
resolve those domains.
Now, even when the internal nameservers are available, they are rarely used:
$ for i in `seq 1 20`; do dig intranet.acme.cz +short; done
193.165.208.153
172.16.21.1
172.16.21.1
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
$ for i in `seq 1 20`; do dig intranet.acme.cz +short; done
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
193.165.208.153
172.16.21.1
193.165.208.153
When I remove the google DNS and leave just 172...
# systemctl restart kresd@{1..4}.service && for i in `seq 1 20`; do dig
intranet.acme.cz +short; done
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
172.16.21.1
Can I somehow switch back to the old algorithm via configuration?
Thanks
Josef
Dear Knot Resolver users,
Knot Resolver 5.3.0 has been released!
Note regarding CentOS 8 packages: Due to the Red Hat's hostile decision
to exclude devel packages from their distribution, we won't be providing
upstream packages or maintaining knot-resolver package in EPEL8 until
libuv-devel has been included in official RHEL8 release [rhbz#1895872].
If you depend on these, we can find a solution for your use-case as part
of the paid support we offer [1].
[rhbz#1895872] - https://bugzilla.redhat.com/show_bug.cgi?id=1895872
[1] - https://www.knot-resolver.cz/support/pro/
Improvements
------------
- more consistency in using parent-side records for NS addresses (!1097)
- better algorithm for choosing nameservers (!1030, !1126, !1140, !1141,
!1143)
- daf module: add daf.clear() (!1114)
- dnstap module: more features and don't log internal requests (!1103)
- dnstap module: include in upstream packages and Docker image (!1110,
!1118)
- randomize record order by default, i.e. reorder_RR(true) (!1124)
- prometheus module: transform graphite tags into prometheus labels
(!1109)
- avoid excessive logging of UDP replies with sendmmsg (!1138)
Bugfixes
--------
- view: fail config if bad subnet is specified (!1112)
- doh2: fix memory leak (!1117)
- policy.ANSWER: minor fixes, mainly around NODATA answers (!1129)
- http, watchdog modules: fix stability problems (!1136)
Incompatible changes
--------------------
- dnstap module: `log_responses` option gets nested under `client`;
see new docs for config example (!1103)
- libknot >= 2.9 is required
Full changelog:
https://gitlab.nic.cz/knot/knot-resolver/raw/v5.3.0/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.3.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.3.0.tar.xz.asc
Documentation:
https://knot-resolver.readthedocs.io/en/v5.3.0/
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Dear Knot Resolver users,
I have an early notification for those who rely on our upstream package
repositories for Debian 9 and Ubuntu 16.04.
Ubuntu 16.04: We'll no longer provide packages after April 2021 when the
distribution reaches end of life.
Debian 9: Knot Resolver 5.x is the last supported major version for
Debian 9. Once we release a new major version, we'll no longer provide
packages for Debian 9. We expect to release our next major version in
the second half of 2021.
Packages for other distributions remain unaffected and are supported as
usual.
Thanks for understanding.
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Hello Tomas,
You are right, it was just those silly configuration mistakes. Everything works now :)
Thank you so much!
Best regards,
--Manuel
________________________________
De: Tomas Krizek
Enviado: Viernes, 11 de Diciembre de 2020 13:25
Para: Knot Resolver Users List; Urueña-Pascual Manuel
Asunto: Re: [knot-resolver-users] Is policy.rpz a non-chain action?
Hi, the use-case you're trying to achieve is possible, but there are
some issues with your configuration.
On 10/12/2020 17.29, Urueña-Pascual Manuel wrote:>
policy.add(policy.rpz(policy.DENY_MSG('domain blocked'),
'/etc/knot-resolver/blocklist.rpz', true))
> policy.add(policy.rpz(policy.PASS(), '/etc/knot-resolver/allowlist.rpz', true))
You want to specify "policy.PASS" without the brackets.
> and these are the RPZ zones:
>
> $ cat '/etc/knot-resolver/allowlist.rpz':
> www.google.com<http://www.google.com> 600 IN CNAME rpz-passthrough.
> www.bing.com<http://www.bing.com> 600 IN CNAME rpz-passthrough.
When you provide kresd these RPZ zones, it will complain:
[poli] RPZ /tmp/kr_dev/etc/knot-resolver/allowlist.rpz:1: CNAME with
custom target in RPZ is not supported yet (ignored)
It's because you're trying to use unsupported CNAME. See the table in
our docs [1]. What you're probably looking for is "rpz-passthru."
instead. However, if you're using a separate allowlist with policy.PASS
action (which is your case) "." would also work here.
You should also be able to combine the blocklist and allowlist into just
a single rpz file, using policy.DENY_MSG("...") and controlling whether
domain is blocked ("CNAME .") or allowed ("CNAME rpz-passthru.") with
the RPZ rules themselves.
[1] -
https://knot-resolver.readthedocs.io/en/stable/modules-policy.html#response…
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Hello,
I'm trying to setup a knot-resolver 5.2.0-1 instance where all DNS queries should return a fixed IPv4 address, but the domains on an allow list that should return the real IPv4 address instead (by using a policy.PASS action), and the ones on a block list that should return a SRVFAIL response (by using a policy.DROP action).
I'm using Response Policy Zones (RPZ), and with an explicit list of domains to redirect the traffic to (plus the explicit allow and block lists) everything works fine. However, when trying to redirect all queries by default by using a policy.all rule, the allow list does not longer work and all queries (but blocked ones) are responded with the fixed IPv4 address.
This is my '/etc/knot-resolver/kresd.conf':
-- turns off DNSSEC validation
trust_anchors.remove('.')
-- Network interface configuration
net.listen('127.0.0.1', 53, { kind = 'dns' })
net.listen('10.127.0.20', 53, { kind = 'dns' })
net.ipv6 = false
net.listen('/tmp/kres.control', nil, { kind = 'control'})
-- Load useful modules
modules = {
'hints > iterate', -- Load /etc/hosts and allow custom root hints
'stats', -- Track internal statistics
'predict', -- Prefetch expiring/frequent records
}
-- Cache size
cache.size = 100 * MB
policy.add(policy.rpz(policy.DENY_MSG('domain blocked'), '/etc/knot-resolver/blocklist.rpz', true))
--policy.add(policy.rpz(policy.ANSWER(), '/etc/knot-resolver/redirectlist.rpz', true))
policy.add(policy.rpz(policy.PASS(), '/etc/knot-resolver/allowlist.rpz', true))
policy.add(policy.all(policy.ANSWER({ [kres.type.A] = { rdata=kres.str2ip('10.127.0.10'), ttl=300 } })))
and these are the RPZ zones:
$ cat '/etc/knot-resolver/allowlist.rpz':
www.google.com 600 IN CNAME rpz-passthrough.
www.bing.com 600 IN CNAME rpz-passthrough.
$ cat /etc/knot-resolver/blocklist.rpz
examplemalwaredomain.com 600 IN CNAME .
*.examplemalwaredomain.com 600 IN CNAME .
Thus, www.examplemalwaredomain.com is blocked:
$ dig www.examplemalwaredomain.com @127.0.0.1
; <<>> DiG 9.16.1-Ubuntu <<>> www.examplemalwaredomain.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26657
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;www.examplemalwaredomain.com. IN A
;; AUTHORITY SECTION:
www.examplemalwaredomain.com. 10800 IN SOA www.examplemalwaredomain.com. nobody.invalid. 1 3600 1200 604800 10800
;; ADDITIONAL SECTION:
explanation.invalid. 10800 IN TXT "domain blocked"
And any other domain is redirected:
$ dig nic.cz @127.0.0.1
; <<>> DiG 9.16.1-Ubuntu <<>> nic.cz @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60891
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;nic.cz. IN A
;; ANSWER SECTION:
nic.cz. 300 IN A 10.127.0.10
But the domains in the allow list are also redirected :(
$ dig www.google.com @127.0.0.1
; <<>> DiG 9.16.1-Ubuntu <<>> www.google.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49284
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 300 IN A 10.127.0.10
Interestingly, if I add a policy.PASS rule with a list of explicit domains before the policy.all one, it does work properly:
policy.add(policy.suffix(policy.PASS, policy.todnames({'example.com', 'example.net'})))
$ dig www.example.com @127.0.0.1
; <<>> DiG 9.16.1-Ubuntu <<>> www.example.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59322
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 120 IN A 93.184.216.34
Thus, it looks as if the allowed domains first hit the allow RPZ list, but then they hit the policy.ANSWER policy anyway. Is this the expected behaviour? Is there any way to implement such a default redirect but for a list of allowed or blocked domains?
Regards,
--Manuel
The knot-resolver documentation only appears to support Linux. Any plans to
make
the resolver available, or useful on systems other than Linux? While I could
put Linux in a VM, or BE, and use the resolver from there. It wouldn't really
be
very effective. Any insight to using this on any of the BSD's would be
greatly
appreciated (I'm currently using unbound along side knot authoritative).
Thanks!
--Chris
Hi,
I’ve stumbled across knot-resolver because I have an issue with my current DNS solution.
What is the best way to block a large number of domains.
I’ve trying to work with the below by it’s not functioning
Part of /etc/knot-resolver/kresd.conf
-- Domain Blocking
policy.add(
policy.rpz(policy.DENY_MSG('domain blocked by your IT department'),'/etc/knot-resolver/blacklist.rpz', true))
policy.add (
policy.rpz(policy.DENY, '/etc/knot-resolver/blacklist.rpz'))
/etc/knot-resolver/backlist.rpz
007bets.com,
Rrds,
Mike
