[BUG] SOA Serial doesn't update when changing zone multiple times

[gaaf]

Hi,

I noticed that the SOA is only increased the first time the button 'Apply Changes' is pressed. In the scenario that one applies a batch of changes, leave the page open where it is and later apply another batch of changes, the SOA isn't updated on the 2nd and later batches. After reloading the entire page, the SOA is updated again, but again only for the first batch of changes.

Might be related to #375, but there the cause wasn't identified and the report was closed without fix. (the workaround in the server is not a fix for the bug in PowerDNS-Admin).

[righter83]

I noticed the same. Sometimes the SOA gets resetted: Before SOA 2020060503 after second change Before SOA 2020060501

I have then to reload the zone and change something again to increase the serial.

[biwhite]

Think I've tracked down how this happens...

If SOA is selected as an editable field, on Settings->Records, then this process makes it happen:

for instance a zone with Serial 2020060901. edit zone, change something, save, apply, change something, save, apply

The serial is bumped correct by PDNS at the first 'apply' to 2020060902, but at the time of the second 'apply', the original SOA serial is still on the page as 2020060901 and the zone is submitted in full, decreasing the SOA serial to what it was before the change, and then the PDNS serial bump happens again. Both times it's increased to 2020060902, so depending how quick the notify/axfr is happening, slaves might have either the first change or both changes.

You can get around it, by adding a 'reload page' in the middle of the process above, so:

edit zone, change something, save, apply, reload page, change something, save, apply works, and you'd end up with serial 2020060903.

Or, not having SOA ticked in the Settings->Records section, which I believe is the default, hence why this might not be seen very much?

Best fix would be for if SOA is an editable record, re-read the SOA record after apply, in effect refreshing the current view of the zone in the editor to make sure whatever serial bump method is taking place is being reflected.

[gaaf]

Best fix would be for if SOA is an editable record, re-read the SOA record after apply, in effect refreshing the current view of the zone in the editor to make sure whatever serial bump method is taking place is being reflected.

IMHO, the page should not show data that is known to be stale, it should re-fetch all records (including but not limited to SOA). This would also fetch records changed outside PowerDN-Admin.

[righter83]

@biwhite Hmm that makes sense. Thanks for your information. I've disabled the SOA record and for me that's ok for now.

Thanks for your suggestion!

[florianbeer]

@ngoduykhanh Could you have a look at this issue?
This has bitten us multiple times now when customers made multiple edits in their zone and afterwards our two slaves had stale data that needed to be refreshed manually using pdns_control retrieve $ZONE

I too have now disabled SOA as an editable field, but I'd very much like to give customers the ability to change this value and this is clearly a bug that should not happen.

I'd be happy to provide any more data that you might need!

[JSN-1]

Thanks for suggestion of disabling SOA as editable.

I too would like the option to allow people to edit SOA manually.

[vsulin]

SOA should be loaded on every apply of domain changes with the record itself. No matter if the record itself is editable or not. Because as it is now, you don't see that the SOA changed on save when its non-editable?

This can also cause problems with multiple people editing the same domain records at the same time. Which is not an issue that occurs often, but also happens.

I suggest that SOA record is either loaded upon apply or never actually saved unless you actually changed the record after loading the data. So even if someone else saves the domain and updates the SOA, your updates might override other records. (Which would require some kind of domain/record locking when someone else is editing it/them. Which is a whole different issue.) This would make it very hard to make your records not update on secondary and tertiary servers which is a huge problem. And makes me consider if we can use this admin at all.

[jbe-dw]

Hello @vsulin

Thank you for the feedback. We use it in my enterprise and mainly because of the terraform provider behavior we chose to disable SOA editing in PDA and configure PowerDNS with automatic SOA creation. We are limited for unique TTL setting, which is fine for our setup.

There is no easy solution for this, and as you pointed out there better be a lock mechanism. I may not recall correctly but I believe that SOA serial is ignored by recent versions of PowerDNS (at least 4.3) if the zone is set to an automatic update. But the problem can occur if two people try to edit the zone simultaneously in the GUI, not only SOA.