Are there any methods for resolving names without any suffix? It would be helpful if the router could resolve names like “printer” or “router” in addition to “printer.lan” and “router.lan”. Any helpful suggestions would be appreciated!
I believe that’s normally configured at client machines. On Linux-based systems one would typically use a line search lan in /etc/resolv.conf.
It’s about DNS zone configuration, several solution approaches are possible, depending on your (local) dns.
Variant a)
Assumptions: small network, low number of resources to address
Provide dns entries for the resources (printer, scanner, iot1, homekit2) within the dns subzones your planned for (.lan, building_a.lan, …).
Provide a “search list” to your clients dns configuration containing the dns subzoes mentioned above.
Variant b)
Assumptions: larger network, larger number of resources to address, a single client usually copes with a small number out of those resources.
Consider “dns views” to provide with client-specific namespaces - for examples see the “bind reference implementation”, e.g. Understanding views in BIND 9.
Be aware that there’s a lot rope to hang yourself in there.
hi, once I set the static domain name in turris luci then I can access it e.g. switch0.lan switch1.lan synology.lan … but reforis does use .local so if I use turris or router then I reach it by router.local.
Local has advantage as the current browser handle it corrently without the need to add schema - often HTTP or https one.
I tried to make it use .local for static leases in luci. but something is broken.
And here even though the setting is completely against this.
its seems to not have been applied. altough I did restart the turris and saved all.
More evidence here:
router was set by reforis and works perfectly:
- static leases that are made static with hostname are displayed correctly in reforis.
So it seems for kresd which actually handles the stuff, there should be some mechanism that loads these domains with the same suffix local as is used for router itself. hence this is probably bug.
Don’t do that. .local doesn’t belong into DNS. BTW that’s why turris.local can work even if the client’s DNS is set to anywhere (like 8.8.8.8).
The DNS tab in luci is made for dnsmasq, but dnsmasq isn’t used for DNS on Turris (by default).
2 Likes
Thanks I will revert to .lan.
However, I just hate the fact that when I write domain.lan then the browser does not understand unless I include schema. is there way around that?
Seems that local is indeed something else per .local - Wikipedia
There is more info:
these are recommended by RFCs
*** intranet**
*** internal**
*** private**
*** corp**
*** home**
*** lan**
As pointed out in comments on the link, that RFC recommends against using them. (yes, including OpenWrt’s .lan) But it’s not a big deal in practice, as IANA is very unlikely to allow registering a TLD that’s already in wide use like this.
For Firefox I now found a way: in about:config you can define browser.fixup.domainsuffixwhitelist.lan as true. Implemented here I think: https://bugzilla.mozilla.org/show_bug.cgi?id=1634650#c20
You may add it to /etc/hosts
I have a few devices that use DHCP Client and they appear in DNS under name.domain and for those that have static IP I have added them to /etc/hosts and then one line in /etc/config/resolver:
config resolver 'kresd'
list hostname_config '/etc/hosts'
Be sure to reload resolver service after you make changes to /etc/hosts or config file
I think the issue in this case is that browsers will do a search without even attempting DNS.
1 Like
I think the solution to my problem is to add
/
at the end of the URL thus making browser to do mandatory dns request.
Using .local is worse among these options. Stick to .lan top level domain for internal services suffix
As a workaround, you can specify a list of search domains sent via DHCP in dnsmasq.
In /etc/dnsmasq.conf:
dhcp-option=option:domain-search,myprivatedomain
This is not really “resolving” the name, but it means that clients that honor this option (Linux does: I use neither Windows nor MacOS, so I have no idea about those two), in absence of domain, they will ask the DNS for the name plus the domains specified in domain-search.
So if I ask for printer, the request will be made to printer.myprivatedomain.
If you mainly use Firefox .internal is an option. I’ve switched my network to that because it’s recognized by default, no need to reconfigure every device.
Chromium (at least on Android) doesn’t recognize it by default, haven’t tried anything else.