Resolve local hostnames with custom DNS

Hi,

I am currently running my own DNS, consisting of Unbound and Adguard.

Unbound is recursive resolver and acts as Upstream for both Knot and Adguard. Adguard is being handed out to clients via DHCP while Unbound is used directly for statically configured clients which don’t need Ad-Blocking (like VM’s and containers on my Proxmox host).

Complicated enough yep. But now I want to resolve local hostnames from my home.arpa domain to be resolvable across my entire network. Is this possible in any way?

Would be easier to use mDNS (aka Avahi, aka Zeroconf) and address them as hostname.local instead of hostname.home.arpa.

But also, Turris Omnia can run Unbound itself, and update local DHCP hostnames.

If somehow hostname.local is not possible for you then I suggest running unbound on the router instead on another server.

1 Like

So just install Unbound via opkg and copy over my configuration?

I started using Unbound because is a recursive resolver and also able to hold a local copy of the root zone (aka hyperlocal). Can I achieve that without using Unbound just with Knot?

My setup is bit similar to yours and was having the same request. So maybe you can find this useful:

  • My Omnia is acting as DHCP and its internal DNS is resolving hostnames of computers in my LAN.
  • I am using two RPi 3b running PiHole as a DNS server.
  • PiHole is configured, to resolve hostnames of computers in LAN using Omnia (Settings/DNS/Conditional forwarding).

As I said, my setup is different from yours, but it might give you some ideas how to approach the problem.

Not on Turris, as some lua libraries are not packaged.

home.arpa is the domain designated to home networks, so that’s what I want to use.

Is there any advantage of running Unbound on the Omnia instead of in an LXC container on a different host?

I know about conditional forwarding in Pi-Hole, Adguard does not seem to have such an option.

So it would make sense to delegate the resolving of local domains to the Omnia via Unbound right? Is there any way to do that? Right now I cannot even resolve local dhcp hostnames from the Omnia itself:

root@turris:~# dig @127.0.0.1 vuduo4kse
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38676

That may be the case, but its still a domain, who needs an authoritative DNS server, and if you going trough all the trouble of setting that up, you could use any real or made-up domain anyway. So that might be the reason why nobody uses that.

The .local domain on the other hand is for home networks, who use dynamic IP and don’t have an authoritative server at hand. It just works, independently of any local or remote DNS servers or routers.

I know about conditional forwarding in Pi-Hole, Adguard does not seem to have such an option.

I don’t use Pi-hole myself, but from what I understand, it prevents forwarding queries of internal IPs to external DNS servers. unbound doesn’t do that either.

So it would make sense to delegate the resolving of local domains to the Omnia via Unbound right? Is there any way to do that?

Take a look at /etc/config/resolver.

Your DNS query was for a host without domain. With the default settings of most home-routers you would want to query vuduo4kse.lan.

You could also try to ping vuduo4kse.local. You can’t query your DNS for it, because its mDNS not DNS.

1 Like

I don’t know what lua libairies you are talking about.

I did just the standard auth-zone configuration for unbound on my Omnia, which can be cut-and-pasted directly from the RFC.

Since then a root zone file is present in /var/etc/unbound/root.zone which is regularly updated and re-created after reboots.

I was answering the Knot Resolver question. In that case the file gets fetched by lua-http library.
https://knot-resolver.readthedocs.io/en/stable/modules-prefill.html

1 Like

So is there any way to get this working on Omnia? I could then get rid of Unbound and let Knot do all the magic.

I’m not aware of a nice way. There’s always stuff like LXC, but I don’t think you’re asking for such approaches.

Does not make sense for me as Knot is already running on my Omnia. Sadly with reduced functionality :frowning:

Are there any plans of making all features of Knot available on Turris devices?

Not sure if it would help anyone, but I am running Knot + dnsmasq myself as dnsmasq is much better at resolving hostnames assigned to hosts via dhcp.
The only change I had to do was change the listening port of knot to some different port and then start dnsmasq on port 53 and set it’s upstream DNS to Knot on that non-standard port.

I am not sure why, but on the router itself the resolving of local hostnames doesn’t work at all, as it is trying to query local hostnames from the DNS server configured on WAN interface.
I tried to add ‘nameserver 127.0.0.1’ to resolv.conf and allowed dnsmasq to listen on loopback, which makes it working, but I wonder why it doesn’t work out of the box :thinking:

It should work out of the box. localHostname.lan resolves, I believe, if you tick a checkbox in reForis/DNS. (You can choose the suffix in there, too.)

No clue :man_shrugging:
In case you mean the “Enable DHCP clients in DNS” option, I had that one enabled and proper “Domain of DHCP clients in DNS” specified, but resolv.conf only contained two “nameserver” lines pointing to WAN DNS servers and that was it.

But I discovered, that there is an option in LuCI menu “DHCP and DNS” which is called “Ignore resolv file” and that one was ticked by default. When I unticked it /etc/resolv.conf was regenerated to contain local search domain and both nameserver lines now points to loopback (one ipv4 and one ipv6) instead of WAN DNS servers.
This made it working even better than my manual changes :slight_smile:

Yes, the names from DHCP are certainly not put into /etc/resolv.conf.

:rofl:
Yeah, that’s for sure :smiley:
I definitely didn’t mean to hint something like that.

I am just saying that until I unchecked the “Ignore resolv file”, the whole /etc/resolv.conf file consisted just of two lines pointing to upstream/WAN servers, so there was no way to resolve any local hostname (at least using DNS) on the router itself. That was simple not technically possible.

To be completely explicit, this is how it looked before:

nameserver WAN.DNS.1.IP
nameserver WAN.DNS.2.IP

And after allowing dnsmasq to manage the resolv file it looks like this:

search MYDOMAIN
nameserver 127.0.0.1
nameserver ::1

Now it resolves local hostnames just fine, even when you use only short hostname, while previously it was not able to resolve even FQDN as upstream DNS servers obviously have no clue about my local network…

I’m getting that content without touching any dnsmasq settings, but I don’t know these mechanisms.

OK. Good to know.
Maybe I did something wrong during initial setup.