Bug 766233
| Summary: | RFE: Support zone transfers in bind-dyndb-ldap | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Brian J. Atkisson <batkisso> |
| Component: | bind-dyndb-ldap | Assignee: | Adam Tkac <atkac> |
| Status: | CLOSED ERRATA | QA Contact: | IDM QE LIST <seceng-idm-qe-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | atkac, batkisso, dpal, grajaiya, jgalipea, jmontleo, lucas.yamanishi, mkosek, ovasik, pspacek, ricky.schneberger, samuel-rhbugs |
| Target Milestone: | beta | Keywords: | FutureFeature, Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-20 13:51:42 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: | 804619 | ||
| Bug Blocks: | 701677, 767486, 827414 | ||
Seems like a dup to me... *** This bug has been marked as a duplicate of bug 733371 *** > Seems like a dup to me... > > *** This bug has been marked as a duplicate of bug 733371 *** I don't think this is a duplicate of bz 733371. This particular issue applies to the global setting in /etc/named.conf for zone xfers. 733371 deals with zone-level transfer settings. I think Dmitri is right. The ability to do zone transfer very much depends on bind-dyndb-ldap ability to allow and execute the zone transfer them. Adam, can you please confirm that this bug actually depends on Bug 733371 and that allowing the zone transfers in the LDAP (idnsZoneTransfer attribute) fix this? (In reply to comment #4) > I think Dmitri is right. The ability to do zone transfer very much depends on > bind-dyndb-ldap ability to allow and execute the zone transfer them. > > Adam, can you please confirm that this bug actually depends on Bug 733371 and > that allowing the zone transfers in the LDAP (idnsZoneTransfer attribute) fix > this? Bug #733371 is not related to this. Bug #733371 is about zone transfer ACLs and this bug is about zone transfer itself. Although the plugin allows to set zone transfer ACLs, it doesn't have support for zone transfer itself. Zone transfer requires correct SOA serial number. There is a SOA serial number specific bug: https://bugzilla.redhat.com/show_bug.cgi?id=805871 Is it acceptable to have SOA serial numbers only locally significant? (I.e. each DNS master (= IPA server with DNS) will have different SOA serial number for given zone.) In multi-master replicated environment is really hard to maintain single SOA serial number on each server in zone. The related discussion is on freeipa-devel list: https://www.redhat.com/archives/freeipa-devel/2012-May/msg00047.html Thanks for you time. Verified: ipa-server-2.2.0-15.el6.x86_64 Hrm I replied on 5/9 and don't see the answer posted to bugzilla. In any case:
> Is it acceptable to have SOA serial numbers only locally significant? (I.e. each DNS master (= IPA server with DNS) will have different SOA serial number for given zone.)
This would cause problems for non-IPA slaves performing zone transfer.
All the serial numbers should be in sync across the IPA masters.
For example, in a corporate environment, where they maybe one department
using plain bind to host lab zones from corporate IT running IPA
Different labs will have different zone versions based upon those labs
pointing to regional IPA servers.
Also, it would be problematic in environments where a plain old Bind server does zone transfers from IPA servers in a fail-over/load-balanced config.
(In reply to comment #18) > Hrm I replied on 5/9 and don't see the answer posted to bugzilla. In any > case: > > > > Is it acceptable to have SOA serial numbers only locally significant? (I.e. each DNS master (= IPA server with DNS) will have different SOA serial number for given zone.) > > This would cause problems for non-IPA slaves performing zone transfer. > All the serial numbers should be in sync across the IPA masters. Of course, generally you are right. But IPA violates classical single-master DNS model and we search for some trade-offs. (For example RFC 5936 http://tools.ietf.org/html/rfc5936#section-3.1 says "don't do it".) Question should be: "Is there real configuration where it matters?" > For example, in a corporate environment, where they maybe one department > using plain bind to host lab zones from corporate IT running IPA > Different labs will have different zone versions based upon those labs > pointing to regional IPA servers. I'm probably missing something, I don't see the problem. Different IPA servers will serve same data (when LDAP replication settles down), only SOA serial number will be different. Each plain BIND will see and serve exactly same zone except serial number. > Also, it would be problematic in environments where a plain old Bind server > does zone transfers from IPA servers in a fail-over/load-balanced config. Yes, I agree. It's known problem of "local SOA serial" approach. Is described configuration deployed anywhere? Probably this problem can be partially alleviated with "tree" of DNS slaves or something similar. Hello, latest discussion can be found at https://www.redhat.com/archives/freeipa-devel/2012-May/msg00271.html and https://www.redhat.com/archives/freeipa-devel/2012-May/msg00278.html . 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-2012-0837.html Required SOA serial auto-incrementation feature was implemented in upstream: Implemented in commits: * https://fedorahosted.org/bind-dyndb-ldap/changeset/99663b6d65cf5dc166b3cb6f83be1878b8de3163 * https://fedorahosted.org/bind-dyndb-ldap/changeset/cd37fba03c5c86a766d1a9f893036ac3540e8b7c * https://fedorahosted.org/bind-dyndb-ldap/changeset/9a3f29c12db99597222ffa2bf0713d0b00cb4699 * https://fedorahosted.org/bind-dyndb-ldap/changeset/c379d81508fbfa00ecb5da727ff7b097ebb29a3d * https://fedorahosted.org/bind-dyndb-ldap/changeset/93ae7491a80ba8c4789f8770e14c053b67176de4 |
Description of problem: When using the integrated DNS management with IPA, turning on zone transfers in /etc/named.conf does not enable zone transfers. Version-Release number of selected component (if applicable): RHEL 6.2 bind-dyndb-ldap-0.2.0-7.el6.x86_64 bind-9.7.3-8.P3.el6.x86_64 ipa-server-2.1.3-9.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. Add 'allow-transfer { any; };' to the options section of /etc/named.conf 2. restart bind 3. 'dig @ipa-server zone_name AXFR' fails to transfer the zone. Actual results: dig @ipa-server ZONE AXFR ; <<>> DiG 9.8.1-P1-RedHat-9.8.1-4.P1.fc16 <<>> @192.168.1.2 ZONE AXFR ; (1 server found) ;; global options: +cmd ; Transfer failed. host -l ZONE ipa-server ; Transfer failed. Using domain server: Name: ipa-server Address: <IP>#53 Aliases: Host ZONE not found: 9(NOTAUTH) ; Transfer failed. Expected results: The zone to transfer Additional info: I also tried with 'also-notify' with the same result. There seemed to have been some discussion on this issue on https://www.redhat.com/archives/freeipa-users/2011-June/msg00150.html, but I could not find an open bug.