I'm migrating the primary BIND DNS configuration from an existing CentOS 7 server to a new Oracle Linux 9 server. I copied the named configuration and zone data, including /etc/named.conf and /var/named, and the new server is intended to use the same IP address after the old one is shut down. When I start named on Oracle Linux 9, it logs messages such as "validating arpa/DS: no valid signature found" and "validating com/DS: no valid signature found." The service does start, but I'm not sure whether these are harmless warnings or signs of a broken configuration. The old configuration did not contain the default dnssec-validation yes; setting. What is likely causing these messages, and what is the safest way to migrate the configuration?
3 Answers
The newer BIND version included with Oracle Linux 9 may handle DNSSEC validation differently from the CentOS 7 version. First determine whether these are startup failures or validation warnings by checking named’s service status and the system journal. Compare the distribution’s default named.conf with the migrated one, especially the DNSSEC and recursion settings. Don’t downgrade immediately; update the configuration for the newer BIND release and verify it with named-checkconf and named-checkzone.
Avoid treating the old named.conf as a drop-in file for the new system. BIND versions and operating-system packaging can change available options, file locations, permissions, and default behavior. Start with the Oracle Linux 9 configuration, then bring over the relevant options and zones in sections. Check ownership and labeling of the zone files as well, and test each change before restarting the service.
If this server hosts authoritative zones, a safer migration is to run the new server as a secondary first and transfer the zones from the current primary. Once the data and responses have been tested, change the roles or update the delegation as appropriate. This avoids a rushed cutover and gives you time to resolve DNSSEC configuration issues. Make sure the old server is fully stopped before assigning its IP address to the replacement, since having both systems active with the same address can cause intermittent failures.
The old server is shut down during testing, so there should not be an IP conflict. The hosted zone is authoritative, so using a temporary primary/secondary setup may be a safer migration path.
The service does start, but it logs the DNSSEC messages. The old configuration did not include dnssec-validation yes;, so I’ll compare it with the new defaults and validate the configuration before considering any version change.