Bug 42399 - Need ability to create subnetted reverse lookup zone
Need ability to create subnetted reverse lookup zone
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: system-config-bind (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Stransky
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-26 21:13 EDT by Mark J. Marshall
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-12 10:29:06 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 Mark J. Marshall 2001-05-26 21:13:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)

Description of problem:
This utility does not allow for the creation of a reverse lookup zone for 
a subnetted IP class.  For example, we can't create a zone for 
12.32.197.144/29 - the zone should be called 144/29.197.32.12.in-
addr.arpa .   The bindconf utility does not allow for the creation of 
these zones.  It doesn't seem like a bug though, it looks like it just 
doesn't have the intelligence to understand them.  Hence, I'm making this 
an RFE.

How reproducible:
Always

Steps to Reproduce:
1. Open bindconf utility
2. try to create the zone 12.32.197.144/29
3.
	

Actual Results:  You can't type in a "/" character.  If you try to trick 
it, it just breaks.

Expected Results:  As this is an IP standard, and there is an RFC for it, 
this feature should be supported.

Additional info:

Also (possibly unrelated) I am not able to create these zones by hand 
either on Red Hat 7.1.  I had it working on Red Hat 6.2, but I can't move 
those configuration files over to Red Hat 7.1 and make it work.  I'll 
submit a separate bugzilla bug for that, but you should be aware of it 
when trying to fix this.  If necessary, I can email you all the files that 
work on 6.2 but don't work on 7.1.
Comment 1 Daniel Roesen 2001-05-31 11:03:59 EDT
RFC2317 also discusses that using "/" in the zone name is not a good idea
because of some broken resolver implementations out there.
Comment 2 Mark J. Marshall 2001-05-31 13:01:51 EDT
You're right - it recommends you "substitute a more conservative character, 
such as hyphen", but that doesn't work in bindconf either.  Also, the ability 
to do a subnetted in-addr.arpa zone still needs to be the utility, and 
shouldn't hinge on someone else's obsolete, stubborn or otherwise broken 
resolver.  A simple "warning message" from bindconf will probably do.

By the way, my "Additional Comments" may not be true after all.  After creating 
the zones by hand and working with AT&T to get it working, I think that issue 
may be showing up as a result of the something between us and AT&T and not with 
Red Hat 7.1.  When (if) we get that working, I'll definitely post a follow up.
Comment 3 Mark J. Marshall 2002-08-05 13:56:37 EDT
Thought this got lost!  The reason I couldn't do it by hand had to do with the 
slave needing to be able to see the master even though the slave is the one 
with the data.  In other words...  When my server is set up with my subnetted 
reverse zone, and AT&T's DNS server has the full reverse zone, any request sent 
to my server needs to first get forwarded to AT&T who then looks up the answer 
on my server.  I was trying to test it offline, which doesn't work.  So please 
disregard my "Additional Info" in the call, although the original call still 
stands.  Thanks,
Mark
Comment 4 John Thacker 2006-10-30 09:45:47 EST
[This is a mass update sent to many bugs that missed earlier such messages due
to having their version set to a test version.]

This bug was originally filed against a version of Fedora Core which is no
longer supported, even for security updates.  Many changes have occured since
then.  Please retest this bug against a still supported version.  Note that FC3
and FC4 are supported by Fedora Legacy for security fixes only.  If
it still occurs on FC5 or FC6, please assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

This bug will be closed after a few weeks if no information is given indicating
that the bug is still present in a supported release.
Comment 5 John Thacker 2007-01-12 10:29:06 EST
Closing per lack of response to previous request for information.
This bug was originally filed against a much earlier version of Fedora
Core, and significant changes have taken place since the last version
for which this bug is confirmed.

Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

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