Bug 840383

Summary: Implement SOA serial number increments for external changes
Product: Red Hat Enterprise Linux 6 Reporter: Petr Spacek <pspacek>
Component: bind-dyndb-ldapAssignee: Adam Tkac <atkac>
Status: CLOSED ERRATA QA Contact: Namita Soman <nsoman>
Severity: unspecified Docs Contact:
Priority: high    
Version: 6.4CC: jgalipea, ovasik, pspacek
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Feature: Automatic updates of SOA serial number Reason: When multiple named processes shared one LDAP database and dynamically updated DNS record there (via DDNS), they didn't update SOA serial numbers so it was impossible to serve such zones on secondary servers correctly (i.e. they wasn't updated on slave servers) Result (if any): The plugin now updates SOA serial automatically, if configured. Check "serial_autoincrement" option in /usr/share/doc/bind-dyndb-ldap/README for more details.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-21 08:58:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Petr Spacek 2012-07-16 08:25:23 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/bind-dyndb-ldap/ticket/67

Watch updates comming from persistent search query and update SOA serial number for each update.

Necessary for zone transfer RFE: https://bugzilla.redhat.com/show_bug.cgi?id=766233

Proposed details & discussion:
https://www.redhat.com/archives/freeipa-devel/2012-May/msg00047.html

Comment 1 Petr Spacek 2012-07-16 08:27:19 UTC
Implemented solution is "dumb" variant as described in https://www.redhat.com/archives/freeipa-devel/2012-May/msg00047.html.

Comment 5 Petr Spacek 2012-10-04 14:18:20 UTC
Note for testers:
It is necessary to test behaviour after change in ordinary DNS record and change in DNS zone record separately, but any change in DNS-representable data should be enough. You can add/delete/change arbitrary record (TXT is perfectly fine).

SOA serial will not increment after change in zone record if changed attribute do not represent DNS data, e.g. change in idnsAllowDynUpdate attribute will not trigger SOA serial update.
It is perfectly fine, because this attribute is not transferred to slave servers.

In other words: You can initiate zone transfer with dig -t AXFR @master_IP zone.name.test and see what is transferred. SOA serial should be incremented if you change any value which is part of zone transfer (except serial itself).

Comment 6 Namita Soman 2012-11-16 19:17:42 UTC
Verified using:
ipa-server-3.0.0-8.el6.x86_64


::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: bz840383 - Implement SOA serial number increments for external changes
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [13:40:06] ::  Executing: ipa dnszone-add --name-server=ipaqavmh.testrelm.com. --admin-email=ipaqar.redhat.com --serial=11 --refresh=303 --retry=101 --expire=8 --minimum=33 --ttl=55 zone840383.testrelm.com
  Zone name: zone840383.testrelm.com
  Authoritative nameserver: ipaqavmh.testrelm.com.
  Administrator e-mail address: ipaqar.redhat.com.
  SOA serial: 11
  SOA refresh: 303
  SOA retry: 101
  SOA expire: 8
  SOA minimum: 33
  SOA time to live: 55
  BIND update policy: grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM krb5-self * AAAA; grant TESTRELM.COM krb5-self * SSHFP;
  Active zone: TRUE
  Dynamic update: FALSE
  Allow query: any;
  Allow transfer: none;
:: [   PASS   ] :: Add a new zone to test with
:: [13:40:07] ::  Executing: ipa dnsrecord-add zone840383.testrelm.com txt --txt-rec "bug test"
  Record name: txt
  TXT record: bug test
:: [   PASS   ] :: add record type txt
:: [13:40:09] ::  Executing: ipa dnszone-mod zone840383.testrelm.com --allow-transfer='any;'
  Zone name: zone840383.testrelm.com
  Authoritative nameserver: ipaqavmh.testrelm.com.
  Administrator e-mail address: ipaqar.redhat.com.
  SOA serial: 1353091209
  SOA refresh: 303
  SOA retry: 101
  SOA expire: 8
  SOA minimum: 33
  Active zone: TRUE
  Allow query: any;
  Allow transfer: any;
:: [   PASS   ] :: Allow zone transfers
:: [13:40:11] ::  Executing: dig @10.16.98.193 -t AXFR zone840383.testrelm.com | grep "TXT" 
txt.zone840383.testrelm.com. 86400 IN	TXT	"bug" "test"
:: [   PASS   ] :: Verify the TXT record is part of zone transfer
:: [13:40:12] ::  Executing: ipa dnsrecord-mod zone840383.testrelm.com txt --txt-rec="bug test" --txt-data="Bug Test for 840383"
  Record name: txt
  TXT record: Bug Test for 840383
:: [   PASS   ] :: update record type txt
:: [   PASS   ] :: new serial after updating record is higher. Was: 1353091209; New: 1353091213
:: [13:40:14] ::  Executing: ipa dnszone-mod --dynamic-update=true zone840383.testrelm.com
  Zone name: zone840383.testrelm.com
  Authoritative nameserver: ipaqavmh.testrelm.com.
  Administrator e-mail address: ipaqar.redhat.com.
  SOA serial: 1353091213
  SOA refresh: 303
  SOA retry: 101
  SOA expire: 8
  SOA minimum: 33
  Active zone: TRUE
  Dynamic update: TRUE
  Allow query: any;
  Allow transfer: any;
:: [   PASS   ] :: Update idnsAllowDynUpdate attribute
:: [   PASS   ] :: serial was not updated when idnsAllowDynUpdate attr was updated 
'f1001af6-b4c1-4e3e-a6fe-7db3dc68e44f'
bz840383-Implement-SOA-serial-number-increments-for-external-changes result: PASS
   metric: 0
   Log: /tmp/beakerlib-9193278/journal.txt
    Info: Searching AVC errors produced since 1353091205.84 (Fri Nov 16 13:40:05 2012)
     Searching logs...
     Info: No AVC messages found.
 Writing to /mnt/testarea/tmp.zW6ING
:
   AvcLog: /mnt/testarea/tmp.zW6ING

Comment 8 errata-xmlrpc 2013-02-21 08:58:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0359.html