Hi Harald,

is not probably broken for years. I think it is broken for about 4 days. I broke it by backporting commit [1] in minor version. Yes, I admit it was not tested properly in chroot environment.

If you could find a time to write an automated test, I would appreciate pull request. I can see it would find the issue much sooner that way.

1. https://src.fedoraproject.org/rpms/bind/c/6e9104cae5059bffde95f6dac831b0d57720d430?branch=master

bind-9.11.4-9.P2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f22b937f52

bind-9.11.4-9.P2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a54e46032f

bind-9.11.4-9.P2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-a54e46032f

bind-9.11.4-9.P2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f22b937f52

bind-9.11.4-10.P2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f22b937f52

bind-9.11.4-10.P2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a54e46032f

chroot still looks fishy but at least bind-32:9.11.4-10.P2.fc28.x86_64 continues to work

[root@srv-rhsoft:~]$ ls /var/named/chroot/dev/
insgesamt 0
crw-r--r-- 1 root named 1, 3 2009-08-21 15:03 null
crw-r--r-- 1 root named 1, 8 2009-08-21 15:03 random
crw-r--r-- 1 root named 1, 5 2009-08-21 15:03 zero

[root@srv-rhsoft:~]$ systemctl status named
● named.service - DNS Server
   Loaded: loaded (/etc/systemd/system/named.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2018-09-27 13:25:18 CEST; 36s ago
  Process: 953822 ExecStopPost=/usr/libexec/setup-named-chroot.sh /var/named/chroot off /etc/named-chroot.files (code=exited, status=0/SUCCESS)
  Process: 953821 ExecStop=/usr/bin/kill -TERM $MAINPID (code=exited, status=0/SUCCESS)
  Process: 953902 ExecStartPre=/usr/sbin/named-checkconf -t /var/named/chroot -z /etc/named.conf (code=exited, status=0/SUCCESS)
  Process: 953863 ExecStartPre=/usr/libexec/setup-named-chroot.sh /var/named/chroot on /etc/named-chroot.files (code=exited, status=0/SUCCESS)
 Main PID: 953903 (named)
    Tasks: 11 (limit: 512)
   Memory: 75.2M
   CGroup: /system.slice/named.service
           └─953903 /usr/sbin/named -4 -f -u named -t /var/named/chroot

Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface lo, 127.0.0.1#53
Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface vpn-server, 192.168.11.1#53
Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface vmnet8, 192.168.196.2#53
Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface br-wan, 62.178.103.85#53
Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface br-guest, 192.168.10.1#53
Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface br-lan, 192.168.2.2#53
Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface vpn-client, 10.0.0.241#53
Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: generating session key for dynamic DNS
Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: sizing zone task pool based on 16 zones
Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: set up managed keys zone for view _default, file 'managed-keys.bind'

bind-9.11.4-10.P2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-a54e46032f

bind-9.11.4-10.P2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f22b937f52

The -10 release of the package appears to be still broken on F28. It gives SELinux denials and chrooted named refuses to start. Specifically:

type=AVC msg=audit(1538083144.528:216): avc:  denied  { read } for  pid=1762 comm="named" name="urandom" dev="dm-3" ino=1183207 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=chr_file permissive=1
type=AVC msg=audit(1538083144.528:217): avc:  denied  { open } for  pid=1762 comm="named" path="/dev/urandom" dev="dm-3" ino=1183207 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=chr_file permissive=1
type=AVC msg=audit(1538083144.528:218): avc:  denied  { getattr } for  pid=1762 comm="named" path="/dev/urandom" dev="dm-3" ino=1183207 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=chr_file permissive=1

Even after running restorecon, This is what I see in /var/named/chroot/dev:

[root@beauty dev]# ls -lZ
total 0
crw-rw-r--. 1 root named unconfined_u:object_r:null_device_t:s0   1, 3 Dec  4  2013 null
crw-rw-r--. 1 root named unconfined_u:object_r:random_device_t:s0 1, 8 Dec  4  2013 random
crw-rw-r--. 1 root named system_u:object_r:named_conf_t:s0        1, 9 Sep 28 07:07 urandom
crw-rw-r--. 1 root named unconfined_u:object_r:zero_device_t:s0   1, 5 Dec  4  2013 zero

I'm guessing that named_conf_t should probably be random_device_t, right?

Sorry, actually probably urandom_device_t. In fact, when I set it like this, it starts.

(In reply to Bojan Smojver from comment #11)
> [root@beauty dev]# ls -lZ
> total 0
> crw-rw-r--. 1 root named unconfined_u:object_r:null_device_t:s0   1, 3 Dec 
> 4  2013 null
> crw-rw-r--. 1 root named unconfined_u:object_r:random_device_t:s0 1, 8 Dec 
> 4  2013 random
> crw-rw-r--. 1 root named system_u:object_r:named_conf_t:s0        1, 9 Sep
> 28 07:07 urandom
> crw-rw-r--. 1 root named unconfined_u:object_r:zero_device_t:s0   1, 5 Dec 
> 4  2013 zero
> 
> I'm guessing that named_conf_t should probably be random_device_t, right?

Yes, it should. I completely forgot it requires modification of selinux-policy. I tested in only in my Fedora 28 container where restorecon does not work.

bind-9.11.4-10.P2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Just it occured to me when testing on f28:
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007fd1c60e75b9 in __GI_abort () at abort.c:79
#2  0x000055d1d3a7b705 in library_fatal_error (file=<optimized out>, line=294, 
    format=0x7fd1ca2f83f0 "OpenSSL pseudorandom number generator cannot be initialized (see the `PRNG not seeded' message in the OpenSSL FAQ)", args=0x7ffd751aa230) at ../../../bin/named-sdb/main.c:277
#3  0x00007fd1c8efa106 in isc_error_fatal () from /lib64/libisc.so.169
#4  0x00007fd1ca2a83a6 in dst.openssl_init () from /lib64/libdns.so.1102
#5  0x00007fd1ca2ae997 in dst_lib_init2 () from /lib64/libdns.so.1102
#6  0x000055d1d3ab4249 in ns_server_create (mctx=0x55d1d5ba26f0, serverp=0x55d1d3d30d70 <ns_g_server>)
    at ../../../bin/named-sdb/server.c:8898
#7  0x000055d1d3a7c931 in setup () at ../../../bin/named-sdb/main.c:1342
#8  main (argc=<optimized out>, argv=<optimized out>) at ../../../bin/named-sdb/main.c:1554

It is kind tricky, because it would pass when there is enough entropy on that machine. If there is not, OpenSSL wants to get some entropy from /dev/urandom.

Until selinux-policy is adjusted properly, please use these commands:

semanage fcontext -a -e /dev/urandom /var/named/chroot/dev/urandom
semanage fcontext -a -e /dev/urandom /var/named/chroot_sdb/dev/urandom
restorecon /var/named/chroot*/dev/urandom

It should work after it fine.

bind-9.11.4-10.P2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

bind-9.11.4-10.P2.fc28.x86_64 - at least it satrts now somehow most of the time

this is still a joke
[root@srv-rhsoft:~]$ ls /var/named/chroot/dev/
insgesamt 0
crw-r--r-- 1 root named 1, 3 2009-08-21 15:03 null
crw-r--r-- 1 root named 1, 8 2009-08-21 15:03 random
crw-r--r-- 1 root named 1, 5 2009-08-21 15:03 zero

but yesterday i still had the smae idiotic message but thank to "Restart=laways" it recovered after boot, maybe ordering after "rngd.service haveged.service" will prevent this now but the whole stuff is fishy


[root@srv-rhsoft:~]$ cat /etc/systemd/system/named.service
[Unit]
Description=DNS Server
After=network-online.target network-wan-bridge.service network-wlan-bridge.service openvpn.service rngd.service haveged.service
Requires=network-online.target

[Service]
Type=simple
ExecStartPre=/usr/libexec/setup-named-chroot.sh /var/named/chroot on /etc/named-chroot.files
ExecStartPre=/usr/sbin/named-checkconf -t /var/named/chroot -z /etc/named.conf
ExecStart=/usr/sbin/named -4 -f -u named -t /var/named/chroot
ExecReload=/usr/bin/kill -HUP $MAINPID
ExecStop=/usr/bin/kill -TERM $MAINPID
ExecStopPost=/usr/libexec/setup-named-chroot.sh /var/named/chroot off /etc/named-chroot.files
TimeoutSec=25
Restart=always
RestartSec=1

CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID CAP_SYS_ADMIN CAP_DAC_READ_SEARCH CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW CAP_IPC_LOCK CAP_SYS_CHROOT
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateDevices=yes
PrivateTmp=yes
ProtectControlGroups=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_LOCAL AF_UNIX AF_NETLINK
RestrictRealtime=yes
SystemCallArchitectures=x86-64
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @obsolete @raw-io @reboot @swap acct modify_ldt add_key adjtimex clock_adjtime delete_module fanotify_init finit_module get_mempolicy init_module io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp kexec_load keyctl lookup_dcookie migrate_pages move_pages open_by_handle_at perf_event_open process_vm_readv process_vm_writev ptrace remap_file_pages request_key set_mempolicy swapoff swapon uselib vmsplice

ReadOnlyPaths=/etc
ReadOnlyPaths=/usr
ReadOnlyPaths=/var/lib

InaccessiblePaths=-/root
InaccessiblePaths=-/media
InaccessiblePaths=-/boot
InaccessiblePaths=-/home
InaccessiblePaths=-/run/console
InaccessiblePaths=-/run/dbus
InaccessiblePaths=-/run/lock
InaccessiblePaths=-/run/mount
InaccessiblePaths=-/run/systemd/generator
InaccessiblePaths=-/run/systemd/system
InaccessiblePaths=-/run/systemd/users
InaccessiblePaths=-/run/udev
InaccessiblePaths=-/run/user
InaccessiblePaths=-/var/lib/dbus
InaccessiblePaths=-/var/lib/rpm
InaccessiblePaths=-/var/lib/systemd
InaccessiblePaths=-/var/lib/dnf
InaccessiblePaths=-/var/spool

[Install]
WantedBy=multi-user.target

This was working fine for me until bind-chroot-32:9.11.4-5.P1.fc28, then broke when updated to bind-chroot-32:9.11.4-10.P2.fc28.   Logs from the service start:


Oct 06 10:12:02 hostname named[6552]: starting BIND 9.11.4-P2-RedHat-9.11.4-10.P2.fc28 (Extended Support Version) <id:>
Oct 06 10:12:02 hostname named[6552]: running on Linux x86_64 4.18.11-200.fc28.x86_64 #1 SMP Sun Sep 30 15:31:40 UTC 2> 
Oct 06 10:12:02 hostname named[6552]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '->
Oct 06 10:12:02 hostname named[6552]: running as: named -u named -c /etc/named.conf -t /var/named/chroot
Oct 06 10:12:02 hostname named[6552]: compiled by GCC 8.1.1 20180712 (Red Hat 8.1.1-5)
Oct 06 10:12:02 hostname named[6552]: compiled with OpenSSL version: OpenSSL 1.1.0i  14 Aug 2018
Oct 06 10:12:02 hostname named[6552]: linked to OpenSSL version: OpenSSL 1.1.0i-fips  14 Aug 2018
Oct 06 10:12:02 hostname named[6552]: compiled with libxml2 version: 2.9.8
Oct 06 10:12:02 hostname named[6552]: linked to libxml2 version: 20908
Oct 06 10:12:02 hostname named[6552]: compiled with zlib version: 1.2.11 
Oct 06 10:12:02 hostname named[6552]: linked to zlib version: 1.2.11 
Oct 06 10:12:02 hostname named[6552]: threads support is enabled
Oct 06 10:12:02 hostname named[6552]: ----------------------------------------------------
Oct 06 10:12:02 hostname named[6552]: BIND 9 is maintained by Internet Systems Consortium,
Oct 06 10:12:02 hostname named[6552]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
Oct 06 10:12:02 hostname named[6552]: corporation.  Support and training for BIND 9 are
Oct 06 10:12:02 hostname named[6552]: available at https://www.isc.org/support
Oct 06 10:12:02 hostname named[6552]: ----------------------------------------------------
Oct 06 10:12:02 hostname named[6552]: adjusted limit on open files from 4096 to 1048576
Oct 06 10:12:02 hostname named[6552]: found 2 CPUs, using 2 worker threads
Oct 06 10:12:02 hostname named[6552]: using 1 UDP listener per interface
Oct 06 10:12:02 hostname named[6552]: using up to 21000 sockets
Oct 06 10:12:02 hostname named[6552]: ../../../lib/dns/openssl_link.c:294: fatal error: 
Oct 06 10:12:02 hostname audit[6552]: ANOM_ABEND auid=4294967295 uid=25 gid=25 ses=4294967295 pid=6552 comm="named" ex>
Oct 06 10:12:02 hostname named[6552]: OpenSSL pseudorandom number generator cannot be initialized (see the `PRNG not s> 
Oct 06 10:12:02 hostname named[6552]: exiting (due to fatal error in library)
Oct 06 10:12:02 hostname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump>
Oct 06 10:12:02 hostname systemd[1]: Started Process Core Dump (PID 6557/UID 0).
Oct 06 10:12:03 hostname systemd[1]: named-chroot.service: Control process exited, code=exited status=1
Oct 06 10:12:03 hostname systemd[1]: named-chroot.service: Failed with result 'exit-code'.
Oct 06 10:12:03 hostname systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). 
Oct 06 10:12:03 hostname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=named-chroot com>
Oct 06 10:12:03 hostname systemd[1]: Stopping Set-up/destroy chroot environment for named (DNS)...
Oct 06 10:12:03 hostname systemd-coredump[6558]: Process 6552 (named) of user 25 dumped core.
                                                        
                                                        Stack trace of thread 6552:
                                                        #0  0x00007ff1e747eeab raise (libc.so.6)
                                                        #1  0x00007ff1e74695b9 abort (libc.so.6)
                                                        #2  0x000055fd0b8a6605 library_fatal_error.cold.4 (named)
                                                        #3  0x00007ff1e9053106 isc_error_fatal (libisc.so.169)
                                                        #4  0x00007ff1ea4013a6 dst__openssl_init (libdns.so.1102)
                                                        #5  0x00007ff1ea407997 dst_lib_init2 (libdns.so.1102)
                                                        #6  0x000055fd0b8def59 ns_server_create (named)
                                                        #7  0x000055fd0b8a76bd main (named)
                                                        #8  0x00007ff1e746b11b __libc_start_main (libc.so.6)
                                                        #9  0x000055fd0b8a801a _start (named)
                                                        
                                                        Stack trace of thread 6556:
                                                        #0  0x00007ff1e754218f epoll_wait (libc.so.6)
                                                        #1  0x00007ff1e908b06c watcher (libisc.so.169)
                                                        #2  0x00007ff1e8787594 start_thread (libpthread.so.0)
                                                        #3  0x00007ff1e7541e6f __clone (libc.so.6)
                                                        
                                                        Stack trace of thread 6554:
                                                        #0  0x00007ff1e878d51c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.>
                                                        #1  0x00007ff1e90736e5 run (libisc.so.169)
                                                        #2  0x00007ff1e8787594 start_thread (libpthread.so.0)
                                                        #3  0x00007ff1e7541e6f __clone (libc.so.6)
                                                        
                                                        Stack trace of thread 6553:
                                                        #0  0x00007ff1e878d51c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.>
                                                        #1  0x00007ff1e90736e5 run (libisc.so.169)
                                                        #2  0x00007ff1e8787594 start_thread (libpthread.so.0)
                                                        #3  0x00007ff1e7541e6f __clone (libc.so.6)
                                                        
                                                        Stack trace of thread 6555:
                                                        #0  0x00007ff1e878d51c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.>
                                                        #1  0x00007ff1e907a7a8 run (libisc.so.169)
                                                        #2  0x00007ff1e8787594 start_thread (libpthread.so.0)
                                                        #3  0x00007ff1e7541e6f __clone (libc.so.6)



Downgraded back to the packages from https://koji.fedoraproject.org/koji/buildinfo?buildID=1135047 works again.

(In reply to Lucas Maneos from comment #19)
> This was working fine for me until bind-chroot-32:9.11.4-5.P1.fc28, then
> broke when updated to bind-chroot-32:9.11.4-10.P2.fc28.   Logs from the
> service start:
> 
> 
> Oct 06 10:12:02 hostname named[6552]: starting BIND
> 9.11.4-P2-RedHat-9.11.4-10.P2.fc28 (Extended Support Version) <id:>
> Oct 06 10:12:02 hostname named[6552]: running on Linux x86_64
> 4.18.11-200.fc28.x86_64 #1 SMP Sun Sep 30 15:31:40 UTC 2> 
> Oct 06 10:12:02 hostname named[6552]: built with
> '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '->
> Oct 06 10:12:02 hostname named[6552]: running as: named -u named -c
> /etc/named.conf -t /var/named/chroot
> Oct 06 10:12:02 hostname named[6552]: compiled by GCC 8.1.1 20180712 (Red
> Hat 8.1.1-5)
> Oct 06 10:12:02 hostname named[6552]: compiled with OpenSSL version: OpenSSL
> 1.1.0i  14 Aug 2018
> Oct 06 10:12:02 hostname named[6552]: linked to OpenSSL version: OpenSSL
> 1.1.0i-fips  14 Aug 2018
> Oct 06 10:12:02 hostname named[6552]: compiled with libxml2 version: 2.9.8
> Oct 06 10:12:02 hostname named[6552]: linked to libxml2 version: 20908
> Oct 06 10:12:02 hostname named[6552]: compiled with zlib version: 1.2.11 
> Oct 06 10:12:02 hostname named[6552]: linked to zlib version: 1.2.11 
> Oct 06 10:12:02 hostname named[6552]: threads support is enabled
> Oct 06 10:12:02 hostname named[6552]:
> ----------------------------------------------------
> Oct 06 10:12:02 hostname named[6552]: BIND 9 is maintained by Internet
> Systems Consortium,
> Oct 06 10:12:02 hostname named[6552]: Inc. (ISC), a non-profit 501(c)(3)
> public-benefit
> Oct 06 10:12:02 hostname named[6552]: corporation.  Support and training for
> BIND 9 are
> Oct 06 10:12:02 hostname named[6552]: available at
> https://www.isc.org/support
> Oct 06 10:12:02 hostname named[6552]:
> ----------------------------------------------------
> Oct 06 10:12:02 hostname named[6552]: adjusted limit on open files from 4096
> to 1048576
> Oct 06 10:12:02 hostname named[6552]: found 2 CPUs, using 2 worker threads
> Oct 06 10:12:02 hostname named[6552]: using 1 UDP listener per interface
> Oct 06 10:12:02 hostname named[6552]: using up to 21000 sockets
> Oct 06 10:12:02 hostname named[6552]: ../../../lib/dns/openssl_link.c:294:
> fatal error: 
> Oct 06 10:12:02 hostname audit[6552]: ANOM_ABEND auid=4294967295 uid=25
> gid=25 ses=4294967295 pid=6552 comm="named" ex>
> Oct 06 10:12:02 hostname named[6552]: OpenSSL pseudorandom number generator
> cannot be initialized (see the `PRNG not s> 
> Oct 06 10:12:02 hostname named[6552]: exiting (due to fatal error in library)
> Oct 06 10:12:02 hostname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
> ses=4294967295 msg='unit=systemd-coredump>
> Oct 06 10:12:02 hostname systemd[1]: Started Process Core Dump (PID 6557/UID
> 0).
> Oct 06 10:12:03 hostname systemd[1]: named-chroot.service: Control process
> exited, code=exited status=1
> Oct 06 10:12:03 hostname systemd[1]: named-chroot.service: Failed with
> result 'exit-code'.
> Oct 06 10:12:03 hostname systemd[1]: Failed to start Berkeley Internet Name
> Domain (DNS). 
> Oct 06 10:12:03 hostname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
> ses=4294967295 msg='unit=named-chroot com>
> Oct 06 10:12:03 hostname systemd[1]: Stopping Set-up/destroy chroot
> environment for named (DNS)...
> Oct 06 10:12:03 hostname systemd-coredump[6558]: Process 6552 (named) of
> user 25 dumped core.
>                                                         
>                                                         Stack trace of
> thread 6552:
>                                                         #0 
> 0x00007ff1e747eeab raise (libc.so.6)
>                                                         #1 
> 0x00007ff1e74695b9 abort (libc.so.6)
>                                                         #2 
> 0x000055fd0b8a6605 library_fatal_error.cold.4 (named)
>                                                         #3 
> 0x00007ff1e9053106 isc_error_fatal (libisc.so.169)
>                                                         #4 
> 0x00007ff1ea4013a6 dst__openssl_init (libdns.so.1102)
>                                                         #5 
> 0x00007ff1ea407997 dst_lib_init2 (libdns.so.1102)
>                                                         #6 
> 0x000055fd0b8def59 ns_server_create (named)
>                                                         #7 
> 0x000055fd0b8a76bd main (named)
>                                                         #8 
> 0x00007ff1e746b11b __libc_start_main (libc.so.6)
>                                                         #9 
> 0x000055fd0b8a801a _start (named)
>                                                         

Have you applied selinux steps mentioned in comment #16? It should fix the issue in chroot.

(In reply to Harald Reindl from comment #18)
> bind-9.11.4-10.P2.fc28.x86_64 - at least it satrts now somehow most of the
> time
> 
> this is still a joke
> [root@srv-rhsoft:~]$ ls /var/named/chroot/dev/
> insgesamt 0
> crw-r--r-- 1 root named 1, 3 2009-08-21 15:03 null
> crw-r--r-- 1 root named 1, 8 2009-08-21 15:03 random
> crw-r--r-- 1 root named 1, 5 2009-08-21 15:03 zero
> 
> but yesterday i still had the smae idiotic message but thank to
> "Restart=laways" it recovered after boot, maybe ordering after "rngd.service
> haveged.service" will prevent this now but the whole stuff is fishy
> 
> 
It requires access to /dev/urandom to gather entropy. rngd should not hurt, but should not be required to even start. Did you restart named-chroot after installing bind-chroot-9.11.4-10.P2.fc28.x86_64 and importing custom policy from comment #16?

looks like the chroot-script needs a ton of capabilities and has a bad error handling so that you can find the messages somwhere long before named itelf will fail, CapabilityBoundingSet removed for now

(In reply to Harald Reindl from comment #22)
> looks like the chroot-script needs a ton of capabilities and has a bad error
> handling so that you can find the messages somwhere long before named itelf
> will fail, CapabilityBoundingSet removed for now

Capabilities are required when preparing chroot. Devices are now created on demand before start. That is main reason why it has its own named-chroot-setup.service. It requires capability for mount, mknod create and more. Just named itself should be restricted.

(In reply to Petr Menšík from comment #20)
> Have you applied selinux steps mentioned in comment #16? It should fix the
> issue in chroot.

Yes (although I don't have a /var/named/chroot_sdb), and even tried with SELINUX disabled, same issue.

Running it under strace shows EACCESS on trying to open /dev/{,u}random:

# sestatus 
SELinux status:                 disabled
# strace -f -e trace=file /usr/sbin/named -u named -t /var/named/chroot
[...]
chroot("/var/named/chroot")             = 0
chdir("/")                              = 0
strace: Process 14668 attached
strace: Process 14669 attached
[pid 14668] openat(AT_FDCWD, "/proc/self/task/14669/comm", O_RDWR) = -1 ENOENT (No such file or directory)
strace: Process 14670 attached
[pid 14668] openat(AT_FDCWD, "/proc/self/task/14670/comm", O_RDWR) = -1 ENOENT (No such file or directory)
strace: Process 14671 attached
[pid 14668] openat(AT_FDCWD, "/proc/self/task/14671/comm", O_RDWR) = -1 ENOENT (No such file or directory)
strace: Process 14672 attached
[pid 14668] openat(AT_FDCWD, "/proc/self/task/14672/comm", O_RDWR) = -1 ENOENT (No such file or directory)
[pid 14668] openat(AT_FDCWD, "/etc/pki/tls/openssl.cnf", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 14668] openat(AT_FDCWD, "/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = -1 EACCES (Permission denied)
[pid 14668] openat(AT_FDCWD, "/dev/random", O_RDONLY|O_NOCTTY|O_NONBLOCK) = -1 EACCES (Permission denied)
[pid 14668] openat(AT_FDCWD, "/dev/srandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
[pid 14668] --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=14668, si_uid=25} ---
[pid 14669] +++ killed by SIGABRT (core dumped) +++
[pid 14672] +++ killed by SIGABRT (core dumped) +++
[pid 14671] +++ killed by SIGABRT (core dumped) +++
[pid 14670] +++ killed by SIGABRT (core dumped) +++
[pid 14668] +++ killed by SIGABRT (core dumped) +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_DUMPED, si_pid=14668, si_uid=25, si_status=SIGABRT, si_utime=0, si_stime=11} ---
+++ exited with 1 +++

The chroot dev directory contents are:

# ls -la /var/named/chroot/dev
total 8
drwxr-x---  2 root named 4096 Oct 28 07:40 .
drwxr-x---. 7 root named 4096 Sep 26 21:16 ..
crw-rw-r--  1 root named 1, 3 Nov 23  2013 null
crw-rw-r--  1 root named 1, 8 Nov 23  2013 random
crw-rw-r--  1 root named 1, 9 Oct 28 07:40 urandom
crw-rw-r--  1 root named 1, 5 Nov 23  2013 zero

(In reply to Lucas Maneos from comment #24)
> Running it under strace shows EACCESS on trying to open /dev/{,u}random:

It turns out that this was due to /var being mounted with the nodev option.   Earlier versions worked because they were falling back to the pre-chroot /dev/random:

Oct 28 08:26:02 hostname named[27545]: could not open entropy source /dev/random: permission denied
Oct 28 08:26:02 hostname named[27545]: using pre-chroot entropy source /dev/random

Sorry for the noise.

Okay, original cause was resolved by updated selinux-policy package, no other modification should be necessary. Required selinux-policy is 3.14.2-39.

I think it could be possible to work around that by:

touch /var/named/chroot/dev/urandom

then adding /dev/urandom to /etc/named-chroot.files

This way original device is mounted, I think it should also work with nodev mount option to /var. It would work for any /dev file required.

I will think whether this is good idea to have by default. I would not have to worry about setting correct selinux context, rights at the cost of more bind mounts. Empty files would have to be prepared for devices. It would rpm -V bind-chroot make fail verification either when running or when stopped, because type of file would be always different.

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.