I’m documenting something that wasn’t easy to uncover.
TL;DR – if you want to create a CNAME in Samba to replace an existing DNS record, you must delete the A record first.
Background
I have an Active Directory domain running on Samba. I’ve had an underpowered file server, simply called ‘files’, for a while. I finally had a chance to upgrade it to some newer hardware with a rather large SSD.
Since this, like all my home projects, is a side-project that takes several days to complete I chose to build the new server (‘concord’) and get it running while leaving ‘files’ in-place.
I like to have servers named after their roles, because it makes things easy, but we have a lot more computers than formal roles in the house. We’ve finally settled on a naming convention: Windows names are places in Washington, Apple products are from California, and Linux products are from Massachusetts. (I am aware that Unix was birthed in New Jersey but… Ew. At least X came from MIT, that’s good enough for me.)
I also have a number of dependencies on the name ‘files’ including, most crucially, my own brain. Muscle memory is hard to overcome (“ls /net/files/… damn ^H/net/concord/…”) and I don’t want to relearn a server name.
That left me with three problems to solve: follow the naming standard, use a “taken” name for the server, and build said server while the needed name is still available on the network.
The obvious answer is to use CNAMEs. I planned to set up ‘files’ as an alias to ‘concord’. Similar practice would carry us forward through an indefinite number of role-swaps in the future.
After copying all of our data from ‘files’ to ‘concord’ I confidently shut ‘files’ down and added my CNAME. This is where things went wrong.
The Problem
After shutting ‘files’ down, I started by creating the CNAME:
dc1 # samba-tool dns add 192.168.1.2 ad.jonesling.us files CNAME concord.ad.jonesling.us -U administrator Password for [AD\administrator]: ****** Record added successfully
That’s all well and good. Let’s test it out from another computer:
natick $ nslookup > files Server: dc1 Address: 2001:470:1f07:583:44a:52ff:fe4a:8cee#53 Name: files.ad.jonesling.us Address: 192.168.1.153 files.ad.jonesling.us canonical name = concord.ad.jonesling.us.
Crap. That’s the correct canonical name, but the wrong IP address – it’s ‘files’ old IP address.
Some googling uncovered someone with a similar issue back in 2012, but they “solved” it by creating static A records instead. That’s not a great solution, certainly not what I want.
I thought about it for a few minutes. I got a success message, but was the record actually created? How can I tell? What happens if I insert it again?
dc1 # samba-tool dns add 192.168.1.2 ad.jonesling.us files CNAME concord.ad.jonesling.us -U administrator
Password for [AD\administrator]: ******
ERROR(runtime): uncaught exception - (9711, 'WERR_DNS_ERROR_RECORD_ALREADY_EXISTS')
File "/usr/lib/python3.7/site-packages/samba/netcmd/__init__.py", line 186, in _run
return self.run(*args, **kwargs)
File "/usr/lib/python3.7/site-packages/samba/netcmd/dns.py", line 945, in run
raise e
File "/usr/lib/python3.7/site-packages/samba/netcmd/dns.py", line 941, in run
0, server, zone, name, add_rec_buf, None)Well, it was inserted somewhere, that much is clear.
What happens if I dig it? nslookup gave us a canonical address, but I want to see the actual DNS record. Maybe it contains a clue.
First, lets dig the CNAME:
dc1 # dig @dc1 files.ad.jonesling.us IN CNAME ; <<>> DiG 9.14.8 <<>> @dc1 files.ad.jonesling.us IN CNAME ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10370 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 7a0aa65a623d5d3bdbdc39075f2eff9d5b81dbd9ed05c9d0 (good) ;; QUESTION SECTION: ;files.ad.jonesling.us. IN CNAME ;; ANSWER SECTION: files.ad.jonesling.us. 900 IN CNAME concord.ad.jonesling.us. ;; Query time: 8 msec ;; SERVER: 192.168.1.2#53(192.168.1.2) ;; WHEN: Sat Aug 08 15:40:13 EDT 2020 ;; MSG SIZE rcvd: 100
I’ve bolded the line that shows the alias. That looks right.
But what about ‘files’?
dc1 # dig @dc1 files.ad.jonesling.us ; <<>> DiG 9.14.8 <<>> @dc1 files.ad.jonesling.us ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42296 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 0352365b5c07ecdace1ebf3c5f2effa6da5d32bfe9002b32 (good) ;; QUESTION SECTION: ;files.ad.jonesling.us. IN A ;; ANSWER SECTION: files.ad.jonesling.us. 3600 IN A 192.168.1.153 ;; Query time: 8 msec ;; SERVER: 192.168.1.2#53(192.168.1.2) ;; WHEN: Sat Aug 08 15:40:22 EDT 2020 ;; MSG SIZE rcvd: 94
Ah. That looks like a conflict. Both records exist, and one has primacy over the other.
‘files’ was assigned an address via DHCP, I never gave it a static address, so I didn’t expect that I would need to delete anything. But if I think about it, I realized that Samba doesn’t know that ‘files’ isn’t coming back. (That makes me wonder what kind of graveyard DNS becomes, with friends’ phones and laptops popping in from time to time.)
So, can we delete the old A record, and what happens if we do?
The Solution
We delete the address. It looks like it’s working:
dc1 # samba-tool dns delete 192.168.1.2 ad.jonesling.us files A 192.168.1.153 -U administrator Password for [AD\administrator]: Record deleted successfully
Was that the problem all along?
dc1 # dig @dc1 files.ad.jonesling.us ; <<>> DiG 9.14.8 <<>> @dc1 files.ad.jonesling.us ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38286 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 1610fb8ec07db8e3a43976ed5f2effdffeb142b30ca93848 (good) ;; QUESTION SECTION: ;files.ad.jonesling.us. IN A ;; ANSWER SECTION: files.ad.jonesling.us. 900 IN CNAME concord.ad.jonesling.us. concord.ad.jonesling.us. 3600 IN A 192.168.1.82 ;; Query time: 15 msec ;; SERVER: 192.168.1.2#53(192.168.1.2) ;; WHEN: Sat Aug 08 15:41:20 EDT 2020 ;; MSG SIZE rcvd: 116
That looks pretty good!