SOA RNAME Value

[Justin Krejci]

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!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110413/1018f47f/attachment.html>