Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 908893

Summary: Cannot transfer vía AXFR an IPA hosted zone with more than 2000 records
Product: Red Hat Enterprise Linux 6 Reporter: Loris Santamaria <loris.santamaria>
Component: ipaAssignee: Rob Crittenden <rcritten>
Status: CLOSED CURRENTRELEASE QA Contact: Namita Soman <nsoman>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.3CC: jgalipea, mgregg, mkosek, pspacek, sgoveas
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-3.0.0-1.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-05 12:37:14 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:
Attachments:
Description Flags
details of single record created with 2000 txt entries in it
none
output of dig for search of the single entry containing 2000 txt records
none
output of dig for the 2000 individual dns records each containing one txt record.
none
Zone transfer file with more than 4000 records none

Description Loris Santamaria 2013-02-07 19:17:27 UTC
Description of problem:

To ease the load on an IPA based DNS server we set up a slave bind server to have the clients query the slave server. However zone transfers from the master server failed consistently.

On the master we get a ldap size limit exceeded every time the slave tries to transfer the zone. The zone has more than 2000 records.

We solved the problem setting to unlimited the per user resource limits for the kerberos principal used by named to connect to the IPA server.

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

bind-dyndb-ldap-1.1.0-0.9.b1.el6_3.1.x86_64
389-ds-base-1.2.10.2-20.el6_3.x86_64
ipa-server-2.2.0-17.el6_3.1.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Host in IPA a DNS zone with more than 2000 records
2. Set up a slave DNS server and try to transfer the above zone from the master
  
Actual results:

Zone transfer will fail

Expected results:

Zone transfer should succeed, regardless of the number of records in the zone

Comment 2 Petr Spacek 2013-02-08 15:00:07 UTC
This bug is fixed in upcoming IPA 3.0 release.

Workaround for older IPA versions is described in upstream ticket:
https://fedorahosted.org/freeipa/ticket/2531

Re-assigning to component "ipa" because there is nothing to do with bind-dyndb-ldap. It is only about limits set in directory server.

Comment 3 Petr Spacek 2013-02-08 16:07:57 UTC
Fix released to upstream in IPA 3.0.0 beta 1. First RHEL build should contain the fix.

Comment 5 Michael Gregg 2013-02-09 01:34:13 UTC
Created attachment 695296 [details]
details of single record created with 2000 txt entries in it

output of creating a single dns entry with 2000 txt records in it.

Comment 6 Michael Gregg 2013-02-09 01:35:03 UTC
Created attachment 695297 [details]
output of dig for search of the single entry containing 2000 txt records

Comment 7 Michael Gregg 2013-02-09 01:35:51 UTC
Created attachment 695298 [details]
output of dig for the 2000 individual dns records each containing one txt record.

Comment 8 Michael Gregg 2013-02-09 01:41:19 UTC
There was a bit of confusion in what kind of records were created.

To test this bug, I created two things on server 1:
1. I created a single dns entry containing 2000 txt records.
2. I added 2000 separate records to server one. Each record contained one txt entry.

I've attached the output from server 1 where I added the large 2000 txt record entry.

I then attached the output of digging for the very large entry and the 2000 individual txt record from server 2 after I can created a zone on server 2 that forwarded to server 1.

I am rather sure that one of these tests verifies this bug. I am going to mark it as verified.

Comment 9 Michael Gregg 2013-02-09 01:41:41 UTC
verified against ipa-server-3.0.0-25.el6.x86_64

Comment 10 Petr Spacek 2013-02-11 13:14:30 UTC
Sorry, but this verification is incorrect for two (independent) reasons:

- You used 2000 records, but bug description mentions problem with "more than" 2000 records. Some hop-by-one problem could be hidden somewhere. Please add some (e.g. 50) records to overreach 2000 records.

- This bug is about *zone transfer*, i.e. you need to use "dig -t AXFR" and check if all records were transferred successfully.

Comment 11 Steeve Goveas 2013-02-27 13:05:02 UTC
Created attachment 703426 [details]
Zone transfer file with more than 4000 records

DNS Master

[root@ibm-x3500m4-01 ~]# ipa dnszone-show testrelm.com
  Zone name: testrelm.com
  Authoritative nameserver: ibm-x3500m4-01.testrelm.com.
  Administrator e-mail address: hostmaster.testrelm.com.
  SOA serial: 1361969021
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: 10.34.35.54; <<<<<<<<<<<<<<<

[root@ibm-x3500m4-01 ~]# for i in `seq 2 2458`; do ipa dnsrecord-add testrelm.com --a-ip-address 10.16.64.99 rec$i ; done

[root@ibm-x3500m4-01 ~]# for i in `seq 1 2458`; do ipa dnsrecord-add testrelm.com bigtxt --txt-rec rec$i ; done

DNS Slave
[root@dell-pe1950-03 ~]# dig @ibm-x3500m4-01.testrelm.com bigtxt.testrelm.com txt | grep -c rec
2459

[root@dell-pe1950-03 ~]# dig +short @ibm-x3500m4-01.testrelm.com rec{1..2459}.testrelm.com | grep -c 10.16.64.99
2457

[root@dell-pe1950-03 ~]# ifconfig | grep "inet "
          inet addr:10.34.35.54  Bcast:10.34.35.255  Mask:255.255.252.0
          inet addr:127.0.0.1  Mask:255.0.0.0

[root@dell-pe1950-03 ~]# dig @ibm-x3500m4-01.testrelm.com testrelm.com AXFR > testrelm_trnsfr_file

[root@dell-pe1950-03 ~]# wc -l testrelm_trnsfr_file 
4943 testrelm_trnsfr_file

Comment 12 Petr Spacek 2013-02-27 15:17:49 UTC
Thank you!

Did you also checked content of the resulting file? Basically, two successive zone transfers should produce same results. Please pick some records randomly and check if they were transferred correctly.

Comment 13 Steeve Goveas 2013-02-27 16:06:11 UTC
Did another transfer and compared the files

On Slave

[root@dell-pe1950-03 ~]# dig @ibm-x3500m4-01.testrelm.com testrelm.com AXFR > testrelm_trnsfr_file_2

[root@dell-pe1950-03 ~]# diff testrelm_trnsfr_file testrelm_trnsfr_file_2 
4939c4939
< ;; Query time: 2074 msec
---
> ;; Query time: 1113 msec
4941c4941
< ;; WHEN: Wed Feb 27 18:07:18 2013
---
> ;; WHEN: Wed Feb 27 21:02:36 2013

Configured slave dns and started named
[root@dell-pe1950-03 ~]# service named restart

On Master

* Logs of restarting named on Slave

[root@ibm-x3500m4-01 ~]# tail -f /var/log/messages
Feb 27 21:20:06 ibm-x3500m4-01 named[8533]: client 10.34.35.54#40802: transfer of 'testrelm.com/IN': AXFR started
Feb 27 21:20:06 ibm-x3500m4-01 named[8533]: client 10.34.35.54#40802: transfer of 'testrelm.com/IN': AXFR ended
Feb 27 21:23:03 ibm-x3500m4-01 named[8533]: client 10.34.35.54#34625: transfer of 'testrelm.com/IN': AXFR started
Feb 27 21:23:03 ibm-x3500m4-01 named[8533]: client 10.34.35.54#34625: transfer of 'testrelm.com/IN': AXFR ended

* Random queries on Slave

[root@ibm-x3500m4-01 ~]# dig +short @dell-pe1950-03.testrelm.com intel-d3c4702-01.testrelm.com
10.16.64.99
[root@ibm-x3500m4-01 ~]# dig +short @dell-pe1950-03.testrelm.com rec2014.testrelm.com
10.16.64.99
[root@ibm-x3500m4-01 ~]# dig +short @dell-pe1950-03.testrelm.com rec214.testrelm.com
10.16.64.99
[root@ibm-x3500m4-01 ~]# dig +short @dell-pe1950-03.testrelm.com rec2414.testrelm.com
10.16.64.99
[root@ibm-x3500m4-01 ~]# dig @dell-pe1950-03.testrelm.com  bigtxt.testrelm.com txt | grep -c rec
2459