+++ This bug was initially created as a clone of Bug #894131 +++

Description of problem:

It looks like ipa-replica-install doesn't always properly add idnssoaserial for new entries.  From testing, I'm seeing a zone get added but it's missing that data.  At least that's not getting replicate back to the master.  

In order to test in my isolated environment, I have to delete the existing reverse zone because the master and replica are on same virtual network.  And in test scripts, I can't currently guarantee servers will be on different networks, so that does the same.

After initial Master install, I see this:

[root@rhel6-1 shared]# ipa dnszone-show 122.168.192.in-addr.arpa.
  Zone name: 122.168.192.in-addr.arpa.
  Authoritative nameserver: rhel6-1.testrelm.com.
  Administrator e-mail address: hostmaster.testrelm.com.
  SOA serial: 1357837632
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;

Afterward ipa dnszone-del and ipa-replica-install, I see this:

[root@rhel6-1 log]# ipa dnszone-find
  Zone name: 122.168.192.in-addr.arpa.
  Authoritative nameserver: rhel6-2.testrelm.com.
  Administrator e-mail address: hostmaster.testrelm.com.
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;


No "SOA serial" option there.  Then, if I try to re-run ipa-replica-prepare, that's when I see errors that led me here.


Version-Release number of selected component (if applicable):


How reproducible:
always (at least with ipa-replica-install options listed):

Steps to Reproduce:

On Master:
1. setup IPA Master server
2. ipa dnszone-del <reverse zone for replica if it exists>
3. ipa-replica-prepare (with no --ip-address option)

On Replica:
4. sftp replica info gpg file
5. ipa-replica-install -U --setup-dns --no-forwarders -w $ADMINPW -p $ADMINPW /dev/shm/replica-info-$s_short.$DOMAIN.gpg
  
Actual results:
ipa dnszone-show <reverse zone for replica>
does not show SOA serial value.

However, looks like it was created with one:

log shows that it should have been added with the the idnssoaserial value though:

2013-01-10T18:42:51Z DEBUG   [2/8]: setting up reverse zone
2013-01-10T18:42:51Z DEBUG raw: dnszone_add(u'122.168.192.in-addr.arpa.', idnssoamname=u'rhel6-2.testre
lm.com.', idnssoarname=u'hostmaster.testrelm.com', idnsupdatepolicy=u'grant TESTRELM.COM krb5-subdomain
 122.168.192.in-addr.arpa. PTR;', idnsallowdynupdate=True, idnsallowquery=u'any', idnsallowtransfer=u'n
one', force=True, ip_address=None)
2013-01-10T18:42:51Z DEBUG dnszone_add(u'122.168.192.in-addr.arpa.', idnssoamname=u'rhel6-2.testrelm.co
m.', idnssoarname=u'hostmaster.testrelm.com.', idnssoaserial=1357843371, idnssoarefresh=3600, idnssoare
try=900, idnssoaexpire=1209600, idnssoaminimum=3600, idnsupdatepolicy=u'grant TESTRELM.COM krb5-subdoma
in 122.168.192.in-addr.arpa. PTR;', idnsallowdynupdate=True, idnsallowquery=u'any;', idnsallowtransfer=
u'none;', force=True, ip_address=None, all=False, raw=False)
2013-01-10T18:42:51Z DEBUG raw: dnsrecord_add(u'122.168.192.in-addr.arpa.', u'@', nsrecord=u'rhel6-2.te
strelm.com.', force=True)
2013-01-10T18:42:51Z DEBUG dnsrecord_add(u'122.168.192.in-addr.arpa.', u'@', a_extra_create_reverse=Fal
se, aaaa_extra_create_reverse=False, nsrecord=(u'rhel6-2.testrelm.com.',), force=True, structured=False
, all=False, raw=False)
2013-01-10T18:42:51Z DEBUG   duration: 0 seconds

And I can see it in ldap on replica:

[root@rhel6-2 shm]# ldapsearch -h $(hostname) -xLLL -D "cn=Directory Manager" -w $ADMINPW -b dc=testrelm,dc=com idnsname=122.168.192.in-addr.arpa.
dn: idnsname=122.168.192.in-addr.arpa.,cn=dns,dc=testrelm,dc=com
idnsSOAminimum: 3600
idnsSOAexpire: 1209600
idnsSOAretry: 900
idnsSOArefresh: 3600
idnsSOAserial: 1357843373
idnsZoneActive: TRUE
nSRecord: rhel6-2.testrelm.com.
objectClass: top
objectClass: idnsrecord
objectClass: idnszone
idnsAllowTransfer: none;
idnsUpdatePolicy: grant TESTRELM.COM krb5-subdomain 122.168.192.in-addr.arpa.
 PTR;
idnsAllowQuery: any;
idnsName: 122.168.192.in-addr.arpa.
idnsSOAmName: rhel6-2.testrelm.com.
idnsSOArName: hostmaster.testrelm.com.
idnsAllowDynUpdate: TRUE

but, I cannot see it in ldap on master:
[root@rhel6-1 log]# ldapsearch -h $(hostname) -xLLL -D "cn=Directory Manager" -w $ADMINPW -b dc=testrelm,dc=com idnsname=122.168.192.in-addr.arpa.
dn: idnsname=122.168.192.in-addr.arpa.,cn=dns,dc=testrelm,dc=com
idnsSOAminimum: 3600
idnsSOAexpire: 1209600
idnsSOAretry: 900
idnsSOArefresh: 3600
idnsZoneActive: TRUE
nSRecord: rhel6-2.testrelm.com.
objectClass: top
objectClass: idnsrecord
objectClass: idnszone
idnsAllowTransfer: none;
idnsUpdatePolicy: grant TESTRELM.COM krb5-subdomain 122.168.192.in-addr.arpa.
 PTR;
idnsAllowQuery: any;
idnsName: 122.168.192.in-addr.arpa.
idnsSOAmName: rhel6-2.testrelm.com.
idnsSOArName: hostmaster.testrelm.com.
idnsAllowDynUpdate: TRUE

Also, I did confirm that I could reproduce it (at least with those ipa-replica-install options.  So, I'll go ahead and open a bug now and we can work from that I think.


Expected results:

idnssoaserial set properly and synced across all servers.

Additional info:

--- Additional comment from Rob Crittenden on 2013-01-10 21:22:52 CET ---

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3340

--- Additional comment from RHEL Product and Program Management on 2013-01-10 21:23:24 CET ---

Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Scott Poore on 2013-01-10 21:24:30 CET ---

missed listing version:

ipa-server-3.0.0-19.el6.x86_64

--- Additional comment from Martin Kosek on 2013-01-11 09:27:32 CET ---

Hello Scott, DNS SOA serial is not synchronized on purpose due to the SOA serial autoincrement feature in bind-dyndb-ldap component. In order to avoid replication issues in SOA serial increments, the attribute is not replicated.

This, however, causes masters other than the one where a zone was created to miss the SOA serial attribute and fail in serving the zone:

# ipa dnszone-show example.com
  Zone name: example.com
  Authoritative nameserver: vm-037.idm.lab.bos.redhat.com.
  Administrator e-mail address: hostmaster.example.com.
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;

/var/log/messages:
...
Jan 11 03:17:22 vm-024 named[27579]: zone example.com/IN: has 0 SOA records
Jan 11 03:17:22 vm-024 named[27579]: zone example.com/IN: not loaded due to errors.
Jan 11 03:17:22 vm-024 named[27579]: update_zone (psearch) failed for 'idnsname=example.com,cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. Zones can be outdated, run `rndc reload`: bad zone
Jan 11 03:17:22 vm-024 named[27579]: zone example.com/IN: has 0 SOA records
Jan 11 03:17:22 vm-024 named[27579]: zone example.com/IN: not loaded due to errors.
Jan 11 03:17:22 vm-024 named[27579]: update_zone (psearch) failed for 'idnsname=example.com,cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. Zones can be outdated, run `rndc reload`: bad zone

# dig -t soa example.com

; <<>> DiG 9.9.2-P1-RedHat-9.9.2-5.P1.fc18 <<>> -t soa example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26845
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.			IN	SOA

;; Query time: 3 msec
;; SERVER: 10.16.78.24#53(10.16.78.24)
;; WHEN: Fri Jan 11 03:22:09 2013
;; MSG SIZE  rcvd: 40

Petr, could this issue be fixed in bind-dyndb-ldap component which would be less strict to missing SOA serial attribute and ideally fill it with default value (current unix timestamp) when it is missing?

Other solution would be for IPA dnszone-add command to connect to each other replica and fill this attribute or configure the replication agreement to replicate this attribute just for the first time when the entry is created - and I don't think that either approach is an option.

--- Additional comment from Petr Spacek on 2013-01-11 14:58:11 CET ---

First workaround:

On each IPA server run:
ldapmodify -Y GSSAPI << EOF
dn: idnsname=example.com.,cn=dns,dc=corp,dc=test
changetype: modify
add: idnsSOAserial
idnsSOAserial: 1
EOF

and then reload BIND:
rndc reload

Note: DN above have to be modified to match real installation.

--- Additional comment from Petr Spacek on 2013-01-11 18:43:09 CET ---

Simpler workaround:

On each IPA server run:

ipa dnszone-mod --serial=1 example.com
rndc reload

--- Additional comment from Petr Spacek on 2013-01-14 15:23:07 CET ---

Hotfix for bind-dyndb-ldap was ACKed upstream:
https://www.redhat.com/archives/freeipa-devel/2013-January/msg00070.html