[CentOS] Restarting Named on CentOS-6 gives SE Error

Restarting one of our named services produces this entry in the system
log file:

Oct 12 08:47:45 inet08 setroubleshoot: SELinux is preventing
/usr/sbin/named from search access on the directory . For complete
SELinux messages. run sealert -l 9eabadb9-0e03-4238-bdb8-c5204333a0bf

Checking the selinux incident reference shows this:

# sealert -l 9eabadb9-0e03-4238-bdb8-c5204333a0bf

SELinux is preventing /usr/sbin/named from search access on the
directory .

*****  Plugin catchall (100. confidence) suggests 
***************************

If you believe that named should be allowed search access on the 
directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do allow this access for now by executing:
# grep named /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                unconfined_u:system_r:named_t:s0
Target Context                system_u:object_r:sysctl_vm_t:s0
Target Objects                 [ dir ]
Source                        named
Source Path                   /usr/sbin/named
Port                          <Unknown>
Host                          inet08.hamilton.harte-lyne.ca
Source RPM Packages           bind-9.8.2-0.62.rc1.el6_9.5.x86_64
Target RPM Packages
Policy RPM                    selinux-policy-3.7.19-307el6_9.3.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     inet08.hamilton.harte-lyne.ca
Platform                      Linux inet08.hamilton.harte-lyne.ca
                              2.6.32-696.30.1.el6.x86_64 #1 SMP Tue
May 22
                              03:28:18 UTC 2018 x86_64 x86_64
Alert Count                   16
First Seen                    Tue Aug 18 18:05:47 2015
Last Seen                     Fri Oct 12 08:47:35 2018
Local ID                      9eabadb9-0e03-4238-bdb8-c5204333a0bf

Raw Audit Messages
type=AVC msg=audit(1539348455.165:43003): avc:  denied  { search } for
 pid=31815 comm="named" scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:sysctl_vm_t:s0 tclass=dir


type=AVC msg=audit(1539348455.165:43003): avc:  denied  { read } for 
pid=31815 comm="named" scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:sysctl_vm_t:s0 tclass=file


type=SYSCALL msg=audit(1539348455.165:43003): arch=x86_64 syscall=open
success=yes exit=ECHILD a0=7f3203a41f60 a1=80000 a2=61f a3=26640
items=0 ppid=31813 pid=31815 auid=0 uid=25 gid=25 euid=25 suid=25
fsuid=25 egid=25 sgid=25 fsgid=25 tty=(none) ses=6575 comm=named
exe=/usr/sbin/named subj=unconfined_u:system_r:named_t:s0 key=(null)

Hash: named,named_t,sysctl_vm_t,dir,search

audit2allow

#============= named_t ==============
allow named_t sysctl_vm_t:dir search;
allow named_t sysctl_vm_t:file read;

audit2allow -R

#============= named_t ==============
allow named_t sysctl_vm_t:dir search;
allow named_t sysctl_vm_t:file read;


Is this a bug or an unset boolean?  Or something else?  It appears to
have been present for quite some time and we have no DNS resolver
issues of which we are aware.

-- 
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3