Since the introduction of Knot as DNS resolver with Core 203, OpenVPN or WireGuard users can no longer resolve names via IPFire’s DNS. For clients that have joined the IPFire network via a VPN connection, every DNS query results in a timeout. The Knot documentation states: "On machines with multiple IP addresses, avoid listening on wildcards like 0.0.0.0 or ::. If a client can be reached through multiple addresses, UDP responses from a wildcard address might use the wrong source address—most well-behaved clients will then reject such a response." https://www.knot-resolver.cz/documentation/latest/gettingstarted-config.html#id1 A temporary solution is to add the IP addresses of the network zones to the file “/etc/knot-resolver/config.yaml”. " network: listen: - interface: 0.0.0.0@53 - interface: 192.168.1.1@53 " It should also be possible to enter the zone names (green0, blue0, orange0, ect) there, but doing so causes knot to crash. See Bug 14024, https://bugzilla.ipfire.org/show_bug.cgi?id=14024
Hello Jörn, I can acknowledge this problem and I have been working on fixing this problem in Knot Resolver. A PoC patch is available and has already been tested successfully internally. I have submitted it to the Knot Resolver developers and am awaiting whether this has a chance of being merged as many more people are experiencing the same problem: > https://gitlab.nic.cz/knot/knot-resolver/-/work_items/173#note_335164
Hi! Do you thunk the patch will also help with the problem using Keepalived virtual IP address? My setup consists of two IPFire systems: Primary IPFire: 192.168.222.251 Secondary IPFire: 192.168.222.252 Keepalived virtual IP: 192.168.222.254 The virtual IP is used as both the default gateway and the primary DNS server for clients on the GREEN network. The virtual IP is present correctly on the active node: inet 192.168.222.251/24 scope global green0 inet 192.168.222.254/32 scope global proto keepalived green0 Knot Resolver is listening on: 0.0.0.0:53 The generated configuration contains: network: listen: - interface: 0.0.0.0@53 When a client sends a DNS query to the virtual address, the reply is sent from the physical address of the active IPFire system: nslookup google.com 192.168.222.254 reply from unexpected source: 192.168.222.251#53, expected 192.168.222.254#53
Hello, yes, this is exactly what this patch is supposed to fix. Sadly I have not heard back from upstream yet and therefore cannot finish working on the patch.
If you do not get a response from upstream, the https://gitlab.nic.cz/knot/knot-resolver/-/blob/master/CONTRIBUTING.md mentions the following options: 1. File issues and merge requests directly against the upstream repository: https://gitlab.nic.cz/knot/knot-resolver 2. Open a pull request on GitHub: https://github.com/CZ-NIC/knot-resolver They will take care of it and move it upstream. 3. Send a patch to the users mailing list: knot-resolver-users@lists.nic.cz