Knot-resolver configuration improvement in omnia

Hi,

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’).

Peter

6 Likes

Hello.
Seems we’re solving the simmilar issue. I’m seconding this proposal.
Regards, Lukas

The functionality is already in the testing version of turris-os-packages and should (if I’ve understood it correctly) be part of the next OS release…

I have made the following changes here:

--- /tmp/kresd.orig     2016-11-22 22:00:15.772770426 -0500
+++ /etc/init.d/kresd   2016-11-22 21:59:40.512689223 -0500
@@ -38,6 +38,8 @@
                echo "  }" >> $CONFIGFILE
        fi
        echo "}" >> $CONFIGFILE
+       # load local config file
+       cat /etc/kresd/kres.config.local >> $CONFIGFILE
 }
 
 set_param_func() {

I have also added this to my config so that the fix survives the upgrade that will supposedly make this work without a patch:

--- /tmp/resolver.orig  2016-11-22 22:01:15.664544379 -0500
+++ /etc/config/resolver        2016-11-22 21:49:54.029138608 -0500
@@ -19,6 +19,7 @@
        option log_stderr '0'
        option log_stdout '0'
        option forks '1'
+       option include_config '/etc/kresd/kres.config.local'
 
 config resolver 'unbound'
        option outgoing_range '60'

… hopefully I have parsed this function correctly.

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:

policy:add(policy.suffix(policy.FORWARD('192.168.0.1'), {todname('example.com')}))

I had to dig in the knot documentation to figure that one out…

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.

Yes, maybe…

I just threw in my 2 cents, means vision…

…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. :slight_smile:

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 think you missed a letter ‘d’ in directoryname kres

The path to your local configfile should read ‘/etc/kresd/kres.config.local’.

I added your patch and it’s working for me.
Thanks for the solution.

I found an example for splitview at https://github.com/CZ-NIC/knot-resolver/blob/master/etc/config.splitview that included policy.suffix(…, {todname(…)})

oh yes, you are totally right! i have fixed my earlier comment to correct the mistake, thanks!

of course, i didn’t notice because that line doesn’t do anyhing yet - it will only when the knot resolver will be upgraded on the machine. :slight_smile:

yeah, that seems similar to what i am using.

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. :slight_smile:

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.

Sorry, I have no insight into the release process beside the few hints that can be gleaned from the dev team’s posts to this forum…

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)

1 Like

There is already one: odhcpd

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!

1 Like

i have auto-upgrades enabled, and this still doesn’t work here.

knot-libdnssec - 2.3.0-2
knot-libknot - 2.3.0-2
knot-libzscanner - 2.3.0-2
knot-resolver - 1.1.1-8

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. :frowning:

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… :confused:

 uci set resolver.common.forward_upstream=0
1 Like

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)

policy:add( --your rules here --)

policy.add(first_dns_rule)
policy.add(second_dns_rule)

1 Like

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?

1 Like