Bug 829388 - Zone transfers fail for certain non-FQDNs
Zone transfers fail for certain non-FQDNs
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: bind-dyndb-ldap (Show other bugs)
6.3
Unspecified Unspecified
high Severity unspecified
: rc
: ---
Assigned To: Adam Tkac
Namita Soman
:
: 885138 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-06 11:12 EDT by Dmitri Pal
Modified: 2015-05-20 11:48 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The bug in bind-dyndb-ldap caused that some relative domain names weren't expanded correctly to FQDNs. Consequence: Zone transfer could contain relative domain names although it should contain only FQDNs (for example contained "name." record instead of "name.example.com.") Fix: The plugin was patched Result: Zone transfers now contain correct domain names.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 03:58:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dmitri Pal 2012-06-06 11:12:42 EDT
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/bind-dyndb-ldap/ticket/47

Consider following record in LDAP:

idnsName=cname,idnsName=example.com,dc=example,dc=com cNAMERecord: name

During zone transfer master server sends following record:

cname.example.com. 86400 IN CNAME name.

instead of
cname.example.com. 86400 IN CNAME name
or
cname.example.com. 86400 IN CNAME name.example.com.
Comment 1 RHEL Product and Program Management 2012-07-10 04:51:04 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 2 RHEL Product and Program Management 2012-07-10 19:06:41 EDT
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 3 Jenny Galipeau 2012-07-13 10:30:05 EDT
please add steps to reproduce and verify with ipa
Comment 4 Petr Spacek 2012-07-16 03:17:50 EDT
Necessary information is part of bug desciption: https://bugzilla.redhat.com/show_bug.cgi?id=829388#c0

What exactly you want to add?
Comment 6 Michael Gregg 2012-09-04 22:02:52 EDT
How do you reproduce this? 

Would a LDAP entry specifically need to be added? Can one of these entries be added via ipa tools?

Are multiple servers going to be needed to test this?

The test would be done by running a dig against a second server to a dns name?
Comment 7 Petr Spacek 2012-09-05 03:07:14 EDT
(In reply to comment #6)
> How do you reproduce this? 
> 
> Would a LDAP entry specifically need to be added? Can one of these entries
> be added via ipa tools?
> 

Bug description contains LDIF snippet with record which triggers the failure.
(dn) idnsName=cname,idnsName=example.com,dc=example,dc=com
(attribute) cNAMERecord: name

You can add similar record with IPA command (zone is "lab.example"):
$ ipa dnsrecord-add lab.example cname-rec --cname-rec=cname-target

> Are multiple servers going to be needed to test this?
No.

> The test would be done by running a dig against a second server to a dns
> name?
You can dig from the same server as IPA master is.
$ dig -t AXFR @127.0.0.1 lab.example

In my case it prints (correct output):
lab.example.		86400	IN	SOA	vm-148.lab.example. hostmaster.lab.example. 1346827541 1 1 1209600 1
lab.example.		86400	IN	NS	vm-148.lab.example.
vm-148.lab.example.	86400	IN	A	192.168.10.148
cname-rec.lab.example.	86400	IN	CNAME	cname-target.lab.example.
lab.example.		86400	IN	SOA	vm-148.lab.example. hostmaster.lab.example. 1346827541 1 1 1209600 1

Don't forget to allow zone transfers from test zone. For test purposes you can use:
$ ipa dnszone-mod lab.example --allow-transfer="any;"
Comment 8 Petr Spacek 2012-09-05 04:44:07 EDT
Some details are in FreeIPA Fedora test day page: https://fedoraproject.org/wiki/QA:Testcase_freeipav3_dns_zone_transfer
Comment 11 Namita Soman 2012-11-16 14:56:55 EST
Verified using:
ipa-server-3.0.0-8.el6.x86_64


::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: Bug 829388 - Zone transfers fail for certain non-FQDNs
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

spawn /usr/bin/kinit -V admin
Using default cache: /tmp/krb5cc_0
Using principal: admin@TESTRELM.COM
Password for admin@TESTRELM.COM: 
Authenticated to Kerberos v5
Default principal: admin@TESTRELM.COM
:: [13:40:27] ::  kinit as admin with password Secret123 was successful.
:: [   PASS   ] :: Kinit as admin user
  Zone name: testrelm.com
  Authoritative nameserver: ipaqavmh.testrelm.com.
  Administrator e-mail address: hostmaster.testrelm.com.
  SOA serial: 1353091222
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: any;
:: [   PASS   ] :: Enable DNS zone transfers
  Record name: bz829388
  CNAME record: bz829388
:: [   PASS   ] :: Add a dns record to test zone transfers with
bz829388.testrelm.com.	86400	IN	CNAME	bz829388.testrelm.com.
:: [   PASS   ] :: Ensure that bz829388.testrelm.com is in the list of AXFR records as a FQDN BZ 829388
-------------------------
Deleted record "bz829388"
-------------------------
:: [   PASS   ] :: Cleanup added DNS record.
'830c765e-f572-46ba-b30d-66f64f67f990'
Bug-829388-Zone-transfers-fail-for-certain-non-FQDNs result: PASS
   metric: 0
   Log: /tmp/beakerlib-9193278/journal.txt
    Info: Searching AVC errors produced since 1353091225.32 (Fri Nov 16 13:40:25 2012)
     Searching logs...
     Info: No AVC messages found.
 Writing to /mnt/testarea/tmp.zW6ING
:
   AvcLog: /mnt/testarea/tmp.zW6ING
Comment 12 Petr Spacek 2012-12-07 10:29:45 EST
*** Bug 885138 has been marked as a duplicate of this bug. ***
Comment 14 errata-xmlrpc 2013-02-21 03:58:05 EST
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

Note You need to log in before you can comment on or make changes to this bug.