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.
Cause: Identity Management dnszone-add command accepts --name-server option specifying a hostname of primary name server resolving the zone. However, the option considered all hostnames as fully qualified domain names (FQDN) even though they were not FQDN (e.g. nameserver "ns.example.com." for zone example.com) and were relative to the zone name (e.g. nameserver "ns" for zone "example.com").
Consequence: When using Identity Management dnszone-add command, the Administrator was not able to specify nameserver in the relative name format.
Fix: Detect the nameserver format correctly with respect to DNS naming rules, i.e. name with trailing "." is FQDN, name without trailing "." is a relative name.
Result: dnszone-add command can process both relative and fully qualified domain names.
Description of problem:
Can add zone using cmd below:
# ipa dnszone-add --name-server=ipaqa64vmc.testrelm.com --admin-email=ipaqar.redhat.com --serial=2010010701 --refresh=303 --retry=101 --expire=1202 --minimum=33 --ttl=55 westford.testrelm.com
To this Petr's response:
CLI adds implicit dot to end of the name-server parameter.
That is a reason why it works in your case.
There are two rules:
--name-server=host.name.ends.with.dot.
--> name has to be resolvable to IP address
(i.e. name belongs to existing zone and is resolvable)
--> your test case falls to this category because of implicit dot
--> test will pass because "ipaqa64vmc.testrelm.com" is resolvable
--name-server=relative.hostname
--> --ip-address= has to be used because hostname is not resolvable to IP
address
--> relative.hostname will be expanded to relative.hostname.new.zone. - this
name can't be resolvable because that zone doesn't exist yet
So tried the below which adds the zone, but has invalid data:
# ipa dnszone-add --name-server=pspacek --ip-address=10.34.4.89 q.test
Administrator e-mail address [hostmaster.q.test.]:
ipa: ERROR: 'dnszoneidnsname' is required
[root@pspacek nsupdate-test]# ipa dnszone-show q.test
Zone name: q.test
Authoritative nameserver: pspacek. <<<<---- that is wrong - there should not be a dot at the end of name
Administrator e-mail address: hostmaster.q.test.
SOA serial: 1350916014
SOA refresh: 3600
SOA retry: 900
SOA expire: 1209600
SOA minimum: 3600
Active zone: TRUE
Allow query: any;
Allow transfer: none;
Version-Release number of selected component (if applicable):
ipa-server-3.0.0-105.20121016T0259zgitf6bd4b0.el6.x86_64
How reproducible:
always
Steps to Reproduce:
1. Add a new zone usign relative hostname, and ipaddress
2.
3.
Actual results:
throws an error, adds the zone, but dnszone-show has a period at the end of the nameserver
Expected results:
add zone sucessully, with no error and dnszone-show should not have a period at the end of the nameserver.
Additional info:
Fixed upstream:
master: https://fedorahosted.org/freeipa/changeset/a00109585684fac520c48188298b75df816fbd23
ipa-3-0: https://fedorahosted.org/freeipa/changeset/dc406253821ba7a616dd12e2bcc5dd602247a279
--name-server option now behaves correctly with respect to absolute/relative DNS names. You may need to update your test cases if you do not use it right!
Examples:
1) Add new zone using absolute address to nameserver:
# ipa dnszone-add new.zone --name-server ns.ipa.testrelm.
Effective nameserver will be ns.ipa.testrelm.
2) Add new zone using relative address to nameserver:
# ipa dnszone-add new.zone --name-server ns --ip-address 10.0.0.1
Effective nameserver will be ns.new.zone.
New A record with IP 10.0.0.1 will be created in new.zone
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/RHSA-2013-0528.html
Description of problem: Can add zone using cmd below: # ipa dnszone-add --name-server=ipaqa64vmc.testrelm.com --admin-email=ipaqar.redhat.com --serial=2010010701 --refresh=303 --retry=101 --expire=1202 --minimum=33 --ttl=55 westford.testrelm.com To this Petr's response: CLI adds implicit dot to end of the name-server parameter. That is a reason why it works in your case. There are two rules: --name-server=host.name.ends.with.dot. --> name has to be resolvable to IP address (i.e. name belongs to existing zone and is resolvable) --> your test case falls to this category because of implicit dot --> test will pass because "ipaqa64vmc.testrelm.com" is resolvable --name-server=relative.hostname --> --ip-address= has to be used because hostname is not resolvable to IP address --> relative.hostname will be expanded to relative.hostname.new.zone. - this name can't be resolvable because that zone doesn't exist yet So tried the below which adds the zone, but has invalid data: # ipa dnszone-add --name-server=pspacek --ip-address=10.34.4.89 q.test Administrator e-mail address [hostmaster.q.test.]: ipa: ERROR: 'dnszoneidnsname' is required [root@pspacek nsupdate-test]# ipa dnszone-show q.test Zone name: q.test Authoritative nameserver: pspacek. <<<<---- that is wrong - there should not be a dot at the end of name Administrator e-mail address: hostmaster.q.test. SOA serial: 1350916014 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Allow query: any; Allow transfer: none; Version-Release number of selected component (if applicable): ipa-server-3.0.0-105.20121016T0259zgitf6bd4b0.el6.x86_64 How reproducible: always Steps to Reproduce: 1. Add a new zone usign relative hostname, and ipaddress 2. 3. Actual results: throws an error, adds the zone, but dnszone-show has a period at the end of the nameserver Expected results: add zone sucessully, with no error and dnszone-show should not have a period at the end of the nameserver. Additional info: