That is helpful. Yes.
I’m going to summarize the content of that thread here to make sure I understand. Would you let me know if I’ve misunderstood something?
Configuring NethServer (dnsmasq) as a DHCP server and then pointing clients to NethServer for DNS/DHCP yields both forward and reverse lookup entries. These entries can be seen in NethServer’s web GUI. Reverse lookup entries are only made for clients whose IP address reside in the same subnet as NethServer’s. All of the aforementioned entries are forwarded to the nsdc, however; AD DNS passthrough doesn’t work (in other words if I attempt to join the domain while using NethServer’s DNS the join will fail).
Pointing clients to nsdc for DNS yields forward lookup entries. Clients may join the AD Domain through the nsdc DNS. Entries are not passed to NethServer’s DNS (they do not show up in the web GUI). Reverse lookup entries are not created by default on domain join (aside from the nsdc and NethServer itself (reference this thread: PTR Records, Domain deletions, and domain redirection)).
Correct? Please let me know if I’ve misunderstood.
While testing NethServer/nsdc, and after getting assistance in figuring out how to properly provision reverse lookup zones, I am still unable to achieve reverse lookup entry creation on domain join. Forward lookup zones work great.
This is not a huge stopping block for me at the moment but could be in the future. As the environment where NethServer/nsdc is deployed as an AD/DNS solution grows the administrative overhead of having to manually create each reverse lookup entry will become a bit overwhelming/tedious.
Is it expected that reverse lookup zones do not work properly? It seems to me that they should and that I’m just not going about this the correct way. Show me the light!
EDIT: Another anomaly I forgot to mention:
When creating zones via this process:
- ssh to NethServer
systemd-run -M nsdc -t /bin/bash/ (creates bash session inside nsdc container)
samba-tool dns zonecreate nsdc.fqdb.domain.io ##.##.##.ip.in-addr.arpa. -U admin
The process is successful, however; the “reverse” lookup zones are created inside the forward lookup zones folder, any entries created inside those .ip.in-addr.arpa zones do not seem to respond to nslookup/dig/etc, and (as noted earlier) are not populated dynamically when clients are joined to the domain.
I thought that was a bit odd and worth sharing.