Machine friendly alternative to nsupdate

[Tony Finch]

Petr Bena <petr at bena.rocks> wrote:
>
> The problem with this approach is that it's not atomic.

That's the point of the prerequisite section! You can package up the
atomicity checks and updates into one request. You will have to deal with
concurrent update clashes in some way, but that's true for any system that
has serializable updates. (DNS updates are one-at-a-time serialized, not
concurrent and serializable, but concurrency hazards have the same
high-level effect in both cases.)

For an example / discussion from elsewhere ...
https://www.postgresql.org/docs/current/transaction-iso.html#XACT-SERIALIZABLE

Whether it's DNS or SQL, concurrency hazards aren't just about the storage
or the protocol: they are also about the user interface. If your user
prepares and submits an update based on old data, that clashes with a
concurrent update, you need to show them that things have changed under
their feet so that they know something weird is happening. There are cases
where you might be able to retry automatically without causing confusion,
but it needs some thought.

To get atomicity, use the UPDATE prerequisites section to ensure that the
zone actually matches what your user interface was showing the user before
the user prepared the update.

> I am looking for a some alternative to nsupdate, that can achieve the
> same, but more machine friendly, like a "proper DNS library" you talk
> about, is there any such a thing?

The system I work with is mostly perl, so I use Net::DNS which is
generally very good.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North
Channel: Westerly to northwesterly, 4 to 6, occasionally 7 in north. Slight or
moderate, occasionally rough later near Mull of Kintyre. Rain or showers.
Good, occasionally moderate.