nsupdate and round robin
kcd at daimlerchrysler.com
Wed Jan 3 00:03:19 UTC 2007
Victor Hugo dos Santos wrote:
> 2006/12/14, Mark Andrews <Mark_Andrews at isc.org>:
>>> i need setup dns with option of "round robin" and this is my actual
>>> zone file (only relevant lines):
>>> www 60 IN A 220.127.116.11
>>> www 60 IN A 18.104.22.168
>>> www 60 IN A 22.214.171.124
>>> but, i don't know how delete/update the specific host (www 60 IN A
>>> DINAMIC_IP) and not other www hosts for this zone with round robin
>>> options !!!
>> update delete www.<zone> A <oldaddress>
>> update add www.<zone>. 60 A <newaddress>
> but.. the "oldaddress" is dynamic !!!
> or you know one secure alternative for get the host with dynamic
> "oldaddress" in middle of other hosts/registers ???
I'm not sure what you're saying here. nsupdate doesn't care whether an
address is "dynamic" or not, it treats all of the records it manipulates
as "dynamic" in the sense that they are subject to change. Any given
invocation/instance of nsupdate doesn't inherently know about any other
processes or subsystems that might be trying to update the same data.
If what you're saying is you have a mixture of "static" entries and 1
"dynamic" entry associated with a particular domain name, then the
algorithm I'd follow would be:
1. do a lookup of the name and enumerate all of the addresses
2. identify the "dynamic" one through process of elimination (i.e. it's
the only one not from the "static" list)
3. submit a record-specific (as Mark described above) Dynamic Update of
that record with also a _prerequisite_ that the old "dynamic" record
exists with the value determined from Step #2.
4. If the Dynamic Update fails because the prerequisite is not met,
then presumably this is because the record is being updated by some
other process or subsystem while you are trying to make your update.
Repeat the sequence at Step #1, but you might want to put a limit on the
number of such "restarts" so as not to get in an "infinite" loop.
5. Otherwise, if the update is successful, then you're done.
Alternatively, you might potentially be able to co-ordinate these
disparate processes/subsystems by using some sort of "flag" record to
control update access. But I don't know the capabilities of these other
processes/subsystems in your environment, so I don't know if that's even
More information about the bind-users