10 thoughts on - CentOS 6 As DNS-Server

• # cat /etc/rc.d/init.d/named
  … ROOTDIR_MOUNT=’/etc/named /etc/pki/dnssec-keys /var/named
  /etc/named.conf
  /etc/named.dnssec.keys /etc/named.rfc1912.zones /etc/rndc.conf
  /etc/rndc.key
  /usr/lib64/bind /usr/lib/bind /etc/named.iscdlv.key /etc/named.root.key’

  mount_chroot_conf()
  …

  # rpm -qf /etc/named.root.key /etc/named.iscdlv.key bind-9.8.2-0.37.rc1.el6_7.7.x86_64
  bind-9.8.2-0.37.rc1.el6_7.7.x86_64

• 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.

• are you using DDNS in DualStack (IPv4 and IPv6 together) or do you have only DHCP or DHCPv6 and not both?

  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:
  
  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

• 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.

• IPv4 only.

  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_

• 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;
  I have them in /var/named/dynamic

• 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-DDNS.html. It might be relevant. I don’t know. ‘ddns-update-style standard’ didn’t even exist when I fiddled with this.

• 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

• AFAIK rndc freeze/thaw will do that but you may try other rndc commands too.