It seems that ISPConfig is using either UTC or the realtime clock to construct the DNS SOA value. My master server is running in CDT, but new SOA values are computing as UTC. This is causing warnings with monitoring packages that the SOA is invalid as it is in the future. Obviously not a showstopper, but I'd like to stop getting the alerts. $ timedatectl Local time: Thu 2025-10-02 23:24:38 CDT Universal time: Fri 2025-10-03 04:24:38 UTC RTC time: Fri 2025-10-03 04:24:37 Time zone: America/Chicago (CDT, -0500) System clock synchronized: yes NTP service: n/a RTC in local TZ: no Any suggestions? TIA.
DNS serial numbers are not strictly time-based; they are incremented 32bit integer numbers. So if you use a service that claims a record is invalid due to the serial number, then they should fix that service.
Agreed on the data type. There's no reason for it to be strictly date-based, but it is convention. It leads to one more synapse having to fire when diagnosing an issue to recall that the date may not reflect the last update. The real question was if I was understanding the behavior correctly and if there was a reason that the serial generation is using UTC rather than the system timestamp. I will also follow up with the service to see if they can adjust their rules to be more forgiving, as I like the bulk of their service. They just complain about this for a few hours and only if the DNS record was updated in the window between date rolls. Aside, we've been using ISPConfig for many years and love the product. It's made our lives so much easier and we've had almost no issues whatsoever. Keep up the great work! --Chris
If you like to know in detail how serials are generated in ISPConfig, please take a look at the code. The timezone used by ISPConfig is set in the two config.inc.php files and it defaults to UTC. The only thing a DNS monitoring system should warn about when it comes to the zone serial number is when it detects that the number decreases instead of increases. Everything else, like the serial number being related to a specific date or timestamp or timezone, is pure speculation from that service and not part of the RFC.
