Of those two devices, whichever is running DHCP also displays hostnames and can ping client devices using the LAN domain; e.g. ping 'engage' or 'engage.castle.hom' works as expected. Trying this on the non-dhcp device (the router in this case) returns this error:
So I had a look at the router's resolve.conf. It reads:
------------------------------
search castle.hom
nameserver 127.0.0.1
------------------------------
Here I wondered why even though this search domain is listed right there, the router doesn't use it.
I assume resolv.conf grabbed the search domain from the system>identification page.
Strange that it doesn't use the domain. Stranger still, I wondered why the nameserver address is loopback instead of the pihole's address as specifed.
(The pihole works. So clearly dns requests are pointed to it in some file, somewhere. But resolv.conf seems to disagree. Possible bug or do I just not know what the hell I'm talking about?)
I'm hazy on the concept of loopback but feeling adventurous, I thought maybe changing the nameserver there from loopback to the pihole would work.
And it does! Sort of. Temporarily.
I could then ping engage and engage.castle.hom from the router, although hostnames are still absent from the router's connected hosts page. Go figure. And its moot because resolv.conf reverts back to the above "default" upon restarting dnsmasq or rebooting the router, so the partial fix doesn't stick in any case.
The last thing I remember trying was to add this information to /etc/hosts and /etc/dnsmasq.conf on my router and pihole both:
domain=castle.hom
local=/castle.hom/
Alas, nope.
DHCP on the router is off.
I'd be fine with, and even prefer it if dhcp was served from the router if it would help. I only switched because some threads out there suggested this domain resolution snag would be fixed if the PI served dhcp. It didn't.
What I'd like to know is what information needs to be entered into which files in order for this to work. Thank you very much for your time.