How to configure local address DNS resoultion on Omnia

dns

#1

Does anybody knows, how to configure local DNS address resolution? Existing howto guides rely on unbound service, which on Omnia doesn’t exist.


#2

As the Omnia uses the Knot DNS Resolver, this might help: https://knot-resolver.readthedocs.io/en/latest/modules.html#static-hints

(I don’t own an Omnia yet, and I found this by looking at the documentation around).


#3

Thank you for the previous link, but I don’t want static mapping I want to use information from DHCP…


Demo for Turris Omnia
#4

Had the same problem here. I was not able to have DHCP names served via DNS with Knot and/or odhcpd. Thus I’m only using dnsmasq for IPv4.

These steps resolved the problem for me:

  1. make sure that kresd (aka Knot DNS server) is deactivated (luci -> startup) and stop it
  2. make sure that odhcpd is not running as DNS
    • from /etc/config/dhcp delete the line “option dhcpv4 ‘server’”
    • only delete the dhcpv4 not the dhcpv6!
    • restart odhcpd (luci -> startup) if you changed the file
  3. configure dnsmasq to use port 53, and thus start the dns function of dnsmasq
    • go to luci -> network -> DNS and DHCP -> Advanced Settings
    • delete the value in “DNS server port” or set it to “53”)
  4. make sure dnsmasq is activated (luci -> startup) and restart it

#5

Same problem, thanks for help. But why is knot dns installed ?


#6

Knot is probably there for DNSSEC, dnsmasq does not support DNSSEC.

So stopping knot and replacing it with DNSSEC is a bad idea.
Correct way is to configure dnsmasq to run on some higher port and configure knot to get local domains from dnsmasq.


#7

Then how do you:

  • configure knot to use the static host names from the /etc/hosts?
  • configure knot to use the dynamic hosts names that are collected via dnsmasq/DHCP?

I did not find anything about that in the knot documentation. Those two problems were my main reason for switching back to dnsmasq…


#8

From /etc/hosts? Why would anyone want to do that, /etc/hosts is only for local machine only?
Seems that dnsproxy module might do the trick: https://www.knot-dns.cz/docs/2.x/singlehtml/
I have original Turris where is unbound and dnsmasq. I did it exactly like this, I forwarded local domain zone from unbound to dnsmasq.


#9

To be honest I am a bit confused that this is not working OOB. As I see it, there is user interfaces to add host names and to configure DHCP and DNS, at a first glance this should be a breeze to set up. However, whatever setting I put into the host names entries seems to be ignored.
Can someone please explain, in a step-by-step answer, how to enable local address resolution because I can’t seem to get it to work at all.


#10

Yes, I wanted to do it like this but it seems that there is Knot resolver https://www.knot-resolver.cz/ installed and I did not find possibility yet, how to configure Knot resolver to forward local domain zone to dnsmasq. Or maybe there is no such feature yet.

Knot dns (which you are referring in your post) is probably different product (maybe I am wrong).

It looks like that in case of Knot resolver we will need some module which will be able to handle this functionality. Something like http://knot-resolver.readthedocs.io/en/latest/modules.html#static-hints but in case of local domain query it should be able either read data from files created by dnsmasq dhcp part or it should be able to make query to dnsmasq. Unfortunately there is probably not suitable module yet. Or at least I did not find it yet.


LAN hostnames no longer available? (Solved - sortof)
#11

It is already answered here.

Update (19.04.2018): Dunno exactly since when, but since some version of kresd you have to use policy.STUB() instead of policy.FORWARD()


#12

Hi,

is odhcpd really necessary, if dnsmasq is used?

p.


#13

odhcpd is used as a DHCPv6/RA Server & Relay. It’s DHCP(v4) functions are disabled. This is exactly the same setup like in current OpenWRT/LEDE.


#14

I found a solution how to resolve host-names from DHCP. Here is the solution:

Edit:
/etc/init.d/kresd
Add those two lines:

  1. in section init_header, after line echo " 'policy'" >> $CONFIGFILE
    echo " , 'hints'" >> $CONFIGFILE
  2. in section load_uci_config_common, after line set_param_func "cache.clear" ""
    set_param_func "hints.config" "'/tmp/hosts/dhcp'"

restart the KNOT service:
/etc/init.d/kresd restart

If you edit /etc/config/dhcp and add anything you want, it will be resolved as well.


DNS: which resolver to use?
Statické DNS záznamy
#15

i had a similar problem, and ended up looking at how it would be done in the next update of the resolver. it seems it will support arbitrary configuration files, with the include_config option. this allows arbitrary extensions to the resolver configuration, but of course it would be much better if the specific use case here would be covered in UCI and LUCI.

see this discussion for more information about the exact changes I did:


#16

Should this resolve static leases added to LuCI? Did not work for me.

IMHO local addres DNS resolution from /etc/ethers and /etc/hosts should be working by default.


#17

Well, for me all this works. What I had to change in comparision to default is:

  • dnsmasq port I set to 54
  • /etc/init.d/kresd - line 41 I included the line
    echo “policy.add(policy.suffix(policy.FORWARD(‘127.0.0.1@54’), policy.todnames({‘lan’,‘2.168.192.in-addr.arpa’,‘4.168.192.in-addr.arpa’})))” >>$CONFIGFILE
  • firewall update for port 54 for my guest network

This constellation works properly on my turris. DHCP dynamic, statisc lease from LUCI, DNS resolving as well.

Works also together with OpenVPN in tun mode, no issues.


#18

Thanks. This solution worked for me. After adding entries to /etc/config/dhcp I had to restart kresd for the changes to take effect. Same thing when I added them through luci hostnames option.


#19

Extremely clear and useful ! No more headaches :slight_smile:
Thanks !


#20

@tr1l1ner’s fix worked for me too, why isn’t that just the default config? I assume they can get that local domain from the GUI.