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 750210

Summary: dnszone-find displays administrator's e-mail address without "@" when added using --zonemgr option.
Product: Red Hat Enterprise Linux 6 Reporter: Gowrishankar Rajaiyan <grajaiya>
Component: ipaAssignee: Rob Crittenden <rcritten>
Status: CLOSED NOTABUG QA Contact: IDM QE LIST <seceng-idm-qe-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.2CC: jgalipea, mkosek, shaines
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-02 12:27:38 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:

Description Gowrishankar Rajaiyan 2011-10-31 11:14:37 UTC
Description of problem:


Version-Release number of selected component (if applicable):
ipa-server-2.1.3-6.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. ipa-dns-install  --ip-address=10.65.201.66 --zonemgr=gsr
2. ipa dnszone-find

  
Actual results:
  Zone name: testrelm
  Authoritative nameserver: mudflap.testrelm.
  Administrator e-mail address: gsr.redhat.com.  <<<<<
  SOA serial: 2011311001
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE


Expected results:
  Zone name: testrelm
  Authoritative nameserver: mudflap.testrelm.
  Administrator e-mail address: gsr    <<<<<
  SOA serial: 2011311001
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE


Additional info:

Comment 1 Martin Kosek 2011-10-31 11:28:58 UTC
This is intentional and standard way of storing zone administrator mail address.

As RFC 1035 defines, zone administrator mail is stored in a form of domain name, i.e. no @ is present. I think you were confused by the fact that we automatically do a conversion of standard mail address (with @) to proper zone mail address format.

Comment 3 Gowrishankar Rajaiyan 2011-11-02 04:52:36 UTC
(In reply to comment #1)
> This is intentional and standard way of storing zone administrator mail
> address.
> 
> As RFC 1035 defines, zone administrator mail is stored in a form of domain
> name, i.e. no @ is present. I think you were confused by the fact that we
> automatically do a conversion of standard mail address (with @) to proper zone
> mail address format.

Ok, I went through RFC 1035, which states 
<snip>
The DNS encodes the <local-part> as a single label, and encodes the
<mail-domain> as a domain name.  The single label from the <local-part>
is prefaced to the domain name from <mail-domain> to form the domain
name corresponding to the mailbox.  Thus the mailbox HOSTMASTER@SRI-
NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA.
</snip>

Hence the out that we display is as expected. The RFC also continues to state:

<snip>
 If the <local-part> contains dots or other special characters, its
representation in a master file will require the use of backslash
quoting to ensure that the domain name is properly encoded.  For
example, the mailbox Action.domains would be represented as
Action\.domains.ISI.EDU.
</snip>

So, to test this out I created a zone as:


[root@jetfire ~]# ipa dnszone-add
Authoritative nameserver: jetfire.testrelm.
Zone name: lab.eng.pnq.redhat.com
Administrator e-mail address [root.lab.eng.pnq.redhat.com.]: gs.r <<<
  Zone name: lab.eng.pnq.redhat.com
  Authoritative nameserver: jetfire.testrelm.
  Administrator e-mail address: gs.r.redhat.com.
  SOA serial: 2011021101
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Dynamic update: FALSE
[root@jetfire ~]# 


# ldapsearch -x -h jetfire.lab.eng.pnq.redhat.com   -D "cn=Directory Manager" -w Secret123 -b idnsname=lab.eng.pnq.redhat.com,cn=dns,dc=testrelm

# lab.eng.pnq.redhat.com, dns, testrelm
dn: idnsname=lab.eng.pnq.redhat.com,cn=dns,dc=testrelm
idnsZoneActive: TRUE
idnsSOAexpire: 1209600
nSRecord: jetfire.testrelm.
idnsSOAserial: 2011021101
idnsSOAretry: 900
idnsSOAminimum: 3600
idnsSOArefresh: 3600
objectClass: top
objectClass: idnsrecord
objectClass: idnszone
idnsName: lab.eng.pnq.redhat.com
idnsSOAmName: jetfire.testrelm.
idnsSOArName: gs.r.redhat.com.   <<<
idnsAllowDynUpdate: FALSE


I expected a backslash quoting as "gs\.r.redhat.com", however do not see that, is this as expected too?

Comment 4 Martin Kosek 2011-11-02 12:27:38 UTC
You are right, we can do email normalization better. I created a bug for this: Bug 750806.

I am closing this bug as NotABug (as you confirmed, the display is OK).