Bug 908780

Summary: Zone without idnsUpdatePolicy causes error message during each zone_refresh
Product: Red Hat Enterprise Linux 6 Reporter: Petr Spacek <pspacek>
Component: bind-dyndb-ldapAssignee: Petr Spacek <pspacek>
Status: CLOSED ERRATA QA Contact: Namita Soman <nsoman>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 6.3CC: chhudson, dpal, pspacek
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: The bind-dyndb-ldap plug-in didn't handle DNS zones without 'idnsUpdatePolicy' attribute properly. Consequence: Harmless, but misleading error message "zone serial (<zone serial>) unchanged. zone may fail to transfer to slaves." was logged after each zone reload or potentially after each change in the affected DNS zone. Fix: The bind-dyndb-ldap plug-in was fixed to not print any error message if 'idnsUpdatePolicy' attribute is not defined in the DNS zone. Result: DNS zones without 'idnsUpdatePolicy' attribute are processed correctly and no error message is logged.
 Story Points: ---
Clone Of:
: 920663 (view as bug list) Environment:
Last Closed: 2013-11-21 12:10:27 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:
Bug Depends On:    
Bug Blocks: 883504, 920663, 960054    

Description Petr Spacek 2013-02-07 14:00:41 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/bind-dyndb-ldap/ticket/79

Zone without `idnsUpdatePolicy` attribute causes following error message each `zone_refresh` seconds:

{{{
07-Jun-2012 17:15:56.140 zone zone.example/IN: zone serial (2012060301) unchanged. zone may fail to transfer to slaves.
}}}

LDIF with example zone is attached.



**Workaround**

Define `idnsUpdatePolicy` attribute (e.g. `grant E.EXAMPLE krb5-self * A;`) and set `idnsAllowDynUpdate` to `FALSE`. Dynamic updates will remain disabled and error message will not be logged.
Comment 2 Petr Spacek 2013-02-07 14:48:58 UTC 
Clearer workaround:

For each zone (e.g. "example.com") which spams the log execute:

    $ ipa dnszone-mode example.com --dynamic-update=FALSE
    $ ipa dnszone-mode example.com --update-policy='/**/'


This bug was fixed in upstrem release 2.4.
Comment 17 Namita Soman 2013-10-17 13:39:44 UTC 
Verified using bind-dyndb-ldap-2.3-5.el6.i686, ipa-server-3.0.0-37.el6.i686

1> Added a new zone:
# ipa dnszone-add
Authoritative nameserver: ipaqa64vmj.testrelm.com.
Zone name: example
Administrator e-mail address [hostmaster.example.]:
  Zone name: example
  Authoritative nameserver: <$serverhostname>.
  Administrator e-mail address: hostmaster.example.
  SOA serial: 1381865595
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  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;

2> Made sure this zone does not have the `idnsUpdatePolicy` attribute
# ipa dnszone-mod example --update-policy=""
  Zone name: example
  Authoritative nameserver: <$serverhostname>.
  Administrator e-mail address: hostmaster.example.
  SOA serial: 1381865667
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;

3> Updated /etc/named.conf to have:
arg "zone_refresh 5";
arg "psearch no";
arg "serial_autoincrement no";

Then:
# service named restart

# tail -f /var/log/messages
Nothing logged

4> Also tried with /etc/named as:      
arg "zone_refresh 5";
arg "psearch yes";
arg "serial_autoincrement yes";

Then:
# service named restart

# ipa dnszone-mod --admin-email=nk example
where example is the zone without idnsUpdatePolicy

# tail -f /var/log/messages
No error logged
Comment 18 errata-xmlrpc 2013-11-21 12:10:27 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-1636.html