I am able to create a reverse lookup zone, however; new DNS entries from Computer Accounts joined to the domain and added to DNS did not receive PTR records.
Manually creating the records seems to work fine (via the samba-tool dns zonecreate dc.domain.io ip.in-addr.arpa. -U admin command). I really don’t like the idea of having to manually create PTR records for everything I join to the domain. Is this expected behavior? Shouldn’t the PTRs get created automatically?
Thanks!
Please see if this discussion helps
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:
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.
Not completely true: the join works. Failures occur with DDNS update queries.
The reverse lookup zone is not required by AD to work, but can be created manually. IIRC this is the same for MS AD too.
AFAIK the domain members send DDNS update query for the forward zone. About the reverse zone I don’t know. We have to dig the MS docs…
As said, my typical use case is different: the dnsmasq DHCP server provides the reverse lookup. How to configure it for AD needs to be studied.
Thanks for raising this point
@blechinger, it seems clients are responsible for updating the reverse zone too.
In samba docs they say to restart samba after the reverse zone creation. See DNS Administration - SambaWiki
systemctl -M nsdc restart samba
That’s brilliant. I’ll give that a try. Thank you @davidep !
I may not be able to experiment soon. But when I do I’d like to provide feedback on the results. Safe to post here again?