IPA Server | Cannot create a re​vers​e record

I had an irritating issue with my IPA Server, and it had puzzled me for a while. It didn’t prevent things from working, but made it more difficult as when I would create a new A record, I would want to have it create the reverse PTR record as well, the only problem is it wouldn’t work and I would receive this error. Cannot create reverse record for 192.168.9.150. DNS reverse zone 192.in-addr.arpa. for IP address 192.168.9.150 is not managed by this server.

I could go to the reverse zone and add it just fine, and DNS resolution appeared to work without issue, however, it irritated me and I wanted to figure out what was going on. I first tried doing a Google search on the issue, however all I was really finding was some old archive issues on Red Hat’s Site regarding the issue, and it didn’t address my issue from what I could tell. It did give me some ideas though, so I began troubleshooting my DNS woes with dig and ip addr. I also looked into the /etc/resolv.conf file on the IPA server. Here is what I found.

Initial Dig

# dig -x 192.168.1.53
; <<>> DiG 9.9.4-RedHat-9.9.4-73.el7_6 <<>> -x 192.168.1.53
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18079
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 512
 ;; QUESTION SECTION:
 ;53.1.168.192.in-addr.arpa.     IN      PTR

;; Query time: 7 msec
 ;; SERVER: 8.8.8.8#53(8.8.8.8)
 ;; WHEN: Thu Feb 21 18:57:34 MST 2019
 ;; MSG SIZE  rcvd: 54

So, the dig command showed only a query and an additional, no answers. Upon learning this, I went to look at /etc/resolv.conf on the server itself.

/etc/resolv.conf

# cat /etc/resolv.conf 
Generated by NetworkManager
search home.therootuser.com
 nameserver 8.8.8.8
 nameserver 8.8.4.4

Well that doesn’t look right does it. Probably me setting up the server reflexively, as the name servers are pointing to Google. But why? That shouldn’t be there. The DNS forwarders are in the IPA server itself, and actually point to the OpenDNS servers. So having these here is an issue, and what is messing things up. So out they go. I remove the google servers, and just add the server IP itself of 192.168.1.53. Then to make sure everything is seeing the new changes, a quick systemctl restart.

Once the server rebooted, I did the dig command again.

# dig -x 192.168.1.53

; <<>> DiG 9.9.4-RedHat-9.9.4-73.el7_6 <<>> -x 192.168.1.53
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10504
 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4096
 ;; QUESTION SECTION:
 ;53.1.168.192.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
 53.1.168.192.in-addr.arpa. 86400 IN     PTR     prometheus.home.therootuser.com.

;; AUTHORITY SECTION:
 1.168.192.in-addr.arpa. 86400   IN      NS      prometheus.home.therootuser.com.

;; ADDITIONAL SECTION:
 prometheus.home.therootuser.com. 1200 IN A      192.168.1.53

;; Query time: 1 msec
 ;; SERVER: 192.168.1.53#53(192.168.1.53)
 ;; WHEN: Thu Feb 21 19:50:44 MST 2019
 ;; MSG SIZE  rcvd: 129

Ah, that is much better. This time I see 1 Query, 1 Answer, 1 Authority, and 2 Additional. So, now that it looks more promising, I went back to the IPA GUI and added a test A record, and told it to create the reverse record at the same time. This time it works without issue.

So in the end, the issue was adding DNS servers other than the DNS server, which caused the confusion. Not sure how it ended up this way, as I was sure it worked at some point, or why I put those DNS addresses in the resolv.conf file. I’m just happy the issue has been resolved and now I don’t have to do double work each time I create a DNS A record.