Hello all, I noticed that when a user makes a mistake in the DNS configuration, ISPConfig creates a file like: pri.example.com.err and keeps serving the last valid zone file. However, no error message is shown in the ISPConfig web interface — neither to the user nor to the admin. This means the user has no idea something went wrong unless the admin manually checks the .err files or the Bind logs. Would it be possible to integrate named-checkzone validation directly into ISPConfig so that errors are reported in the UI? I believe this would make DNS management more user-friendly and prevent confusion when zones silently fail to apply. Thank you!
ISPConfig runs named-checkzone and reports this also. But the report is not shown in realtime as the zone is created up to 1 minute after the user added it.
Thank you till, I understand that ISPConfig runs `named-checkzone`. However, I'm having difficulty locating the report. After I added a problem record and wait for a minute, nothing is shown in the panel. Could you please clarify where I can find the report? Or I need to check .err file by SSH? Thank you for your assistance!
Yes, I have upgraded ISPConfig to version 3.3.0p2. I've recorded the steps to replicate the issue. Please take a look here:
Thank you for your reply. I understand that in theory a report might be sent to the admin's email address, but in our case no such mail exists. We never configured an email address for the ISPConfig admin, and I also monitor the server's mail log, there was no email sent out when a .err file was created. Even if an email were sent, it still wouldn't solve the main issue: the user does not see any error in the ISPConfig interface and assumes their DNS change was applied successfully. In reality, the change silently fails and ISPConfig creates a .err file. From a usability perspective, this is confusing for users and creates unnecessary support load for admins. It would be much more effective if ISPConfig could display the error message directly in the UI. That way they can immediately see what went wrong and correct it, instead of relying on the admin to investigate logs or email reports that may not even be sent.
