most recent release of BIND can obtain latest root hints by itself, and i do not think it connects with (INTERNIC.NET or with) root servers after a successful authentication of DNSSEC records, so at initial point (during setup), there is a chance for an entity in the middle to supply a false one. but that is only a speculation, i don't know for sure what real mechanism are in place to thwart such exploitation(s). If even at initial/startup/setup point, BIND can use the pre-included root.KEY to DNSSEC authenticate root (.) servers (and INTERNIC.NET server) and then obtain root.hint/named.cache file, then previously mentioned exploitation(s) are avoidable. Most likely that is what it does when it obtain root hints. If obtained hint file does not pass with root.key then it is either corrupted or an altered/exploited version. (and altered/exploited root.hint at this level would only indicate toward very higher level compromise). So for newer BIND no need to include named.ca/named.cache/root.hint, (i guess). When server goes online, and queries are sent to it, then it will obtain/download a correct one(hint file), and as root.KEY is already pre-included for verification/authenticate, so that may be suffice. For resolving every query, or repeat query, BIND does not need to start from the root.hints again and again, that is the reason for existence of this root.hint file in BIND. But older release of BIND, cannot auto obtain latest root.hints/named.cache file, for such that (hints file) is necessary, so that admin can manually overwrite older one, and indicate BIND to use that. And, if root.hint/named.cache/named.ca file's access & owner permission levels are pre-set on it, then BIND can set proper/previous access permission on the latest hint file when it obtains the latest one. If one hint-file did not exist, and BIND downloaded new one, then if all permission ACL/levels/PAM-rules/etc are properly set on it by BIND, or not, i'm not sure on those factors. ... those came to mind now, what else reason exist for a root.hint/named.ca file to pre-exist in BIND ? -- Bright Star. Received from Robert Moskowitz, on 2013-02-20 4:04 AM: > > On 02/19/2013 09:07 PM, Markus Falb wrote: >> On 20.2.2013 02:20, John R Pierce wrote: >>> On 2/19/2013 4:35 PM, Bry8 Star wrote: >>>> they can do so bit easily if the old one is visible. >>> whats not visible about /var/named/named.ca ? its even >>> listed in /etc/named.conf as the root zone. >> hmm, here as I understand this: >> >> A point was made by Robert that named.ca is not necessary at >> all and should be removed. >> >> https://lists.isc.org/pipermail/bind-users/2013-February/089740.html >> >> https://bugzilla.redhat.com/show_bug.cgi?id=901741 >> >> Bry8 said even if named.ca is not necessary it could be still >> useful for some so do not remove it from the rpm. > > I would like to know the use case of its usefulness. > > > _______________________________________________ CentOS mailing > list CentOS@xxxxxxxxxx > http://lists.centos.org/mailman/listinfo/centos >
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
