OS: Scientific Linux release 6.3 (Carbon) kernel: Linux cgta-srv-03.cgtanalytics.com 2.6.32-042stab061.2 #1 SMP Fri Aug 24 09:07:21 MSK 2012 x86_64 x86_64 x86_64 GNU/Linux Verseon: ipa-server-2.2.0-16.el6.x86_64 Verseon: bind-dyndb-ldap-1.1.0-0.9.b1.el6_3.1.x86_64
After installing and configuring freeIPA server, I went to migrate DNS from our old server parsing Bind conf files with bash script
I used CLI to add new records:
A record:
$ ipa dnsrecord-add example.com tiger --a-rec 192.168.78.205 --a- create-reverse
CNAME recprd:
$ ipa dnsrecord-add example.com cgta-srv-01v03 --cname-rec aptcache
A records were added w/out any problem. Though CNAME command completed w/out any warning and/or errors, I could not use DIG to retrieve any of the new CNAME records.
1--------------
$ dig @192.168.78.96 sand.cgtanalytics.com -t any ; <<>> DiG 9.8.1-P1 <<>> @192.168.78.96 sand.cgtanalytics.com -t any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30214 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;sand.cgtanalytics.com. IN ANY ;; ANSWER SECTION: sand.cgtanalytics.com. 86400 IN A 192.168.78.207 sand.cgtanalytics.com. 86400 IN CNAME marketdata.cgtanalytics.com. sand.cgtanalytics.com. 86400 IN CNAME db-qa.cgtanalytics.com. sand.cgtanalytics.com. 86400 IN CNAME histvarys.cgtanalytics.com. sand.cgtanalytics.com. 86400 IN CNAME varys.cgtanalytics.com. ;; AUTHORITY SECTION: cgtanalytics.com. 86400 IN NS cgta-srv-03.cgtanalytics.com. ;; ADDITIONAL SECTION: cgta-srv-03.cgtanalytics.com. 86400 IN A 192.168.78.96 ;; Query time: 2 msec ;; SERVER: 192.168.78.96#53(192.168.78.96) ;; WHEN: Wed Oct 3 15:38:14 2012 ;; MSG SIZE rcvd: 186
2-------------------
$ dig @192.168.78.96 marketdata.cgtanalytics.com ; <<>> DiG 9.8.1-P1 <<>> @192.168.78.96 marketdata.cgtanalytics.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24927 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;marketdata.cgtanalytics.com. IN A ;; AUTHORITY SECTION: cgtanalytics.com. 3600 IN SOA cgta-srv-03.cgtanalytics.com. itadmin.cgtanalytics.com. 2012100301 3600 900 1209600 3600 ;; Query time: 3 msec ;; SERVER: 192.168.78.96#53(192.168.78.96) ;; WHEN: Wed Oct 3 15:47:36 2012 ;; MSG SIZE rcvd: 101
Close examination of LDAP objects shows:
3-------------------
# sand, cgtanalytics.com, dns, cgtanalytics.com dn: idnsname=sand,idnsname=cgtanalytics.com,cn=dns,dc=cgtanalytics,dc=com objectClass: top objectClass: idnsrecord aRecord: 192.168.78.207 idnsName: sand cNAMERecord: db-qa cNAMERecord: histvarys cNAMERecord: varys cNAMERecord: marketdata
Other words, CNAME were added to the existing A record object, and Bind failed to retreive them.
Then, using GUI, I've added a standalone CNAME object 'test-test'
4--------------------
# test-test, cgtanalytics.com, dns, cgtanalytics.com dn: idnsname=test-test,idnsname=cgtanalytics.com,cn=dns,dc=cgtanalytics,dc=com objectClass: top objectClass: idnsrecord cNAMERecord: desktop-01 idnsName: test-test
This time, dig produced expected results
5--------------------
$ dig @192.168.78.96 test-test.cgtanalytics.com ; <<>> DiG 9.8.1-P1 <<>> @192.168.78.96 test-test.cgtanalytics.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7336 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;test-test.cgtanalytics.com. IN A ;; ANSWER SECTION: test-test.cgtanalytics.com. 86400 IN CNAME desktop-01.cgtanalytics.com. desktop-01.cgtanalytics.com. 86400 IN A 192.168.78.60 ;; AUTHORITY SECTION: cgtanalytics.com. 86400 IN NS cgta-srv-03.cgtanalytics.com. ;; ADDITIONAL SECTION: cgta-srv-03.cgtanalytics.com. 86400 IN A 192.168.78.96 ;; Query time: 3 msec ;; SERVER: 192.168.78.96#53(192.168.78.96) ;; WHEN: Wed Oct 3 15:58:40 2012 ;; MSG SIZE rcvd: 127
However, dig with -t any fails to bring a newly added CNAME
6--------------------
$ dig @192.168.78.96 desktop-01.cgtanalytics.com -t any ; <<>> DiG 9.8.1-P1 <<>> @192.168.78.96 desktop-01.cgtanalytics.com -t any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53251 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;desktop-01.cgtanalytics.com. IN ANY ;; ANSWER SECTION: desktop-01.cgtanalytics.com. 86400 IN A 192.168.78.60 ;; AUTHORITY SECTION: cgtanalytics.com. 86400 IN NS cgta-srv-03.cgtanalytics.com. ;; ADDITIONAL SECTION: cgta-srv-03.cgtanalytics.com. 86400 IN A 192.168.78.96 ;; Query time: 0 msec ;; SERVER: 192.168.78.96#53(192.168.78.96) ;; WHEN: Wed Oct 3 16:00:10 2012 ;; MSG SIZE rcvd: 103
... as some of you might guess why (Bind pluging does not search for object attributes)
So, looks like there is a missing agreement between all involved on where CNAME should leave in LDAP.
In addition, CLI tools "ipa dnsrecord-add" (as oppose GUI) does not allow flexibility on choosing where to add CNAME, and proceeds adding CNAME to the existing A record LDAP object.
A decision to go with LDAP object attributes or with separate LDAP object for CNAME will impact performance of either 'dig' or 'dig ANY' commands.
Keeping CNAME with A record object is logical and more compact solution, however 'dig <cname>' search timing and LDAP load will suffer as result. My guess, 'dig ANY' is used in the real world less... significantly less than 'dig <cname>', and its performance can be sacrificed in favor of a single record 'dig'.
If performance is a priority over LDAP size and readability, CNAME record has to be stored as a separate LDAP object, on par with A records.
Basically, CNAME record can't coexist with any other record type under same name. This constraint is not enforced in IPA 2.2, this check was added in IPA 3.0 beta 2. Please see ticket #2601.
Please provide LDIF for "good" and "wrong" records and also "good" and "bad" outputs from dig if your problem is not related to A + CNAME under same name.
This issue was caused by interchanging parameters in dnsrecord-add and missing check from #2601.
It was my mistake incorrectly switching A-name and CNAME-name in CLI,
ipa dnsrecord-add cgtanalytics.com sand --cname-rec db-qa;
vs
ipa dnsrecord-add cgtanalytics.com db-qa --cname-rec sand;
According to simo/pspacek: 3.0 checks for this condition
Closing the ticket...
Metadata Update from @cherno: - Issue assigned to mkosek - Issue set to the milestone: 0.0 NEEDS_TRIAGE
Login to comment on this ticket.