this seems to be relevant in chroot environments;
as I noticed when configuring the DDNS-feature, that this is a little bit weired, when running in a chroot environment; I saw the recommendation not to use a chroot in the man-page and removed bind-chroot and then the zone updates worked perfekt;
so this file /etc/named.root.key isn't really used; or am I missing something?
These files are included in both my /etc/named.conf and /usr/share/doc/bind-x.x.x/named.conf.default which I probably used as a template years ago. I'm no dns expert but you'd probably need these files when accessing root servers directly without use of forwarders.
I'm also using ddns and have my zone files in /var/named/chroot/var/named/dynamic. Selinux is enabled and I don't see any additional bind-related rules in my local policy or /etc/selinux/targeted/contexts/files/file_contexts.local.
On 10.05.2016 18:57, Александр Кириллов wrote:
this seems to be relevant in chroot environments;
as I noticed when configuring the DDNS-feature, that this is a little bit weired, when running in a chroot environment; I saw the recommendation not to use a chroot in the man-page and removed bind-chroot and then the zone updates worked perfekt;
so this file /etc/named.root.key isn't really used; or am I missing something?
These files are included in both my /etc/named.conf and /usr/share/doc/bind-x.x.x/named.conf.default which I probably used as a template years ago. I'm no dns expert but you'd probably need these files when accessing root servers directly without use of forwarders.
I'm also using ddns and have my zone files in /var/named/chroot/var/named/dynamic.
are you using DDNS in DualStack (IPv4 and IPv6 together) or do you have only DHCP or DHCPv6 and not both?
Selinux is enabled and I don't see any additional bind-related rules in my local policy or /etc/selinux/targeted/contexts/files/file_contexts.local.
the manpage shows this:
"NOTES Red Hat SELinux BIND Security Profile:
By default, Red Hat ships BIND with the most secure SELinux policy that will not prevent normal BIND operation and will prevent exploitation of all known BIND security vulnerabilities . See the selinux(8) man page for information about SElinux.
It is not necessary to run named in a chroot environment if the Red Hat SELinux policy for named is enabled. When enabled, this policy is far more secure than a chroot environment. Users are recommended to enable SELinux and remove the bind-chroot package.
With this extra security comes some restrictions:
By default, the SELinux policy does not allow named to write any master zone database files. Only the root user may create files in the $ROOTDIR/var/named zone database file directory (the options { "directory" } option), where $ROOTDIR is set in /etc/sysconfig/named.
The "named" group must be granted read privelege to these files in order for named to be enabled to read them.
Any file created in the zone database file directory is automatically assigned the SELinux file context named_zone_t .
By default, SELinux prevents any role from modifying named_zone_t files; this means that files in the zone database directory cannot be modified by dynamic DNS (DDNS) updates or zone transfers.
The Red Hat BIND distribution and SELinux policy creates three directories where named is allowed to create and modify files: /var/named/slaves, /var/named/dynamic /var/named/data. By placing files you want named to modify, such as slave or DDNS updateable zone files and database / statistics dump files in these directories, named will work normally and no further operator action is required. Files in these directories are automatically assigned the ’named_cache_t’ file context, which SELinux allows named to write."
Walter H. wrote:
On 10.05.2016 18:57, Александр Кириллов wrote:
this seems to be relevant in chroot environments;
as I noticed when configuring the DDNS-feature, that this is a little bit weired, when running in a chroot environment; I saw the recommendation not to use a chroot in the man-page and removed bind-chroot and then the zone updates worked perfekt;
so this file /etc/named.root.key isn't really used; or am I missing something?
These files are included in both my /etc/named.conf and /usr/share/doc/bind-x.x.x/named.conf.default which I probably used as a template years ago. I'm no dns expert but you'd probably need these files when accessing root servers directly without use of forwarders.
I'm also using ddns and have my zone files in /var/named/chroot/var/named/dynamic.
are you using DDNS in DualStack (IPv4 and IPv6 together) or do you have only DHCP or DHCPv6 and not both?
Selinux is enabled and I don't see any additional bind-related rules in my local policy or /etc/selinux/targeted/contexts/files/file_contexts.local.
the manpage shows this:
"NOTES Red Hat SELinux BIND Security Profile:
By default, Red Hat ships BIND with the most secure SELinuxpolicy that will not prevent normal BIND operation and will prevent exploitation of all known BIND security vulnerabilities . See the
<snip> Which assumes that setting selinux to enforcing doesn't break your websites, or the locally-created root directories that have been created before an actual sysadmin came onboard, or....
mark
On 05/10/2016 12:08 PM, m.roth@5-cent.us wrote:
Which assumes that setting selinux to enforcing doesn't break your websites, or the locally-created root directories that have been created before an actual sysadmin came onboard, or....
That's my biggest problem with SELinux. I suppose at some point I need to invest both time and money and take a class on it, but every time I try to use it - it gets in the way and when I try to resolve it, the documentation is very confusing and I think the documentation often makes assumptions about concepts being known that I don't know.
I know that it can be a significant benefit when you are attacked with an exploit that either is either zero-day or hasn't been patched, but so far when I have tried enabling SELinux it ends up taking up hours and hours and hours of my time.
And sometimes the problems are things like tmpfs - I don't remember exactly what it was, but I had an issue where when I finally got help, the answer was don't use tmpfs if you have SELinux enabled.
I want to use it, I do, but so far it has only caused me grief.
On 10.05.2016 21:08, m.roth@5-cent.us wrote:
Walter H. wrote:
On 10.05.2016 18:57, Александр Кириллов wrote:
I'm also using ddns and have my zone files in /var/named/chroot/var/named/dynamic.
are you using DDNS in DualStack (IPv4 and IPv6 together) or do you have only DHCP or DHCPv6 and not both?
my box has both DHCP and DHCPv6; but some hosts have already a fix IPv4 address, so only DHCPv6 is used; or some hosts are IPv4only but if the host has no IP address at all; then this works only sometimes; and with both IPv4 and IPv6 the same domain is used ddns.local
I'm also using ddns and have my zone files in /var/named/chroot/var/named/dynamic.
are you using DDNS in DualStack (IPv4 and IPv6 together) or do you have only DHCP or DHCPv6 and not both?
IPv4 only.
By default, SELinux prevents any role from modifyingnamed_zone_t files; this means that files in the zone database directory cannot be modified by dynamic DNS (DDNS) updates or zone transfers.
The Red Hat BIND distribution and SELinux policy creates three directories where named is allowed to create and modify files: /var/named/slaves, /var/named/dynamic /var/named/data. Byplacing files you want named to modify, such as slave or DDNS updateable zone files and database / statistics dump files in these directories, named will work normally and no further operator action is required. Files in these directories are automatically assigned the ’named_cache_t’ file context, which SELinux allows named to write."
That's probably why I have updateable zone files in chrooted /var/named/dynamic. Default targeted policy comes with necessary rules for chrooted bind. See
# semanage fcontext -l | grep named_
On 10.05.2016 21:36, Александр Кириллов wrote:
I'm also using ddns and have my zone files in /var/named/chroot/var/named/dynamic.
are you using DDNS in DualStack (IPv4 and IPv6 together) or do you have only DHCP or DHCPv6 and not both?
IPv4 only.
if a host has IPv4 only or IPv6 only this works fine, but when a host has both - DualStack somethimes it works sometimes only one - can be IPv4 or can be IPv6 works; and in /var/log/messages I get something like
May 10 18:51:30 dnssrvr named[2526]: client 192.168.1.2#38618: view wkst: updating zone 'ddns.local/IN': update unsuccessful: WIN7HOST.ddns.local: 'name not in use' prerequisite not satisfied (YXDOMAIN)
for several times;
By default, SELinux prevents any role from modifying named_zone_t files; this means that files in the zone database directorycannot be modified by dynamic DNS (DDNS) updates or zone transfers.
The Red Hat BIND distribution and SELinux policy creates three directories where named is allowed to create and modify files: /var/named/slaves, /var/named/dynamic /var/named/data. Byplacing files you want named to modify, such as slave or DDNS updateable zone files and database / statistics dump files in these directories, named will work normally and no further operator action is required. Files in these directories are automatically assigned the ’named_cache_t’ file context, which SELinux allows named to write."
That's probably why I have updateable zone files in chrooted /var/named/dynamic. Default targeted policy comes with necessary rules for chrooted bind. See
# semanage fcontext -l | grep named_
I have them in /var/named/dynamic
if a host has IPv4 only or IPv6 only this works fine, but when a host has both - DualStack somethimes it works sometimes only one - can be IPv4 or can be IPv6 works; and in /var/log/messages I get something like
May 10 18:51:30 dnssrvr named[2526]: client 192.168.1.2#38618: view wkst: updating zone 'ddns.local/IN': update unsuccessful: WIN7HOST.ddns.local: 'name not in use' prerequisite not satisfied (YXDOMAIN)
for several times;
Which probably means that the name for the host has already been added to dns with an IPv6 address or vice versa. Have a look at https://deepthought.isc.org/article/AA-01091/0/ISC-DHCP-support-for-Standard.... It might be relevant. I don't know. 'ddns-update-style standard' didn't even exist when I fiddled with this.
-
Alice Wonder -
m.roth＠5-cent.us -
Walter H. -
Александр Кириллов