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@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.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
