Bug 9216 - Problems when IP changes on samba server.
Summary: Problems when IP changes on samba server.
Status: CLOSED WONTFIX
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: DNS server (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Kai Blin
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-26 18:09 UTC by Ricky
Modified: 2013-06-09 08:07 UTC (History)
0 users

See Also:


Attachments
strace ping some.local (130 bytes, text/plain)
2012-09-26 18:09 UTC, Ricky
no flags Details
The Right file... strace ping some.local (8.03 KB, text/plain)
2012-09-26 18:27 UTC, Ricky
no flags Details
Packet Capture of ping with INTERNAL DNS (242 bytes, application/vnd.tcpdump.pcap)
2012-10-10 05:07 UTC, Ricky
no flags Details
Packet Capture of ping with BIND9_DLZ DNS (2.09 KB, application/vnd.tcpdump.pcap)
2012-10-10 05:08 UTC, Ricky
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ricky 2012-09-26 18:09:21 UTC
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
Comment 1 Ricky 2012-09-26 18:24:39 UTC
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
Comment 2 Ricky 2012-09-26 18:27:21 UTC
Created attachment 7945 [details]
The Right file... strace ping some.local

Attached the wrong file the first time, sorry.
Comment 3 Kai Blin 2012-10-01 07:18:24 UTC
Did you remove the old entry?
Comment 4 Ricky 2012-10-02 06:07:50 UTC
(In reply to comment #3)
> Did you remove the old entry?

When the old entry (or entries) are removed, everything works as expected again.
Comment 5 Ricky 2012-10-10 05:07:57 UTC
Created attachment 8027 [details]
Packet Capture of ping with INTERNAL DNS
Comment 6 Ricky 2012-10-10 05:08:32 UTC
Created attachment 8028 [details]
Packet Capture of ping with BIND9_DLZ DNS
Comment 7 Ricky 2012-10-10 05:09:53 UTC
It looks like recursion is the missing link in the packet captures.
Comment 8 Kai Blin 2012-10-10 06:00:05 UTC
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?
Comment 9 Kai Blin 2013-05-25 10:16:45 UTC
Any news here?
Comment 10 Kai Blin 2013-06-09 08:07:14 UTC
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.