On 02/14/2013 12:47 PM, Reindl Harald wrote:
Am 14.02.2013 18:37, schrieb Robert Moskowitz:
On 02/14/2013 12:29 PM, Paul Heinlein wrote:
On Thu, 14 Feb 2013, Robert Moskowitz wrote:
Over on the bind-users@lists.isc.org list, I am in a discussion about building the named.zone file, as Centos 6.3 does not provide it. It DOES provide a named.ca which is already old (wrt AAAA records) compared to the named.zone provided by internic.
A few contributors have stated that now the hints are built into bind and you can see this with:
strings /usr/local/sbin/named | grep A.ROOT-SERVERS.NET
Well it looks like Centos has it at /usr/sbin/named and there are no such strings in there. Oh, these hints come from "lib/dns/rootns.c in the source code tree".
So are the hints built in here?
See /var/named/named.ca (also visible in /var/named/chroot/var/named).
Yes. I know about that. But as I said, the discussion is that this is no longer needed as the hints are now built into bind if no explicit hint is provided. I am asking if the above stub is included in the Redhat/Centos build. It does not seem so.
and even if - how would this be updated without the need for a security fix since otherwise there are no updates in RHEL
I asked this on the bind-users list, as AAAA records are slowly being added to each root, and got back:
"No need to worry. They are only hints, and named uses them to get the current list of root name servers at startup. Even if they are 15 years out of date it will still work, because the root name servers do not change very often."
So take that with whatever size of salt grain you prefer.
ftp://ftp.internic.net/domain/named.cache and update /var/named/chroot/var/named/named.ca with it is the way to go
What I am doing. But so far something is not set right, as I am not getting responses back, but I think I know why and it is a grrr moment.
On Feb 14, 2013, at 11:02 AM, Robert Moskowitz rgm@htt-consult.com wrote:
"No need to worry. They are only hints, and named uses them to get the current list of root name servers at startup. Even if they are 15 years out of date it will still work, because the root name servers do not change very often."
That's because all it takes is one, and the memory cache is then updated with the current list. If even one of the hinted servers is correct, the show goes on.
On 02/19/2013 08:17 AM, Nathan Duehr wrote:
On Feb 14, 2013, at 11:02 AM, Robert Moskowitz rgm@htt-consult.com wrote:
"No need to worry. They are only hints, and named uses them to get the current list of root name servers at startup. Even if they are 15 years out of date it will still work, because the root name servers do not change very often."
That's because all it takes is one, and the memory cache is then updated with the current list. If even one of the hinted servers is correct, the show goes on.
Since I posted this, and a similar thread on the bind-users list, I have tested without a hint stub and it works just fine.
Redhat should pull it (named.ca) from the distribution. Even a caching server will discover the current root addresses from what is built in.
The named.cache / root hints just updated on jan 3 2013 after jun 8 2011. I'm not 100% sure but i think many centos/rhel boxes are still using that 2011 hint. So before rhel/centos releases/updates their bind/hint file/bin, or users who do not want to update hint/bind portion specifically via yum, for such type of users, to use the latest hint file, i think the existing hint file & its location would help to place the latest hint file.
-- Bright Star.
Received from Robert Moskowitz, on 2013-02-19 1:26 PM:
On 02/19/2013 08:17 AM, Nathan Duehr wrote:
On Feb 14, 2013, at 11:02 AM, Robert Moskowitz rgm@htt-consult.com wrote:
"No need to worry. They are only hints, and named uses them to get the current list of root name servers at startup. Even if they are 15 years out of date it will still work, because the root name servers do not change very often."
That's because all it takes is one, and the memory cache is then updated with the current list. If even one of the hinted servers is correct, the show goes on.
Since I posted this, and a similar thread on the bind-users list, I have tested without a hint stub and it works just fine.
Redhat should pull it (named.ca) from the distribution. Even a caching server will discover the current root addresses from what is built in.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 2/19/2013 4:22 PM, Bry8 Star wrote:
So before rhel/centos releases/updates their bind/hint file/bin, or users who do not want to update hint/bind portion specifically via yum, for such type of users, to use the latest hint file, i think the existing hint file & its location would help to place the latest hint file.
huh? I can't tell what you're suggesting.
sorry, let me re-phrase:
Some users do not want to update their bind with what rhel/centos repo provides. Some users update their bind/hint files when centos/rhel repo updates. so those who want to manually place/use the hint file for their BIND, they can do so bit easily if the old one is visible.
-- Bright Star.
Received from John R Pierce, on 2013-02-20 12:28 AM:
On 2/19/2013 4:22 PM, Bry8 Star wrote:
So before rhel/centos releases/updates their bind/hint file/bin, or users who do not want to update hint/bind portion specifically via yum, for such type of users, to use the latest hint file, i think the existing hint file & its location would help to place the latest hint file.
huh? I can't tell what you're suggesting.
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.
ofcourse it is now visible. which is good. so removing it would not be good. even if bind has built into it older or latest hint.
Received from John R Pierce, on 2013-02-20 1:20 AM:
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.
On 02/19/2013 08:59 PM, Bry8 Star wrote:
ofcourse it is now visible. which is good. so removing it would not be good. even if bind has built into it older or latest hint.
My point, what I have learned over the past few days, is that having a hint stub for the roots is an artifact of the old way in bind. Today's bind no longer needs it. The built in file will supply at LEAST on working root that would then provide the current list of root addresses. Both the IPv4 and IPv6 addresses. For this to break would require that EVERY root address to change.
So continuing and old practice is just not the best thing. Even I (I am an old dog at 62; I sat in front of my first teletype in 11th grade in 1965 tied into a GE Mark IV) can learn to leave chroot behind for selinux. Likewise I can figure out that bind can now find the roots by itself and I don't need to provide the current list of hints which of course is only hints. It then learns what is real out there.
So let's get with it. Eventhough Centos 6.3 comes with bind 4.8.2 which in bind releases is OLD (Redhat DOES back port security patches), it is new enough for most of our needs.
Received from John R Pierce, on 2013-02-20 1:20 AM:
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.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
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.
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@centos.org http://lists.centos.org/mailman/listinfo/centos
A LONG time ago an older (at the time, I think I've caught up) sysadmin told me to use "dig" to update the named.ca file. Periodically he would run dig with no arguments and compare the output to the existing /var/named/named.ca file and copy it over the old one if anything had changed.
Maybe it's a bad habit, but I still do it. I haven't had any adverse issues with it for about 15 years now. Your mileage may vary!
-
Bry8 Star -
Jay Leafey -
John R Pierce -
Markus Falb -
Nathan Duehr -
Robert Moskowitz