Machine friendly alternative to nsupdate

[Petr Bena]

Hello,

The problem with this approach is that it's not atomic. I can run a 
query to check if record exists before it's created, but there are two 
problems:

* It adds an overhead (one more call of dig to lookup current situation)

* It's not reliable - because it's not atomic

So I was hoping this can be achieved with the nsupdate, I guess the 
prereq statement is what I need to work with, but as I said - parsing 
the current output of nsupdate, especially that header from debug or 
answer section, is just not very easy, and I wouldn't be surprised if 
the format of output changed in future versions (that would break my 
parser), so that's why 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?

On 01/04/2020 14:35, Tony Finch wrote:
> Petr Bena <petr at bena.rocks> wrote:
> I think your approach of using standard protocols (DNS queries and
> updages) to edit zones is very good!
>
>> Is there any alternative to nsupdate, something that can work with XML
>> or JSON payloads or provide output in such machine parseable format?
> I've done a lot with wrapping dig and nsupdate, and it works quite well,
> but I find that when I start getting into parsing swamps (anything more
> complicated than one line per record, or caring about response codes)
> it's better to use a proper DNS library, which should include support for
> UPDATE requests as well as queries.
>
>> For example, typical problem I am facing right now - is that nsupdate
>> silently ignores things that IMHO shouldn't be ignored - for example
>> when someone try to add a record that already exists, or try to add an A
>> record over CNAME, nsupdate silently ignores this,
> This error behaviour is mostly specified by the UPDATE protocol (RFC
> 2136). It's worth reading the RFC becasue (as you have found) some of the
> behaviour is a bit surprising. For instance, adding a record that already
> exists is not an error because multiple copies of the same record
> traditionally get silently de-duplicated in the DNS. (I can't explain the
> lack of error in the CNAME case...)
>
> You might find that a more complicated update strategy gives you better
> error detection, using UPDATE's prerequisite feature. Something roughly
> like,
>
>    * Query the current state of the name you want to edit. In most cases
>      you care about the type being edited and whether or not there's a
>      CNAME involved. You may already have this information for display in
>      your user interface!
>
>    * In your update request, assert in the prerequisite section that the
>      state of the zone matches what you expect, to detect problems with
>      concurrent updates;
>
>    * In the update section, you'll have to explicitly delete existing
>      records and add new ones if a CNAME is involved. If you have all the
>      records of all the types at a name in hand, a simple strategy
>      might be to delete everything at the name and add all the records that
>      you think should be there.
>
> In nsdiff (https://dotat.at/prog/nsdiff/) I'm doing whole-zone updates
> which makes things slightly simpler. I know I have all the records at a
> name so I can handle CNAMEs fairly straightforwardly, and I can just use
> the SOA serial number (a SOA record in the prerequisite section) to detect
> concurrent updates. But it gets slow and eats memory with big zones!
>
> Tony.