Hi All,
Just wondering how you guys are ingesting RPZ feeds into Knot Resolver.
While Knot doesn't natively support zone transfers at this time, it
can import the zone files, and then kick the zone if the file changes,
so that's what I'm doing.
I'm doing the zone transfers (10 zones from ioc2rpz) using BIND for
now, and then writing the zone files to storage that Knot Resolver can
read.
I know that dns4eu uses Knot Resolver for their protective recursor
service, so I'd be curious to know how they're doing this.
Could be that they're using a custom version of Knot that's zone
transfer capable.
For context, I run Knot Resolver behind dnsdist, and they're
complimentary, offering huge flexibility.
Would be great to see rpz-passthru support in the BIND format too
(forgive me if that's already possible) so that a traditional
white-list-first tiered approach can be followed.
(Super impressed with Knot resolver, so hats off to all at CZ).
Cheers,
GC
Hi knot-resolver-users -- I am looking to install a DNS resolver for my local network and `knot-resolver` seemed to fit the bill.
Network is setup like this:
VLAN 1
Gateway IP 10.0.0.5
Search Domain Name internal.example.com <http://internal.example.com/>
VLAN 2
Gateway IP 10.0.1.1
Search Domain Name research.internal.example.com <http://research.example.com/>
...
At the moment, `knot-resolver` deployed to a single server (10.0.1.6) with this configuration:
```
forward:
- options:
authoritative: true
dnssec: false
servers:
- 10.0.0.5
subtree:
- internal.example.com
- options:
authoritative: true
dnssec: false
servers:
- 10.0.1.1
subtree:
- research.internal.example.com
logging:
level: info
network:
listen:
- freebind: false
interface:
- 127.0.0.1
- 10.0.1.6
kind: dns
port: 53
workers: 1
```
On another machine (10.0.0.100), public queries resolve correctly:
```
# dig @10.0.1.6 knot-resolver.cz
; <<>> DiG 9.20.17 <<>> @10.0.2.6 knot-resolver.cz
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34301
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;knot-resolver.cz. IN A
;; ANSWER SECTION:
knot-resolver.cz. 1800 IN A 217.31.204.96
;; Query time: 1281 msec
;; SERVER: 10.0.1.6#53(10.0.1.6) (UDP)
;; WHEN: Fri Jan 30 16:19:23 CST 2026
;; MSG SIZE rcvd: 61
# nslookup knot-resolver.cz 10.0.1.6
Server: 10.0.1.6
Address: 10.0.1.6#53
Non-authoritative answer:
Name: knot-resolver.cz
Address: 217.31.204.96
Name: knot-resolver.cz
Address: 2001:1488:800:400::2:96
```
Queries within internal network return the correct assigned IP address however report `SERVFAIL`:
```
# nslookup m1.research.internal.example.com 10.0.2.6
Server: 10.0.1.6
Address: 10.0.1.6#53
Non-authoritative answer:
Name: m1.research.internal.example.com
Address: 10.0.2.6
;; Got SERVFAIL reply from 10.0.1.6
** server can't find m1.research.internal.example.com: SERVFAIL
```
Replacing `10.0.2.6` with `10.0.0.5` (gateway IP that normally acts as resolver) does not return `SERVFAIL`:
```
# nslookup obnoxious.research.in.rambaud.dev 10.0.0.5
Server: 10.0.0.5
Address: 10.0.0.5#53
Name: m1.research.internal.example.com
Address: 10.0.2.6
```
Is the SERVFAIL something I should worry about here? Or is there a misconfiguration on my end with `knot-resolver`?
Darren
