Hello List, When troubleshooting a particular reverse delegated zone to us we used the normal "d/26.c.b.a.in-addr.arpa" naming for the zone. A couple of zones did not get served correctly (tried on BIND 9.7.0-P2 and 9.7.3) and any query for a record within these zones always came back with a SERVFAIL. After coming thru all of the syntax in the config and zone everything checked out as valid. I enabled debug logging which didn't really yield any useful data. I tried running debug on the named-checkzone and everything came back clean. Web searches were not very helpful especially since I didn't really know what search keywords to use. Eventually I compared one working reverse delegated zone to one of the problem ones with a more granular eye and I noticed the RNAME in the SOA was different where the SERVFAIL one had "hostmaster" and the working one had "hostmaster.domain.com.". I thought well I might as try it out and replaced the "hostmaster" with "hostmaster.domain.com." and sure enough it was serving the domain just fine after that.
So I know you can get away with using just "hostmaster" in the RNAME field if your zone/domain actually makes sense but in this case it was not working and I can only think it has to do with the slash "/" character in the zone name. Is this behavior documented? Is it perhaps a bug? Certainly I personally will remember this as an issue going forward but will others run into this trouble as well? Am I way off base on thinking it should have been more easily identifiable what the problem is with using the debug logs and debug named-checkzone tool? I know the RNAME field should just be set to an appropriate value but does anyone generally even use the RNAME? The authoritative name servers are giving an NXDOMAIN or SERVFAIL or whatever it's not like you can even see the SOA anyways. Thanks for any insight!!
_______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
