"Preferred" way for router to serve local DNS

[carlucci]

DSL-AX82U here. When I first got my router, I struggled to get devices on the network to resolve by their host names. After some research and tinkering, I've accomplished this by entering my router's IP address in the LAN DHCP DNS server setting, as DNS server #1 instead of the "advertise" checkbox because apparently that appends and might cause problems. It works pretty well so far, but sometimes resolution fails for some period of time, perhaps after I reboot the router, or something.

My question is whether the most elegant way to accomplish this is what I'm doing. I've noticed the DNS Director settings and wonder if that is a more appropriate solution, or if there is another alternative someone more knowledgeable than me suggests.

p.s. there is no good reason I've chosen not to assign static hostnames along with static IPs in the manual override section of the DHCP list -- I guess I just feel like this *should* work and I'd like to figure out how to do it.

Thanks in advance.

 

[eightiescalling]

What do you define as "a period of time" after the reboot?

In the setup you describe, the resolution relies on known DHCP data - the reboot clears that information and you have to wait for it to repopulate as the clients refresh their leases. Default lease times of a day mean this can take 12 hours.

You could reduce the default lease time to reduce the time this happens for.

@drinkingbird recently put together a how-to on restoring dnsmasq lease information on a reboot but I don't recall whether that included host names or just mac/ip mappings.

 

[drinkingbird]

What do you define as "a period of time" after the reboot?

In the setup you describe, the resolution relies on known DHCP data - the reboot clears that information and you have to wait for it to repopulate as the clients refresh their leases. Default lease times of a day mean this can take 12 hours.

You could reduce the default lease time to reduce the time this happens for.

@drinkingbird recently put together a how-to on restoring dnsmasq lease information on a reboot but I don't recall whether that included host names or just mac/ip mappings.

My script is just to maintain DHCP leases upon reboot by moving the file to JFFS and setting the lease time to 30 days.

When the router reboots, the majority of connected devices will renew their lease which should get DNS resolution working again (assuming they report their hostname when obtaining a lease). However I have found some devices when in sleep or low power mode do not, some don't even do it when coming out of sleep as they don't know that the connection went down/up.

With manual assignments, that is stored in NVRAM and should survive a reboot fine.

As far as @carlucci 's comment about manually setting router IP in DHCP not sure why that changed anything, should be no different than just leaving them blank and checking "advertise router IP". That's how mine is and never any issues with resolution.

 

[carlucci]

Thank you both for your responses.

Admittedly, I've had a difficult time in the past learning the separation between DHCP and DNS, but I have a much better handle on it these days. Although, perhaps you're right, I need to pay more attention to DHCP lease-renewal when this issue pops up. FWIW - the devices that are typically unresolvable when the issue occurs are Raspberry Pis. From what you write, @drinkingbird, it sounds like I should SSH to the "not found" device by IP and manually try to renew the DHCP lease. Is it then reasonable to expect local DNS resolution immediately?

With regard to setting the router IP in DHCP, it's been a while so I can't quite remember, but I think I was having issues getting local DNS to resolve over VPN. But, differing from your point, I always had DNS public DNS servers manually specified in addition to checking the "advertise" checkbox. I will test the settings you outline over the weekend, perhaps.

 

[drinkingbird]

Thank you both for your responses.

Admittedly, I've had a difficult time in the past learning the separation between DHCP and DNS, but I have a much better handle on it these days. Although, perhaps you're right, I need to pay more attention to DHCP lease-renewal when this issue pops up. FWIW - the devices that are typically unresolvable when the issue occurs are Raspberry Pis. From what you write, @drinkingbird, it sounds like I should SSH to the "not found" device by IP and manually try to renew the DHCP lease. Is it then reasonable to expect local DNS resolution immediately?

With regard to setting the router IP in DHCP, it's been a while so I can't quite remember, but I think I was having issues getting local DNS to resolve over VPN. But, differing from your point, I always had DNS public DNS servers manually specified in addition to checking the "advertise" checkbox. I will test the settings you outline over the weekend, perhaps.

As long as the client reports a hostname, renewing the lease should make it resolve right away, by both hostname and IP (reverse/PTR). You can go to system log -> dhcp leases to see what the client reports for hostname. If it does not report a hostname, it will have a "*" and will not resolve, the only way to get a hostname in DNS for those devices via the GUI is to create a DHCP reservation for them.

 

[carlucci]

Thank you for the education! I'll use this to troubleshoot next time it pops up.