NOTE: FortiNAC is now named FortiNAC-F. For post-9.4 articles, see FortiNAC-F. FortiNAC is a zero-trust network access solution that provides users with enhanced visibility into the Internet of Things (IoT) devices on their enterprise networks.
Article Id 242401


This article describes the scenarios where DNS is not working for users in isolation networks.

There are some rare cases in where the DNS service will fail to start.

It can be caused by a misconfiguration on ConfigWizard or after upgrading from older versions.




FortiNAC 9.x.




First, check the service status:


> service named-chroot status
Redirecting to /bin/systemctl status named-chroot.service
● named-chroot.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2022-12-29 16:47:17 CET; 1 day 8h ago
Process: 7566 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t /var/named/chroot -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=1/FAILURE)
Dec 29 16:47:17 systemd[1]: Starting Berkeley Internet Name Domain (DNS)...
Dec 29 16:47:17 bash[7566]: /etc/named.conf:346: zone '': already e...482
Dec 29 16:47:17 systemd[1]: named-chroot.service: control process exited, code=...s=1
Dec 29 16:47:17 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS).
Dec 29 16:47:17 systemd[1]: Unit named-chroot.service entered failed state.
Dec 29 16:47:17 systemd[1]: named-chroot.service failed.
Hint: Some lines were ellipsized, use -l to show in full


The service can be started and stopped from the CLI using the commands below but this should be used only to have more information regarding the service.

It is not recommended to manually change the status of the service and leave it in production.


> service named-chroot stop
> service named-chroot start


The service status change should be done by ConfigWizard only and the new configuration will be applied after the reboot.


In case of service failures follow the steps:

- Update the system:


> yum -y update

- Check the isolation network pool and do not use the root domain ex '' but use a subdomain for ex. ' or' (even though the example is [example:]).




- After reboot check, if the DNS service is running


As an extra step, it is possible to check if user requests are being resolved by checking the logs that can be found on '/var/named/chroot/var/log/named.log' ( is fnac eth1 interface).


29-Dec-2022 17:47:40.965 queries: client @0x7f9ed408b3e0 ( view registration: query: IN A + (


Or by enabling tcpdump using the following command:


> tcpdump -i eth1 port 53
18:11:28.574885 IP > 58677+ A? (25)
18:11:28.575619 IP > 58677 1/1/1 A (83)


Every domain will try (ex. to be resolved to FortiNAC eth1 IP (


As the next step, check if any user has resolved the cheated DNS and has successfully accessed the portal it should leave a trace on this log file:


"/bsc/logs/apache/access_log" - - [29/Dec/2022:18:01:03 +0100] "GET /wpad.dat HTTP/1.1" 200 1884 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36 Edg/106.0.1370.52" - - [29/Dec/2022:18:01:03 +0100] "GET /wpad.dat HTTP/1.1" 200 1884 "-" "WinHttp-Autoproxy-Service/5.1" - - [29/Dec/2022:18:01:03 +0100] "GET /connecttest.txt HTTP/1.1" 302 215 "-" "Microsoft NCSI"


In cases where the DNS service still fails to start, it is possible to try to run DNS on an empty configuration:

- remove the isolation DHCP pool from the Config wizard and reboot.
- DNS service should be running on an empty configuration.

- add again the DHCP pools.

Related article: