Repository navigation
Issues when doing "Edit Zone File" through webgui #2234
Description
A couple of anomalies found in 15.6.2:
When editing zone file as textfile through webgui and saving then all entries becomes:
Last Used: 0001-01-01 00:00:00 (never)
Last modified will also vanish for all entries that was present when the "edit zone file" was saved in webgui.
IMHO "Last modified" should be set for all entries to datetime as when the "edit zone file" was saved to match as if the entries were changed through the webgui.
When editing zone file as textfile through webgui and saving then "Use Serial Date Scheme" becomes disabled when you later click on the SOA record.
The value "Use SOA Serial Date Scheme" is enabled by default in Settings -> Zone Defaults.
Workaround is that you then must go to SOA record for this zone and re-enable "Use Serial Date Scheme" manually.
This seems to be related to if you in "Edit Zone File" select "Overwrite SOA Serial" - then the option for "User Serial Date Scheme" is lost in the SOA record.
SOA record in webgui and through dig says noc@example.com as "Responsible person".
However when in edit zone file the SOA record is displayed as:
@ 900 IN SOA vyos1 noc 2026101701 900 300 604800 900
Im guessing this is by default (zone is "example.com") but I would prefer to have the contact email fully written out (again unless this is violating RFC?):
@ 900 IN SOA vyos1 noc@example.com 2026101701 900 300 604800 900
Activity
ShreyasZare commentedon Oct 19, 2026
Thanks for the feedback.
Will get this fixed to set the "Last modified" value for all entries. The "Last Used" one is not feasible since the process removes older records before adding the new ones and the last used value is lost with it. This value is not stored too and is reset when server restarts.
The SOA record is not exporting the "Use Serial Date Scheme" parameter currently. Will get it updated to export so that the import call will have the value in comments section to set it back.
The SOA Responsible Person value is email id represented as a domain name and thus supports relative domain names. Thus the
nocyou see in there is a relative domain name such that the origin domain name will be appended to it while parsing. If you wish to use a full email in there then you can specify a FQDN in there likenoc.example.com.where the domain ends with a.char. If the domain name for the email id did not belong to the same origin/zone then it would get exported as a FQDN. This current representation is standard for SOA record.