DNS confusion in my LAN

MAC takes precedence, careful it also assigns the hostname to that IP


Yes if MAC matches and hostname is also configured, any hostname supplied by the host will be ignored. I think also if MAC is specified but does not match, nothing else in the reservation has any effect.

The first case is useful with IP cameras and other things where you can't configure its hostname. If you make a reservation just MAC and hostname, the IP address will still be automatically assigned but you can access the thing with your DNS having a known hostname.

Really the only time not to let the "random" automatic IP's be set is if the only way an application can be configured to reach the host is a fixed IP, for example a GRE tunnel or port forward. The OP hasn't made a case for doing this. In the basic home network just be sure that two things with the same hostname can never be online at the same time. Use reservations to give DNS unique names if necessary but don't assign reserved IP addresses. That way there's no IP conflict.


Tried a few things. I wanted to try @psherman way of just naming the machine by it's MAC address and giving it a static lease IP. Any distro that's booted on that machine will get assigned that IP. I could do that for a laptop and a secondary machine, but I have nightly backup script that requires the hostnames for my main machine distros. So I tried a hybrid (all in Static Leases): I gave the laptop an entry for it's MAC address and a static lease IP. Same for the secondary machine. For my primary machine and server, I retained a separate hostname and IP for each distro. I thought this would work and initially it seemed to. All distros on the laptop booted and ifconfig showed the same IP that I set in the router. Same for the secondary machine. They could all ping one another using their names. However, some pings produced the IP of the target, but others a number like 2631:658:8406:5f::b18 which looks like an IP6 derivative. OK, but ping did reach it's target. However, in those cases, cifs mount fails. Entries in fstab previously worked to mount shares using cifs, but now "mount" fails to find it's target. So I guess more is needed than just one addition for the laptop. I tried adding all the distros giving them different hostnames but the same MAC address and IP...that didn't fly with cifs mount either.

I think, I will go back to a version of a name for each distro and give them separate static leases. Pretty much what I had to start, but in the Static Leases page rather than Hostnames. The one thing that I'll need to change is the lease duration. Rebooting the laptop sometimes gives the new distro the old one's IP.

Since your network is IPv4 only, make sure OpenWrt's DHCP IPv6 server options are set to disabled. By default they are enabled, and this can cause problems with some clients.

It seems to me you're making this way more complicated than it needs to be. The whole point of DNS is to access network hosts by name instead of number. If all your applications can use names, you don't have to reserve numbers at all. Just be sure everything has a unique name. DHCP will take care of giving them unique numbers. You may never even see an IP address.

I started this post because recently I began having problems mounting cifs shares between machines in my lan. I assumed that perhaps the router was hanging unto IP leases for machines that had been rebooted into another distro. Everyone gave good advice about how to do my Openwrt DHCP settings. I tried all of those approaches. SSH always worked to find and connect within the lan. On the other hand, samba-cifs always had a problem somewhere. Since ssh and ping rely upon DNS thru the router, maybe I was wrong about Openwrt settings being the source of the problem. I tried rebooting machines, and the router between many of these changes...no joy. Then I tried just rebooting samba via #systemctl restart smbd nmbd. Afterwards the "status" of smbd was working & normal, but nmbd status showed a problem:

normal stuff, cut
May 29 09:00:32 ixub nmbd[1715]: query_name_response: Multiple (2) responses received for a query on subnet 192.168.1.abc (lan machine) for name MSHOME<1d>.
May 29 09:00:32 ixub nmbd[1715]: This response was from IP 192.168.1.xyz, reporting an IP address of 192.168.1.xyz (this is my debian server).

So I think the source of the problem is not on my DNS config on Openwrt. Perhaps something on my debian server is interfering: getting TWO responses for a query from my lan machine cannot be good. I'll start looking from this side.
@mk24 Yes, it shouldn't be that hard! It can be when one is stubborn enough.

I don't think this is the source of my problem, but I do only use IPv4 in the lan, and I see that I have some IPv6 leases. So where do I disable IPv6?

Under LAN interface disable the IPv6 address assignment.
Then go to DHCP server tab, IPv6 settings sub tab and switch Router Advertisements, DHCPv6 and NDP to disabled.

Hmmm, that seems to have cleaned up my mount-cifs problems :blush: wasn't expecting that!
So this WAS the solution! I was looking in the wrong place, so I asked my question badly. Other solutions would have worked just as well, if I had done this first. The problem was not so much a Static Lease holding on to an IP (IPv4) but a conflict from samba-cifs seeing and not recognizing IPv6 identities, at least that's what I think now. Thx to all for digging in on this. Sorry for the confusion.

There can only be one solution, so I have to give that to @mk24 for suggesting disabling IPv6
but thks @trendy for tell me how -- it was not obvious.

Don't want to start a new thread for this, but if anyone knows why I got two responses to "nmbd" please let me know

This is out of the Openwrt realm, but there are a lot of smart people here and someone may know. I won't follow up on this whether there is a response or not. Since all is working, I may not even try to fix it in my lan. Also, since nmbd is the Samba Netbios nameserver it may not even be needed...redundant? Just asking...

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.