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.
RFC2317 also discusses that using "/" in the zone name is not a good idea because of some broken resolver implementations out there.
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.
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
[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.
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.