Okay so one major snag is that I don’t want the root domain getting caught up in this and I think it is. I only want subdomains, i guess I have to write a regex patter but the format in Knot is a bit confusing.
Other solution (static, but supported I think and also without breaking init.d scripts) is to add static DHCP leases (edit /etc/config/dhcp or use LuCi → Network → DHCP and DNS → Static Leases). After that you have to restart Knot using /etc/init.d/resolver restart (this is possibly bug, because I think it should work also without restart).
Verify a solution in file /tmp/kresd.config. It should contains:
hints['obluda.lan'] = '192.168.10.232'
hints['turris.lan'] = '192.168.10.1'
hints['cloudia.lan'] = '192.168.10.121'
hints['krtko.lan'] = '192.168.10.124'
I have the hints in my config file, but when I ping those names the ip is not resolved.
root@turris:~# cat /tmp/kresd.config | grep Foscam
hints['Foscam.lan'] = '192.168.1.98'
root@turris:~# ping Foscam.lan
ping: bad address 'Foscam.lan'Do the hints work for you?
Can you ping them?
It works for me. what is output of:
nslookup Foscam.lan 192.168.1.1
did you try this from your client machine, not from turris?
Server: 192.168.1.1
Address 1: 192.168.1.1
nslookup: can't resolve 'Foscam.lan': Name does not resolve
Both from turris and a client.
I don’t forward the DNS request to other IPs or Dnsmasq.
I added an entry into /etc/hosts file, and that works.
But the hints are not working.
I don’t know, it works for me with or without forwarding
@tr1l1ner I’m attempting to use this solution to a bug I’ve reported with revrerse lookup. My /etc/config/dhcp contains all of the hosts that I am attempting to reach by reverse lookup. My /etc/config/dhcp looks like this - not sure what to expect, but the only entry is my Omnia:
auto-generated config file from /etc/config/dhcp
x.x.x.1 nxnet
My interpretation of the proposed solution is that I should see (or add?) all of the other host entries. Manual add to an autogenerated file makes no sense to me. What am I missing?
You should all note that calling hints.config(...) removes all hints and loads a file, so you can lose lots of them this way. As knot-resolver documentation didn’t mention this important point, it was easy to get caught by that.
There was a bug in hints that caused it not to work if you specified a name that wasn’t all lower-case. I think it’s still so in the currently default version on Omnia. knot-resolver: add patch for hints to work with non-lowercased hints (8f64040e) · Commits · Turris / Turris OS / Turris OS packages · GitLab
4 Likes
Hah, this means that LuCI needs to be modified. It’s very misleading at the moment as the resolution settings on that page make no difference to the actual setup.
If you set the resolver configuration point to /tmp/hosts/dhcp you can at least set hostnames (“Hostnames” in LuCI) directly:
option hostname_config '/tmp/hosts/dhcp'
For static DHCP leases, you need to restart the resolver after applying changes at the moment for them to get picked up.
Hi,
may be stupid question, but what is the difference between hostnames definition in static lease section and hostnames definition in that standalone section? If i have it in static lease table as i want to have named devices with same IPs all the time, do i need it also on second place? Or i should have it only on one of these places?
Thanks for explain.
Thats an extremelly important post. No need to do adnything with dnmsaqs port or anything, just use lowecase letter (us) or update kresd (Omnia Team).
Thank you! I wouldnt notice that, and I think automatically its broken (of course I was using all first-capital-letter names).
should we mark this thread as solved? it is similar to this other one which was asking for the include_config functionality, which mostly resolves this issue…
1 Like
I think you meant dnsmasq not DNSSEC but I’m curious if you can elaborate? I’m facing Knot issues:
https://forum.test.turris.cz/t/knot-resolver-not-resolving/4356/4
And would work around it by using dnsmasq if I can’t find a resolution. But you’re suggesting that it’s bad idea because dnsmasq does not support DNSSEC. I’d rather have a working resolver without DNSSEC than no resolver though so that puts me in a bind doesn’t it? And I’m curious what the consequence is of running without DNSSEC.
Further, it looks like dnsmasq does support DNSSEC:
http://www.thekelleys.org.uk/dnsmasq/doc.html
The Omnia shipped (to me) with dnsmasq version 2.73, and it’s up to 2.77 but 2.73 supports DNSSEC:
http://www.thekelleys.org.uk/dnsmasq/CHANGELOG
and it’s being actively developed:
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=summary
So I’m left wondering why is Knot even in the equation here? But why would dropping be a bad idea when dnsmasq does DNSSEC? And is there a simple way to drop Knot, use dnsmasq, and ensure the Forris and LuCI interfaces work well with that?
It would seem /etc/config/resolver is the key and perhaps /etc/init.d/resolver as OpenWRT has a clean UCI driven configuration system I guess.
I’m not going to be popular with this opinion, but most probably because Knot is the brainchild of NIC.cz. They are managing DNS on a much greater scale than most of the users of Omnia, and perhaps they cannot see the forest for the trees. DNSSEC matters for them, whilst to most users it does not at all (and maybe they don’t even know what it is). The easy resolvability of internal hostnames (as it works with stock OpenWRT images by default) would be much more important.
1 Like
It seems to resolve local LAN hostnames fine both with and without .lan as a domain. Though sometimes I’ve noticed it stop resolving names without .lan yet still resolve names with .lan. Not to sure of why or when etc. But I’ve found .lan addresses more reliable.
For the router itself all my shortcuts now point to the IP address as every time the Knot resolver flakes on me I can’t even get to the router with name based URLs ;-). It’s been good this past day, which is better than the prior three days.
I would, I admit prefer it if the Omnia shipped with a less problematic resolver setup. I’d have no qualms if Knot wasn’t flaking on me, wouldn’t even have known what was doing the resolving … I mean these are look and learn issues when stuff isn’t working.
And yes, to me local LAN name resolution is more important than DNSSEC, totally. Though I’m a tad ignorant of the risks lacking DNSSEC poses so it’s not a well informed position, just an ordinary on ;-).
note that with the latest update here, the configuration changed. instead of using FORWARD in your rules, you need to use STUB.
Well, that’s oversimplification. It mainly depends whether you want to validate DNSSEC.
1 Like