Created attachment 7944 [details] strace ping some.local If samba is provisioned with the ip (in this example) 172.16.10.10, but later changed to 192.168.1.100, the DNS entry for the domain does not get updated. Manually updating it with "samba-tool dns add ubuntu some.local @ A 192.168.1.100 -Uadministrator" adds the entry but breaks all name resolution for that machine. Attached is a "strace ping some.local" showing a simple ping breaking when it hits an 'unknown' network. "nslookup some.local" reports the following Server: 192.168.1.100 Address: 192.168.1.100#53 Name: some.local Address: 172.16.10.10 Name: some.local Address: 192.168.1.100 This is quite problematic when moving around VM's and trying to join other machines to the VM. The workaround/fix is to delete the invalid entry(ies) using "samba-tool dns delete ubuntu some.local @ A 172.16.10.10" At this point I have only tested this on the INTERNAL DNS, but I will give bind9_dlz a try and see if it show the same behavior. Ricky
I just confirmed that bind9_dlz does not show this behavior. Nslookup some.local still shows both entries, but the right one is returned when doing a ping some.local. Ricky
Created attachment 7945 [details] The Right file... strace ping some.local Attached the wrong file the first time, sorry.
Did you remove the old entry?
(In reply to comment #3) > Did you remove the old entry? When the old entry (or entries) are removed, everything works as expected again.
Created attachment 8027 [details] Packet Capture of ping with INTERNAL DNS
Created attachment 8028 [details] Packet Capture of ping with BIND9_DLZ DNS
It looks like recursion is the missing link in the packet captures.
Ok, recursion is not available in the internal server if you don't have a forwarder set up. Do you have a forwarder set up? That said, I don't believe that is related to your problem, because you're clearly getting an answer. Do your clients have a route to 172.16.10.10? Is the server even listening to that address?
Any news here?
Thinking about this a bit more, the ordering of the A records in a response is arbitrary and could be rotated to give round-robin load balancing. If your set-up depends in the last-set IP address being returned first, then your set-up is broken. Anyway, I don't think that automatically detecting IP addresses on the server during startup and then messing with DNS records is the correct solution here, and if you later want to change your DC's IP address, you'll have to do some additional leg work. I'll close this as WONTFIX, as I don't see a good code change to fix it and the dlz module only does the "right" thing by accident in your test.