Yes, that is the expected behavior. The order of the policy rules is important. Because the startup script appends the user’s custom configuration to the end of the kresd’s config file they are executed last.
With @eman’s change, you don’t need to rewrite the startup script anymore.
This is what my full /tmp/kresd.config looks like (notice the custom config gets added to the end):
--Automatically generated file; DO NOT EDIT
modules = {
'hints'
, 'policy'
, 'stats'
, predict = {
window = 30 -- 30 minutes sampling window
, period = 24*(60/30) -- track last 24 hours
}
}
hints.config('/etc/hosts')
net.bufsize(4096)
net.ipv4=true
net.ipv6=true
cache.open(20*MB)
cache.clear()
--- Included custom configuration file from: ---
--- /etc/kresd/custom.conf
local lan_rule = policy.add(policy.suffix(policy.FORWARD('127.0.0.1@54'), policy.todnames({'lan','in-addr.arpa'})))
policy.del(lan_rule.id)
table.insert(policy.rules, 1, lan_rule)
The top comment has the setup instructions
Still I believe this to be unnecessary complicated, it is kinda more logical to insert custom config before all other commands to fix priority.
@eman’s way seams to be the long term solution, since my lan lookup broke after an update or two.
2 Likes
Agreed (as the /etc/kresd/custom.conf will not be overwritten during an upgrade, making it it persistent).
But I was more specifically referring to your remark about the location of the line (or better: the include-line) in /etc/init.d/kresd:
In the mean time I did what is stated in the OP (and only that) and it works (persistently). I asked to double-check.
So: I think that the part that I quoted just now from your post is not necessary anylonger when implementing @eman’s solution, as also confirmed by @dpdrown’s post) , right?
Right, you don’t need to modify /etc/init.d/kresd anymore
1 Like
No need to make any changes on dnsmasq or kresd.conf, just use lowercase letters for hostnames, until they will not propagate fixed version of kresd 
I think this should be somewhere on top of errata page, this isnt something which could somebody thought, when usual hostnames.lan doesnt work OOB.
1 Like
@Jason_A did you get it working? I haven’t seen any replies. It would be good to append the local domain suffix if there is dns query without any suffix.
I ended up installing a pihole in a LXC to use for ad-blocking DNS and through a configuration of dnsmasq that it uses and the existing setup of having knot and dnsmasq both running on the omnia on different ports, I believe it is actually working correctly.
I have the pihole’s dnsmasq doing expand hosts and also defined the server for that domain to be the port 5353 (dnsmasq) on the omnia. Same server and port for the reverse lookup too.
It seems to work, but it’s not really solving the problem of using the .lan domain while using knot, since dnsmasq is used on both the pihole and omnia for the local domain resolution.