DNS resolver for local domain not always resolving

Software SW help
1

Hi,

i have enabled the DNS resolver for local resolving by enabling the option in Foris UI. I have noticed the following behaviour:

I ping “myhost.mylocaldomain”, and the pings are returned by "myhost.mylocaldomain"
I ping “myhost” without the extended domain and the pings are returned by “myhost.mylocaldomain”. So far, so good, but:

I dig the DNS from a lan client for “myhost.mylocaldomain” and the DNS returns the correct IP.
I dig the DNS from a lan client for “myhost” without the extended domain, and DNS does not resolve this host. What can i do to fix this?

2

I am old, and this is from memory…

I am assuming you’ve a WIndows client (I am not so sure of the behaviors of un*x clients).

If you execute ipconfig /all, you’ll see something like:

Connection-specific DNS Suffix . : home

The Turris/OpenWrt default is ‘lan’, but I use ‘home’.

So, if your client pings somehost, it goes via the gethostbyname API and will try:

somehost
somehost.home

IIRC, on Windows, if the Primary (?) domain suffix is A.B.C (e.g. company.co.uk), it will also try:

somehost
somehost.A.B.C
somehost.B.C
somehost.C

There are ways of adding multiple suffices to a Windows client (I recall via DHCP options).

[EDIT] Oh, and there is also a primary DNS suffix. So the Primary suffix is used for all interfaces, but the Connection-specific suffix is only for that interface.

And don’t even ask me what is was like when Windows relied upon NetBIOS name resolution in addition to the above!

3

dig queries raw DNS. IMO it’s best, assuming you want it, to instruct your OS to append your domain suffix for dot-less names. (Some dotless names do have data in today’s DNS, but well…) On Linux systems you want search myDomain in /etc/resolv.conf (details in man resolv.conf).

4

I am propagating the search domain via DHCP. So you say this is indented behaviour of DNS and that i should not worry about dig not resolving dotless names?

5

Well, squatting on “random” global names is risky in general. Even using .lan top-level domain is actually risky, because it’s not reserved in any way – someone may just register it in the next round; there are many already – but we would know about .lan being taken long enough in advance, etc.

6

The search domain i propagate is reserved by myself. It is a subdomain of a “real” domain i own, and which points to my home LAN via DynDNS, so this is no problem. Trying to reach to a random hostname from the inside is pointing to my router via a default fallback directive in dnsmasq.
However, i still am not sure if you made clear that the search domain extension is the intended behaviour - or should i configure my dnsmasq/kresd to resolve not-extended hostnames as well?

7

Knot-resolver does not auto-extend queries. There it would be more risky than usual if some other resolver was forwarding to it, as it’s common to ask one-label queries, e.g. cz NS.

I certainly prefer doing this on the client, though one could easily change the scripts to fill the resolver with both the dot-less and full names.