Bug 921167
| Summary: | update-policy with match type 'zonesub' crashes BIND with bind-dyndb-ldap | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Najmuddin Chirammal <nc> |
| Component: | bind-dyndb-ldap | Assignee: | Petr Spacek <pspacek> |
| Status: | CLOSED ERRATA | QA Contact: | Namita Soman <nsoman> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.3 | CC: | dpal, pspacek, sradvan, yjog |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Cause:
The bind-dyndb-ldap plug-in processed update policies with match-type 'zonesub' incorrectly.
Consequence:
The problem led to the BIND daemon terminating unexpectedly during update-policy processing.
Fix:
The bind-dyndb-ldap plug-in has been fixed to process update-policy with match-type 'zonesub' correctly.
Result:
The bind-dyndb-ldap plug-in no longer crashes during update-policy processing.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-11-21 12:10:48 UTC | Type: | Bug |
| 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: | 835616, 883504, 960054 | ||
Upstream ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/111 Match type 'zonesub' is not handled properly. Workaround: Replace 'zonesub' with 'subdomain' match type. E.g. for zone 'example.com' use following update policy: grant keyname subdomain example.com; Result: Update requests signed by key 'keyname' are allowed to change all records in zone 'example.com'. Fixed in upstream by commit 55b623b947b8bef1eb31ad6cd4efe1b846c036c4. Using ipa-server-3.0.0-33.el6.x86_64, followed steps:
# cat /etc/named.conf
<snip>
...
key selfupdate {
algorithm hmac-md5;
secret "05Fu1ACKv1/1Ag==";
};
# ipa dnszone-mod testrelm.com --update-policy="grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM krb5-self * AAAA; grant TESTRELM.COM krb5-self * SSHFP; grant selfupdate zonesub A;"
Zone name: testrelm.com
Authoritative nameserver: mgmt6.testrelm.com.
Administrator e-mail address: hostmaster.testrelm.com.
SOA serial: 1377713531
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; grant selfupdate zonesub A;
Active zone: TRUE
Allow query: any;
Allow transfer: none;
# service named restart
Stopping named: .[ OK ]
Starting named: [ OK ]
# ipa dnszone-show testrelm.com --all
dn: idnsname=testrelm.com,cn=dns,dc=testrelm,dc=com
Zone name: testrelm.com
Authoritative nameserver: mgmt6.testrelm.com.
Administrator e-mail address: hostmaster.testrelm.com.
SOA serial: 1377715681
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; grant selfupdate zonesub A;
Active zone: TRUE
Dynamic update: TRUE
Allow query: any;
Allow transfer: none;
nsrecord: mgmt6.testrelm.com.
objectclass: top, idnsrecord, idnszone
named restarted successfuly
Verified further. After the above steps, did further verification: # cat dnsupdate.txt server ipaqa64vme.testrelm.com zone testrelm.com key selfupdate 05Fu1ACKv1/1Ag== update add foo.testrelm.com. 60 IN A <IPADDR> send # nsupdate -v -D dnsupdate.txt Verified "Outgoing" and "Reply" results (similar to dig output). Since the update wad successful, got NOERROR. 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 |
Public description: User wants to update DNS records from his DHCP server using TSIG keys, the key is added into named.conf file. Once the update-policy in LDAP is updated to use the key from named.conf named fails to start (crashes with an assertion failure). Version-Release number of selected component (if applicable): bind-dyndb-ldap-2.3-2.el6.x86_64 How reproducible: Always. Steps to Reproduce: 1.Add a key to named.conf. for eg: key selfupdate { algorithm hmac-md5; secret "05Fu1ACKv1/1Ag=="; }; 2. Add the key to IPA managed zone's update-policy. for eg: # ipa dnszone-mod example.com --update-policy="grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM krb5-self * AAAA; grant EXAMPLE.COM krb5-self * SSHFP; grant selfupdate zonesub A;" (Only the last grant statement is relevant here, rest are present by default). 3. restart 'named' service. Actual results: named crashes with assertion failure named[19050]: managed-keys-zone ./IN: loaded serial 0 named[19050]: running named[19050]: acl.c:234: INSIST(0) failed, back trace named[19050]: #0 0x7f201cb3beff in ?? named[19050]: #1 0x7f201b4ec89a in ?? named[19050]: #2 0x7f201619d6d8 in ?? named[19050]: #3 0x7f20161a7423 in ?? named[19050]: #4 0x7f20161aa8a5 in ?? named[19050]: #5 0x7f201b50b2f8 in ?? named[19050]: #6 0x7f201aec0851 in ?? named[19050]: #7 0x7f201a42290d in ?? named[19050]: exiting (due to assertion failure) Expected results: named start without any errors and we should be able to use the key from a client to update the zone entries. Additional info: stack trace from the core file. Thread 1 (Thread 0x7f7700519700 (LWP 9768)): #0 0x00007f7701abb8a5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007f7701abd085 in abort () at abort.c:92 #2 0x00007f7704283e14 in assertion_failed (file=<value optimized out>, line=<value optimized out>, type=<value optimized out>, cond=<value optimized out>) at ./main.c:219 #3 0x00007f7702c3a89a in isc_assertion_failed (file=<value optimized out>, line=<value optimized out>, type=<value optimized out>, cond=<value optimized out>) at assertions.c:57 #4 0x00007f76fd8f8aa8 in get_match_type (policy_str=<value optimized out>, zone=0x7f76f832beb0) at acl.c:234 #5 acl_configure_zone_ssutable (policy_str=<value optimized out>, zone=0x7f76f832beb0) at acl.c:417 #6 0x00007f76fd901331 in ldap_parse_zoneentry (entry=0x7f77042066a0, inst=0x7f7704226f10) at ldap_helper.c:1022 #7 0x00007f76fd901bcd in refresh_zones_from_ldap (ldap_inst=0x7f7704226f10) at ldap_helper.c:1161 #8 0x00007f76fd906214 in manager_create_db_instance (mctx=0x7f7705eb6250, name=<value optimized out>, argv=<value optimized out>, dyndb_args=<value optimized out>) at zone_manager.c:183 #9 0x00007f76fd8fac19 in dynamic_driver_init (mctx=0x7f7705eb6250, name=0x7f77042161f0 "ipa", argv=0x7f77041ff330, dyndb_args=0x7f7704202550) at ldap_driver.c:1329 #10 0x00007f7703ae2de6 in dns_dynamic_db_load (libname=<value optimized out>, name=0x7f77042161f0 "ipa", mctx=0x7f7705eb6250, argv=0x7f77041ff330, dyndb_args=0x7f7704202550) at ./dynamic_db.c:232 #11 0x00007f77042a24dc in configure_dynamic_db (view=0x7f76f8111550, config=<value optimized out>, vconfig=<value optimized out>, cachelist=0x7f77042161f0, bindkeys=0x7f77042161f8, mctx=0x7f7705eb6250, actx=0x7f7704202090, need_hints=isc_boolean_true) at server.c:1210 #12 configure_view (view=0x7f76f8111550, config=<value optimized out>, vconfig=<value optimized out>, cachelist=0x7f77042161f0, bindkeys=0x7f77042161f8, mctx=0x7f7705eb6250, actx=0x7f7704202090, need_hints=isc_boolean_true) at server.c:2784 #13 0x00007f77042a57b5 in load_configuration (filename=0x7f7700518850 "\370\005#\004w\177", server=0x7f770420d010, first_time=isc_boolean_true) at server.c:4912 #14 0x00007f77042a6bb5 in run_server (task=<value optimized out>, event=0x0) at server.c:5381 #15 0x00007f7702c592f8 in dispatch (uap=0x7f7704204010) at task.c:1012 #16 run (uap=0x7f7704204010) at task.c:1157 #17 0x00007f770260e851 in start_thread (arg=0x7f7700519700) at pthread_create.c:301 #18 0x00007f7701b7111d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115