I’d like to proporse an update to knot-resolver package to support custom configuration tweaks.
Since the running configuration file for kresd daemon is generated by /etc/init.d/kresd, it is hard to inject any configuration parameters (in my case a policy for my non-public domain and a hints file) without modification of the /etc/init.d/kresd itself (my fix is to cat my_config_file >>$CONFIGFILE in init_header() function of the script.
This of course works, but in an event of package update, it will be lost and has to be re-hacked.
My proporsal is to add an option into /etc/config/resolver in ‘kresd’ section (something like option include ‘path_to_file’).
ideally, the actual functionality would be present in UCI (and LUCI) so that I wouldn’t have to mess around with this. What I needed was something to forward specific domains to another host, like this:
IMHO you should parse /etc/dnsmasq.conf to get correct local domain, or there would be an problem where you would have to configure local domain twice and posibility for mismatch between dnsmasq and kresd config.
As you are forwarding those requests to another server, you don’t have that issue, but if you would want to use dnsmasq for local DNS names, it would be rather inconvinient to modify two files, when you could actually achive it with only one config file.
Well, IMHO, there should be a GUI for Knot as there is for dnsmasq. It’s really too confusing for users to have that UI to configure DNS that actually doesn’t do anything.
This is just a a quickfix, and one that follows what the Turris people are actually doing right now - it will work after the next update. But of course the forwarding specifications from the GUI should be taken into account here. I am just not sure if the knot config should follow the dnsmasq config or there should be a separate dialog. I just didn’t want to fix that whole problem myself right now, i’ll let the turris people handle the longer term fix.
…and that vision is very welcome… i think that’s a good idea, i just hoped my solution could work as a short term solutions for more people in the meantime.
Maybe we should just wait till latest DNSMASQ makes it’s way, which apparently it contains DNSSEC support, in this way perhaps knot can be retired from default config.
i doubt this will happen: knot is made by the same people that make the turris: if anything, my bet would be they would get rid of dnsmasq more than knot, if they had an alternative DHCP server.
Do you know what is the current status and release roadmap? I consider this really very important function. I was very grateful for the Dnsmasq .lan domain while still using knot resolver configuration guide.
Hello again…
Beside local configuration file, I figured out, that there is no “official” way to have resolve reverse queries for private networks - it’s mentioned in Dnsmasq .lan domain while still using knot resolver … The documentation mentions it just “by-the-way”, but there is no other way (without modifying the /usr/lib/kdns_modules/policy.lua).
On one hand, I understand the reasons for not to do it globally, but IMHO it is quite stupid way to achieve it without a possibility to revert this behavior in local config…
But, for those, who (like me) want to make the config as clear as it could be (no modifications to system files), here is a bit of code, you can use in our local config:
–[[ “Backup” default rule for reverse DNS blocking in private networks (it’s first in rule-list) ]]–
local private_zones_rule = policy.rules[1].cb
table.remove(policy.rules, 1)
–[[ Insert your policy here… ]]–
policy.suffix(policy.FORWARD(‘192.168.100.1’), {todname(‘mydomain.net’), todname(‘100.168.192.in-addr.arpa’)}))
–[[ Reinsert the original policy ]]–
policy.add(private_zones_rule)
Good news to everybody - todays update brought the option "include_config " (under kresd section as described by anarcat above) to /etc/config/resolver! The config pragma is not present in default, however it works!
obviously, my configuration will silently fail on the next reboot, as /etc/init.d seems to be regenerated from the package. or something happened here that made my configuration go away, i am not sure what.
update: i have found out that while the include actually works now, it is overriden by other “forward” directives. so before my file is included, there are directives like:
policy:add(policy.all(policy.FORWARD('1.2.3.4')))
in the config, which override my site-specific configs…
the solution is to disable forwarding, which impacts performance, but makes things work…
Well, I haven’t noticed it, because I already had upstream forward disabled…
You could probably go around that with my “ugly” hack described a few comments before - the forward rules will be number 2 or 3 - depends how many upstream DNSes have you configured…
so - something like this will do the trick (keep upstream DNS together with overrides)… - unfortunately the way the config is generated is not very clever… ;(
local first_dns_rule = policy.rules[2].cb
table.remove(policy.rules, 2)
local second_dns_rule = policy.rules[3].cb
table.remove(policy.rules, 3)
i think that, with the latest updates, this is resolved, ie. that we can inject stuff safely in the knot resolver configuration - shouldn’t this thread be tagged as solved?