Re: Bind - built in root hints?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux